Re: [PATCH v4 05/20] backlight: improve backlight_device documentation
On 7/3/20, 2:46 PM, Sam Ravnborg wrote: > > Improve the documentation for backlight_device and > adapt it to kernel-doc style. > > The updated documentation is more strict on how locking is used. > With the update neither update_lock nor ops_lock may be used > outside the backlight core. > This restriction was introduced to keep the locking simple > by keeping it in the core. > It was verified that this documents the current state by renaming > update_lock => bl_update_lock and ops_lock => bl_ops_lock. > The rename did not reveal any uses outside the backlight core. > The rename is NOT part of this patch. > > v3: > - Update changelog to explain locking details (Daniel) > > v2: > - Add short intro to all fields (Daniel) > - Updated description of update_lock (Daniel) > > Signed-off-by: Sam Ravnborg > Reviewed-by: Emil Velikov > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han It looks good! Reviewed-by: Jingoo Han For the rebase, if you don't know which branch of maintainer's git can be used, linux-next tree [1] is useful. The linux-next git collects all next branches from other maintainers' git every day. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ Thank you. Best regards, Jingoo Han > --- > include/linux/backlight.h | 72 ++- > 1 file changed, 49 insertions(+), 23 deletions(-) . ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: Accept 'legacy' format modifiers
Did you just cherry-pick my change, or were you running the latest drm-next or drm-fixes code? There do appear to be various MM-related fixes that may be related to this in drm-fixes when I scroll down the log looking for nouveau stuff. Shot in the dark, but might be worth trying with Dave's tree if you weren't already. I was testing with drm-fixes-2020-07-17-1 from here: git://anongit.freedesktop.org/drm/drm Thanks, -James On 7/17/20 8:13 PM, James Jones wrote: This doesn't look related. -James On 7/17/20 2:30 PM, Kirill A. Shutemov wrote: On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote: Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Tested with Xorg 1.20 modesetting driver, weston@c46c70dac84a4b3030cd05b380f9f410536690fc, gnome & KDE wayland desktops from Ubuntu 18.04, and sway 1.5 Signed-off-by: James Jones I tried and it crashes. Not sure if it's related. [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:vblank_disable_fn] disabling vblank on crtc 0 [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_CPU_PREP [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF BUG: unable to handle page fault for address: 059c #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] PREEMPT SMP PTI CPU: 13 PID: 3351 Comm: alacritty Tainted: G I 5.8.0-rc5-00191-g086f86c033f9 #53 Hardware name: Gigabyte Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3 Pro-CF, BIOS F5d 11/28/2019 RIP: 0010:kmem_cache_alloc_trace (/home/kas/linux/torvalds/mm/slub.c:272 /home/kas/linux/torvalds/mm/slub.c:278 /home/kas/linux/torvalds/mm/slub.c:292 /home/kas/linux/torvalds/mm/slub.c:2791 /home/kas/linux/torvalds/mm/slub.c:2832 /home/kas/linux/torvalds/mm/slub.c:2849) Code: 8b 51 08 48 89 c8 65 48 03 05 d4 0e ca 70 48 8b 70 08 48 39 f2 75 e7 4c 8b 38 4d 85 ff 0f 84 8f 01 00 00 8b 45 20 48 8b 7d 00 <49> 8b 1c 07 40 f6 c7 0f 0f 85 95 01 00 00 48 8d 8a 80 00 00 00 4c All code 0: 8b 51 08 mov 0x8(%rcx),%edx 3: 48 89 c8 mov %rcx,%rax 6: 65 48 03 05 d4 0e ca add %gs:0x70ca0ed4(%rip),%rax # 0x70ca0ee2 d: 70 e: 48 8b 70 08 mov 0x8(%rax),%rsi 12: 48 39 f2 cmp %rsi,%rdx 15: 75 e7 jne 0xfffe 17: 4c 8b 38 mov (%rax),%r15 1a: 4d 85 ff test %r15,%r15 1d: 0f 84 8f 01 00 00 je 0x1b2 23: 8b 45 20 mov 0x20(%rbp),%eax 26: 48 8b 7d 00 mov 0x0(%rbp),%rdi 2a:* 49 8b 1c 07 mov (%r15,%rax,1),%rbx <-- trapping instruction 2e: 40 f6 c7 0f test $0xf,%dil 32: 0f 85 95 01 00 00 jne 0x1cd 38: 48 8d 8a 80 00 00 00 lea 0x80(%rdx),%rcx 3f: 4c rex.WR Code starting with the faulting instruction === 0: 49 8b 1c 07 mov (%r15,%rax,1),%rbx 4: 40 f6 c7 0f test $0xf,%dil 8: 0f 85 95 01 00 00 jne 0x1a3 e: 48 8d 8a 80 00 00 00 lea 0x80(%rdx),%rcx 15: 4c rex.WR RSP: 0018:a8a381bcfba0 EFLAGS: 00010206 RAX: 0030 RBX: 9c0b15e05e00 RCX: 0003fe50 RDX: fc8d RSI: fc8d RDI: 0003fe50 RBP: 9c0b18407840 R08: R09: 0001 R10: 9c0b06c28000 R11: 0001 R12: 0dc0 [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, DRM_IOCTL_CRTC_GET_SEQUENCE R13: 0060 R14: 8fa35a47 R15: 056c FS: 7fbe7a8e3900() GS:9c0b1f88() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 059c CR3: 00103c7fe004 CR4: 003606e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: nouveau_fence_new (/home/kas/linux/torvalds/include/linux/slab.h:555 /home/kas/linux/torvalds/include/linux/slab.h:669 /home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_fence.c:423) [drm:drm_vblank_enable] enabling vblank on crtc 0, ret: 0 nouveau_gem_ioctl_pushbuf (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:852) [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, DRM_IOCTL_CRTC_QUEUE_SEQUENCE ? nouveau_gem_ioctl_new (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:680) ? drm_ioctl_kernel (/home/kas/linux/torvalds/drivers/gpu/drm/drm_ioctl.c:793) ? nouveau_gem_ioctl_new
Re: [PATCH] drm/nouveau: Accept 'legacy' format modifiers
On 7/17/20 12:47 PM, Daniel Vetter wrote:
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Just bikeshed, but maybe a few more words on what exactly is broken and
how this works around it. Specifically why we only accept these, but don't
advertise them.
Added quite a few words.
Signed-off-by: James Jones
Needs Fixes: line here. Also nice to mention the bug reporter/link.
Done in v2.
---
drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 496c4621cc78..31543086254b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
uint32_t *tile_mode,
uint8_t *kind)
{
+ struct nouveau_display *disp = nouveau_display(drm->dev);
BUG_ON(!tile_mode || !kind);
+ if ((modifier & (0xffull << 12)) == 0ull) {
+ /* Legacy modifier. Translate to this device's 'kind.' */
+ modifier |= disp->format_modifiers[0] & (0xffull << 12);
+ }
Hm I tried to understand what this magic does by looking at drm_fourcc.h,
but the drm_fourcc_canonicalize_nvidia_format_mod() in there implements
something else. Is that function wrong, or should we use it here instead?
> Or is there something else going on entirely?
This may be slightly clearer with the expanded change description:
Canonicalize assumes the old modifiers are only used by certain Tegra
revisions, because the Mesa patches were supposed to land and obliterate
all uses beyond that. That assumption means it can assume the specific
page kind (0xfe) used by the display-engine-compatible layout on those
specific devices. There is no way to generally canonicalize a legacy
modifier without referencing a specific device type, as is indirectly
done here.
This code does a limited device-specific canonicalization: It
substitutes the display-appropriate page kind used by this specific
device, ensuring we derive this correct page kind later in the function.
I iterated on the best way to accomplish this a few times, and this
was the least-invasive thing I came up with, but it does require a
pretty thorough understanding of the NVIDIA modifier macros.
Thanks for the quick review.
-James
Cheers, Daniel
+
if (modifier == DRM_FORMAT_MOD_LINEAR) {
/* tile_mode will not be used in this case */
*tile_mode = 0;
@@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct drm_framebuffer *fb,
}
}
+static const u64 legacy_modifiers[] = {
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5),
+ DRM_FORMAT_MOD_INVALID
+};
+
static int
nouveau_validate_decode_mod(struct nouveau_drm *drm,
uint64_t modifier,
@@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm,
(disp->format_modifiers[mod] != modifier);
mod++);
- if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
- return -EINVAL;
+ if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) {
+ for (mod = 0;
+(legacy_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
+(legacy_modifiers[mod] != modifier);
+mod++);
+ if (legacy_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
+ return -EINVAL;
+ }
nouveau_decode_mod(drm, modifier, tile_mode, kind);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/nouveau: Accept 'legacy' format modifiers
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers which do not differentiate
between different variations of the block linear
layout. When the format modifier support flag was
flipped in the nouveau kernel driver, the X.org
modesetting driver began attempting to use its
format modifier-enabled framebuffer path. Because
the set of format modifiers advertised by the
kernel prior to this change do not intersect with
the set of format modifiers advertised by Mesa,
allocating GBM buffers using format modifiers
fails and the modesetting driver falls back to
non-modifier allocation. However, it still later
queries the modifier of the GBM buffer when
creating its DRM-KMS framebuffer object, receives
the old-format modifier from Mesa, and attempts
to create a framebuffer with it. Since the kernel
is still not aware of these formats, this fails.
Userspace should not be attempting to query format
modifiers of GBM buffers allocated with a non-
format-modifier-aware allocation path, but to
avoid breaking existing userspace behavior, this
change accepts the old-style format modifiers when
creating framebuffers and applying them to planes
by translating them to the equivalent new-style
modifier. To accomplish this, some layout
parameters must be assumed to match properties of
the device targeted by the relevant ioctls. To
avoid perpetuating misuse of the old-style
modifiers, this change does not advertise support
for them. Doing so would imply compatibility
between devices with incompatible memory layouts.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Reported-by: Kirill A. Shutemov
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 496c4621cc78..31543086254b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
uint32_t *tile_mode,
uint8_t *kind)
{
+ struct nouveau_display *disp = nouveau_display(drm->dev);
BUG_ON(!tile_mode || !kind);
+ if ((modifier & (0xffull << 12)) == 0ull) {
+ /* Legacy modifier. Translate to this device's 'kind.' */
+ modifier |= disp->format_modifiers[0] & (0xffull << 12);
+ }
+
if (modifier == DRM_FORMAT_MOD_LINEAR) {
/* tile_mode will not be used in this case */
*tile_mode = 0;
@@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct drm_framebuffer *fb,
}
}
+static const u64 legacy_modifiers[] = {
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5),
+ DRM_FORMAT_MOD_INVALID
+};
+
static int
nouveau_validate_decode_mod(struct nouveau_drm *drm,
uint64_t modifier,
@@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm,
(disp->format_modifiers[mod] != modifier);
mod++);
- if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
- return -EINVAL;
+ if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) {
+ for (mod = 0;
+(legacy_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
+(legacy_modifiers[mod] != modifier);
+mod++);
+ if (legacy_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
+ return -EINVAL;
+ }
nouveau_decode_mod(drm, modifier, tile_mode, kind);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: Accept 'legacy' format modifiers
This doesn't look related. -James On 7/17/20 2:30 PM, Kirill A. Shutemov wrote: On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote: Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Tested with Xorg 1.20 modesetting driver, weston@c46c70dac84a4b3030cd05b380f9f410536690fc, gnome & KDE wayland desktops from Ubuntu 18.04, and sway 1.5 Signed-off-by: James Jones I tried and it crashes. Not sure if it's related. [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:vblank_disable_fn] disabling vblank on crtc 0 [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_CPU_PREP [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF BUG: unable to handle page fault for address: 059c #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] PREEMPT SMP PTI CPU: 13 PID: 3351 Comm: alacritty Tainted: G I 5.8.0-rc5-00191-g086f86c033f9 #53 Hardware name: Gigabyte Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3 Pro-CF, BIOS F5d 11/28/2019 RIP: 0010:kmem_cache_alloc_trace (/home/kas/linux/torvalds/mm/slub.c:272 /home/kas/linux/torvalds/mm/slub.c:278 /home/kas/linux/torvalds/mm/slub.c:292 /home/kas/linux/torvalds/mm/slub.c:2791 /home/kas/linux/torvalds/mm/slub.c:2832 /home/kas/linux/torvalds/mm/slub.c:2849) Code: 8b 51 08 48 89 c8 65 48 03 05 d4 0e ca 70 48 8b 70 08 48 39 f2 75 e7 4c 8b 38 4d 85 ff 0f 84 8f 01 00 00 8b 45 20 48 8b 7d 00 <49> 8b 1c 07 40 f6 c7 0f 0f 85 95 01 00 00 48 8d 8a 80 00 00 00 4c All code 0: 8b 51 08mov0x8(%rcx),%edx 3: 48 89 c8mov%rcx,%rax 6: 65 48 03 05 d4 0e caadd%gs:0x70ca0ed4(%rip),%rax# 0x70ca0ee2 d: 70 e: 48 8b 70 08 mov0x8(%rax),%rsi 12: 48 39 f2cmp%rsi,%rdx 15: 75 e7 jne0xfffe 17: 4c 8b 38mov(%rax),%r15 1a: 4d 85 fftest %r15,%r15 1d: 0f 84 8f 01 00 00 je 0x1b2 23: 8b 45 20mov0x20(%rbp),%eax 26: 48 8b 7d 00 mov0x0(%rbp),%rdi 2a:* 49 8b 1c 07 mov(%r15,%rax,1),%rbx <-- trapping instruction 2e: 40 f6 c7 0f test $0xf,%dil 32: 0f 85 95 01 00 00 jne0x1cd 38: 48 8d 8a 80 00 00 00lea0x80(%rdx),%rcx 3f: 4c rex.WR Code starting with the faulting instruction === 0: 49 8b 1c 07 mov(%r15,%rax,1),%rbx 4: 40 f6 c7 0f test $0xf,%dil 8: 0f 85 95 01 00 00 jne0x1a3 e: 48 8d 8a 80 00 00 00lea0x80(%rdx),%rcx 15: 4c rex.WR RSP: 0018:a8a381bcfba0 EFLAGS: 00010206 RAX: 0030 RBX: 9c0b15e05e00 RCX: 0003fe50 RDX: fc8d RSI: fc8d RDI: 0003fe50 RBP: 9c0b18407840 R08: R09: 0001 R10: 9c0b06c28000 R11: 0001 R12: 0dc0 [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, DRM_IOCTL_CRTC_GET_SEQUENCE R13: 0060 R14: 8fa35a47 R15: 056c FS: 7fbe7a8e3900() GS:9c0b1f88() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 059c CR3: 00103c7fe004 CR4: 003606e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: nouveau_fence_new (/home/kas/linux/torvalds/include/linux/slab.h:555 /home/kas/linux/torvalds/include/linux/slab.h:669 /home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_fence.c:423) [drm:drm_vblank_enable] enabling vblank on crtc 0, ret: 0 nouveau_gem_ioctl_pushbuf (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:852) [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, DRM_IOCTL_CRTC_QUEUE_SEQUENCE ? nouveau_gem_ioctl_new (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:680) ? drm_ioctl_kernel (/home/kas/linux/torvalds/drivers/gpu/drm/drm_ioctl.c:793) ? nouveau_gem_ioctl_new (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:680) drm_ioctl_kernel (/home/kas/linux/torvalds/drivers/gpu/drm/drm_ioctl.c:793) drm_ioctl (/home/kas/linux/torvalds/drivers/gpu/drm/drm_ioctl.c:888) ? nouveau_gem_ioctl_new (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:680) ? _raw_spin_unlock_irqrestore (/home/kas/linux/torvalds/arch/x86/include/asm/irqflags.h:41 /home/kas/linux/torvalds/arch/x86/include/asm/irqflags.h:84 /home/kas/linux/torvalds/include/linux/spinlock_api_smp.h:160
Re: [PATCH 17/18] drm/arc: Move to drm/tiny
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.8-rc5 next-20200717]
[cannot apply to arm/drm-armada-devel arm/drm-armada-fixes]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-armada-Use-devm_drm_dev_alloc/20200717-170827
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
ed6b578040a85977026c93bf4188f996148f3218)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/tiny/arcpgu.c:137:36: warning: unused variable
>> 'arc_pgu_crtc_funcs' [-Wunused-const-variable]
static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
^
1 warning generated.
vim +/arc_pgu_crtc_funcs +137 drivers/gpu/drm/tiny/arcpgu.c
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 136
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 @137
static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 138
.destroy = drm_crtc_cleanup,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 139
.set_config = drm_atomic_helper_set_config,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 140
.page_flip = drm_atomic_helper_page_flip,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 141
.reset = drm_atomic_helper_crtc_reset,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 142
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 143
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 144
};
bdae5c29d72870d drivers/gpu/drm/arc/arcpgu_drv.c Daniel Vetter 2020-07-17 145
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL FOR v5.9] Xilinx ZynqMP DisplayPort Subsystem driver
Hi Dave, Daniel, The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/drm-xilinx-dpsub-20200718 for you to fetch changes up to d76271d22694e874ed70791702db9252ffe96a4c: drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem (2020-07-18 02:59:16 +0300) The tag is based on the topic/xilinx branch from Vinod's dmaengine tree, which contains required dependencies. That branch is itself based on v5.8-rc1, and has been merged in the dmaengine -next branch, scheduled for v5.9. I have verified that it doesn't conflict with drm-next. Xilinx ZynqMP DisplayPort Subsystem driver Hyun Kwon (3): dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem Laurent Pinchart (2): dt: bindings: dma: xilinx: dpdma: DT bindings for Xilinx DPDMA dmaengine: Add support for repeating transactions .../display/xlnx/xlnx,zynqmp-dpsub.yaml | 174 ++ .../bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml | 68 + Documentation/driver-api/dmaengine/client.rst |4 +- Documentation/driver-api/dmaengine/provider.rst | 49 + MAINTAINERS | 18 + drivers/dma/Kconfig | 10 + drivers/dma/xilinx/Makefile |1 + drivers/dma/xilinx/xilinx_dpdma.c | 1533 +++ drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/xlnx/Kconfig| 13 + drivers/gpu/drm/xlnx/Makefile |2 + drivers/gpu/drm/xlnx/zynqmp_disp.c | 1697 drivers/gpu/drm/xlnx/zynqmp_disp.h | 42 + drivers/gpu/drm/xlnx/zynqmp_disp_regs.h | 201 ++ drivers/gpu/drm/xlnx/zynqmp_dp.c| 1734 + drivers/gpu/drm/xlnx/zynqmp_dp.h| 27 + drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 322 +++ drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 54 + include/dt-bindings/dma/xlnx-zynqmp-dpdma.h | 16 + include/linux/dmaengine.h | 17 + 21 files changed, 5984 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml create mode 100644 Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml create mode 100644 drivers/dma/xilinx/xilinx_dpdma.c create mode 100644 drivers/gpu/drm/xlnx/Kconfig create mode 100644 drivers/gpu/drm/xlnx/Makefile create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.c create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.h create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp_regs.h create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.c create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.h create mode 100644 include/dt-bindings/dma/xlnx-zynqmp-dpdma.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 1/2] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings
From: Hyun Kwon The bindings describe the ZynqMP DP subsystem. They don't support the interface with the programmable logic (FPGA) or audio yet. Signed-off-by: Hyun Kwon Signed-off-by: Laurent Pinchart Reviewed-by: Rob Herring Acked-by: Sam Ravnborg --- .../display/xlnx/xlnx,zynqmp-dpsub.yaml | 174 ++ 1 file changed, 174 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml new file mode 100644 index ..52a939cade3b --- /dev/null +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/xlnx/xlnx,zynqmp-dpsub.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP DisplayPort Subsystem + +description: | + The DisplayPort subsystem of Xilinx ZynqMP (Zynq UltraScale+ MPSoC) + implements the display and audio pipelines based on the DisplayPort v1.2 + standard. The subsystem includes multiple functional blocks as below: + + ++ + ++ | ++ +---+ | + | DPDMA | --->|| --> | Video | Video +-+ | + | 4x vid | | || | Rendering | -+--> | | | +--+ + | 2x aud | | | Audio/Video | --> | Pipeline | || DisplayPort |---> | PHY0 | + ++ | | Buffer Manager | +---+ || Source| | +--+ + | |and STC | +---+ || Controller | | +--+ + Live Video --->|| --> | Audio | Audio | |---> | PHY1 | + | || | Mixer | --+-> | | | +--+ + Live Audio --->|| --> | | || +-+ | + | ++ +---+ || | + +---||---+ + vv + Blended Video and + Mixed Audio to PL + + The Buffer Manager interacts with external interface such as DMA engines or + live audio/video streams from the programmable logic. The Video Rendering + Pipeline blends the video and graphics layers and performs colorspace + conversion. The Audio Mixer mixes the incoming audio streams. The DisplayPort + Source Controller handles the DisplayPort protocol and connects to external + PHYs. + + The subsystem supports 2 video and 2 audio streams, and various pixel formats + and depths up to 4K@30 resolution. + + Please refer to "Zynq UltraScale+ Device Technical Reference Manual" + (https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf) + for more details. + +maintainers: + - Laurent Pinchart + +properties: + compatible: +const: xlnx,zynqmp-dpsub-1.7 + + reg: +maxItems: 4 + reg-names: +items: + - const: dp + - const: blend + - const: av_buf + - const: aud + + interrupts: +maxItems: 1 + + clocks: +description: + The APB clock and at least one video clock are mandatory, the audio clock + is optional. +minItems: 2 +maxItems: 4 +items: + - description: dp_apb_clk is the APB clock + - description: dp_aud_clk is the Audio clock + - description: + dp_vtc_pixel_clk_in is the non-live video clock (from Processing + System) + - description: + dp_live_video_in_clk is the live video clock (from Programmable + Logic) + clock-names: +oneOf: + - minItems: 2 +maxItems: 3 +items: + - const: dp_apb_clk + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - minItems: 3 +maxItems: 4 +items: + - const: dp_apb_clk + - const: dp_aud_clk + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + + power-domains: +maxItems: 1 + + resets: +maxItems: 1 + + dmas: +maxItems: 4 +items: + - description: Video layer, plane 0 (RGB or luma) + - description: Video layer, plane 1 (U/V or U) + - description: Video layer, plane 2 (V) + - description: Graphics layer + dma-names: +items: + - const: vid0 + - const: vid1 + - const: vid2 + - const: gfx0 + + phys: +description: PHYs for the DP data lanes +minItems: 1 +maxItems: 2 + phy-names: +
[PATCH v12 0/2] Xilinx ZynqMP DisplayPort Subsystem DRM/KMS driver
Hello, Here's a new and hopefully last version of the Xilinx ZynqMP DisplayPort Subsystem driver, the fourth version since I took over v8 of the series ([1]) from Hyun. This new version is based on top of the dmaengine topic branch that contains the required dependencies, available at git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git topic/xilinx That branch is itself based directly on top of v5.8-rc1, and has been merged in the dmaengine -next branch scheduled for v5.9. I have verified that the result doesn't conflict with drm-next. DT integration has been stripped out in this version and will be submitted separately. The tag that contains this series on top of the required dependencies is available at git://linuxtv.org/pinchartl/media.git drm-xilinx-dpsub-20200718 I will send a pull request shortly. [1] https://lists.freedesktop.org/archives/dri-devel/2018-July/182477.html Hyun Kwon (2): dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem .../display/xlnx/xlnx,zynqmp-dpsub.yaml | 174 ++ MAINTAINERS |9 + drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/xlnx/Kconfig | 13 + drivers/gpu/drm/xlnx/Makefile |2 + drivers/gpu/drm/xlnx/zynqmp_disp.c| 1697 drivers/gpu/drm/xlnx/zynqmp_disp.h| 42 + drivers/gpu/drm/xlnx/zynqmp_disp_regs.h | 201 ++ drivers/gpu/drm/xlnx/zynqmp_dp.c | 1734 + drivers/gpu/drm/xlnx/zynqmp_dp.h | 27 + drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 322 +++ drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 54 + 13 files changed, 4278 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml create mode 100644 drivers/gpu/drm/xlnx/Kconfig create mode 100644 drivers/gpu/drm/xlnx/Makefile create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.c create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.h create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp_regs.h create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.c create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Fri, Jul 17, 2020 at 10:43:18AM -0400, Sasha Levin wrote:
> On Fri, Jul 17, 2020 at 02:43:52AM +0200, Karol Herbst wrote:
> > On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
> > > On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > > > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> > > > >
> > > > > Hi everybody,
> > > > >
> > > > > with the mentioned commit Nouveau isn't able to load firmware onto the
> > > > > GPU on one of my systems here. Even though the issue doesn't always
> > > > > happen I am quite confident this is the commit breaking it.
> > > > >
> > > > > I am still digging into the issue and trying to figure out what
> > > > > exactly breaks, but it shows up in different ways. Either we are not
> > > > > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > > > > Btw, this is also a system where our runtime power management issue
> > > > > shows up, so maybe there is indeed something funky with the bridge
> > > > > controller.
> > > > >
> > > > > Just pinging you in case you have an idea on how this could break
> > > > > Nouveau
> > > > >
> > > > > most of the times it shows up like this:
> > > > > nouveau :01:00.0: acr: AHESASC binary failed
> > > > >
> > > > > Sometimes it works at boot and fails at runtime resuming with random
> > > > > faults. So I will be investigating a bit more, but yeah... I am super
> > > > > sure the commit triggered this issue, no idea if it actually causes
> > > > > it.
> > > >
> > > > so yeah.. I reverted that locally and never ran into issues again.
> > > > Still valid on latest 5.7. So can we get this reverted or properly
> > > > fixed? This breaks runtime pm for us on at least some hardware.
> > >
> > > Yeah, that stinks. We had another similar report from Patrick:
> > >
> > >
> > > https://lore.kernel.org/r/caerspo5stek_my1dehwp7ahd0xop87+ohywktjbl7algdbx...@mail.gmail.com
> > >
> > > Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
> > > DLL Link Active train links in 100 ms"), which Patrick found was
> > > backported to v5.4.49 as 828b192c57e8, and you found was backported to
> > > v5.7.6 as afaff825e3a4.
> > >
> > > Oddly, Patrick reported that v5.7.7 worked correctly, even though it
> > > still contains afaff825e3a4.
> > >
> > > I guess in the absence of any other clues we'll have to revert it.
> > > I hate to do that because that means we'll have slow resume of
> > > Thunderbolt-connected devices again, but that's better than having
> > > GPUs completely broken.
> > >
> > > Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
> > > logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
> > > original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
> > > and to this thread?
> > >
> > > There must be a way to fix the slow resume problem without breaking
> > > the GPUs.
> > >
> >
> > I wouldn't be surprised if this is related to the Intel bridge we
> > check against for Nouveau.. I still have to check on another laptop
> > with the same bridge our workaround was required as well but wouldn't
> > be surprised if it shows the same problem. Will get you the
> > information from both systems tomorrow then.
>
> I take it that ec411e02b7a2 will be reverted upstream?
Yes, unless we have a better fix soon. I applied the revert to my
for-linus branch, so it will appear in -next soon. I think it's a
little late to get it in -rc5, so I'll probably ask Linus to pull it
next week for -rc6.
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: Accept 'legacy' format modifiers
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote: > Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() > family of modifiers to handle broken userspace > Xorg modesetting and Mesa drivers. > > Tested with Xorg 1.20 modesetting driver, > weston@c46c70dac84a4b3030cd05b380f9f410536690fc, > gnome & KDE wayland desktops from Ubuntu 18.04, > and sway 1.5 > > Signed-off-by: James Jones I tried and it crashes. Not sure if it's related. [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:vblank_disable_fn] disabling vblank on crtc 0 [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_CPU_PREP [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF [drm:drm_ioctl] pid=3351, dev=0xe200, auth=1, NOUVEAU_GEM_PUSHBUF BUG: unable to handle page fault for address: 059c #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] PREEMPT SMP PTI CPU: 13 PID: 3351 Comm: alacritty Tainted: G I 5.8.0-rc5-00191-g086f86c033f9 #53 Hardware name: Gigabyte Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3 Pro-CF, BIOS F5d 11/28/2019 RIP: 0010:kmem_cache_alloc_trace (/home/kas/linux/torvalds/mm/slub.c:272 /home/kas/linux/torvalds/mm/slub.c:278 /home/kas/linux/torvalds/mm/slub.c:292 /home/kas/linux/torvalds/mm/slub.c:2791 /home/kas/linux/torvalds/mm/slub.c:2832 /home/kas/linux/torvalds/mm/slub.c:2849) Code: 8b 51 08 48 89 c8 65 48 03 05 d4 0e ca 70 48 8b 70 08 48 39 f2 75 e7 4c 8b 38 4d 85 ff 0f 84 8f 01 00 00 8b 45 20 48 8b 7d 00 <49> 8b 1c 07 40 f6 c7 0f 0f 85 95 01 00 00 48 8d 8a 80 00 00 00 4c All code 0: 8b 51 08mov0x8(%rcx),%edx 3: 48 89 c8mov%rcx,%rax 6: 65 48 03 05 d4 0e caadd%gs:0x70ca0ed4(%rip),%rax# 0x70ca0ee2 d: 70 e: 48 8b 70 08 mov0x8(%rax),%rsi 12: 48 39 f2cmp%rsi,%rdx 15: 75 e7 jne0xfffe 17: 4c 8b 38mov(%rax),%r15 1a: 4d 85 fftest %r15,%r15 1d: 0f 84 8f 01 00 00 je 0x1b2 23: 8b 45 20mov0x20(%rbp),%eax 26: 48 8b 7d 00 mov0x0(%rbp),%rdi 2a:* 49 8b 1c 07 mov(%r15,%rax,1),%rbx <-- trapping instruction 2e: 40 f6 c7 0f test $0xf,%dil 32: 0f 85 95 01 00 00 jne0x1cd 38: 48 8d 8a 80 00 00 00lea0x80(%rdx),%rcx 3f: 4c rex.WR Code starting with the faulting instruction === 0: 49 8b 1c 07 mov(%r15,%rax,1),%rbx 4: 40 f6 c7 0f test $0xf,%dil 8: 0f 85 95 01 00 00 jne0x1a3 e: 48 8d 8a 80 00 00 00lea0x80(%rdx),%rcx 15: 4c rex.WR RSP: 0018:a8a381bcfba0 EFLAGS: 00010206 RAX: 0030 RBX: 9c0b15e05e00 RCX: 0003fe50 RDX: fc8d RSI: fc8d RDI: 0003fe50 RBP: 9c0b18407840 R08: R09: 0001 R10: 9c0b06c28000 R11: 0001 R12: 0dc0 [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, DRM_IOCTL_CRTC_GET_SEQUENCE R13: 0060 R14: 8fa35a47 R15: 056c FS: 7fbe7a8e3900() GS:9c0b1f88() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 059c CR3: 00103c7fe004 CR4: 003606e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: nouveau_fence_new (/home/kas/linux/torvalds/include/linux/slab.h:555 /home/kas/linux/torvalds/include/linux/slab.h:669 /home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_fence.c:423) [drm:drm_vblank_enable] enabling vblank on crtc 0, ret: 0 nouveau_gem_ioctl_pushbuf (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:852) [drm:drm_ioctl] pid=3327, dev=0xe200, auth=1, DRM_IOCTL_CRTC_QUEUE_SEQUENCE ? nouveau_gem_ioctl_new (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:680) ? drm_ioctl_kernel (/home/kas/linux/torvalds/drivers/gpu/drm/drm_ioctl.c:793) ? nouveau_gem_ioctl_new (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:680) drm_ioctl_kernel (/home/kas/linux/torvalds/drivers/gpu/drm/drm_ioctl.c:793) drm_ioctl (/home/kas/linux/torvalds/drivers/gpu/drm/drm_ioctl.c:888) ? nouveau_gem_ioctl_new (/home/kas/linux/torvalds/drivers/gpu/drm/nouveau/nouveau_gem.c:680) ? _raw_spin_unlock_irqrestore (/home/kas/linux/torvalds/arch/x86/include/asm/irqflags.h:41 /home/kas/linux/torvalds/arch/x86/include/asm/irqflags.h:84 /home/kas/linux/torvalds/include/linux/spinlock_api_smp.h:160 /home/kas/linux/torvalds/kernel/locking/spinlock.c:191) ? lockdep_hardirqs_on
[PATCH v3] Add support for KeemBay DRM driver
This is a new DRM driver for Intel's KeemBay SOC. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This driver is tested with the KMB EVM board which is the refernce baord for Keem Bay SOC. The SOC's display pipeline is as follows +--++-++---+ |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | +--++-++---+ LCD controller and Mipi DSI transmitter are part of the SOC and mipi to HDMI converter is ADV7535 for KMB EVM board. The DRM driver is a basic KMS atomic modesetting display driver and has no 2D or 3D graphics.It calls into the ADV bridge driver at the connector level. Only 1080p resolution and single plane is supported at this time. The usecase is for debugging video and camera outputs. Device tree patches are under review here https://lore.kernel.org/linux-arm-kernel/20200708175020.194436-1-daniele.alessandre...@linux.intel.com/T/ Changes since v1: - Removed redundant license text, updated license - Rearranged include blocks - renamed global vars and removed extern in c - Used upclassing for dev_private - Used drm_dev_init in drm device create - minor cleanups Changes since v2: - squashed all commits to a single commit - logging changed to drm_info, drm_dbg etc. - used devm_drm_dev_alloc() - removed commented out sections and general cleanup Anitha Chrisanthus (1): drm/kmb: Add support for KeemBay Display drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/kmb/Kconfig | 12 + drivers/gpu/drm/kmb/Makefile|2 + drivers/gpu/drm/kmb/kmb_crtc.c | 219 + drivers/gpu/drm/kmb/kmb_crtc.h | 41 + drivers/gpu/drm/kmb/kmb_drv.c | 759 drivers/gpu/drm/kmb/kmb_drv.h | 165 drivers/gpu/drm/kmb/kmb_dsi.c | 1833 +++ drivers/gpu/drm/kmb/kmb_dsi.h | 370 drivers/gpu/drm/kmb/kmb_plane.c | 515 +++ drivers/gpu/drm/kmb/kmb_plane.h | 124 +++ drivers/gpu/drm/kmb/kmb_regs.h | 738 13 files changed, 4781 insertions(+) create mode 100644 drivers/gpu/drm/kmb/Kconfig create mode 100644 drivers/gpu/drm/kmb/Makefile create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.h create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: msm: a6xx: fix gpu failure after system resume
Hi, On Fri, Jul 17, 2020 at 1:24 PM Rob Clark wrote: > > On Fri, Jul 17, 2020 at 10:39 AM Doug Anderson wrote: > > > > Hi, > > > > On Fri, Jul 17, 2020 at 7:46 AM Jordan Crouse > > wrote: > > > > > > On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote: > > > > On targets where GMU is available, GMU takes over the ownership of GX > > > > GDSC > > > > during its initialization. So, move the refcount-get on GX PD before we > > > > initialize the GMU. This ensures that nobody can collapse the GX GDSC > > > > once GMU owns the GX GDSC. This patch fixes some GMU OOB errors seen > > > > during GPU wake up during a system resume. > > > > > > > Signed-off-by: Akhil P Oommen > > > > Reported-by: Matthias Kaehlcke > > > > Tested-by: Matthias Kaehlcke > > > > > > The Signed-off-by needs to be at the end but I think Rob can do that for > > > you. > > > > It does? I've always been told that this is supposed to be roughly a > > log of what happens. In that sense you added your SoB before the > > review/test happened so it should come before. I know some > > maintainers seem to do things differently but that seems to be the > > most common. In that sense, I think the order that Akhil has is > > correct. ...but, obviously, it's up to the maintainer. ;-) > > yeah, I chronological order was my understanding too.. but presumably > the Reported-by happened before the Signed-of-by (which is how I > reordered things when applying the patch) Doh! Yeah, I somehow read that as Reviewed-by. Thanks! :-) -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: msm: a6xx: fix gpu failure after system resume
On Fri, Jul 17, 2020 at 10:39 AM Doug Anderson wrote: > > Hi, > > On Fri, Jul 17, 2020 at 7:46 AM Jordan Crouse wrote: > > > > On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote: > > > On targets where GMU is available, GMU takes over the ownership of GX GDSC > > > during its initialization. So, move the refcount-get on GX PD before we > > > initialize the GMU. This ensures that nobody can collapse the GX GDSC > > > once GMU owns the GX GDSC. This patch fixes some GMU OOB errors seen > > > during GPU wake up during a system resume. > > > > > Signed-off-by: Akhil P Oommen > > > Reported-by: Matthias Kaehlcke > > > Tested-by: Matthias Kaehlcke > > > > The Signed-off-by needs to be at the end but I think Rob can do that for > > you. > > It does? I've always been told that this is supposed to be roughly a > log of what happens. In that sense you added your SoB before the > review/test happened so it should come before. I know some > maintainers seem to do things differently but that seems to be the > most common. In that sense, I think the order that Akhil has is > correct. ...but, obviously, it's up to the maintainer. ;-) yeah, I chronological order was my understanding too.. but presumably the Reported-by happened before the Signed-of-by (which is how I reordered things when applying the patch) BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Fri, Jul 17, 2020 at 03:04:10PM -0400, Lyude Paul wrote: > Isn't it possible to tell whether a PCI device is connected through > thunderbolt or not? We could probably get away with just defaulting > to 100ms for thunderbolt devices without DLL Link Active specified, > and then default to the old delay value for non-thunderbolt devices. pci_is_thunderbolt_attached() ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/4] drm/imx: Add initial support for DCSS on iMX8MQ
Hi Laurentiu. On Fri, Jul 17, 2020 at 05:41:27PM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS). > Some of its capabilities include: > * 4K@60fps; > * HDR10; > * one graphics and 2 video pipelines; > * on-the-fly decompression of compressed video and graphics; > > The reference manual can be found here: > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM > > The current patch adds only basic functionality: one primary plane for > graphics, linear, tiled and super-tiled buffers support (no graphics > decompression yet), no HDR10 and no video planes. > > Video planes support and HDR10 will be added in subsequent patches once > per-plane de-gamma/CSC/gamma support is in. > > Signed-off-by: Laurentiu Palcu > Reviewed-by: Lucas Stach > --- return drm_bridge_attach(encoder, bridge, NULL, 0); The above code-snippet tells that the display-driver rely on the bridge to create the connector. Could this by any chance be updated to the new way where the display driver creates the connector - and thus passing DRM_BRIDGE_ATTACH_NO_CONNECTOR as the flags argument? What bridges would be relevant? To check that the reelvant bridges are already ported. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: Accept 'legacy' format modifiers
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote:
> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> family of modifiers to handle broken userspace
> Xorg modesetting and Mesa drivers.
>
> Tested with Xorg 1.20 modesetting driver,
> weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
> gnome & KDE wayland desktops from Ubuntu 18.04,
> and sway 1.5
Just bikeshed, but maybe a few more words on what exactly is broken and
how this works around it. Specifically why we only accept these, but don't
advertise them.
>
> Signed-off-by: James Jones
Needs Fixes: line here. Also nice to mention the bug reporter/link.
> ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 496c4621cc78..31543086254b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
> uint32_t *tile_mode,
> uint8_t *kind)
> {
> + struct nouveau_display *disp = nouveau_display(drm->dev);
> BUG_ON(!tile_mode || !kind);
>
> + if ((modifier & (0xffull << 12)) == 0ull) {
> + /* Legacy modifier. Translate to this device's 'kind.' */
> + modifier |= disp->format_modifiers[0] & (0xffull << 12);
> + }
Hm I tried to understand what this magic does by looking at drm_fourcc.h,
but the drm_fourcc_canonicalize_nvidia_format_mod() in there implements
something else. Is that function wrong, or should we use it here instead?
Or is there something else going on entirely?
Cheers, Daniel
> +
> if (modifier == DRM_FORMAT_MOD_LINEAR) {
> /* tile_mode will not be used in this case */
> *tile_mode = 0;
> @@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct drm_framebuffer
> *fb,
> }
> }
>
> +static const u64 legacy_modifiers[] = {
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5),
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static int
> nouveau_validate_decode_mod(struct nouveau_drm *drm,
> uint64_t modifier,
> @@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm,
>(disp->format_modifiers[mod] != modifier);
>mod++);
>
> - if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
> - return -EINVAL;
> + if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) {
> + for (mod = 0;
> + (legacy_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
> + (legacy_modifiers[mod] != modifier);
> + mod++);
> + if (legacy_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
> + return -EINVAL;
> + }
>
> nouveau_decode_mod(drm, modifier, tile_mode, kind);
>
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Don't force IOSF_MBI
Quoting Jisheng Zhang (2020-07-17 07:11:38) > The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines > isof_mbi_* APIs when ISOF_MBI is disabled. > > Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC platforms. But it is required for Valleyview/Cherryview and we want to support those by default. Tricky. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: ACPI / OSI: remove workarounds for hybrid graphics laptops
Hey-just wanted to give some additional context I think Karol missed here. It
should be noted that since the last time me and Karol looked at reverting these,
we've already fixed all of the nasty runtime PM (e.g. runtime D3) issues we
could find. This includes the infamous one that was affecting nearly all of the
nvidia pascal (+ some maxwell 2 and turing, it ended up being that the intel PCI
bridge was the culprit) machines on the market. Right now I'm only aware of one
major issue we have, which is the result of a recent PCI core change that we're
already in the process of getting reverted:
https://lkml.org/lkml/2020/7/16/1288
[if you do any testing of runtime PM, you may need to temporarily revert this
patch to make things work]
So, really-runtime D3 is very much supported with nouveau. And we've put a _lot_
of effort into making sure of that, and are happy to fix any issues you're still
finding. It also works just fine in AMD, but if you're finding systems it
doesn't work with amd on then please let the amdgpu folks know upstream so they
can properly fix it. Otherwise, these ACPI workarounds are likely making the
power consumption on these systems (for nouveau, amdgpu, and radeon)
dramatically higher then it needs to be.
On Fri, 2020-07-17 at 21:05 +0200, Karol Herbst wrote:
> It's hard to figure out what systems are actually affected and right now I
> don't see a good way of removing those...
>
> But I'd like to see thos getting removed and drivers fixed instead (which
> happened at least for nouveau).
>
> And as mentioned before, I prefer people working on fixing issues instead
> of spending time to add firmware level workarounds which are hard to know
> to which systems they apply to, hard to remove and basically a big huge
> pain to work with.
> In the end I have no idea how to even figure out what systems are affected
> and which not by this, so I have no idea how to even verify we can safely
> remove this (which just means those are impossible to remove unless we risk
> breaking systems, which again makes those supper annoying to deal with).
>
> Also from the comments it's hard to get what those bits really do. Are they
> just preventing runtime pm or do the devices are powered down when booting?
> I am sure it's the former, still...
>
> Please, don't do this again.
>
> For now, those workaround prevent power savings on systems those workaround
> applies to, which might be any so those should get removed asap and if
> new issues arrise removing those please do a proper bug report and we can
> look into it and come up with a proper fix (and keep this patch out until
> we resolve all of those).
>
> Signed-off-by: Karol Herbst
> CC: Alex Hung
> CC: "Rafael J. Wysocki"
> CC: Len Brown
> CC: Lyude Paul
> CC: linux-ker...@vger.kernel.org
> CC: dri-devel@lists.freedesktop.org
> CC: nouv...@lists.freedesktop.org
> ---
> drivers/acpi/osi.c | 24
> 1 file changed, 24 deletions(-)
>
> diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
> index 9f68538091384..d4405e1ca9b97 100644
> --- a/drivers/acpi/osi.c
> +++ b/drivers/acpi/osi.c
> @@ -44,30 +44,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = {
> {"Processor Device", true},
> {"3.0 _SCP Extensions", true},
> {"Processor Aggregator Device", true},
> - /*
> - * Linux-Dell-Video is used by BIOS to disable RTD3 for NVidia graphics
> - * cards as RTD3 is not supported by drivers now. Systems with NVidia
> - * cards will hang without RTD3 disabled.
> - *
> - * Once NVidia drivers officially support RTD3, this _OSI strings can
> - * be removed if both new and old graphics cards are supported.
> - */
> - {"Linux-Dell-Video", true},
> - /*
> - * Linux-Lenovo-NV-HDMI-Audio is used by BIOS to power on NVidia's HDMI
> - * audio device which is turned off for power-saving in Windows OS.
> - * This power management feature observed on some Lenovo Thinkpad
> - * systems which will not be able to output audio via HDMI without
> - * a BIOS workaround.
> - */
> - {"Linux-Lenovo-NV-HDMI-Audio", true},
> - /*
> - * Linux-HPI-Hybrid-Graphics is used by BIOS to enable dGPU to
> - * output video directly to external monitors on HP Inc. mobile
> - * workstations as Nvidia and AMD VGA drivers provide limited
> - * hybrid graphics supports.
> - */
> - {"Linux-HPI-Hybrid-Graphics", true},
> };
>
> static u32 acpi_osi_handler(acpi_string interface, u32 supported)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] RFC: ACPI / OSI: remove workarounds for hybrid graphics laptops
It's hard to figure out what systems are actually affected and right now I
don't see a good way of removing those...
But I'd like to see thos getting removed and drivers fixed instead (which
happened at least for nouveau).
And as mentioned before, I prefer people working on fixing issues instead
of spending time to add firmware level workarounds which are hard to know
to which systems they apply to, hard to remove and basically a big huge
pain to work with.
In the end I have no idea how to even figure out what systems are affected
and which not by this, so I have no idea how to even verify we can safely
remove this (which just means those are impossible to remove unless we risk
breaking systems, which again makes those supper annoying to deal with).
Also from the comments it's hard to get what those bits really do. Are they
just preventing runtime pm or do the devices are powered down when booting?
I am sure it's the former, still...
Please, don't do this again.
For now, those workaround prevent power savings on systems those workaround
applies to, which might be any so those should get removed asap and if
new issues arrise removing those please do a proper bug report and we can
look into it and come up with a proper fix (and keep this patch out until
we resolve all of those).
Signed-off-by: Karol Herbst
CC: Alex Hung
CC: "Rafael J. Wysocki"
CC: Len Brown
CC: Lyude Paul
CC: linux-ker...@vger.kernel.org
CC: dri-devel@lists.freedesktop.org
CC: nouv...@lists.freedesktop.org
---
drivers/acpi/osi.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
index 9f68538091384..d4405e1ca9b97 100644
--- a/drivers/acpi/osi.c
+++ b/drivers/acpi/osi.c
@@ -44,30 +44,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = {
{"Processor Device", true},
{"3.0 _SCP Extensions", true},
{"Processor Aggregator Device", true},
- /*
-* Linux-Dell-Video is used by BIOS to disable RTD3 for NVidia graphics
-* cards as RTD3 is not supported by drivers now. Systems with NVidia
-* cards will hang without RTD3 disabled.
-*
-* Once NVidia drivers officially support RTD3, this _OSI strings can
-* be removed if both new and old graphics cards are supported.
-*/
- {"Linux-Dell-Video", true},
- /*
-* Linux-Lenovo-NV-HDMI-Audio is used by BIOS to power on NVidia's HDMI
-* audio device which is turned off for power-saving in Windows OS.
-* This power management feature observed on some Lenovo Thinkpad
-* systems which will not be able to output audio via HDMI without
-* a BIOS workaround.
-*/
- {"Linux-Lenovo-NV-HDMI-Audio", true},
- /*
-* Linux-HPI-Hybrid-Graphics is used by BIOS to enable dGPU to
-* output video directly to external monitors on HP Inc. mobile
-* workstations as Nvidia and AMD VGA drivers provide limited
-* hybrid graphics supports.
-*/
- {"Linux-HPI-Hybrid-Graphics", true},
};
static u32 acpi_osi_handler(acpi_string interface, u32 supported)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Thu, 2020-07-16 at 18:54 -0500, Bjorn Helgaas wrote:
> [+cc Sasha -- stable kernel regression]
> [+cc Patrick, Kai-Heng, LKML]
>
> On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> > > Hi everybody,
> > >
> > > with the mentioned commit Nouveau isn't able to load firmware onto the
> > > GPU on one of my systems here. Even though the issue doesn't always
> > > happen I am quite confident this is the commit breaking it.
> > >
> > > I am still digging into the issue and trying to figure out what
> > > exactly breaks, but it shows up in different ways. Either we are not
> > > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > > Btw, this is also a system where our runtime power management issue
> > > shows up, so maybe there is indeed something funky with the bridge
> > > controller.
> > >
> > > Just pinging you in case you have an idea on how this could break Nouveau
> > >
> > > most of the times it shows up like this:
> > > nouveau :01:00.0: acr: AHESASC binary failed
> > >
> > > Sometimes it works at boot and fails at runtime resuming with random
> > > faults. So I will be investigating a bit more, but yeah... I am super
> > > sure the commit triggered this issue, no idea if it actually causes
> > > it.
> >
> > so yeah.. I reverted that locally and never ran into issues again.
> > Still valid on latest 5.7. So can we get this reverted or properly
> > fixed? This breaks runtime pm for us on at least some hardware.
>
> Yeah, that stinks. We had another similar report from Patrick:
>
>
> https://lore.kernel.org/r/caerspo5stek_my1dehwp7ahd0xop87+ohywktjbl7algdbx...@mail.gmail.com
>
> Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
> DLL Link Active train links in 100 ms"), which Patrick found was
> backported to v5.4.49 as 828b192c57e8, and you found was backported to
> v5.7.6 as afaff825e3a4.
>
> Oddly, Patrick reported that v5.7.7 worked correctly, even though it
> still contains afaff825e3a4.
>
> I guess in the absence of any other clues we'll have to revert it.
> I hate to do that because that means we'll have slow resume of
> Thunderbolt-connected devices again, but that's better than having
> GPUs completely broken.
>
> Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
> logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
> original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
> and to this thread?
>
> There must be a way to fix the slow resume problem without breaking
> the GPUs.
Isn't it possible to tell whether a PCI device is connected through thunderbolt
or not? We could probably get away with just defaulting to 100ms for thunderbolt
devices without DLL Link Active specified, and then default to the old delay
value for non-thunderbolt devices.
>
> Bjorn
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: Accept 'legacy' format modifiers
This should resolve the inability to start X with the new NV format
modifier support in nouveau. FYI, I'm offline next week, but I'll check
in tonight in case there are any review comments. When I'm back, I'll
get the associated userspace fixes cleaned up and out to the appropriate
lists.
Thanks,
-James
On 7/17/20 11:57 AM, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 496c4621cc78..31543086254b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
uint32_t *tile_mode,
uint8_t *kind)
{
+ struct nouveau_display *disp = nouveau_display(drm->dev);
BUG_ON(!tile_mode || !kind);
+ if ((modifier & (0xffull << 12)) == 0ull) {
+ /* Legacy modifier. Translate to this device's 'kind.' */
+ modifier |= disp->format_modifiers[0] & (0xffull << 12);
+ }
+
if (modifier == DRM_FORMAT_MOD_LINEAR) {
/* tile_mode will not be used in this case */
*tile_mode = 0;
@@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct drm_framebuffer *fb,
}
}
+static const u64 legacy_modifiers[] = {
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5),
+ DRM_FORMAT_MOD_INVALID
+};
+
static int
nouveau_validate_decode_mod(struct nouveau_drm *drm,
uint64_t modifier,
@@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm,
(disp->format_modifiers[mod] != modifier);
mod++);
- if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
- return -EINVAL;
+ if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) {
+ for (mod = 0;
+(legacy_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
+(legacy_modifiers[mod] != modifier);
+mod++);
+ if (legacy_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
+ return -EINVAL;
+ }
nouveau_decode_mod(drm, modifier, tile_mode, kind);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Accept 'legacy' format modifiers
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 496c4621cc78..31543086254b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
uint32_t *tile_mode,
uint8_t *kind)
{
+ struct nouveau_display *disp = nouveau_display(drm->dev);
BUG_ON(!tile_mode || !kind);
+ if ((modifier & (0xffull << 12)) == 0ull) {
+ /* Legacy modifier. Translate to this device's 'kind.' */
+ modifier |= disp->format_modifiers[0] & (0xffull << 12);
+ }
+
if (modifier == DRM_FORMAT_MOD_LINEAR) {
/* tile_mode will not be used in this case */
*tile_mode = 0;
@@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct drm_framebuffer *fb,
}
}
+static const u64 legacy_modifiers[] = {
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5),
+ DRM_FORMAT_MOD_INVALID
+};
+
static int
nouveau_validate_decode_mod(struct nouveau_drm *drm,
uint64_t modifier,
@@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm,
(disp->format_modifiers[mod] != modifier);
mod++);
- if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
- return -EINVAL;
+ if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) {
+ for (mod = 0;
+(legacy_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
+(legacy_modifiers[mod] != modifier);
+mod++);
+ if (legacy_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
+ return -EINVAL;
+ }
nouveau_decode_mod(drm, modifier, tile_mode, kind);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains
On Thu, Jul 9, 2020 at 4:05 AM Rajendra Nayak wrote:
>
> Add the OPP tables for DSI and MDP based on the perf state/clk
> requirements, and add the power-domains property to specify the
> scalable power domain.
>
> Signed-off-by: Rajendra Nayak
> Reviewed-by: Matthias Kaehlcke
Tested-by: Rob Clark
Bjorn, the two driver patches are queued up in msm-next, I assume
you'll pickup the two dt patches?
BR,
-R
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 59
>
> 1 file changed, 59 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index fee50d9..3efdd70 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -3296,6 +3296,35 @@
> #power-domain-cells = <1>;
> };
>
> + dsi_opp_table: dsi-opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-1920 {
> + opp-hz = /bits/ 64 <1920>;
> + required-opps = <_opp_min_svs>;
> + };
> +
> + opp-18000 {
> + opp-hz = /bits/ 64 <18000>;
> + required-opps = <_opp_low_svs>;
> + };
> +
> + opp-27500 {
> + opp-hz = /bits/ 64 <27500>;
> + required-opps = <_opp_svs>;
> + };
> +
> + opp-32858 {
> + opp-hz = /bits/ 64 <32858>;
> + required-opps = <_opp_svs_l1>;
> + };
> +
> + opp-35800 {
> + opp-hz = /bits/ 64 <35800>;
> + required-opps = <_opp_nom>;
> + };
> + };
> +
> mdss: mdss@ae0 {
> compatible = "qcom,sdm845-mdss";
> reg = <0 0x0ae0 0 0x1000>;
> @@ -3340,6 +3369,8 @@
> <
> DISP_CC_MDSS_VSYNC_CLK>;
> assigned-clock-rates = <3>,
><1920>;
> + operating-points-v2 = <_opp_table>;
> + power-domains = < SDM845_CX>;
>
> interrupt-parent = <>;
> interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> @@ -3364,6 +3395,30 @@
> };
> };
> };
> +
> + mdp_opp_table: mdp-opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-1920 {
> + opp-hz = /bits/ 64 <1920>;
> + required-opps =
> <_opp_min_svs>;
> + };
> +
> + opp-171428571 {
> + opp-hz = /bits/ 64
> <171428571>;
> + required-opps =
> <_opp_low_svs>;
> + };
> +
> + opp-34400 {
> + opp-hz = /bits/ 64
> <34400>;
> + required-opps =
> <_opp_svs_l1>;
> + };
> +
> + opp-43000 {
> + opp-hz = /bits/ 64
> <43000>;
> + required-opps =
> <_opp_nom>;
> + };
> + };
> };
>
> dsi0: dsi@ae94000 {
> @@ -3386,6 +3441,8 @@
> "core",
> "iface",
> "bus";
> + operating-points-v2 = <_opp_table>;
> + power-domains = < SDM845_CX>;
>
> phys = <_phy>;
> phy-names = "dsi";
> @@ -3450,6 +3507,8 @@
> "core",
> "iface",
> "bus";
> + operating-points-v2 = <_opp_table>;
> + power-domains = < SDM845_CX>;
>
>
Re: [PATCH v2] drm: msm: a6xx: fix gpu failure after system resume
Hi, On Fri, Jul 17, 2020 at 7:46 AM Jordan Crouse wrote: > > On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote: > > On targets where GMU is available, GMU takes over the ownership of GX GDSC > > during its initialization. So, move the refcount-get on GX PD before we > > initialize the GMU. This ensures that nobody can collapse the GX GDSC > > once GMU owns the GX GDSC. This patch fixes some GMU OOB errors seen > > during GPU wake up during a system resume. > > > Signed-off-by: Akhil P Oommen > > Reported-by: Matthias Kaehlcke > > Tested-by: Matthias Kaehlcke > > The Signed-off-by needs to be at the end but I think Rob can do that for you. It does? I've always been told that this is supposed to be roughly a log of what happens. In that sense you added your SoB before the review/test happened so it should come before. I know some maintainers seem to do things differently but that seems to be the most common. In that sense, I think the order that Akhil has is correct. ...but, obviously, it's up to the maintainer. ;-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: Use platform_get_irq_optional() to get optional IRQs
On Thu, Jul 16, 2020 at 7:51 AM Nicolas Saenz Julienne
wrote:
>
> Aside from being more correct, the non optional version of the function
> prints an error when failing to find the IRQ.
>
> Fixes: eea9b97b4504 ("drm/v3d: Add support for V3D v4.2")
> Signed-off-by: Nicolas Saenz Julienne
> ---
> drivers/gpu/drm/v3d/v3d_irq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
> index c88686489b88..0be2eb7876be 100644
> --- a/drivers/gpu/drm/v3d/v3d_irq.c
> +++ b/drivers/gpu/drm/v3d/v3d_irq.c
> @@ -217,7 +217,7 @@ v3d_irq_init(struct v3d_dev *v3d)
> V3D_CORE_WRITE(core, V3D_CTL_INT_CLR, V3D_CORE_IRQS);
> V3D_WRITE(V3D_HUB_INT_CLR, V3D_HUB_IRQS);
>
> - irq1 = platform_get_irq(v3d_to_pdev(v3d), 1);
> + irq1 = platform_get_irq_optional(v3d_to_pdev(v3d), 1);
> if (irq1 == -EPROBE_DEFER)
> return irq1;
> if (irq1 > 0) {
> --
Reviewed-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/tegra: Changes for v5.9-rc1
Hi Dave, The following changes since commit fce3a51d9b31312aa12ecb72ffabfc4c7b40bdc6: drm/tegra: Add zpos property for cursor planes (2020-06-16 19:03:25 +0200) are available in the Git repository at: ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.9-rc1 for you to fetch changes up to 4fba6d22ca9ad28b8871d763b35a4da2e1ca272e: drm/tegra: plane: Support 180° rotation (2020-07-17 16:06:17 +0200) Note that I've supplied the ssh:// URL above as opposed to the git:// URL that I usually use. The latter has been somewhat spotty for me. Let me know if this is causing any issues. Thanks, Thierry drm/tegra: Changes for v5.9-rc1 This set of patches contains a few preparatory patches to enable video capture support from external camera modules. This is a dependency for the V4L2 driver patches that will likely be merged in v5.9 or v5.10. On top of that there are a couple of fixes across the board as well as some improvements. From a feature point of view this also adds support for horizontal reflection and 180° rotation of planes. Dmitry Osipenko (9): gpu: host1x: Optimize BOs usage when firewall is enabled gpu: host1x: Put gather's BO on pinning error gpu: host1x: debug: Fix multiple channels emitting messages simultaneously gpu: host1x: debug: Dump push buffer state drm/tegra: gr3d: Assert reset before power-gating drm/tegra: gr2d: Add tiled PATBASE address register drm/tegra: plane: Rename bottom_up to reflect_y drm/tegra: plane: Support horizontal reflection drm/tegra: plane: Support 180° rotation Sowjanya Komatineni (3): gpu: host1x: mipi: Update tegra_mipi_request() to be node based gpu: host1x: mipi: Use readl_relaxed_poll_timeout() in tegra_mipi_wait() gpu: host1x: mipi: Split tegra_mipi_calibrate() and tegra_mipi_wait() Tang Bin (1): drm/tegra: dc: Omit superfluous error message in tegra_dc_probe() Thierry Reding (1): drm/tegra: sor: Use correct power supply names for HDMI drivers/gpu/drm/tegra/dc.c | 50 ++-- drivers/gpu/drm/tegra/dc.h | 3 ++- drivers/gpu/drm/tegra/dsi.c | 9 ++-- drivers/gpu/drm/tegra/gr2d.c | 1 + drivers/gpu/drm/tegra/gr2d.h | 1 + drivers/gpu/drm/tegra/gr3d.c | 2 ++ drivers/gpu/drm/tegra/plane.c| 3 ++- drivers/gpu/drm/tegra/plane.h| 3 ++- drivers/gpu/drm/tegra/sor.c | 4 ++-- drivers/gpu/host1x/debug.c | 4 drivers/gpu/host1x/hw/debug_hw.c | 6 + drivers/gpu/host1x/job.c | 27 -- drivers/gpu/host1x/mipi.c| 37 - include/linux/host1x.h | 4 +++- 14 files changed, 111 insertions(+), 43 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hello Eugeniu, On Mon, Jun 15, 2020 at 04:17:23PM +0200, Eugeniu Rosca wrote: > Hi Jacopo, > > On Fri, Jun 12, 2020 at 05:12:09PM +0200, Jacopo Mondi wrote: > > On Mon, Jun 08, 2020 at 11:44:32AM +0200, Eugeniu Rosca wrote: > > > FWIW, I seem to hit pre-existing issues in vanilla rcar-du, > > > while unplugging HDMI cable during a cyclic suspend-resume: > > > > > > HW: H3 ES2.0 Salvator-X > > > SW: renesas-drivers-2020-06-02-v5.7 > > > .config: renesas_defconfig +CONFIG_PM_DEBUG +CONFIG_PM_ADVANCED_DEBUG > > > Use-case: > > > > > > 8<- > > > $ cat s2ram.sh > > > modprobe i2c-dev > > > echo 9 > /proc/sys/kernel/printk > > > i2cset -f -y 7 0x30 0x20 0x0F > > > > According to > > https://elinux.org/R-Car/Boards/Salvator-X#Suspend-to-RAM > > this is not needed anymore > > Good to know. Thanks for the useful remark. > > > > echo 0 > /sys/module/suspend/parameters/pm_test_delay > > > echo core > /sys/power/pm_test > > > echo deep > /sys/power/mem_sleep > > > echo 1 > /sys/power/pm_debug_messages > > > echo 0 > /sys/power/pm_print_times > > > echo mem > /sys/power/state > > > > > > $ while true; do sh s2ram.sh ; done > > > $ # unplug HDMI cable several times > > > > I tried unplugging an plugging the cable while the system was > > suspended and after resume but I was not able to reproduce anything. > > Your comment sounds like you suspended the system once and resumed it > afterwards, while my description mentions "cyclic" :), meaning: > > $ while true; do sh s2ram.sh; done > $ # connect-disconnect the hdmi display a couple of times > $ # NOTE: to avoid this manual step, I am thinking of a USB-controlled > HDMI switcher long-term > > > > > Could you provide more precise instructions on how to reproduce this ? > > I.e. when to disconnect the cable to trigger the below error. > > See above :) > > BTW, using renesas-drivers-2020-06-02-v5.7 as base and performing the > use-case just described, I got today (with minimal effort): > > [ 459.321733] Enabling non-boot CPUs ... > [ 459.331132] Detected PIPT I-cache on CPU1 > [ 459.331189] CPU1: Booted secondary processor 0x01 [0x411fd073] > [ 459.332312] CPU1 is up > [ 459.345635] Detected PIPT I-cache on CPU2 > [ 459.345671] CPU2: Booted secondary processor 0x02 [0x411fd073] > [ 459.346624] CPU2 is up > [ 459.359912] Detected PIPT I-cache on CPU3 > [ 459.359942] CPU3: Booted secondary processor 0x03 [0x411fd073] > [ 459.360918] CPU3 is up > [ 459.374183] Detected VIPT I-cache on CPU4 > [ 459.374252] CPU4: Booted secondary processor 0x000100 [0x410fd034] > [ 459.375875] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: > 119 KHz > [ 459.394204] cpufreq: cpufreq_online: CPU4: Unlisted initial frequency > changed to: 120 KHz > [ 459.403879] CPU4 is up > [ 459.406469] Detected VIPT I-cache on CPU5 > [ 459.406519] CPU5: Booted secondary processor 0x000101 [0x410fd034] > [ 459.408520] CPU5 is up > [ 459.421762] Detected VIPT I-cache on CPU6 > [ 459.421810] CPU6: Booted secondary processor 0x000102 [0x410fd034] > [ 459.423831] CPU6 is up > [ 459.437114] Detected VIPT I-cache on CPU7 > [ 459.437164] CPU7: Booted secondary processor 0x000103 [0x410fd034] > [ 459.439258] CPU7 is up > [ 459.456217] PM: noirq resume of devices complete after 3.878 msecs > [ 459.471529] PM: early resume of devices complete after 8.590 msecs > [ 469.726906] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CRTC:76:crtc-3] flip_done timed out I've been able to reproduce this same issue, but I see that errors in drm_atomic_helper_wait_for_dependencies always follow a first failure in drm_atomic_helper_wait_for_flip_done Looking at the log what I see is that [ 160.488762] PM: late suspend of devices complete after 10.509 msecs [ 171.235584] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:75:crtc-1] flip_done timed out The 10 second elapsed there matches the timout in drm_atomic_helper_wait_for_flip_done and it seems the issue is related to the first atomic commit after resume not being able to succesfully receive a flip_done event, possibly as the HDMI connector has been disconnected while the system was suspending or suspended and the DRM state was not updated. Can you confirm you see the same failure sequence ? Thanks j ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: msm: a6xx: fix gpu failure after system resume
On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote:
> On targets where GMU is available, GMU takes over the ownership of GX GDSC
> during its initialization. So, move the refcount-get on GX PD before we
> initialize the GMU. This ensures that nobody can collapse the GX GDSC
> once GMU owns the GX GDSC. This patch fixes some GMU OOB errors seen
> during GPU wake up during a system resume.
> Signed-off-by: Akhil P Oommen
> Reported-by: Matthias Kaehlcke
> Tested-by: Matthias Kaehlcke
The Signed-off-by needs to be at the end but I think Rob can do that for you.
Reviewed-by: Jordan Crouse
> ---
> Changes from v1:
> - Reworded the commit text
> - Added Reported-by & Tested-by tags
>
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 21e77d6..1d33020 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -854,10 +854,19 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> /* Turn on the resources */
> pm_runtime_get_sync(gmu->dev);
>
> + /*
> + * "enable" the GX power domain which won't actually do anything but it
> + * will make sure that the refcounting is correct in case we need to
> + * bring down the GX after a GMU failure
> + */
> + if (!IS_ERR_OR_NULL(gmu->gxpd))
> + pm_runtime_get_sync(gmu->gxpd);
> +
> /* Use a known rate to bring up the GMU */
> clk_set_rate(gmu->core_clk, 2);
> ret = clk_bulk_prepare_enable(gmu->nr_clocks, gmu->clocks);
> if (ret) {
> + pm_runtime_put(gmu->gxpd);
> pm_runtime_put(gmu->dev);
> return ret;
> }
> @@ -903,19 +912,12 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> else
> a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
>
> - /*
> - * "enable" the GX power domain which won't actually do anything but it
> - * will make sure that the refcounting is correct in case we need to
> - * bring down the GX after a GMU failure
> - */
> - if (!IS_ERR_OR_NULL(gmu->gxpd))
> - pm_runtime_get(gmu->gxpd);
> -
> out:
> /* On failure, shut down the GMU to leave it in a good state */
> if (ret) {
> disable_irq(gmu->gmu_irq);
> a6xx_rpmh_stop(gmu);
> + pm_runtime_put(gmu->gxpd);
> pm_runtime_put(gmu->dev);
> }
>
> --
> 2.7.4
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Fri, Jul 17, 2020 at 02:43:52AM +0200, Karol Herbst wrote:
On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> >
> > Hi everybody,
> >
> > with the mentioned commit Nouveau isn't able to load firmware onto the
> > GPU on one of my systems here. Even though the issue doesn't always
> > happen I am quite confident this is the commit breaking it.
> >
> > I am still digging into the issue and trying to figure out what
> > exactly breaks, but it shows up in different ways. Either we are not
> > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > Btw, this is also a system where our runtime power management issue
> > shows up, so maybe there is indeed something funky with the bridge
> > controller.
> >
> > Just pinging you in case you have an idea on how this could break Nouveau
> >
> > most of the times it shows up like this:
> > nouveau :01:00.0: acr: AHESASC binary failed
> >
> > Sometimes it works at boot and fails at runtime resuming with random
> > faults. So I will be investigating a bit more, but yeah... I am super
> > sure the commit triggered this issue, no idea if it actually causes
> > it.
>
> so yeah.. I reverted that locally and never ran into issues again.
> Still valid on latest 5.7. So can we get this reverted or properly
> fixed? This breaks runtime pm for us on at least some hardware.
Yeah, that stinks. We had another similar report from Patrick:
https://lore.kernel.org/r/caerspo5stek_my1dehwp7ahd0xop87+ohywktjbl7algdbx...@mail.gmail.com
Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
DLL Link Active train links in 100 ms"), which Patrick found was
backported to v5.4.49 as 828b192c57e8, and you found was backported to
v5.7.6 as afaff825e3a4.
Oddly, Patrick reported that v5.7.7 worked correctly, even though it
still contains afaff825e3a4.
I guess in the absence of any other clues we'll have to revert it.
I hate to do that because that means we'll have slow resume of
Thunderbolt-connected devices again, but that's better than having
GPUs completely broken.
Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
and to this thread?
There must be a way to fix the slow resume problem without breaking
the GPUs.
I wouldn't be surprised if this is related to the Intel bridge we
check against for Nouveau.. I still have to check on another laptop
with the same bridge our workaround was required as well but wouldn't
be surprised if it shows the same problem. Will get you the
information from both systems tomorrow then.
I take it that ec411e02b7a2 will be reverted upstream?
--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/4] MAINTAINERS: Add entry for i.MX 8MQ DCSS driver
From: Laurentiu Palcu The driver is part of DRM subsystem and is located in drivers/gpu/drm/imx/dcss. Signed-off-by: Laurentiu Palcu --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index dad5a62d21a7..200c5985b41f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12276,6 +12276,14 @@ F: drivers/iio/gyro/fxas21002c_core.c F: drivers/iio/gyro/fxas21002c_i2c.c F: drivers/iio/gyro/fxas21002c_spi.c +NXP i.MX 8MQ DCSS DRIVER +M: Laurentiu Palcu +R: Lucas Stach +L: dri-devel@lists.freedesktop.org +S: Maintained +F: Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml +F: drivers/gpu/drm/imx/dcss/ + NXP SGTL5000 DRIVER M: Fabio Estevam L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/4] Add support for iMX8MQ Display Controller Subsystem
From: Laurentiu Palcu Hi, This patchset adds initial DCSS support for iMX8MQ chip. Initial support includes only graphics plane support (no video planes), no HDR10 capabilities, no graphics decompression (only linear, tiled and super-tiled buffers allowed). Support for the rest of the features will be added incrementally, in subsequent patches. The patchset was tested with both HDP driver (in the downstream tree) and the upstream MIPI-DSI driver (with a couple of patches on top, to make it work correctly with DCSS). Thanks, Laurentiu Changes in v6: * Addressed Rob's comment and added "additionalProperties: false" at the end of the bindings' properties. However, this change surfaced an issue with the assigned-clock* properties not being documented in the properties section. Added the descriptions and the bindings patch will need another review; * Added an entry for DCSS driver in the MAINTAINERS file; * Removed the component framework patch altogether; Changes in v5: * Rebased to latest; * Took out component framework support and made it a separate patch so that people can still test with HDP driver, which makes use of it. But the idea is to get rid of it once HDP driver's next versions will remove component framework as well; * Slight improvement to modesetting: avoid cutting off the pixel clock if the new mode and the old one are equal. Also, in this case, is not necessary to wait for DTG to shut off. This would allow to switch from 8b RGB to 12b YUV422, for example, with no interruptions (at least from DCSS point of view); * Do not fire off CTXLD when going to suspend, unless it still has entries that need to be committed to DCSS; * Addressed Rob's comments on bindings; Changes in v4: * Addressed Lucas and Philipp's comments: * Added DRM_KMS_CMA_HELPER dependency in Kconfig; * Removed usage of devm_ functions since I'm already doing all the clean-up in the submodules_deinit(); * Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); * Removed en_completion variable from dcss_crtc since this was introduced mainly to avoid vblank timeout warnings which were fixed by arming the vblank event in flush() instead of begin(); * Removed clks_on and irq_enabled flags since all the calls to enabling/disabling clocks and interrupts were balanced; * Removed the custom atomic_commit callback and used the DRM core helper and, in the process, got rid of a workqueue that wasn't necessary anymore; * Fixed some minor DT binding issues flagged by Philipp; * Some other minor changes suggested by Lucas; * Removed YUV formats from the supported formats as these cannot work without the HDR10 module CSCs and LUTs. Will add them back when I will add support for video planes; Changes in v3: * rebased to latest linux-next and made it compile as drmP.h was removed; * removed the patch adding the VIDEO2_PLL clock. It's already applied; * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set(); * fixed a a spurious hang reported by Lukas Hartmann and encountered by me several times; * mask DPR and DTG interrupts by default, as they may come enabled from U-boot; Changes in v2: * Removed '0x' in node's unit-address both in DT and yaml; * Made the address region size lowercase, to be consistent; * Removed some left-over references to P010; * Added a Kconfig dependency of DRM && ARCH_MXC. This will also silence compilation issues reported by kbuild for other architectures; Laurentiu Palcu (4): drm/imx: compile imx directory by default drm/imx: Add initial support for DCSS on iMX8MQ MAINTAINERS: Add entry for i.MX 8MQ DCSS driver dt-bindings: display: imx: add bindings for DCSS .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 +++ MAINTAINERS | 8 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/imx/Kconfig | 2 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dcss/Kconfig | 9 + drivers/gpu/drm/imx/dcss/Makefile | 6 + drivers/gpu/drm/imx/dcss/dcss-blkctl.c| 70 ++ drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 + drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 + drivers/gpu/drm/imx/dcss/dcss-dev.c | 314 +++ drivers/gpu/drm/imx/dcss/dcss-dev.h | 177 drivers/gpu/drm/imx/dcss/dcss-dpr.c | 562 drivers/gpu/drm/imx/dcss/dcss-drv.c | 138 +++ drivers/gpu/drm/imx/dcss/dcss-dtg.c | 409 + drivers/gpu/drm/imx/dcss/dcss-kms.c | 177 drivers/gpu/drm/imx/dcss/dcss-kms.h | 43 + drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 + drivers/gpu/drm/imx/dcss/dcss-scaler.c| 826 ++ drivers/gpu/drm/imx/dcss/dcss-ss.c| 180 20 files changed, 4075 insertions(+), 1
[PATCH v6 2/4] drm/imx: Add initial support for DCSS on iMX8MQ
From: Laurentiu Palcu This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS). Some of its capabilities include: * 4K@60fps; * HDR10; * one graphics and 2 video pipelines; * on-the-fly decompression of compressed video and graphics; The reference manual can be found here: https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM The current patch adds only basic functionality: one primary plane for graphics, linear, tiled and super-tiled buffers support (no graphics decompression yet), no HDR10 and no video planes. Video planes support and HDR10 will be added in subsequent patches once per-plane de-gamma/CSC/gamma support is in. Signed-off-by: Laurentiu Palcu Reviewed-by: Lucas Stach --- drivers/gpu/drm/imx/Kconfig| 2 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dcss/Kconfig | 9 + drivers/gpu/drm/imx/dcss/Makefile | 6 + drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 70 +++ drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 +++ drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 + drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++ drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++ drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 + drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 + drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++ drivers/gpu/drm/imx/dcss/dcss-kms.h| 43 ++ drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 + drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++ 17 files changed, 3962 insertions(+) create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig create mode 100644 drivers/gpu/drm/imx/dcss/Makefile create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig index 207bf7409dfb..6231048aa5aa 100644 --- a/drivers/gpu/drm/imx/Kconfig +++ b/drivers/gpu/drm/imx/Kconfig @@ -39,3 +39,5 @@ config DRM_IMX_HDMI depends on DRM_IMX help Choose this if you want to use HDMI on i.MX6. + +source "drivers/gpu/drm/imx/dcss/Kconfig" diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile index 21cdcc2faabc..b644deffe948 100644 --- a/drivers/gpu/drm/imx/Makefile +++ b/drivers/gpu/drm/imx/Makefile @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/ diff --git a/drivers/gpu/drm/imx/dcss/Kconfig b/drivers/gpu/drm/imx/dcss/Kconfig new file mode 100644 index ..988979bc22cc --- /dev/null +++ b/drivers/gpu/drm/imx/dcss/Kconfig @@ -0,0 +1,9 @@ +config DRM_IMX_DCSS + tristate "i.MX8MQ DCSS" + select RESET_CONTROLLER + select IMX_IRQSTEER + select DRM_KMS_CMA_HELPER + depends on DRM && ARCH_MXC + help + Choose this if you have a NXP i.MX8MQ based system and want to use the + Display Controller Subsystem. This option enables DCSS support. diff --git a/drivers/gpu/drm/imx/dcss/Makefile b/drivers/gpu/drm/imx/dcss/Makefile new file mode 100644 index ..8c7c8da42792 --- /dev/null +++ b/drivers/gpu/drm/imx/dcss/Makefile @@ -0,0 +1,6 @@ +imx-dcss-objs := dcss-drv.o dcss-dev.o dcss-blkctl.o dcss-ctxld.o dcss-dtg.o \ +dcss-ss.o dcss-dpr.o dcss-scaler.o dcss-kms.o dcss-crtc.o \ +dcss-plane.o + +obj-$(CONFIG_DRM_IMX_DCSS) += imx-dcss.o + diff --git a/drivers/gpu/drm/imx/dcss/dcss-blkctl.c b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c new file mode 100644 index ..c9b54bb2692d --- /dev/null +++ b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c @@ -0,0 +1,70 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright 2019 NXP. + */ + +#include +#include +#include + +#include "dcss-dev.h" + +#define DCSS_BLKCTL_RESET_CTRL 0x00 +#define B_CLK_RESETN BIT(0) +#define APB_CLK_RESETN BIT(1) +#define P_CLK_RESETN BIT(2) +#define RTR_CLK_RESETN BIT(4) +#define DCSS_BLKCTL_CONTROL0 0x10 +#define HDMI_MIPI_CLK_SELBIT(0) +#define
[PATCH v6 4/4] dt-bindings: display: imx: add bindings for DCSS
From: Laurentiu Palcu
Add bindings for iMX8MQ Display Controller Subsystem.
Signed-off-by: Laurentiu Palcu
---
.../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
new file mode 100644
index ..68e4635e4874
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 NXP
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: iMX8MQ Display Controller Subsystem (DCSS)
+
+maintainers:
+ - Laurentiu Palcu
+
+description:
+
+ The DCSS (display controller sub system) is used to source up to three
+ display buffers, compose them, and drive a display using HDMI 2.0a(with HDCP
+ 2.2) or MIPI-DSI. The DCSS is intended to support up to 4kp60 displays. HDR10
+ image processing capabilities are included to provide a solution capable of
+ driving next generation high dynamic range displays.
+
+properties:
+ compatible:
+const: nxp,imx8mq-dcss
+
+ reg:
+items:
+ - description: DCSS base address and size, up to IRQ steer start
+ - description: DCSS BLKCTL base address and size
+
+ interrupts:
+items:
+ - description: Context loader completion and error interrupt
+ - description: DTG interrupt used to signal context loader trigger time
+ - description: DTG interrupt for Vblank
+
+ interrupt-names:
+items:
+ - const: ctxld
+ - const: ctxld_kick
+ - const: vblank
+
+ clocks:
+items:
+ - description: Display APB clock for all peripheral PIO access interfaces
+ - description: Display AXI clock needed by DPR, Scaler, RTRAM_CTRL
+ - description: RTRAM clock
+ - description: Pixel clock, can be driven either by HDMI phy clock or
MIPI
+ - description: DTRC clock, needed by video decompressor
+
+ clock-names:
+items:
+ - const: apb
+ - const: axi
+ - const: rtrm
+ - const: pix
+ - const: dtrc
+
+ assigned-clocks:
+items:
+ - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_AXI_ROOT
+ - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_RTRM
+ - description: Phandle and clock specifier of either
IMX8MQ_VIDEO2_PLL1_REF_SEL or
+ IMX8MQ_VIDEO_PLL1_REF_SEL
+
+ assigned-clock-parents:
+items:
+ - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
+ - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
+ - description: Phandle and clock specifier of IMX8MQ_CLK_27M
+
+ assigned-clock-rates:
+items:
+ - description: Must be 800 MHz
+ - description: Must be 400 MHz
+
+ port:
+type: object
+description:
+ A port node pointing to the input port of a HDMI/DP or MIPI display
bridge.
+
+additionalProperties: false
+
+examples:
+ - |
+dcss: display-controller@32e0 {
+compatible = "nxp,imx8mq-dcss";
+reg = <0x32e0 0x2d000>, <0x32e2f000 0x1000>;
+interrupts = <6>, <8>, <9>;
+interrupt-names = "ctxld", "ctxld_kick", "vblank";
+interrupt-parent = <>;
+clocks = < 248>, < 247>, < 249>,
+ < 254>,< 122>;
+clock-names = "apb", "axi", "rtrm", "pix", "dtrc";
+assigned-clocks = < 107>, < 109>, < 266>;
+assigned-clock-parents = < 78>, < 78>, < 3>;
+assigned-clock-rates = <8>,
+ <4>;
+port {
+dcss_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/4] drm/imx: compile imx directory by default
From: Laurentiu Palcu Currently the drm/imx/ directory is compiled only if DRM_IMX is set. Adding a new IMX related IP in the same directory would need DRM_IMX to be set, which would bring in also IPUv3 core driver... The current patch would allow adding new IPs in the imx/ directory without needing to set DRM_IMX. Signed-off-by: Laurentiu Palcu Reviewed-by: Lucas Stach --- drivers/gpu/drm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c0e5a7e5953..c4d12e756c63 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -100,7 +100,7 @@ obj-$(CONFIG_DRM_MSM) += msm/ obj-$(CONFIG_DRM_TEGRA) += tegra/ obj-$(CONFIG_DRM_STM) += stm/ obj-$(CONFIG_DRM_STI) += sti/ -obj-$(CONFIG_DRM_IMX) += imx/ +obj-y += imx/ obj-$(CONFIG_DRM_INGENIC) += ingenic/ obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ obj-$(CONFIG_DRM_MESON)+= meson/ -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: msm: a6xx: fix gpu failure after system resume
On targets where GMU is available, GMU takes over the ownership of GX GDSC
during its initialization. So, move the refcount-get on GX PD before we
initialize the GMU. This ensures that nobody can collapse the GX GDSC
once GMU owns the GX GDSC. This patch fixes some GMU OOB errors seen
during GPU wake up during a system resume.
Signed-off-by: Akhil P Oommen
Reported-by: Matthias Kaehlcke
Tested-by: Matthias Kaehlcke
---
Changes from v1:
- Reworded the commit text
- Added Reported-by & Tested-by tags
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 21e77d6..1d33020 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -854,10 +854,19 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
/* Turn on the resources */
pm_runtime_get_sync(gmu->dev);
+ /*
+* "enable" the GX power domain which won't actually do anything but it
+* will make sure that the refcounting is correct in case we need to
+* bring down the GX after a GMU failure
+*/
+ if (!IS_ERR_OR_NULL(gmu->gxpd))
+ pm_runtime_get_sync(gmu->gxpd);
+
/* Use a known rate to bring up the GMU */
clk_set_rate(gmu->core_clk, 2);
ret = clk_bulk_prepare_enable(gmu->nr_clocks, gmu->clocks);
if (ret) {
+ pm_runtime_put(gmu->gxpd);
pm_runtime_put(gmu->dev);
return ret;
}
@@ -903,19 +912,12 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
else
a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
- /*
-* "enable" the GX power domain which won't actually do anything but it
-* will make sure that the refcounting is correct in case we need to
-* bring down the GX after a GMU failure
-*/
- if (!IS_ERR_OR_NULL(gmu->gxpd))
- pm_runtime_get(gmu->gxpd);
-
out:
/* On failure, shut down the GMU to leave it in a good state */
if (ret) {
disable_irq(gmu->gmu_irq);
a6xx_rpmh_stop(gmu);
+ pm_runtime_put(gmu->gxpd);
pm_runtime_put(gmu->dev);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: msm: a6xx: fix gpu failure after system resume
On 7/15/2020 12:12 AM, Rob Clark wrote: On Tue, Jul 14, 2020 at 10:10 AM Matthias Kaehlcke wrote: On Tue, Jul 14, 2020 at 06:55:30PM +0530, Akhil P Oommen wrote: On targets where GMU is available, GMU takes over the ownership of GX GDSC during its initialization. So, take a refcount on the GX PD on behalf of GMU before we initialize it. This makes sure that nobody can collapse the GX GDSC once GMU owns the GX GDSC. This patch fixes some weird failures during GPU wake up during system resume. Signed-off-by: Akhil P Oommen I went through a few dozen suspend/resume cycles on SC7180 and didn't run into the kernel panic that typically occurs after a few iterations without this patch. Reported-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke On which tree is this patch based on? I had to apply it manually because 'git am' is unhappy when I try to apply it: error: sha1 information is lacking or useless (drivers/gpu/drm/msm/adreno/a6xx_gmu.c). error: could not build fake ancestor Both upstream and drm-msm are in my remotes and synced, so I suspect it's some private tree. Please make sure to base patches on the corresponding maintainer tree or upstream, whichs makes life easier for maintainers, testers and reviewers. I've run into the same issue frequently :-( BR, -R Sorry, I was using msm-next brand as the base, but had the opp-next branch merged too inadvertently. -Akhil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] gpu: host1x: Convert to DEFINE_SHOW_ATTRIBUTE
On Fri, Jul 17, 2020 at 09:32:21AM +0800, miaoqinglang wrote: > > 在 2020/7/16 21:34, Thierry Reding 写道: > > On Thu, Jul 16, 2020 at 05:03:23PM +0800, Qinglang Miao wrote: > > > From: Yongqiang Liu > > > > > > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > > > > > Signed-off-by: Yongqiang Liu > > > --- > > > drivers/gpu/host1x/debug.c | 28 > > > 1 file changed, 4 insertions(+), 24 deletions(-) > > This doesn't apply. Can you please resend, based on something like > > linux-next? > > > > Thanks, > > Thierry > Hi, Thierry > > Sorry I didn't mention it in commit log, but this patch is based on > linux-next where commit <4d4901c6d7> has switched over direct seq_read > method calls to seq_read_iter, this is why there's conflict in your apply. > > Do you think I should send a new patch based on 5.8rc? No need to. I'm about to send out the pull request for v5.9-rc1, so I'll just defer this to v5.10 since it doesn't look like it's anything urgent. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
Am 17.07.20 um 04:27 schrieb Laurent Pinchart: Hi Christian, On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote: On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote: Am 21.06.20 um 04:07 schrieb Laurent Pinchart: Most of the DRM drivers uAPI headers are licensed under the MIT license, and carry copies of the license with slight variations. Replace them with SPDX headers. My personal opinion is that this is a really good idea, but my professional is that we need the acknowledgment from our legal department for this. I think official ack from amd on first patch, especially the .rst snippet, would be really good indeed. Any update on this one ? Sorry totally forgot to forward this because I was waiting for split up patches. Going to do so right now. Christian. Please separate that change into one for each driver/company/maintainer. Amdgpu, radeon, r128 can be one for example. I'll do so. You can leave all the other legacy drivers in one patch (mga, savage, sis, via), since there's likely no one around anymore and will just boil down to drm maintainer ack from Dave Signed-off-by: Laurent Pinchart --- include/uapi/drm/amdgpu_drm.h | 19 +-- include/uapi/drm/i915_drm.h| 22 +- include/uapi/drm/mga_drm.h | 20 +--- include/uapi/drm/msm_drm.h | 20 +--- include/uapi/drm/nouveau_drm.h | 20 +--- include/uapi/drm/qxl_drm.h | 20 +--- include/uapi/drm/r128_drm.h| 20 +--- include/uapi/drm/radeon_drm.h | 20 +--- include/uapi/drm/savage_drm.h | 20 +--- include/uapi/drm/sis_drm.h | 21 + include/uapi/drm/tegra_drm.h | 19 +-- include/uapi/drm/v3d_drm.h | 20 +--- include/uapi/drm/vc4_drm.h | 20 +--- include/uapi/drm/vgem_drm.h| 22 +- include/uapi/drm/via_drm.h | 20 +--- include/uapi/drm/virtgpu_drm.h | 20 +--- include/uapi/drm/vmwgfx_drm.h | 21 + 17 files changed, 17 insertions(+), 327 deletions(-) diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h index 4e873dcbe68f..c6adda72bec7 100644 --- a/include/uapi/drm/amdgpu_drm.h +++ b/include/uapi/drm/amdgpu_drm.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: MIT */ /* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c -*- * * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas. @@ -5,24 +6,6 @@ * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. * Copyright 2014 Advanced Micro Devices, Inc. * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. - * * Authors: *Kevin E. Martin *Gareth Hughes diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index 14b67cd6b54b..c29e3acb3026 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -1,27 +1,7 @@ +/* SPDX-License-Identifier: MIT */ /* * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas. * All Rights Reserved. - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the - * "Software"), to deal in the Software without restriction, including - * without limitation the rights to use, copy, modify, merge, publish, - * distribute, sub license, and/or sell copies of the Software, and to - * permit persons to whom the Software is furnished to do so, subject to - * the following conditions: - * - * The above copyright notice and this permission notice (including the - * next paragraph) shall be included in all copies or substantial portions - * of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS - * OR IMPLIED,
[PATCH] drm/todo: Plumb drm_atomic_state all over
From: Ville Syrjälä Add a TODO for plumbing drm_atomic_state all over to ease the hurdles of accessing additional object states. Reviewed-by: Daniel Vetter #irc Signed-off-by: Ville Syrjälä --- Documentation/gpu/todo.rst | 46 ++ 1 file changed, 46 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7969f106877d..b0ea17da8ff6 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -403,6 +403,52 @@ Contact: Emil Velikov, respective driver maintainers Level: Intermediate +Plumb drm_atomic_state all over +--- + +Currently various atomic functions take just a single or a handful of +object states (eg. plane state). While that single object state can +suffice for some simple cases, we often have to dig out additional +object states for dealing with various dependencies between the individual +objects or the hardware they represent. The process of digging out the +additional states is rather non-intuitive and error prone. + +To fix that most functions should rather take the overall +drm_atomic_state as one of their parameters. The other parameters +would generally be the object(s) we mainly want to interact with. + +For example, instead of + +.. code-block:: c + + int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state *state); + +we would have something like + +.. code-block:: c + + int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state *state); + +The implementation can then trivially gain access to any required object +state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(), +drm_atomic_get_old_plane_state(), and their equivalents for +other object types. + +Additionally many drivers currently access the object->state pointer +directly in their commit functions. That is not going to work if we +eg. want to allow deeper commit pipelines as those pointers could +then point to the states corresponding to a future commit instead of +the current commit we're trying to process. Also non-blocking commits +execute locklessly so there are serious concerns with dereferencing +the object->state pointers without holding the locks that protect them. +Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(), +etc. avoids these problems as well since they relate to a specific +commit via the passed in drm_atomic_state. + +Contact: Ville Syrjälä, Daniel Vetter + +Level: Intermediate + Core refactorings = -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 15/16] drm/i915: panel: Honor the VBT PWM min setting for devs with an external PWM controller
So far for devices using an external PWM controller (devices using pwm_setup_backlight()), we have been hardcoding the minimum allowed PWM level to 0. But several of these devices specify a non 0 minimum setting in their VBT. Change pwm_setup_backlight() to use get_backlight_min_vbt() to get the minimum level. Acked-by: Jani Nikula Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/intel_panel.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c index 14e611c92194..cb28b9908ca4 100644 --- a/drivers/gpu/drm/i915/display/intel_panel.c +++ b/drivers/gpu/drm/i915/display/intel_panel.c @@ -1925,8 +1925,8 @@ static int pwm_setup_backlight(struct intel_connector *connector, */ pwm_apply_args(panel->backlight.pwm); - panel->backlight.min = 0; /* 0% */ panel->backlight.max = 100; /* 100% */ + panel->backlight.min = get_backlight_min_vbt(connector); level = intel_panel_compute_brightness(connector, 100); ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100); @@ -1941,8 +1941,9 @@ static int pwm_setup_backlight(struct intel_connector *connector, level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100, panel->backlight.pwm_period_ns); - panel->backlight.level = - intel_panel_compute_brightness(connector, level); + level = intel_panel_compute_brightness(connector, level); + panel->backlight.level = clamp(level, panel->backlight.min, + panel->backlight.max); panel->backlight.enabled = panel->backlight.level != 0; drm_info(_priv->drm, "Using %s PWM for LCD backlight control\n", -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 16/16] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastset path.
Note that this commit also simplifies pwm_disable_backlight(), by dropping
the intel_panel_actually_set_backlight(..., 0) call. This call sets the
PWM to 0% duty-cycle. I believe that this call was only present as a
workaround for a bug in the pwm-crc.c driver where it failed to clear the
PWM_OUTPUT_ENABLE bit. This is fixed by an earlier patch in this series.
After the dropping of this workaround, the usleep call, which seems
unnecessary to begin with, has no useful effect anymore, so drop that too.
Acked-by: Jani Nikula
Signed-off-by: Hans de Goede
---
Changes in v4:
- Add a note to the commit message about the dropping of the
intel_panel_actually_set_backlight() and usleep() calls from
pwm_disable_backlight()
- Use the pwm_set/get_relative_duty_cycle() helpers instead of using DIY code
for this
---
.../drm/i915/display/intel_display_types.h| 3 +-
drivers/gpu/drm/i915/display/intel_panel.c| 71 +--
2 files changed, 34 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index de32f9efb120..4bd9981e70a1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -223,7 +224,7 @@ struct intel_panel {
bool util_pin_active_low; /* bxt+ */
u8 controller; /* bxt+ only */
struct pwm_device *pwm;
- int pwm_period_ns;
+ struct pwm_state pwm_state;
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index cb28b9908ca4..3d97267c8238 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -592,10 +592,10 @@ static u32 bxt_get_backlight(struct intel_connector
*connector)
static u32 pwm_get_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = >panel;
- int duty_ns;
+ struct pwm_state state;
- duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
- return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
+ pwm_get_state(panel->backlight.pwm, );
+ return pwm_get_relative_duty_cycle(, 100);
}
static void lpt_set_backlight(const struct drm_connector_state *conn_state,
u32 level)
@@ -669,10 +669,9 @@ static void bxt_set_backlight(const struct
drm_connector_state *conn_state, u32
static void pwm_set_backlight(const struct drm_connector_state *conn_state,
u32 level)
{
struct intel_panel *panel =
_intel_connector(conn_state->connector)->panel;
- int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
- pwm_config(panel->backlight.pwm, duty_ns,
- panel->backlight.pwm_period_ns);
+ pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
+ pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
}
static void
@@ -841,10 +840,8 @@ static void pwm_disable_backlight(const struct
drm_connector_state *old_conn_sta
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
- /* Disable the backlight */
- intel_panel_actually_set_backlight(old_conn_state, 0);
- usleep_range(2000, 3000);
- pwm_disable(panel->backlight.pwm);
+ panel->backlight.pwm_state.enabled = false;
+ pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
}
void intel_panel_disable_backlight(const struct drm_connector_state
*old_conn_state)
@@ -1176,9 +1173,12 @@ static void pwm_enable_backlight(const struct
intel_crtc_state *crtc_state,
{
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
+ int level = panel->backlight.level;
- pwm_enable(panel->backlight.pwm);
- intel_panel_actually_set_backlight(conn_state, panel->backlight.level);
+ level = intel_panel_compute_brightness(connector, level);
+ pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
+ panel->backlight.pwm_state.enabled = true;
+ pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
}
static void __intel_panel_enable_backlight(const struct intel_crtc_state
*crtc_state,
@@ -1897,8 +1897,7 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
struct drm_i915_private *dev_priv = to_i915(dev);
[PATCH v5 13/16] drm/i915: panel: Add get_vbt_pwm_freq() helper
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_panel.c | 27 ++
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 3c5056dbf607..8efdd9f08a08 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1543,18 +1543,9 @@ static u32 vlv_hz_to_pwm(struct intel_connector
*connector, u32 pwm_freq_hz)
return DIV_ROUND_CLOSEST(clock, pwm_freq_hz * mul);
}
-static u32 get_backlight_max_vbt(struct intel_connector *connector)
+static u16 get_vbt_pwm_freq(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct intel_panel *panel = >panel;
u16 pwm_freq_hz = dev_priv->vbt.backlight.pwm_freq_hz;
- u32 pwm;
-
- if (!panel->backlight.hz_to_pwm) {
- drm_dbg_kms(_priv->drm,
- "backlight frequency conversion not supported\n");
- return 0;
- }
if (pwm_freq_hz) {
drm_dbg_kms(_priv->drm,
@@ -1567,6 +1558,22 @@ static u32 get_backlight_max_vbt(struct intel_connector
*connector)
pwm_freq_hz);
}
+ return pwm_freq_hz;
+}
+
+static u32 get_backlight_max_vbt(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_panel *panel = >panel;
+ u16 pwm_freq_hz = get_vbt_pwm_freq(dev_priv);
+ u32 pwm;
+
+ if (!panel->backlight.hz_to_pwm) {
+ drm_dbg_kms(_priv->drm,
+ "backlight frequency conversion not supported\n");
+ return 0;
+ }
+
pwm = panel->backlight.hz_to_pwm(connector, pwm_freq_hz);
if (!pwm) {
drm_dbg_kms(_priv->drm,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 14/16] drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which greatly exceeds
the PWM_MAX_PERIOD_NS define in the Crystal Cove PMIC PWM driver, which
used to be 21333.
This PWM_MAX_PERIOD_NS define was actually based on a bug in the PWM
driver where its period and duty-cycle times where off by a factor of 256.
Due to this bug the hardcoded CRC_PMIC_PWM_PERIOD_NS value of 21333 would
result in the PWM driver using its divider of 128, which would result in
a PWM output frequency of 600 Hz / 256 / 128 = 183 Hz. So actually
pretty close to the default VBT value of 200 Hz.
Now that this bug in the pwm-crc driver is fixed, we can actually use
the VBT defined frequency.
This is important because:
a) With the pwm-crc driver fixed it will now translate the hardcoded
CRC_PMIC_PWM_PERIOD_NS value of 21333 ns / 46 Khz to a PWM output
frequency of 23 KHz (the max it can do).
b) The pwm-lpss driver used on many models has always honored the
21333 ns / 46 Khz request
Some panels do not like such high output frequencies. E.g. on a Terra
Pad 1061 tablet, using the LPSS PWM controller, the backlight would go
from off to max, when changing the sysfs backlight brightness value from
90-100%, anything under aprox. 90% would turn the backlight fully off.
Honoring the VBT specified PWM frequency will also hopefully fix the
various bug reports which we have received about users perceiving the
backlight to flicker after a suspend/resume cycle.
Acked-by: Jani Nikula
Signed-off-by: Hans de Goede
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_panel.c| 19 +++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 2bf3d4cb4ea9..de32f9efb120 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -223,6 +223,7 @@ struct intel_panel {
bool util_pin_active_low; /* bxt+ */
u8 controller; /* bxt+ only */
struct pwm_device *pwm;
+ int pwm_period_ns;
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 8efdd9f08a08..14e611c92194 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -40,8 +40,6 @@
#include "intel_dsi_dcs_backlight.h"
#include "intel_panel.h"
-#define CRC_PMIC_PWM_PERIOD_NS 21333
-
void
intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -597,7 +595,7 @@ static u32 pwm_get_backlight(struct intel_connector
*connector)
int duty_ns;
duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
- return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+ return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
}
static void lpt_set_backlight(const struct drm_connector_state *conn_state,
u32 level)
@@ -671,9 +669,10 @@ static void bxt_set_backlight(const struct
drm_connector_state *conn_state, u32
static void pwm_set_backlight(const struct drm_connector_state *conn_state,
u32 level)
{
struct intel_panel *panel =
_intel_connector(conn_state->connector)->panel;
- int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+ int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
- pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+ pwm_config(panel->backlight.pwm, duty_ns,
+ panel->backlight.pwm_period_ns);
}
static void
@@ -1917,6 +1916,9 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
return -ENODEV;
}
+ panel->backlight.pwm_period_ns = NSEC_PER_SEC /
+get_vbt_pwm_freq(dev_priv);
+
/*
* FIXME: pwm_apply_args() should be removed when switching to
* the atomic PWM API.
@@ -1926,9 +1928,10 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
panel->backlight.min = 0; /* 0% */
panel->backlight.max = 100; /* 100% */
level = intel_panel_compute_brightness(connector, 100);
- ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+ ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
- retval = pwm_config(panel->backlight.pwm, ns, CRC_PMIC_PWM_PERIOD_NS);
+ retval = pwm_config(panel->backlight.pwm, ns,
+ panel->backlight.pwm_period_ns);
if
[PATCH v5 10/16] pwm: crc: Enable/disable PWM output on enable/disable
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set it again on re-enable.
Acked-by: Uwe Kleine-König
Signed-off-by: Hans de Goede
---
Changes in v3:
- Remove paragraph about tri-stating the output from the commit message,
we don't have a datasheet so this was just an unfounded guess
---
drivers/pwm/pwm-crc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 81232da0c767..b72008c9b072 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -54,7 +54,9 @@ static int crc_pwm_calc_clk_div(int period_ns)
static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
{
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+ int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
+ regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div | PWM_OUTPUT_ENABLE);
regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
return 0;
@@ -63,8 +65,10 @@ static int crc_pwm_enable(struct pwm_chip *c, struct
pwm_device *pwm)
static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
{
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+ int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+ regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div);
}
static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enabled -> enabled transition there, so that we can error check
the entire transition in a single place and only have one pm_runtime_put()
on failure call site.
While working on this I noticed that the enabled -> enabled (update
settings) path was quite similar, so I've added an enable parameter to
the new pwm_lpss_prepare_enable() helper, which allows using it in that
path too.
Suggested-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-lpss.c | 45 --
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index da9bc3d10104..8a136ba2a583 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -122,41 +122,48 @@ static inline void pwm_lpss_cond_enable(struct pwm_device
*pwm, bool cond)
pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
}
+static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
+ struct pwm_device *pwm,
+ const struct pwm_state *state,
+ bool enable)
+{
+ int ret;
+
+ ret = pwm_lpss_is_updating(pwm);
+ if (ret)
+ return ret;
+
+ pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
+ pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
+ ret = pwm_lpss_wait_for_update(pwm);
+ if (ret)
+ return ret;
+
+ pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);
+ return 0;
+}
+
static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
- int ret;
+ int ret = 0;
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
- ret = pwm_lpss_is_updating(pwm);
- if (ret) {
- pm_runtime_put(chip->dev);
- return ret;
- }
- pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
state->period);
- pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
- ret = pwm_lpss_wait_for_update(pwm);
- if (ret) {
+ ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
+ if (ret)
pm_runtime_put(chip->dev);
- return ret;
- }
- pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
} else {
- ret = pwm_lpss_is_updating(pwm);
- if (ret)
- return ret;
- pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
state->period);
- return pwm_lpss_wait_for_update(pwm);
+ ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
pm_runtime_put(chip->dev);
}
- return 0;
+ return ret;
}
static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 11/16] pwm: crc: Implement apply() method to support the new atomic PWM API
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Signed-off-by: Hans de Goede
---
Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
drivers/pwm/pwm-crc.c | 89 ++-
1 file changed, 53 insertions(+), 36 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index b72008c9b072..8a7f4707279c 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -51,59 +51,76 @@ static int crc_pwm_calc_clk_div(int period_ns)
return clk_div;
}
-static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
+static int crc_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+const struct pwm_state *state)
{
- struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
- int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
-
- regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div | PWM_OUTPUT_ENABLE);
- regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
-
- return 0;
-}
-
-static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
-{
- struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
- int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
-
- regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
- regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div);
-}
-
-static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
- int duty_ns, int period_ns)
-{
- struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+ struct crystalcove_pwm *crc_pwm = to_crc_pwm(chip);
struct device *dev = crc_pwm->chip.dev;
- int level;
+ int err;
- if (period_ns > PWM_MAX_PERIOD_NS) {
+ if (state->period > PWM_MAX_PERIOD_NS) {
dev_err(dev, "un-supported period_ns\n");
return -EINVAL;
}
- if (pwm_get_period(pwm) != period_ns) {
- int clk_div = crc_pwm_calc_clk_div(period_ns);
+ if (state->polarity != PWM_POLARITY_NORMAL)
+ return -EOPNOTSUPP;
+
+ if (pwm_is_enabled(pwm) && !state->enabled) {
+ err = regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+ if (err) {
+ dev_err(dev, "Error writing BACKLIGHT_EN %d\n", err);
+ return err;
+ }
+ }
+
+ if (pwm_get_duty_cycle(pwm) != state->duty_cycle ||
+ pwm_get_period(pwm) != state->period) {
+ int level = state->duty_cycle * PWM_MAX_LEVEL / state->period;
+ err = regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
+ if (err) {
+ dev_err(dev, "Error writing PWM0_DUTY_CYCLE %d\n", err);
+ return err;
+ }
+ }
+
+ if (pwm_is_enabled(pwm) && state->enabled &&
+ pwm_get_period(pwm) != state->period) {
/* changing the clk divisor, clear PWM_OUTPUT_ENABLE first */
- regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
+ err = regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
+ if (err) {
+ dev_err(dev, "Error writing PWM0_CLK_DIV %d\n", err);
+ return err;
+ }
+ }
- regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
- clk_div | PWM_OUTPUT_ENABLE);
+ if (pwm_get_period(pwm) != state->period ||
+ pwm_is_enabled(pwm) != state->enabled) {
+ int clk_div = crc_pwm_calc_clk_div(state->period);
+ int pwm_output_enable = state->enabled ? PWM_OUTPUT_ENABLE : 0;
+
+ err = regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
+ clk_div | pwm_output_enable);
+ if (err) {
+ dev_err(dev, "Error writing PWM0_CLK_DIV %d\n", err);
+ return err;
+ }
}
- /* change the pwm duty cycle */
- level = duty_ns * PWM_MAX_LEVEL / period_ns;
- regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
+ if (!pwm_is_enabled(pwm) && state->enabled) {
+ err = regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
+ if (err) {
+ dev_err(dev, "Error writing BACKLIGHT_EN %d\n", err);
+ return err;
+ }
+ }
return 0;
}
static const struct pwm_ops crc_pwm_ops = {
- .config = crc_pwm_config,
- .enable = crc_pwm_enable,
- .disable = crc_pwm_disable,
+ .apply = crc_pwm_apply,
};
static int crystalcove_pwm_probe(struct platform_device *pdev)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 09/16] pwm: crc: Fix period changes not having any effect
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
controls a separate output-only GPIO which is connected to the LCD panels
backlight-enable input. Like how the PANEL_EN register at address 0x52
controls an output-only GPIO which is earmarked for the LCD panel's
enable pin. If this is correct then this GPIO should really be added to
the gpio-crystalcove.c driver and the PWM driver should stop poking it.
But I've been unable to come up with a definitive answer here, so I'm
keeping this as is for now.
As the comment in the old code already indicates we must disable the PWM
before we can change the clock divider. But the crc_pwm_disable() and
crc_pwm_enable() calls the old code make for this only change the
BACKLIGHT_EN register; and the value of that register does not matter for
changing the period / the divider. What does matter is that the
PWM_OUTPUT_ENABLE bit must be cleared before a new value can be written.
This commit modifies crc_pwm_config() to clear PWM_OUTPUT_ENABLE instead
when changing the period, so that period changes actually work.
Note this fix will cause a significant behavior change on some devices
using the CRC PWM output to drive their backlight. Before the PWM would
always run with the output frequency configured by the BIOS at boot, now
the period time specified by the i915 driver will actually be honored.
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-crc.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 44ec7d5b63e1..81232da0c767 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -82,14 +82,11 @@ static int crc_pwm_config(struct pwm_chip *c, struct
pwm_device *pwm,
if (pwm_get_period(pwm) != period_ns) {
int clk_div = crc_pwm_calc_clk_div(period_ns);
- /* changing the clk divisor, need to disable fisrt */
- crc_pwm_disable(c, pwm);
+ /* changing the clk divisor, clear PWM_OUTPUT_ENABLE first */
+ regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
-
- /* enable back */
- crc_pwm_enable(c, pwm);
}
/* change the pwm duty cycle */
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 12/16] pwm: crc: Implement get_state() method
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v5:
- Fix an indentation issue
Changes in v4:
- Use DIV_ROUND_UP when calculating the period and duty_cycle from the
controller's register values
Changes in v3:
- Add Andy's Reviewed-by tag
- Remove extra whitespace to align some code after assignments (requested by
Uwe Kleine-König)
---
drivers/pwm/pwm-crc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 8a7f4707279c..370ab826a20b 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -119,8 +119,39 @@ static int crc_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
return 0;
}
+static void crc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct crystalcove_pwm *crc_pwm = to_crc_pwm(chip);
+ struct device *dev = crc_pwm->chip.dev;
+ unsigned int clk_div, clk_div_reg, duty_cycle_reg;
+ int error;
+
+ error = regmap_read(crc_pwm->regmap, PWM0_CLK_DIV, _div_reg);
+ if (error) {
+ dev_err(dev, "Error reading PWM0_CLK_DIV %d\n", error);
+ return;
+ }
+
+ error = regmap_read(crc_pwm->regmap, PWM0_DUTY_CYCLE, _cycle_reg);
+ if (error) {
+ dev_err(dev, "Error reading PWM0_DUTY_CYCLE %d\n", error);
+ return;
+ }
+
+ clk_div = (clk_div_reg & ~PWM_OUTPUT_ENABLE) + 1;
+
+ state->period =
+ DIV_ROUND_UP(clk_div * NSEC_PER_USEC * 256, PWM_BASE_CLK_MHZ);
+ state->duty_cycle =
+ DIV_ROUND_UP(duty_cycle_reg * state->period, PWM_MAX_LEVEL);
+ state->polarity = PWM_POLARITY_NORMAL;
+ state->enabled = !!(clk_div_reg & PWM_OUTPUT_ENABLE);
+}
+
static const struct pwm_ops crc_pwm_ops = {
.apply = crc_pwm_apply,
+ .get_state = crc_pwm_get_state,
};
static int crystalcove_pwm_probe(struct platform_device *pdev)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.
The LPSS PWM controller has a mechanism where the ctrl register value
and the actual base-unit and on-time-div values used are latched. When
software sets the SW_UPDATE bit then at the end of the current PWM cycle,
the new values from the ctrl-register will be latched into the actual
registers, and the SW_UPDATE bit will be cleared.
The problem is that before this commit our suspend/resume handling
consisted of simply saving the PWM ctrl register on suspend and
restoring it on resume, without setting the PWM_SW_UPDATE bit.
When the controller has lost its state over a suspend/resume and thus
has been reset to the defaults, just restoring the register is not
enough. We must also set the SW_UPDATE bit to tell the controller to
latch the restored values into the actual registers.
Fixing this problem is not as simple as just or-ing in the value which
is being restored with SW_UPDATE. If the PWM was enabled before we must
write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
model we must do this either before or after the setting of PWM_ENABLE.
All the necessary logic for doing this is already present inside
pwm_lpss_apply(), so instead of duplicating this inside the resume
handler, this commit makes the resume handler use pwm_lpss_apply() to
restore the settings when necessary. This fixes the output-freq and
duty-cycle being reset to their defaults on resume.
Signed-off-by: Hans de Goede
---
Changes in v5:
- The changes to pwm_lpss_apply() are much cleaner now thanks to the new
pwm_lpss_prepare_enable() helper.
Changes in v3:
- This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM"
patch from previous versions of this patch-set, which really was a hack
working around the resume issue which this patch fixes properly.
---
drivers/pwm/pwm-lpss.c | 56 --
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 8a136ba2a583..cf4eaf7ef2a2 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -143,29 +143,39 @@ static int pwm_lpss_prepare_enable(struct pwm_lpss_chip
*lpwm,
return 0;
}
-static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
- const struct pwm_state *state)
+static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state, bool from_resume)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
int ret = 0;
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
- pm_runtime_get_sync(chip->dev);
+ if (!from_resume)
+ pm_runtime_get_sync(chip->dev);
+
ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
- if (ret)
+ if (ret && !from_resume)
pm_runtime_put(chip->dev);
} else {
ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
- pm_runtime_put(chip->dev);
+
+ if (!from_resume)
+ pm_runtime_put(chip->dev);
}
return ret;
}
+static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ return __pwm_lpss_apply(chip, pwm, state, false);
+}
+
static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state)
{
@@ -278,10 +288,40 @@ EXPORT_SYMBOL_GPL(pwm_lpss_suspend);
int pwm_lpss_resume(struct device *dev)
{
struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
- int i;
+ struct pwm_state saved_state;
+ struct pwm_device *pwm;
+ int i, ret;
+ u32 ctrl;
- for (i = 0; i < lpwm->info->npwm; i++)
- writel(lpwm->saved_ctrl[i], lpwm->regs + i * PWM_SIZE + PWM);
+ for (i = 0; i < lpwm->info->npwm; i++) {
+ pwm = >chip.pwms[i];
+
+ ctrl = pwm_lpss_read(pwm);
+ /* If we did not reach S0i3/S3 the controller keeps its state */
+
[PATCH v5 03/16] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input clock-cycles the counter has been increased from 0 to
65535 and it will overflow on the next cycle, so it will overflow after
every 65536 clock cycles and thus the calculations done in
pwm_lpss_prepare() should use 65536 and not 65535.
This commit fixes this. Note this also aligns the calculations in
pwm_lpss_prepare() with those in pwm_lpss_get_state().
Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid
potential overflow of base_unit"). The next patch in this series really
fixes the potential overflow of the base_unit value.
Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko
Acked-by: Uwe Kleine-König
Signed-off-by: Hans de Goede
---
Changes in v3:
- Add Fixes tag
- Add Reviewed-by: Andy Shevchenko tag
---
drivers/pwm/pwm-lpss.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 9d965ffe66d1..43b1fc634af1 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -93,7 +93,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
struct pwm_device *pwm,
* The equation is:
* base_unit = round(base_unit_range * freq / c)
*/
- base_unit_range = BIT(lpwm->info->base_unit_bits) - 1;
+ base_unit_range = BIT(lpwm->info->base_unit_bits);
freq *= base_unit_range;
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
@@ -104,8 +104,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
struct pwm_device *pwm,
orig_ctrl = ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
- ctrl &= ~(base_unit_range << PWM_BASE_UNIT_SHIFT);
- base_unit &= base_unit_range;
+ ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
+ base_unit &= (base_unit_range - 1);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 02/16] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
...
}
Where PSAT is the power-status register of the PWM controller.
Since the i915 driver will do a pwm_get on the pwm device as it uses it to
control the LCD panel backlight, there is a device-link marking the i915
device as a consumer of the pwm device. So that the PWM controller will
always be suspended after the i915 driver suspends (which is the right
thing to do). This causes the above GFX0 PS3 AML code to run before
acpi_lpss.c calls acpi_lpss_save_ctx().
So on these devices the PWM controller will already be off when
acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0x)
as ctx register values.
When these bogus values get restored on resume the PWM controller actually
keeps working, since most bits are reserved, but this does set bit 3 of
the LPSS General purpose register, which for the PWM controller has the
following function: "This bit is re-used to support 32kHz slow mode.
Default is 19.2MHz as PWM source clock".
This causes the clock of the PWM controller to switch from 19.2MHz to
32KHz, which is a slow-down of a factor 600. Surprisingly enough so far
there have been few bug reports about this. This is likely because the
i915 driver was hardcoding the PWM frequency to 46 KHz, which divided
by 600 would result in a PWM frequency of approx. 78 Hz, which mostly
still works fine. There are some bug reports about the LCD backlight
flickering after suspend/resume which are likely caused by this issue.
But with the upcoming patch-series to finally switch the i915 drivers
code for external PWM controllers to use the atomic API and to honor
the PWM frequency specified in the video BIOS (VBT), this becomes a much
bigger problem. On most cases the VBT specifies either 200 Hz or 20
KHz as PWM frequency, which with the mentioned issue ends up being either
1/3 Hz, where the backlight actually visible blinks on and off every 3s,
or in 33 Hz and horrible flickering of the backlight.
There are a number of possible solutions to this problem:
1. Make acpi_lpss_save_ctx() run before GFX0._PS3
Pro: Clean solution from pov of not medling with save/restore ctx code
Con: As mentioned the current ordering is the right thing to do
Con: Requires assymmetry in at what suspend/resume phase we do the save vs
restore, requiring more suspend/resume ordering hacks in already
convoluted acpi_lpss.c suspend/resume code.
2. Do some sort of save once mode for the LPSS ctx
Pro: Reasonably clean
Con: Needs a new LPSS flag + code changes to handle the flag
3. Detect we have failed to save the ctx registers and do not restore them
Pro: Not PWM specific, might help with issues on other LPSS devices too
Con: If we can get away with not restoring the ctx why bother with it at
all?
4. Do not save the ctx for CHT PWM controllers
Pro: Clean, as simple as dropping a flag?
Con: Not so simple as dropping a flag, needs a new flag to ensure that
we still do lpss_deassert_reset() on device activation.
5. Make the pwm-lpss code fixup the LPSS-context registers
Pro: Keeps acpi_lpss.c code clean
Con: Moves knowledge of LPSS-context into the pwm-lpss.c code
1 and 5 both do not seem to be a desirable way forward.
3 and 4 seem ok, but they both assume that restoring the LPSS-context
registers is not necessary. I have done a couple of test and those do
show that restoring the LPSS-context indeed does not seem to be necessary
on devices using s2idle suspend (and successfully reaching S0i3). But I
have no hardware to test deep / S3 suspend. So I'm not sure that not
restoring the context is safe.
That leaves solution 2, which is about as simple / clean as 3 and 4,
so this commit fixes the described problem by implementing a new
LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
Changes in v2:
- Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX
---
drivers/acpi/acpi_lpss.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 67892fc0b822..a8d7d83ac761 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -67,7 +67,15 @@ ACPI_MODULE_NAME("acpi_lpss");
#define LPSS_CLK_DIVIDER BIT(2)
#define LPSS_LTR BIT(3)
#define LPSS_SAVE_CTX BIT(4)
-#define LPSS_NO_D3_DELAY BIT(5)
+/*
+ * For some devices the DSDT AML code for another device turns off the device
+ * before our
[PATCH v5 07/16] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
While looking into adding atomic-pwm support to the pwm-crc driver I noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and there is a clock-divider which divides this with a value between 1-128, and there are 256 duty-cycle steps. The pwm-crc code before this commit assumed that a clock-divider setting of 1 means that the PWM output is running at 6 MHZ, if that is true, where do these 256 duty-cycle steps come from? This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that seems unlikely for a PMIC which is using a silicon process optimized for power-switching transistors. It is way more likely that there is an 8 bit counter for the duty cycle which acts as an extra fixed divider wrt the PWM output frequency. The main user of the pwm-crc driver is the i915 GPU driver which uses it for backlight control. Lets compare the PWM register values set by the video-BIOS (the GOP), assuming the extra fixed divider is present versus the PWM frequency specified in the Video-BIOS-Tables: Device: PWM Hz set by BIOS PWM Hz specified in VBT Asus T100TA 200 200 Asus T100HA 200 200 Lenovo Miix 2 8 23437 2 Toshiba WT8-A 23437 2 So as we can see if we assume the extra division by 256 then the register values set by the GOP are an exact match for the VBT values, where as otherwise the values would be of by a factor of 256. This commit fixes the period / duty_cycle calculations to take the extra division by 256 into account. Signed-off-by: Hans de Goede --- Changes in v3: - Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define --- drivers/pwm/pwm-crc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c index 272eeb071147..c056eb9b858c 100644 --- a/drivers/pwm/pwm-crc.c +++ b/drivers/pwm/pwm-crc.c @@ -21,8 +21,8 @@ #define PWM_MAX_LEVEL 0xFF -#define PWM_BASE_CLK 600 /* 6 MHz */ -#define PWM_MAX_PERIOD_NS 21333/* 46.875KHz */ +#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */ +#define PWM_MAX_PERIOD_NS 5461333 /* 183 Hz */ /** * struct crystalcove_pwm - Crystal Cove PWM controller @@ -72,7 +72,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm, /* changing the clk divisor, need to disable fisrt */ crc_pwm_disable(c, pwm); - clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC; + clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC); regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, clk_div | PWM_OUTPUT_ENABLE); -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 08/16] pwm: crc: Fix off-by-one error in the clock-divider calculations
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested frequency was so high that the
calculation has already resulted in a (rounded) divider value of 0.
Note that before this fix, setting a period of PWM_MAX_PERIOD_NS which
corresponds to the max. divider value of 128 could have resulted in a
bug where the code would use 128 as divider-register value which would
have resulted in an actual divider value of 0 (and the enable bit being
set). A rounding error stopped this bug from actually happen. This
same rounding error means that after the subtraction of 1 it is impossible
to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow
setting a divider of 128 (register-value 127).
Signed-off-by: Hans de Goede
---
Changes in v3:
- Introduce crc_pwm_calc_clk_div() here instead of later in the patch-set
to reduce the amount of churn in the patch-set a bit
---
drivers/pwm/pwm-crc.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index c056eb9b858c..44ec7d5b63e1 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -22,7 +22,7 @@
#define PWM_MAX_LEVEL 0xFF
#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */
-#define PWM_MAX_PERIOD_NS 5461333 /* 183 Hz */
+#define PWM_MAX_PERIOD_NS 5461334 /* 183 Hz */
/**
* struct crystalcove_pwm - Crystal Cove PWM controller
@@ -39,6 +39,18 @@ static inline struct crystalcove_pwm *to_crc_pwm(struct
pwm_chip *pc)
return container_of(pc, struct crystalcove_pwm, chip);
}
+static int crc_pwm_calc_clk_div(int period_ns)
+{
+ int clk_div;
+
+ clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
+ /* clk_div 1 - 128, maps to register values 0-127 */
+ if (clk_div > 0)
+ clk_div--;
+
+ return clk_div;
+}
+
static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
{
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
@@ -68,11 +80,10 @@ static int crc_pwm_config(struct pwm_chip *c, struct
pwm_device *pwm,
}
if (pwm_get_period(pwm) != period_ns) {
- int clk_div;
+ int clk_div = crc_pwm_calc_clk_div(period_ns);
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
- clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 04/16] pwm: lpss: Add range limit check for the base_unit register value
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.
When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:
base_unit &= (base_unit_range - 1);
But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.
This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).
Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v5:
- Use clamp_val(... instead of clam_t(unsigned long long, ...
Changes in v3:
- Change upper limit of clamp to (base_unit_range - 1)
- Add Fixes tag
---
drivers/pwm/pwm-lpss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b1fc634af1..da9bc3d10104 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -97,6 +97,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
struct pwm_device *pwm,
freq *= base_unit_range;
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
+ /* base_unit must not be 0 and we also want to avoid overflowing it */
+ base_unit = clamp_val(base_unit, 1, base_unit_range - 1);
on_time_div = 255ULL * duty_ns;
do_div(on_time_div, period_ns);
@@ -105,7 +107,6 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
struct pwm_device *pwm,
orig_ctrl = ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
- base_unit &= (base_unit_range - 1);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 01/16] ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
RSTA = Zero
RSTF = Zero
RSTA = One
RSTF = One
PWMB |= 0xC000
PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
}
Where PSAT is the power-status register of the PWM controller, so if it
is in D3 when the GFX0 device's PS0 method runs then it will turn it on
and restore the PWM ctrl register value it saved from its PS3 handler.
Note not only does it restore it, it ors it with 0xC000 turning it
on at a time where we may not want it to get turned on at all.
The pwm_get call which the i915 driver does to get a reference to the
PWM controller, already adds a device-link making the GFX0 device a
consumer of the PWM device. So it should already have been resumed when
the above AML runs and the AML should thus not do its undesirable poking
of the PWM controller register.
But the PCI core powers on PCI devices in the no-irq resume phase and
thus calls the troublesome PS0 method in the no-irq resume phase.
Where as LPSS devices by default are resumed in the early resume phase.
This commit sets the resume_from_noirq flag in the bsw_pwm_dev_desc
struct, so that Cherry Trail PWM controllers will be resumed in the
no-irq phase. Together with the device-link added by the pwm-get this
ensures that the PWM controller will be on when the troublesome PS0
method runs, which stops it from poking the PWM controller.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_lpss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 5e2bfbcf526f..67892fc0b822 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -257,6 +257,7 @@ static const struct lpss_device_desc bsw_pwm_dev_desc = {
.flags = LPSS_SAVE_CTX | LPSS_NO_D3_DELAY,
.prv_offset = 0x800,
.setup = bsw_pwm_setup,
+ .resume_from_noirq = true,
};
static const struct lpss_device_desc byt_uart_dev_desc = {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 00/16] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
Hi All, Here is v5 of my patch series converting the i915 driver's code for controlling the panel's backlight with an external PWM controller to use the atomic PWM API. See below for the changelog. This series consists of 4 parts: 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness 2. various fixes to the pwm-lpss driver 3. convert the pwm-crc driver to support the atomic PWM API and 4. convert the i915 driver's PWM code to use the atomic PWM API The involved acpi_lpss and pwm drivers do not see a whole lot of churn, so the plan is to merge this all through drm-intel-next-queued (dinq) once all the patches are reviewed / have acks. Specifically patches 5-9, 11 still need an Acked- / Reviewed-by Andy, can you please take a look at the unreviewed patches? Specifically patches 5-6 should address your review remarks from v4 of this set and I've addressed your review remarks on patches 7-9 in v3 already. A review of patch 11 would also be welcome Uwe, can you please take a look at the unreviewed patches? Uwe, may I have your Acked-by for merging this series through the drm-intel-next-queued branch once all PWM patches have an Acked- or Reviewed-by ? This series has been tested (and re-tested after adding various bug-fixes) extensively. It has been tested on the following devices: -Asus T100TA BYT + CRC-PMIC PWM -Toshiba WT8-A BYT + CRC-PMIC PWM -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM -Asus T100HA CHT + CRC-PMIC PWM -Terra Pad 1061 BYT + LPSS PWM -Trekstor Twin 10.1 BYT + LPSS PWM -Asus T101HA CHT + CRC-PMIC PWM -GPD Pocket CHT + CRC-PMIC PWM Changelog: Changes in v5: - Dropped the "pwm: lpss: Correct get_state result for base_unit == 0" patch. The base_unit == 0 condition should never happen and sofar it is unclear what the proper behavior / correct values to store in the pwm_state should be when this does happen. Since this patch was added as an extra pwm-lpss fix in v4 of this patch-set and otherwise is orthogonal to the of this patch-set just drop it (again). - "[PATCH 04/16] pwm: lpss: Add range limit check for the base_unit register value" - Use clamp_val(... instead of clam_t(unsigned long long, ... - "[PATCH 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper" - This is a new patch in v5 of this patchset - [PATCH 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume - Use the new pwm_lpss_prepare_enable() helper Changes in v4: - "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0" - This is a new patch in v4 of this patchset - "[PATCH v4 12/16] pwm: crc: Implement get_state() method" - Use DIV_ROUND_UP when calculating the period and duty_cycle values - "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller" - Add a note to the commit message about the changes in pwm_disable_backlight() - Use the pwm_set/get_relative_duty_cycle() helpers Changes in v3: - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value" - Use base_unit_range - 1 as maximum value for the clamp() - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume" - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM" patch from previous versions of this patch-set, which really was a hack working around the resume issue which this patch fixes properly. - PATCH v3 6 - 11 pwm-crc changes: - Various small changes resulting from the reviews by Andy and Uwe, including some refactoring of the patches to reduce the amount of churn in the patch-set Changes in v2: - Fix coverletter subject - Drop accidentally included debugging patch - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once ( - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/6] drm: msm: a6xx: send opp instead of a frequency
From: Sharat Masetty
This patch changes the plumbing to send the devfreq recommended opp rather
than the frequency. Also consolidate and rearrange the code in a6xx to set
the GPU frequency and the icc vote in preparation for the upcoming
changes for GPU->DDR scaling votes.
Signed-off-by: Sharat Masetty
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 89 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +-
drivers/gpu/drm/msm/msm_gpu.c | 3 +-
drivers/gpu/drm/msm/msm_gpu.h | 3 +-
4 files changed, 52 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 21e77d6..856db46 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -103,17 +103,45 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
}
-static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
+void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)
{
- struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
- struct adreno_gpu *adreno_gpu = _gpu->base;
- struct msm_gpu *gpu = _gpu->base;
- int ret;
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ struct a6xx_gmu *gmu = _gpu->gmu;
+ u32 perf_index;
+ unsigned long gpu_freq;
+ int ret = 0;
+
+ gpu_freq = dev_pm_opp_get_freq(opp);
+
+ if (gpu_freq == gmu->freq)
+ return;
+
+ for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++)
+ if (gpu_freq == gmu->gpu_freqs[perf_index])
+ break;
+
+ gmu->current_perf_index = perf_index;
+ gmu->freq = gmu->gpu_freqs[perf_index];
+
+ /*
+* This can get called from devfreq while the hardware is idle. Don't
+* bring up the power if it isn't already active
+*/
+ if (pm_runtime_get_if_in_use(gmu->dev) == 0)
+ return;
+
+ if (!gmu->legacy) {
+ a6xx_hfi_set_freq(gmu, perf_index);
+ icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+ pm_runtime_put(gmu->dev);
+ return;
+ }
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
- ((3 & 0xf) << 28) | index);
+ ((3 & 0xf) << 28) | perf_index);
/*
* Send an invalid index as a vote for the bus bandwidth and let the
@@ -134,37 +162,6 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
* for now leave it at max so that the performance is nominal.
*/
icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
-}
-
-void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
-{
- struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
- struct a6xx_gmu *gmu = _gpu->gmu;
- u32 perf_index = 0;
-
- if (freq == gmu->freq)
- return;
-
- for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++)
- if (freq == gmu->gpu_freqs[perf_index])
- break;
-
- gmu->current_perf_index = perf_index;
- gmu->freq = gmu->gpu_freqs[perf_index];
-
- /*
-* This can get called from devfreq while the hardware is idle. Don't
-* bring up the power if it isn't already active
-*/
- if (pm_runtime_get_if_in_use(gmu->dev) == 0)
- return;
-
- if (gmu->legacy)
- __a6xx_gmu_set_freq(gmu, perf_index);
- else
- a6xx_hfi_set_freq(gmu, perf_index);
-
pm_runtime_put(gmu->dev);
}
@@ -839,6 +836,19 @@ static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
a6xx_gmu_rpmh_off(gmu);
}
+static void a6xx_gmu_set_initial_freq(struct msm_gpu *gpu, struct a6xx_gmu
*gmu)
+{
+ struct dev_pm_opp *gpu_opp;
+ unsigned long gpu_freq = gmu->gpu_freqs[gmu->current_perf_index];
+
+ gpu_opp = dev_pm_opp_find_freq_exact(>pdev->dev, gpu_freq, true);
+ if (IS_ERR_OR_NULL(gpu_opp))
+ return;
+
+ a6xx_gmu_set_freq(gpu, gpu_opp);
+ dev_pm_opp_put(gpu_opp);
+}
+
int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
{
struct adreno_gpu *adreno_gpu = _gpu->base;
@@ -898,10 +908,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
enable_irq(gmu->hfi_irq);
/* Set the GPU to the current freq */
- if (gmu->legacy)
- __a6xx_gmu_set_freq(gmu, gmu->current_perf_index);
- else
- a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
+ a6xx_gmu_set_initial_freq(gpu, gmu);
/*
* "enable" the GX power domain which won't actually do anything but it
[PATCH v6 4/6] arm64: dts: qcom: SDM845: Enable GPU DDR bw scaling
From: Sharat Masetty
This patch adds the interconnects property for the gpu node and the
opp-peak-kBps property to the opps of the gpu opp table. This should
help enable DDR bandwidth scaling dynamically and proportionally to the
GPU frequency.
Signed-off-by: Sharat Masetty
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 8eb5a31..1cd2dae 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3515,42 +3515,52 @@
qcom,gmu = <>;
+ interconnects = <_noc MASTER_GFX3D _noc
SLAVE_EBI1>;
+ interconnect-names = "gfx-mem";
+
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-71000 {
opp-hz = /bits/ 64 <71000>;
opp-level =
;
+ opp-peak-kBps = <7216000>;
};
opp-67500 {
opp-hz = /bits/ 64 <67500>;
opp-level =
;
+ opp-peak-kBps = <7216000>;
};
opp-59600 {
opp-hz = /bits/ 64 <59600>;
opp-level =
;
+ opp-peak-kBps = <622>;
};
opp-52000 {
opp-hz = /bits/ 64 <52000>;
opp-level = ;
+ opp-peak-kBps = <622>;
};
opp-41400 {
opp-hz = /bits/ 64 <41400>;
opp-level =
;
+ opp-peak-kBps = <4068000>;
};
opp-34200 {
opp-hz = /bits/ 64 <34200>;
opp-level = ;
+ opp-peak-kBps = <2724000>;
};
opp-25700 {
opp-hz = /bits/ 64 <25700>;
opp-level =
;
+ opp-peak-kBps = <1648000>;
};
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 6/6] arm64: dts: qcom: sc7180: Add opp-peak-kBps to GPU opp
From: Sharat Masetty
Add opp-peak-kBps bindings to the GPU opp table, listing the peak
GPU -> DDR bandwidth requirement for each opp level. This will be
used to scale the DDR bandwidth along with the GPU frequency dynamically.
Signed-off-by: Sharat Masetty
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 80fe54b..ff4ddf1 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1479,36 +1479,43 @@
opp-8 {
opp-hz = /bits/ 64 <8>;
opp-level =
;
+ opp-peak-kBps = <8532000>;
};
opp-65000 {
opp-hz = /bits/ 64 <65000>;
opp-level =
;
+ opp-peak-kBps = <7216000>;
};
opp-56500 {
opp-hz = /bits/ 64 <56500>;
opp-level = ;
+ opp-peak-kBps = <5412000>;
};
opp-43000 {
opp-hz = /bits/ 64 <43000>;
opp-level =
;
+ opp-peak-kBps = <5412000>;
};
opp-35500 {
opp-hz = /bits/ 64 <35500>;
opp-level = ;
+ opp-peak-kBps = <3072000>;
};
opp-26700 {
opp-hz = /bits/ 64 <26700>;
opp-level =
;
+ opp-peak-kBps = <3072000>;
};
opp-18000 {
opp-hz = /bits/ 64 <18000>;
opp-level =
;
+ opp-peak-kBps = <1804000>;
};
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/6] arm64: dts: qcom: sc7180: Add interconnects property for GPU
From: Sharat Masetty
This patch adds the interconnects property to the GPU node. This enables
the GPU->DDR path bandwidth voting.
Signed-off-by: Sharat Masetty
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 31b9217..80fe54b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1470,6 +1470,9 @@
operating-points-v2 = <_opp_table>;
qcom,gmu = <>;
+ interconnects = <_noc MASTER_GFX3D _virt
SLAVE_EBI1>;
+ interconnect-names = "gfx-mem";
+
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/6] Add support for GPU DDR BW scaling
This series add support for GPU DDR bandwidth scaling and is based on the bindings from Georgi [1]. This is mostly a rebase of Sharat's patches [2] on the tip of msm-next branch. [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/vireshk/pm/+log/opp/linux-next/ [2] https://patchwork.freedesktop.org/series/75291/ Changes from v5: - Added "interconnect-names" property Changes from v4: - Squashed a patch to another one to fix Jonathan's comment - Add back the pm_runtime_get_if_in_use() check Changes from v3: - Rebased on top of Jonathan's patch which adds support for changing gpu freq through hfi on newer targets - As suggested by Rob, left the icc_path intact for pre-a6xx GPUs Sharat Masetty (6): dt-bindings: drm/msm/gpu: Document gpu opp table drm: msm: a6xx: send opp instead of a frequency drm: msm: a6xx: use dev_pm_opp_set_bw to scale DDR arm64: dts: qcom: SDM845: Enable GPU DDR bw scaling arm64: dts: qcom: sc7180: Add interconnects property for GPU arm64: dts: qcom: sc7180: Add opp-peak-kBps to GPU opp .../devicetree/bindings/display/msm/gpu.txt| 28 ++ arch/arm64/boot/dts/qcom/sc7180.dtsi | 10 ++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++ drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 108 - drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +- drivers/gpu/drm/msm/msm_gpu.c | 3 +- drivers/gpu/drm/msm/msm_gpu.h | 3 +- 7 files changed, 114 insertions(+), 50 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/6] dt-bindings: drm/msm/gpu: Document gpu opp table
From: Sharat Masetty
Update documentation to list the gpu opp table bindings including the
newly added "opp-peak-kBps" needed for GPU-DDR bandwidth scaling.
Signed-off-by: Sharat Masetty
Acked-by: Rob Herring
Signed-off-by: Akhil P Oommen
---
.../devicetree/bindings/display/msm/gpu.txt| 28 ++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index fd779cd..1af0ff1 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -112,6 +112,34 @@ Example a6xx (with GMU):
interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>;
interconnect-names = "gfx-mem";
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-43000 {
+ opp-hz = /bits/ 64 <43000>;
+ opp-level = ;
+ opp-peak-kBps = <5412000>;
+ };
+
+ opp-35500 {
+ opp-hz = /bits/ 64 <35500>;
+ opp-level = ;
+ opp-peak-kBps = <3072000>;
+ };
+
+ opp-26700 {
+ opp-hz = /bits/ 64 <26700>;
+ opp-level = ;
+ opp-peak-kBps = <3072000>;
+ };
+
+ opp-18000 {
+ opp-hz = /bits/ 64 <18000>;
+ opp-level = ;
+ opp-peak-kBps = <1804000>;
+ };
+ };
+
qcom,gmu = <>;
zap-shader {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/6] drm: msm: a6xx: use dev_pm_opp_set_bw to scale DDR
From: Sharat Masetty
This patches replaces the previously used static DDR vote and uses
dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
GPU frequency. Also since the icc path voting is handled completely
in the opp driver, remove the icc_path handle and its usage in the
drm driver.
Signed-off-by: Sharat Masetty
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 856db46..a6f43ff 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -133,7 +133,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct
dev_pm_opp *opp)
if (!gmu->legacy) {
a6xx_hfi_set_freq(gmu, perf_index);
- icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+ dev_pm_opp_set_bw(>pdev->dev, opp);
pm_runtime_put(gmu->dev);
return;
}
@@ -157,11 +157,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct
dev_pm_opp *opp)
if (ret)
dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
- /*
-* Eventually we will want to scale the path vote with the frequency but
-* for now leave it at max so that the performance is nominal.
-*/
- icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+ dev_pm_opp_set_bw(>pdev->dev, opp);
pm_runtime_put(gmu->dev);
}
@@ -849,6 +845,19 @@ static void a6xx_gmu_set_initial_freq(struct msm_gpu *gpu,
struct a6xx_gmu *gmu)
dev_pm_opp_put(gpu_opp);
}
+static void a6xx_gmu_set_initial_bw(struct msm_gpu *gpu, struct a6xx_gmu *gmu)
+{
+ struct dev_pm_opp *gpu_opp;
+ unsigned long gpu_freq = gmu->gpu_freqs[gmu->current_perf_index];
+
+ gpu_opp = dev_pm_opp_find_freq_exact(>pdev->dev, gpu_freq, true);
+ if (IS_ERR_OR_NULL(gpu_opp))
+ return;
+
+ dev_pm_opp_set_bw(>pdev->dev, gpu_opp);
+ dev_pm_opp_put(gpu_opp);
+}
+
int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
{
struct adreno_gpu *adreno_gpu = _gpu->base;
@@ -873,7 +882,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
}
/* Set the bus quota to a reasonable value for boot */
- icc_set_bw(gpu->icc_path, 0, MBps_to_icc(3072));
+ a6xx_gmu_set_initial_bw(gpu, gmu);
/* Enable the GMU interrupt */
gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, ~0);
@@ -1049,7 +1058,7 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
a6xx_gmu_shutdown(gmu);
/* Remove the bus vote */
- icc_set_bw(gpu->icc_path, 0, 0);
+ dev_pm_opp_set_bw(>pdev->dev, NULL);
/*
* Make sure the GX domain is off before turning off the GMU (CX)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd drm-next-5.9
Hi Dave, Daniel, More stuff for 5.9. The following changes since commit 9555152beb1143c85c03f9b9de59863cbbe89f4b: Merge tag 'amd-drm-next-5.9-2020-07-01' of git://people.freedesktop.org/~agd5f/linux into drm-next (2020-07-02 15:17:31 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.9-2020-07-17 for you to fetch changes up to 6e14adea0ac3037d923a9591d1a094c115d7947c: drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read() (2020-07-15 13:27:34 -0400) amd-drm-next-5.9-2020-07-17: amdgpu: - SI UVD/VCE clock support - Updates for Sienna Cichlid - Expose drm rotation property - Atomfirmware updates for renoir - updates to GPUVM hub handling for different register layouts - swSMU restructuring and cleanups - RAS fixes - DC fixes - mode1 reset support for Sienna Cichlid - Add support for Navy Flounder GPUs amdkfd: - Add SMI events watch interface UAPI: - Add amdkfd SMI events watch interface Userspace which uses this interface: https://github.com/RadeonOpenCompute/rocm_smi_lib/commit/2235ede34c456f1c7d3490f6fe74825d442d272e Alex Deucher (5): drm/amdgpu/atomfirmware: fix vram_info fetching for renoir drm/amdgpu/atomfirmware: update to latest integratedinfotable drm/amdgpu/atomfirmware: update vram info handling for renoir drm/amdgpu: use %u rather than %d for sclk/mclk drm/amdgpu/display: create fake mst encoders ahead of time (v4) Alex Jivin (4): drm/amdgpu: SI support for UVD clock control drm/amdgpu: SI support for VCE clock control drm/amdgpu: SI support for UVD and VCE power managment drm/amdgpu: Move the mutex lock/unlock out Amber Lin (2): drm/amdkfd: Provide SMI events watch include/uapi/linux: Update KFD ioctl version Anthony Koo (6): drm/amd/display: [FW Promotion] Release 1.0.20 drm/amd/display: [FW Promotion] Release 1.0.21 drm/amd/display: [FW Promotion] Release 1.0.22 drm/amd/display: [FW Promotion] Release 0.0.23 drm/amd/display: 3.2.93 drm/amd/display: [FW Promotion] Release 0.0.24 Aric Cyr (2): drm/amd/display: 3.2.92 drm/amd/display: 3.2.94 Aurabindo Pillai (1): drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read() Bhawanpreet Lakha (2): drm/amd/display: Add missing reg mask for dcn3 drm/amd/display: add DC support for navy flounder Boyuan Zhang (5): drm/amdgpu: add navy_flounder vcn firmware support drm/amdgpu: add vcn ip block for navy_flounder drm/amdgpu: enable VCN3.0 PG and CG for navy_flounder drm/amdgpu: enable VCN3.0 DPG for navy_flounder drm/amdgpu: enable JPEG3.0 PG and CG for navy_flounder Changfeng (1): Revert "drm/amd/display: add mechanism to skip DCN init" Chengming Gui (2): drm/amdkfd: Support navy_flounder KFD drm/amdkfd: Add kfd2kgd_funcs for navy_flounder kfd support Chiawen Huang (1): drm/amd/display: reduce sr_xxx_time by 3 us when ppt disable Colin Ian King (2): drm/amd/display: remove redundant initialization of variable result drm/amdgpu: fix spelling mistake "Falied" -> "Failed" Dan Carpenter (1): drm/amd/display: remove an unnecessary NULL check Dmytro Laktyushkin (4): drm/amd/display: Enable 4 to 1 mpc combine for max detile use drm/amd/display: Add diags scaling log by default drm/amd/display: update dml var drm/amd/display: fix dcn3 p_state_change_support validation (v2) Evan Quan (35): drm/amd/powerplay: drop unnecessary "@" on OD sysfs output drm/amd/powerplay: fix compile error with ARCH=arc drm/amd/powerplay: correct the .get_workload_type() pointer drm/amd/powerplay: drop unnecessary wrappers around clock retrieving drm/amd/powerplay: bypass wrapper on retrieving current clock frequency drm/amd/powerplay: unshare the code for retrieving current clock frequency drm/amd/powerplay: drop unused code and wrapper around clock retrieving drm/amd/powerplay: put setting hard limit common code in smu_v11_0.c drm/amd/powerplay: revise calling chain on setting soft limit drm/amd/powerplay: revise calling chain on retrieving frequency range drm/amd/powerplay: put dpm frequency setting common code in smu_v11_0.c drm/amd/powerplay: add more members for dpm table drm/amd/powerplay: implement a common set dpm table API for smu V11 drm/amd/powerplay: update Arcturus default dpm table setting drm/amd/powerplay: update Navi10 default dpm table setup drm/amd/powerplay: update Sienna Cichlid default dpm table setup drm/amd/powerplay: add new UMD pstate data structure drm/amd/powerplay: update UMD pstate clock settings drm/amd/powerplay: update the common API for performance level setting drm/amd/powerplay: drop
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #71 from Anthony Ruhier (anthony.ruh...@gmail.com) --- Just to give some news, I can confirm that I haven't had any freeze since Wednesday. Usually, when my system just idled, it would quickly trigger the bug. That or doing something CPU intensive (like compiling firefox). But nothing since I reverted the 3 commits. Really good job Duncan! Thanks a lot for your debug! MB chipset: x470 CPU: ryzen 2700x GPU: vega64 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/4] Add support for iMX8MQ Display Controller Subsystem
On Fri, Jul 17, 2020 at 12:51 PM Lucas Stach wrote: > > Am Freitag, den 17.07.2020, 12:45 +0300 schrieb Laurentiu Palcu: > > Hi Lukas and Daniel, > > > > On Fri, Jul 17, 2020 at 11:27:58AM +0200, Daniel Vetter wrote: > > > On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote: > > > > Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter: > > > > > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach > > > > > wrote: > > > > > > Hi Laurentiu, > > > > > > > > > > > > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu: > > > > > > > From: Laurentiu Palcu > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial > > > > > > > support > > > > > > > includes only graphics plane support (no video planes), no HDR10 > > > > > > > capabilities, > > > > > > > no graphics decompression (only linear, tiled and super-tiled > > > > > > > buffers allowed). > > > > > > > > > > > > > > Support for the rest of the features will be added incrementally, > > > > > > > in subsequent > > > > > > > patches. > > > > > > > > > > > > > > The patchset was tested with both HDP driver (in the downstream > > > > > > > tree) and the upstream > > > > > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > > > > > correctly with DCSS). > > > > > > > > > > > > I think the series (minus 3/5 and minor correction to the DT > > > > > > binding) > > > > > > is fine to go in now. So just some formal questions: are you going > > > > > > to > > > > > > maintain this driver in upstream? If so we should add a MAINTAINERS > > > > > > entry to that effect. I can offer to act as a reviewer in this case. > > > > I can maintain the DCSS driver, sure, and the more reviewers the better. > > Thanks for helping out with this. Should I send a v6 then with a patch > > for MAINTAINERS? > > > > > > > > How do you intend to merge this? IMO pushing this through drm-misc > > > > > > seems like the right thing to do. If you agree I can help you get > > > > > > this > > > > > > applied. If you are going to maintain the driver on your own, I > > > > > > think > > > > > > you should then apply for commit rights to drm-misc. > > > > > > > > > > drm/imx isn't listed yet as under the drm-misc umbrella, maybe we > > > > > should put the entire collective of imx drivers under drm-misc? Or > > > > > maybe it's just an oversight that the git repo isn't specified in the > > > > > MAINTAINERS entry. Also maybe we should add the pengutronix kernel > > > > > team alias there too? > > > > > > > > drm/imx was exclusively the IPUv3 up until now, which is in fact > > > > maintained outside of drm-misc in its own git tree. This has worked > > > > quite well in the past so even though IPUv3 doesn't see a lot of churn > > > > these days the motivation to change anything to this workflow is quite > > > > low. And yes, the git tree is missing from the MAINTAINERS entry. > > > > > > > > For the DCSS driver, if it's going to be maintained by NXP, I figured > > > > it might be easier for Laurentiu to push things into drm-misc than set > > > > up a separate public git tree. But IMHO that's fully up to him to > > > > decide. > > > > > > /me puts on maintainer hat > > > > > > Much prefer drm-misc over random people playing maintainer and fumbling > > > it. I think the reasonable options are either in the current imx tree, or > > > drm-misc. Standalone tree for these small drivers just doesn't make much > > > sense. > > > > I don't have anything against either method, though I have to agree I > > like things to be simple. Going through drm-misc sounds simple enough to > > me. :) > > However, since there is going to be more activity in the DRM IMX area in > > the future, reviving the drm/imx tree, and push all IMX related stuff > > through drm/imx, could make sense as well. > > I think drm-misc is the right place then. > > Please send a v6 with the following changes: > - drop the component framework patch > - drop the i.MX8MQ DT patch, this should go through Shawn's imx tree > after the driver and binding has landed in drm-misc > - you can add my Reviewed-by to the whole series or I can add it when > applying > - add a MAINTAINERS entry, please add me as a reviewer if you don't > mind > > I can push this initial series into drm-misc until you've got your own > commit rights. For drm-misc howto get started: https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html And howto get commit rights: https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html Once you have the fd.o bug report to request commit rights pls paste it here so we can get the ack from drm-misc maintainers. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597
oddly enough I wasn't able to reproduce it on my XPS 9560, will ping
once something breaks.
On Fri, Jul 17, 2020 at 2:43 AM Karol Herbst wrote:
>
> On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
> >
> > [+cc Sasha -- stable kernel regression]
> > [+cc Patrick, Kai-Heng, LKML]
> >
> > On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> > > >
> > > > Hi everybody,
> > > >
> > > > with the mentioned commit Nouveau isn't able to load firmware onto the
> > > > GPU on one of my systems here. Even though the issue doesn't always
> > > > happen I am quite confident this is the commit breaking it.
> > > >
> > > > I am still digging into the issue and trying to figure out what
> > > > exactly breaks, but it shows up in different ways. Either we are not
> > > > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > > > Btw, this is also a system where our runtime power management issue
> > > > shows up, so maybe there is indeed something funky with the bridge
> > > > controller.
> > > >
> > > > Just pinging you in case you have an idea on how this could break
> > > > Nouveau
> > > >
> > > > most of the times it shows up like this:
> > > > nouveau :01:00.0: acr: AHESASC binary failed
> > > >
> > > > Sometimes it works at boot and fails at runtime resuming with random
> > > > faults. So I will be investigating a bit more, but yeah... I am super
> > > > sure the commit triggered this issue, no idea if it actually causes
> > > > it.
> > >
> > > so yeah.. I reverted that locally and never ran into issues again.
> > > Still valid on latest 5.7. So can we get this reverted or properly
> > > fixed? This breaks runtime pm for us on at least some hardware.
> >
> > Yeah, that stinks. We had another similar report from Patrick:
> >
> >
> > https://lore.kernel.org/r/caerspo5stek_my1dehwp7ahd0xop87+ohywktjbl7algdbx...@mail.gmail.com
> >
> > Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
> > DLL Link Active train links in 100 ms"), which Patrick found was
> > backported to v5.4.49 as 828b192c57e8, and you found was backported to
> > v5.7.6 as afaff825e3a4.
> >
> > Oddly, Patrick reported that v5.7.7 worked correctly, even though it
> > still contains afaff825e3a4.
> >
> > I guess in the absence of any other clues we'll have to revert it.
> > I hate to do that because that means we'll have slow resume of
> > Thunderbolt-connected devices again, but that's better than having
> > GPUs completely broken.
> >
> > Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
> > logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
> > original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
> > and to this thread?
> >
> > There must be a way to fix the slow resume problem without breaking
> > the GPUs.
> >
>
> I wouldn't be surprised if this is related to the Intel bridge we
> check against for Nouveau.. I still have to check on another laptop
> with the same bridge our workaround was required as well but wouldn't
> be surprised if it shows the same problem. Will get you the
> information from both systems tomorrow then.
>
> > Bjorn
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/4] Add support for iMX8MQ Display Controller Subsystem
Am Freitag, den 17.07.2020, 12:45 +0300 schrieb Laurentiu Palcu: > Hi Lukas and Daniel, > > On Fri, Jul 17, 2020 at 11:27:58AM +0200, Daniel Vetter wrote: > > On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote: > > > Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter: > > > > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach > > > > wrote: > > > > > Hi Laurentiu, > > > > > > > > > > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu: > > > > > > From: Laurentiu Palcu > > > > > > > > > > > > Hi, > > > > > > > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial > > > > > > support > > > > > > includes only graphics plane support (no video planes), no HDR10 > > > > > > capabilities, > > > > > > no graphics decompression (only linear, tiled and super-tiled > > > > > > buffers allowed). > > > > > > > > > > > > Support for the rest of the features will be added incrementally, > > > > > > in subsequent > > > > > > patches. > > > > > > > > > > > > The patchset was tested with both HDP driver (in the downstream > > > > > > tree) and the upstream > > > > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > > > > correctly with DCSS). > > > > > > > > > > I think the series (minus 3/5 and minor correction to the DT binding) > > > > > is fine to go in now. So just some formal questions: are you going to > > > > > maintain this driver in upstream? If so we should add a MAINTAINERS > > > > > entry to that effect. I can offer to act as a reviewer in this case. > > I can maintain the DCSS driver, sure, and the more reviewers the better. > Thanks for helping out with this. Should I send a v6 then with a patch > for MAINTAINERS? > > > > > > How do you intend to merge this? IMO pushing this through drm-misc > > > > > seems like the right thing to do. If you agree I can help you get this > > > > > applied. If you are going to maintain the driver on your own, I think > > > > > you should then apply for commit rights to drm-misc. > > > > > > > > drm/imx isn't listed yet as under the drm-misc umbrella, maybe we > > > > should put the entire collective of imx drivers under drm-misc? Or > > > > maybe it's just an oversight that the git repo isn't specified in the > > > > MAINTAINERS entry. Also maybe we should add the pengutronix kernel > > > > team alias there too? > > > > > > drm/imx was exclusively the IPUv3 up until now, which is in fact > > > maintained outside of drm-misc in its own git tree. This has worked > > > quite well in the past so even though IPUv3 doesn't see a lot of churn > > > these days the motivation to change anything to this workflow is quite > > > low. And yes, the git tree is missing from the MAINTAINERS entry. > > > > > > For the DCSS driver, if it's going to be maintained by NXP, I figured > > > it might be easier for Laurentiu to push things into drm-misc than set > > > up a separate public git tree. But IMHO that's fully up to him to > > > decide. > > > > /me puts on maintainer hat > > > > Much prefer drm-misc over random people playing maintainer and fumbling > > it. I think the reasonable options are either in the current imx tree, or > > drm-misc. Standalone tree for these small drivers just doesn't make much > > sense. > > I don't have anything against either method, though I have to agree I > like things to be simple. Going through drm-misc sounds simple enough to me. > :) > However, since there is going to be more activity in the DRM IMX area in > the future, reviving the drm/imx tree, and push all IMX related stuff > through drm/imx, could make sense as well. I think drm-misc is the right place then. Please send a v6 with the following changes: - drop the component framework patch - drop the i.MX8MQ DT patch, this should go through Shawn's imx tree after the driver and binding has landed in drm-misc - you can add my Reviewed-by to the whole series or I can add it when applying - add a MAINTAINERS entry, please add me as a reviewer if you don't mind I can push this initial series into drm-misc until you've got your own commit rights. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/4] Add support for iMX8MQ Display Controller Subsystem
Hi Lukas and Daniel, On Fri, Jul 17, 2020 at 11:27:58AM +0200, Daniel Vetter wrote: > On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote: > > Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter: > > > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach > > > wrote: > > > > Hi Laurentiu, > > > > > > > > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu: > > > > > From: Laurentiu Palcu > > > > > > > > > > Hi, > > > > > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial > > > > > support > > > > > includes only graphics plane support (no video planes), no HDR10 > > > > > capabilities, > > > > > no graphics decompression (only linear, tiled and super-tiled buffers > > > > > allowed). > > > > > > > > > > Support for the rest of the features will be added incrementally, in > > > > > subsequent > > > > > patches. > > > > > > > > > > The patchset was tested with both HDP driver (in the downstream tree) > > > > > and the upstream > > > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > > > correctly with DCSS). > > > > > > > > I think the series (minus 3/5 and minor correction to the DT binding) > > > > is fine to go in now. So just some formal questions: are you going to > > > > maintain this driver in upstream? If so we should add a MAINTAINERS > > > > entry to that effect. I can offer to act as a reviewer in this case. I can maintain the DCSS driver, sure, and the more reviewers the better. Thanks for helping out with this. Should I send a v6 then with a patch for MAINTAINERS? > > > > > > > > How do you intend to merge this? IMO pushing this through drm-misc > > > > seems like the right thing to do. If you agree I can help you get this > > > > applied. If you are going to maintain the driver on your own, I think > > > > you should then apply for commit rights to drm-misc. > > > > > > drm/imx isn't listed yet as under the drm-misc umbrella, maybe we > > > should put the entire collective of imx drivers under drm-misc? Or > > > maybe it's just an oversight that the git repo isn't specified in the > > > MAINTAINERS entry. Also maybe we should add the pengutronix kernel > > > team alias there too? > > > > drm/imx was exclusively the IPUv3 up until now, which is in fact > > maintained outside of drm-misc in its own git tree. This has worked > > quite well in the past so even though IPUv3 doesn't see a lot of churn > > these days the motivation to change anything to this workflow is quite > > low. And yes, the git tree is missing from the MAINTAINERS entry. > > > > For the DCSS driver, if it's going to be maintained by NXP, I figured > > it might be easier for Laurentiu to push things into drm-misc than set > > up a separate public git tree. But IMHO that's fully up to him to > > decide. > > /me puts on maintainer hat > > Much prefer drm-misc over random people playing maintainer and fumbling > it. I think the reasonable options are either in the current imx tree, or > drm-misc. Standalone tree for these small drivers just doesn't make much > sense. I don't have anything against either method, though I have to agree I like things to be simple. Going through drm-misc sounds simple enough to me. :) However, since there is going to be more activity in the DRM IMX area in the future, reviving the drm/imx tree, and push all IMX related stuff through drm/imx, could make sense as well. Thanks, Laurentiu > -Daniel > > > > > Regards, > > Lucas > > > > > -Daniel > > > > > > > > > > Regards, > > > > Lucas > > > > > > > > > Thanks, > > > > > Laurentiu > > > > > > > > > > Changes in v5: > > > > > * Rebased to latest; > > > > > * Took out component framework support and made it a separate patch > > > > > so > > > > >that people can still test with HDP driver, which makes use of it. > > > > >But the idea is to get rid of it once HDP driver's next versions > > > > >will remove component framework as well; > > > > > * Slight improvement to modesetting: avoid cutting off the pixel > > > > > clock > > > > >if the new mode and the old one are equal. Also, in this case, is > > > > >not necessary to wait for DTG to shut off. This would allow to > > > > > switch > > > > >from 8b RGB to 12b YUV422, for example, with no interruptions (at > > > > > least > > > > >from DCSS point of view); > > > > > * Do not fire off CTXLD when going to suspend, unless it still has > > > > >entries that need to be committed to DCSS; > > > > > * Addressed Rob's comments on bindings; > > > > > > > > > > Changes in v4: > > > > > * Addressed Lucas and Philipp's comments: > > > > >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; > > > > >* Removed usage of devm_ functions since I'm already doing all the > > > > > clean-up in the submodules_deinit(); > > > > >* Moved the drm_crtc_arm_vblank_event() in > > > > > dcss_crtc_atomic_flush(); > > > > >* Removed en_completion variable from
Re: [PATCH v5 0/4] Add support for iMX8MQ Display Controller Subsystem
On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote: > Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter: > > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach wrote: > > > Hi Laurentiu, > > > > > > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu: > > > > From: Laurentiu Palcu > > > > > > > > Hi, > > > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > > > includes only graphics plane support (no video planes), no HDR10 > > > > capabilities, > > > > no graphics decompression (only linear, tiled and super-tiled buffers > > > > allowed). > > > > > > > > Support for the rest of the features will be added incrementally, in > > > > subsequent > > > > patches. > > > > > > > > The patchset was tested with both HDP driver (in the downstream tree) > > > > and the upstream > > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > > correctly with DCSS). > > > > > > I think the series (minus 3/5 and minor correction to the DT binding) > > > is fine to go in now. So just some formal questions: are you going to > > > maintain this driver in upstream? If so we should add a MAINTAINERS > > > entry to that effect. I can offer to act as a reviewer in this case. > > > > > > How do you intend to merge this? IMO pushing this through drm-misc > > > seems like the right thing to do. If you agree I can help you get this > > > applied. If you are going to maintain the driver on your own, I think > > > you should then apply for commit rights to drm-misc. > > > > drm/imx isn't listed yet as under the drm-misc umbrella, maybe we > > should put the entire collective of imx drivers under drm-misc? Or > > maybe it's just an oversight that the git repo isn't specified in the > > MAINTAINERS entry. Also maybe we should add the pengutronix kernel > > team alias there too? > > drm/imx was exclusively the IPUv3 up until now, which is in fact > maintained outside of drm-misc in its own git tree. This has worked > quite well in the past so even though IPUv3 doesn't see a lot of churn > these days the motivation to change anything to this workflow is quite > low. And yes, the git tree is missing from the MAINTAINERS entry. > > For the DCSS driver, if it's going to be maintained by NXP, I figured > it might be easier for Laurentiu to push things into drm-misc than set > up a separate public git tree. But IMHO that's fully up to him to > decide. /me puts on maintainer hat Much prefer drm-misc over random people playing maintainer and fumbling it. I think the reasonable options are either in the current imx tree, or drm-misc. Standalone tree for these small drivers just doesn't make much sense. -Daniel > > Regards, > Lucas > > > -Daniel > > > > > > > Regards, > > > Lucas > > > > > > > Thanks, > > > > Laurentiu > > > > > > > > Changes in v5: > > > > * Rebased to latest; > > > > * Took out component framework support and made it a separate patch so > > > >that people can still test with HDP driver, which makes use of it. > > > >But the idea is to get rid of it once HDP driver's next versions > > > >will remove component framework as well; > > > > * Slight improvement to modesetting: avoid cutting off the pixel clock > > > >if the new mode and the old one are equal. Also, in this case, is > > > >not necessary to wait for DTG to shut off. This would allow to switch > > > >from 8b RGB to 12b YUV422, for example, with no interruptions (at > > > > least > > > >from DCSS point of view); > > > > * Do not fire off CTXLD when going to suspend, unless it still has > > > >entries that need to be committed to DCSS; > > > > * Addressed Rob's comments on bindings; > > > > > > > > Changes in v4: > > > > * Addressed Lucas and Philipp's comments: > > > >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; > > > >* Removed usage of devm_ functions since I'm already doing all the > > > > clean-up in the submodules_deinit(); > > > >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); > > > >* Removed en_completion variable from dcss_crtc since this was > > > > introduced mainly to avoid vblank timeout warnings which were fixed > > > > by arming the vblank event in flush() instead of begin(); > > > >* Removed clks_on and irq_enabled flags since all the calls to > > > > enabling/disabling clocks and interrupts were balanced; > > > >* Removed the custom atomic_commit callback and used the DRM core > > > > helper and, in the process, got rid of a workqueue that wasn't > > > > necessary anymore; > > > >* Fixed some minor DT binding issues flagged by Philipp; > > > >* Some other minor changes suggested by Lucas; > > > > * Removed YUV formats from the supported formats as these cannot work > > > >without the HDR10 module CSCs and LUTs. Will add them back when I > > > >will add support for video planes; > > > > > > > > Changes in v3: >
Re: [PATCH v5 0/4] Add support for iMX8MQ Display Controller Subsystem
Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter: > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach wrote: > > Hi Laurentiu, > > > > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu: > > > From: Laurentiu Palcu > > > > > > Hi, > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > > includes only graphics plane support (no video planes), no HDR10 > > > capabilities, > > > no graphics decompression (only linear, tiled and super-tiled buffers > > > allowed). > > > > > > Support for the rest of the features will be added incrementally, in > > > subsequent > > > patches. > > > > > > The patchset was tested with both HDP driver (in the downstream tree) and > > > the upstream > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > correctly with DCSS). > > > > I think the series (minus 3/5 and minor correction to the DT binding) > > is fine to go in now. So just some formal questions: are you going to > > maintain this driver in upstream? If so we should add a MAINTAINERS > > entry to that effect. I can offer to act as a reviewer in this case. > > > > How do you intend to merge this? IMO pushing this through drm-misc > > seems like the right thing to do. If you agree I can help you get this > > applied. If you are going to maintain the driver on your own, I think > > you should then apply for commit rights to drm-misc. > > drm/imx isn't listed yet as under the drm-misc umbrella, maybe we > should put the entire collective of imx drivers under drm-misc? Or > maybe it's just an oversight that the git repo isn't specified in the > MAINTAINERS entry. Also maybe we should add the pengutronix kernel > team alias there too? drm/imx was exclusively the IPUv3 up until now, which is in fact maintained outside of drm-misc in its own git tree. This has worked quite well in the past so even though IPUv3 doesn't see a lot of churn these days the motivation to change anything to this workflow is quite low. And yes, the git tree is missing from the MAINTAINERS entry. For the DCSS driver, if it's going to be maintained by NXP, I figured it might be easier for Laurentiu to push things into drm-misc than set up a separate public git tree. But IMHO that's fully up to him to decide. Regards, Lucas > -Daniel > > > > Regards, > > Lucas > > > > > Thanks, > > > Laurentiu > > > > > > Changes in v5: > > > * Rebased to latest; > > > * Took out component framework support and made it a separate patch so > > >that people can still test with HDP driver, which makes use of it. > > >But the idea is to get rid of it once HDP driver's next versions > > >will remove component framework as well; > > > * Slight improvement to modesetting: avoid cutting off the pixel clock > > >if the new mode and the old one are equal. Also, in this case, is > > >not necessary to wait for DTG to shut off. This would allow to switch > > >from 8b RGB to 12b YUV422, for example, with no interruptions (at least > > >from DCSS point of view); > > > * Do not fire off CTXLD when going to suspend, unless it still has > > >entries that need to be committed to DCSS; > > > * Addressed Rob's comments on bindings; > > > > > > Changes in v4: > > > * Addressed Lucas and Philipp's comments: > > >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; > > >* Removed usage of devm_ functions since I'm already doing all the > > > clean-up in the submodules_deinit(); > > >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); > > >* Removed en_completion variable from dcss_crtc since this was > > > introduced mainly to avoid vblank timeout warnings which were fixed > > > by arming the vblank event in flush() instead of begin(); > > >* Removed clks_on and irq_enabled flags since all the calls to > > > enabling/disabling clocks and interrupts were balanced; > > >* Removed the custom atomic_commit callback and used the DRM core > > > helper and, in the process, got rid of a workqueue that wasn't > > > necessary anymore; > > >* Fixed some minor DT binding issues flagged by Philipp; > > >* Some other minor changes suggested by Lucas; > > > * Removed YUV formats from the supported formats as these cannot work > > >without the HDR10 module CSCs and LUTs. Will add them back when I > > >will add support for video planes; > > > > > > Changes in v3: > > > * rebased to latest linux-next and made it compile as drmP.h was > > >removed; > > > * removed the patch adding the VIDEO2_PLL clock. It's already applied; > > > * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set(); > > > * fixed a a spurious hang reported by Lukas Hartmann and encountered > > >by me several times; > > > * mask DPR and DTG interrupts by default, as they may come enabled from > > >U-boot; > > > > > > Changes in v2: > > > * Removed '0x' in node's unit-address both in DT and yaml;
Re: [PATCH -next] drm/komeda: Convert to DEFINE_SHOW_ATTRIBUTE
On Fri, Jul 17, 2020 at 04:00:36PM +0800, miaoqinglang wrote:
>
>
> 在 2020/7/17 15:06, Daniel Vetter 写道:
> > On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
> > wrote:
> > >
> > > On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> > > > From: Liu Shixin
> > > >
> > > > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> > > >
> > > > Signed-off-by: Liu Shixin
> > > > ---
> > > > drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 13 +
> > > > 1 file changed, 1 insertion(+), 12 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > > > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > > > index 0246b2e94..4a10e6b9e 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > > > @@ -41,18 +41,7 @@ static int komeda_register_show(struct seq_file *sf,
> > > > void *x)
> > > >return 0;
> > > > }
> > > >
> > > > -static int komeda_register_open(struct inode *inode, struct file *filp)
> > > > -{
> > > > - return single_open(filp, komeda_register_show, inode->i_private);
> > > > -}
> > > > -
> > > > -static const struct file_operations komeda_register_fops = {
> > > > - .owner = THIS_MODULE,
> > > > - .open = komeda_register_open,
> > > > - .read_iter = seq_read_iter,
> > > > - .llseek = seq_lseek,
> > > > - .release= single_release,
> > > > -};
> > > > +DEFINE_SHOW_ATTRIBUTE(komeda_register);
> > > >
> > >
> > > Hi Shixin & Qinglang
> > >
> > > Thanks for your patch.
> > >
> > > Reviewed-by: James Qian Wang
> > >
> > > Since your patch is not for drm-misc-next, so seems better
> > > to leave it to you to merge it. :)
> >
> > I do think it's for drm-misc-next, what other tree would it be for?
> > Some people put -next in their patch tag to differentiate from -fixes,
> > so maintainers know what to do with the patch. It's also not part of a
> > series, hence I think this is on you to apply it.
> >
> Hi James & Daniel,
>
> Sorry I didn't make it clear in commit log, but it do based on linux-next.
>
> I think the reason why James think it's not for drm-misc-next
> is conflicts exists when this patch being applied. There's conflicts because
> commit <4d4901c6d7> which switched over direct seq_read method calls to
> seq_read_iter should applied before this clean-up patch(linkage listed as
> below).
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/4d4901c6d748efab8aab6e7d2405dadaed0bea50
>
> I can send a new patch based on mainline if needed.
Uh yes this is annoying. We're at feature cutoff so this will likely cause
bad conflicts no matter what if we merge it now, but the clean solution is
to rebase onto drm-misc-next, and then let maintainers sort out the mess
with conflicts. It's a pretty simple change in the above patch, so
shouldn't cause too many troubles.
-Daniel
>
> Thanks.
>
> Qinglang
>
> .
>
> >
> > Cheers, Daniel
> >
> > >
> > > Thanks
> > > James
> > >
> > > > #ifdef CONFIG_DEBUG_FS
> > > > static void komeda_debugfs_init(struct komeda_dev *mdev)
> > > > --
> > > > 2.17.1
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/amd/powerplay: fix a crash when overclocking Vega M
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: Qiu Wenbo
Sent: Friday, July 17, 2020 3:10 PM
To: Quan, Evan ; amd-...@lists.freedesktop.org
Cc: Qiu Wenbo ; Deucher, Alexander
; Koenig, Christian ;
Zhou, David(ChunMing) ; David Airlie ;
Daniel Vetter ; Chen Wandun ;
YueHaibing ; yu kuai ; Huang,
JinHuiEric ; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
Subject: [PATCH] drm/amd/powerplay: fix a crash when overclocking Vega M
Avoid kernel crash when vddci_control is SMU7_VOLTAGE_CONTROL_NONE and
vddci_voltage_table is empty. It has been tested on Intel Hades Canyon
(i7-8809G).
Bug:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D208489data=02%7C01%7Cevan.quan%40amd.com%7Cff6bf841473b46539e1708d82a20723d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637305666456662890sdata=%2FMXKE9MMkUF2JPR3JiCTNdgAyyRnQXkxpZfS9eTPrW8%3Dreserved=0
Fixes: ac7822b0026f ("drm/amd/powerplay: add smumgr support for VEGAM (v2)")
Signed-off-by: Qiu Wenbo
---
drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
index 3da71a088b92..0ecc18b55ffb 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
@@ -644,9 +644,6 @@ static int vegam_get_dependency_volt_by_clk(struct pp_hwmgr
*hwmgr,
/* sclk is bigger than max sclk in the dependence table */
*voltage |= (dep_table->entries[i - 1].vddc * VOLTAGE_SCALE) << VDDC_SHIFT;
-vddci = phm_find_closest_vddci(&(data->vddci_voltage_table),
-(dep_table->entries[i - 1].vddc -
-(uint16_t)VDDC_VDDCI_DELTA));
if (SMU7_VOLTAGE_CONTROL_NONE == data->vddci_control)
*voltage |= (data->vbios_boot_state.vddci_bootup_value *
@@ -654,8 +651,13 @@ static int vegam_get_dependency_volt_by_clk(struct
pp_hwmgr *hwmgr,
else if (dep_table->entries[i - 1].vddci)
*voltage |= (dep_table->entries[i - 1].vddci *
VOLTAGE_SCALE) << VDDC_SHIFT;
-else
+else {
+vddci = phm_find_closest_vddci(&(data->vddci_voltage_table),
+(dep_table->entries[i - 1].vddc -
+(uint16_t)VDDC_VDDCI_DELTA));
+
*voltage |= (vddci * VOLTAGE_SCALE) << VDDCI_SHIFT;
+}
if (SMU7_VOLTAGE_CONTROL_NONE == data->mvdd_control)
*mvdd = data->vbios_boot_state.mvdd_bootup_value * VOLTAGE_SCALE;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/18] drm/arc: Delete arcpgu_priv->fb
Leftover from the conversion to the generic fbdev emulation.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 87821c91a00c..ed77dd5dd5cb 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -12,7 +12,6 @@ struct arcpgu_drm_private {
struct drm_device drm;
void __iomem*regs;
struct clk *clk;
- struct drm_framebuffer *fb;
struct drm_crtc crtc;
struct drm_plane*plane;
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/18] drm/arc: Drop surplus connector registration
drm_connector_register does nothing before drm_dev_register(), it
is meant for hotpluggable connectors only. Same for the unregister side.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/arcpgu_sim.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index e42fe5d05a3d..3772df1647aa 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -29,7 +29,6 @@ static int arcpgu_drm_connector_get_modes(struct
drm_connector *connector)
static void arcpgu_drm_connector_destroy(struct drm_connector *connector)
{
- drm_connector_unregister(connector);
drm_connector_cleanup(connector);
}
@@ -80,7 +79,6 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
device_node *np)
ret = drm_connector_attach_encoder(connector, encoder);
if (ret < 0) {
dev_err(drm->dev, "could not attach connector to encoder\n");
- drm_connector_unregister(connector);
goto error_connector_cleanup;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/18] drm/armada: Use devm_drm_dev_alloc
Also remove the now no longer needed build bug on since that's already
not needed anymore with drmm_add_final_kfree. Conversion to managed
drm_device cleanup is easy, the final drm_dev_put() is already the
last thing in both the bind unbind as in the unbind flow.
Also, this relies on component.c correctly wrapping bind in
separate devres groups, which it does.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_drv.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index 5fc25c3f445c..a8d5908b3922 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -87,24 +87,13 @@ static int armada_drm_bind(struct device *dev)
"armada-drm"))
return -EBUSY;
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- /*
-* The drm_device structure must be at the start of
-* armada_private for drm_dev_put() to work correctly.
-*/
- BUILD_BUG_ON(offsetof(struct armada_private, drm) != 0);
-
- ret = drm_dev_init(>drm, _drm_driver, dev);
- if (ret) {
- dev_err(dev, "[" DRM_NAME ":%s] drm_dev_init failed: %d\n",
- __func__, ret);
- kfree(priv);
- return ret;
+ priv = devm_drm_dev_alloc(dev, _drm_driver,
+ struct armada_private, drm);
+ if (IS_ERR(priv)) {
+ dev_err(dev, "[" DRM_NAME ":%s] devm_drm_dev_alloc failed:
%li\n",
+ __func__, PTR_ERR(priv));
+ return PTR_ERR(priv);
}
- drmm_add_final_kfree(>drm, priv);
/* Remove early framebuffers */
ret = drm_fb_helper_remove_conflicting_framebuffers(NULL,
@@ -174,7 +163,6 @@ static int armada_drm_bind(struct device *dev)
err_kms:
drm_mode_config_cleanup(>drm);
drm_mm_takedown(>linear);
- drm_dev_put(>drm);
return ret;
}
@@ -194,8 +182,6 @@ static void armada_drm_unbind(struct device *dev)
drm_mode_config_cleanup(>drm);
drm_mm_takedown(>linear);
-
- drm_dev_put(>drm);
}
static int compare_of(struct device *dev, void *data)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/18] drm/aspeed: Use managed drmm_mode_config_cleanup
Since aspeed doesn't use devm_kzalloc anymore we can use the managed
mode config cleanup.
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: linux-asp...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index 903f4f304647..0e19523f2a06 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -63,15 +63,15 @@ static const struct drm_mode_config_funcs
aspeed_gfx_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static void aspeed_gfx_setup_mode_config(struct drm_device *drm)
+static int aspeed_gfx_setup_mode_config(struct drm_device *drm)
{
- drm_mode_config_init(drm);
-
drm->mode_config.min_width = 0;
drm->mode_config.min_height = 0;
drm->mode_config.max_width = 800;
drm->mode_config.max_height = 600;
drm->mode_config.funcs = _gfx_mode_config_funcs;
+
+ return drmm_mode_config_init(drm);
}
static irqreturn_t aspeed_gfx_irq_handler(int irq, void *data)
@@ -144,7 +144,9 @@ static int aspeed_gfx_load(struct drm_device *drm)
writel(0, priv->base + CRT_CTRL1);
writel(0, priv->base + CRT_CTRL2);
- aspeed_gfx_setup_mode_config(drm);
+ ret = aspeed_gfx_setup_mode_config(drm);
+ if (ret < 0)
+ return ret;
ret = drm_vblank_init(drm, 1);
if (ret < 0) {
@@ -179,7 +181,6 @@ static int aspeed_gfx_load(struct drm_device *drm)
static void aspeed_gfx_unload(struct drm_device *drm)
{
drm_kms_helper_poll_fini(drm);
- drm_mode_config_cleanup(drm);
}
DEFINE_DRM_GEM_CMA_FOPS(fops);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/18] drm/armada: Don't use drm_device->dev_private
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 4 ++--
drivers/gpu/drm/armada/armada_debugfs.c | 2 +-
drivers/gpu/drm/armada/armada_drm.h | 2 ++
drivers/gpu/drm/armada/armada_drv.c | 4 +---
drivers/gpu/drm/armada/armada_fbdev.c | 4 ++--
drivers/gpu/drm/armada/armada_gem.c | 4 ++--
drivers/gpu/drm/armada/armada_overlay.c | 8
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 38dfaa46d306..a887b6a5f8bd 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -757,7 +757,7 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc
*crtc, int x, int y)
static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
{
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
- struct armada_private *priv = crtc->dev->dev_private;
+ struct armada_private *priv = drm_to_armada_dev(crtc->dev);
if (dcrtc->cursor_obj)
drm_gem_object_put(>cursor_obj->obj);
@@ -901,7 +901,7 @@ static int armada_drm_crtc_create(struct drm_device *drm,
struct device *dev,
struct resource *res, int irq, const struct armada_variant *variant,
struct device_node *port)
{
- struct armada_private *priv = drm->dev_private;
+ struct armada_private *priv = drm_to_armada_dev(drm);
struct armada_crtc *dcrtc;
struct drm_plane *primary;
void __iomem *base;
diff --git a/drivers/gpu/drm/armada/armada_debugfs.c
b/drivers/gpu/drm/armada/armada_debugfs.c
index c6fc2f1d58e9..29f4b52e3c8d 100644
--- a/drivers/gpu/drm/armada/armada_debugfs.c
+++ b/drivers/gpu/drm/armada/armada_debugfs.c
@@ -19,7 +19,7 @@ static int armada_debugfs_gem_linear_show(struct seq_file *m,
void *data)
{
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
- struct armada_private *priv = dev->dev_private;
+ struct armada_private *priv = drm_to_armada_dev(dev);
struct drm_printer p = drm_seq_file_printer(m);
mutex_lock(>linear_lock);
diff --git a/drivers/gpu/drm/armada/armada_drm.h
b/drivers/gpu/drm/armada/armada_drm.h
index a11bdaccbb33..6a5a87932576 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -73,6 +73,8 @@ struct armada_private {
#endif
};
+#define drm_to_armada_dev(dev) container_of(dev, struct armada_private, drm)
+
int armada_fbdev_init(struct drm_device *);
void armada_fbdev_fini(struct drm_device *);
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index a8d5908b3922..980d3f1f8f16 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -106,8 +106,6 @@ static int armada_drm_bind(struct device *dev)
return ret;
}
- priv->drm.dev_private = priv;
-
dev_set_drvdata(dev, >drm);
/* Mode setting support */
@@ -169,7 +167,7 @@ static int armada_drm_bind(struct device *dev)
static void armada_drm_unbind(struct device *dev)
{
struct drm_device *drm = dev_get_drvdata(dev);
- struct armada_private *priv = drm->dev_private;
+ struct armada_private *priv = drm_to_armada_dev(drm);
drm_kms_helper_poll_fini(>drm);
armada_fbdev_fini(>drm);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 0c4601275507..38f5170c0fea 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -117,7 +117,7 @@ static const struct drm_fb_helper_funcs
armada_fb_helper_funcs = {
int armada_fbdev_init(struct drm_device *dev)
{
- struct armada_private *priv = dev->dev_private;
+ struct armada_private *priv = drm_to_armada_dev(dev);
struct drm_fb_helper *fbh;
int ret;
@@ -151,7 +151,7 @@ int armada_fbdev_init(struct drm_device *dev)
void armada_fbdev_fini(struct drm_device *dev)
{
- struct armada_private *priv = dev->dev_private;
+ struct armada_private *priv = drm_to_armada_dev(dev);
struct drm_fb_helper *fbh = priv->fbdev;
if (fbh) {
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 8005614d2e6b..ecf8a55e93d9 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -39,7 +39,7 @@ static size_t roundup_gem_size(size_t size)
void armada_gem_free_object(struct drm_gem_object *obj)
{
struct armada_gem_object *dobj = drm_to_armada_gem(obj);
- struct armada_private *priv = obj->dev->dev_private;
+ struct armada_private *priv = drm_to_armada_dev(obj->dev);
DRM_DEBUG_DRIVER("release obj %p\n", dobj);
@@ -77,7 +77,7 @@ void armada_gem_free_object(struct
[PATCH 15/18] drm/arc: Inline remaining files
At less than 500 lines total feels like the right thing to do.
Also noticed that the simple wrapper around drm_connector_cleanup can
be dropped.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 39
drivers/gpu/drm/arc/arcpgu_drv.c | 102 +-
drivers/gpu/drm/arc/arcpgu_regs.h | 31 -
drivers/gpu/drm/arc/arcpgu_sim.c | 74 --
5 files changed, 101 insertions(+), 147 deletions(-)
delete mode 100644 drivers/gpu/drm/arc/arcpgu.h
delete mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h
delete mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index 379a1145bc2f..b26f2495c532 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-arcpgu-y := arcpgu_sim.o arcpgu_drv.o
+arcpgu-y := arcpgu_drv.o
obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
deleted file mode 100644
index 7dce0c2313ba..
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * ARC PGU DRM driver.
- *
- * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
- */
-
-#ifndef _ARCPGU_H_
-#define _ARCPGU_H_
-
-#include
-
-struct arcpgu_drm_private {
- struct drm_device drm;
- void __iomem*regs;
- struct clk *clk;
- struct drm_simple_display_pipe pipe;
- struct drm_connectorsim_conn;
-};
-
-#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
-
-#define pipe_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, pipe)
-
-static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
-unsigned int reg, u32 value)
-{
- iowrite32(value, arcpgu->regs + reg);
-}
-
-static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
- unsigned int reg)
-{
- return ioread32(arcpgu->regs + reg);
-}
-
-int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
-
-#endif
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 40697cab0d03..3c44b9b4acec 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -17,13 +17,111 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include "arcpgu.h"
-#include "arcpgu_regs.h"
+#define ARCPGU_REG_CTRL0x00
+#define ARCPGU_REG_STAT0x04
+#define ARCPGU_REG_FMT 0x10
+#define ARCPGU_REG_HSYNC 0x14
+#define ARCPGU_REG_VSYNC 0x18
+#define ARCPGU_REG_ACTIVE 0x1c
+#define ARCPGU_REG_BUF0_ADDR 0x40
+#define ARCPGU_REG_STRIDE 0x50
+#define ARCPGU_REG_START_SET 0x84
+
+#define ARCPGU_REG_ID 0x3FC
+
+#define ARCPGU_CTRL_ENABLE_MASK0x02
+#define ARCPGU_CTRL_VS_POL_MASK0x1
+#define ARCPGU_CTRL_VS_POL_OFST0x3
+#define ARCPGU_CTRL_HS_POL_MASK0x1
+#define ARCPGU_CTRL_HS_POL_OFST0x4
+#define ARCPGU_MODE_XRGB BIT(2)
+#define ARCPGU_STAT_BUSY_MASK 0x02
+
+struct arcpgu_drm_private {
+ struct drm_device drm;
+ void __iomem*regs;
+ struct clk *clk;
+ struct drm_simple_display_pipe pipe;
+ struct drm_connectorsim_conn;
+};
+
+#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
+
+#define pipe_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, pipe)
+
+static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
+unsigned int reg, u32 value)
+{
+ iowrite32(value, arcpgu->regs + reg);
+}
+
+static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
+ unsigned int reg)
+{
+ return ioread32(arcpgu->regs + reg);
+}
+
+#define XRES_DEF 640
+#define YRES_DEF 480
+
+#define XRES_MAX 8192
+#define YRES_MAX 8192
+
+static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
+{
+ int count;
+
+ count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
+ drm_set_preferred_mode(connector, XRES_DEF, YRES_DEF);
+ return count;
+}
+
+static const struct drm_connector_helper_funcs
+arcpgu_drm_connector_helper_funcs = {
+ .get_modes = arcpgu_drm_connector_get_modes,
+};
+
+static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
+ .reset = drm_atomic_helper_connector_reset,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int arcpgu_drm_sim_init(struct
[PATCH 10/18] drm/arc: Align with simple pipe helpers
Simple pipe helpers only have an enable and disable hook, no more
mode_set_nofb. Call it from our enable hook to align with that
conversions.
Atomic helpers always call mode_set_nofb and enable together, so
there's no functional change here.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 72719556debb..c7769edeefdf 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -73,10 +73,9 @@ static enum drm_mode_status arc_pgu_crtc_mode_valid(struct
drm_crtc *crtc,
return MODE_NOCLOCK;
}
-static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
+static void arc_pgu_mode_set(struct arcpgu_drm_private *arcpgu)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
- struct drm_display_mode *m = >state->adjusted_mode;
+ struct drm_display_mode *m = >pipe.crtc.state->adjusted_mode;
u32 val;
arc_pgu_write(arcpgu, ARCPGU_REG_FMT,
@@ -110,7 +109,7 @@ static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc
*crtc)
arc_pgu_write(arcpgu, ARCPGU_REG_STRIDE, 0);
arc_pgu_write(arcpgu, ARCPGU_REG_START_SET, 1);
- arc_pgu_set_pxl_fmt(crtc);
+ arc_pgu_set_pxl_fmt(>pipe.crtc);
clk_set_rate(arcpgu->clk, m->crtc_clock * 1000);
}
@@ -120,6 +119,8 @@ static void arc_pgu_crtc_atomic_enable(struct drm_crtc
*crtc,
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+ arc_pgu_mode_set(arcpgu);
+
clk_prepare_enable(arcpgu->clk);
arc_pgu_write(arcpgu, ARCPGU_REG_CTRL,
arc_pgu_read(arcpgu, ARCPGU_REG_CTRL) |
@@ -139,7 +140,6 @@ static void arc_pgu_crtc_atomic_disable(struct drm_crtc
*crtc,
static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
.mode_valid = arc_pgu_crtc_mode_valid,
- .mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
.atomic_enable = arc_pgu_crtc_atomic_enable,
.atomic_disable = arc_pgu_crtc_atomic_disable,
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/18] drm/arc: Move to drm/tiny
Because it is.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
MAINTAINERS | 2 +-
drivers/gpu/drm/Kconfig | 2 --
drivers/gpu/drm/Makefile| 1 -
drivers/gpu/drm/arc/Kconfig | 10 --
drivers/gpu/drm/arc/Makefile| 3 ---
drivers/gpu/drm/tiny/Kconfig| 10 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} | 0
8 files changed, 12 insertions(+), 17 deletions(-)
delete mode 100644 drivers/gpu/drm/arc/Kconfig
delete mode 100644 drivers/gpu/drm/arc/Makefile
rename drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 415954a98934..0ed6c36004e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1322,7 +1322,7 @@ ARC PGU DRM DRIVER
M: Alexey Brodkin
S: Supported
F: Documentation/devicetree/bindings/display/snps,arcpgu.txt
-F: drivers/gpu/drm/arc/
+F: drivers/gpu/drm/tiny/arcpgu.c
ARCNET NETWORK LAYER
M: Michael Grzeschik
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4fd57d8b717..d44c6eac2c58 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -354,8 +354,6 @@ source "drivers/gpu/drm/vc4/Kconfig"
source "drivers/gpu/drm/etnaviv/Kconfig"
-source "drivers/gpu/drm/arc/Kconfig"
-
source "drivers/gpu/drm/hisilicon/Kconfig"
source "drivers/gpu/drm/mediatek/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c0e5a7e5953..e69eafbf9e39 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -109,7 +109,6 @@ obj-y += panel/
obj-y += bridge/
obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
-obj-$(CONFIG_DRM_ARCPGU)+= arc/
obj-y += hisilicon/
obj-$(CONFIG_DRM_ZTE) += zte/
obj-$(CONFIG_DRM_MXSFB)+= mxsfb/
diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
deleted file mode 100644
index e8f3d63e0b91..
--- a/drivers/gpu/drm/arc/Kconfig
+++ /dev/null
@@ -1,10 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-config DRM_ARCPGU
- tristate "ARC PGU"
- depends on DRM && OF
- select DRM_KMS_CMA_HELPER
- select DRM_KMS_HELPER
- help
- Choose this option if you have an ARC PGU controller.
-
- If M is selected the module will be called arcpgu.
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
deleted file mode 100644
index b26f2495c532..
--- a/drivers/gpu/drm/arc/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-arcpgu-y := arcpgu_drv.o
-obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa75..9bbaa1a69050 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -1,5 +1,15 @@
# SPDX-License-Identifier: GPL-2.0-only
+config DRM_ARCPGU
+ tristate "ARC PGU"
+ depends on DRM && OF
+ select DRM_KMS_CMA_HELPER
+ select DRM_KMS_HELPER
+ help
+ Choose this option if you have an ARC PGU controller.
+
+ If M is selected the module will be called arcpgu.
+
config DRM_CIRRUS_QEMU
tristate "Cirrus driver for QEMU emulated device"
depends on DRM && PCI && MMU
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35f..bef6780bdd6f 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/tiny/arcpgu.c
similarity index 100%
rename from drivers/gpu/drm/arc/arcpgu_drv.c
rename to drivers/gpu/drm/tiny/arcpgu.c
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/18] drm/arc: Stop using drm_device->dev_private
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 2 ++
drivers/gpu/drm/arc/arcpgu_crtc.c | 4 ++--
drivers/gpu/drm/arc/arcpgu_drv.c | 4 +---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index cd9e932f501e..87821c91a00c 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -17,6 +17,8 @@ struct arcpgu_drm_private {
struct drm_plane*plane;
};
+#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
+
#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index be7c29cec318..ba796a216244 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -178,7 +178,7 @@ static const struct drm_plane_funcs arc_pgu_plane_funcs = {
static struct drm_plane *arc_pgu_plane_init(struct drm_device *drm)
{
- struct arcpgu_drm_private *arcpgu = drm->dev_private;
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
struct drm_plane *plane = NULL;
int ret;
@@ -202,7 +202,7 @@ static struct drm_plane *arc_pgu_plane_init(struct
drm_device *drm)
int arc_pgu_setup_crtc(struct drm_device *drm)
{
- struct arcpgu_drm_private *arcpgu = drm->dev_private;
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
struct drm_plane *primary;
int ret;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 68eb4a31c54b..c6a8deb56b0f 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -50,8 +50,6 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
struct resource *res;
int ret;
- drm->dev_private = arcpgu;
-
arcpgu->clk = devm_clk_get(drm->dev, "pxlclk");
if (IS_ERR(arcpgu->clk))
return PTR_ERR(arcpgu->clk);
@@ -120,7 +118,7 @@ static int arcpgu_show_pxlclock(struct seq_file *m, void
*arg)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *drm = node->minor->dev;
- struct arcpgu_drm_private *arcpgu = drm->dev_private;
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
unsigned long clkrate = clk_get_rate(arcpgu->clk);
unsigned long mode_clock = arcpgu->crtc.mode.crtc_clock * 1000;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/18] drm/arc: Inline arcpgu_crtc.c
Really not big anymore.
v2: Fixup update function, bug reported by Eugeniy
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_crtc.c | 169 --
drivers/gpu/drm/arc/arcpgu_drv.c | 150 +-
drivers/gpu/drm/arc/arcpgu_sim.c | 12 ---
5 files changed, 149 insertions(+), 185 deletions(-)
delete mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index c7028b7427b3..c686e0287a71 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
+arcpgu-y := arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index b5c699d14f27..cee2448a07d6 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -34,7 +34,6 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private
*arcpgu,
return ioread32(arcpgu->regs + reg);
}
-int arc_pgu_setup_pipe(struct drm_device *dev);
int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
deleted file mode 100644
index a72136ee4e46..
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ /dev/null
@@ -1,169 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * ARC PGU DRM driver.
- *
- * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "arcpgu.h"
-#include "arcpgu_regs.h"
-
-#define ENCODE_PGU_XY(x, y)x) - 1) << 16) | ((y) - 1))
-
-static const u32 arc_pgu_supported_formats[] = {
- DRM_FORMAT_RGB565,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
-};
-
-static void arc_pgu_set_pxl_fmt(struct arcpgu_drm_private *arcpgu)
-{
- const struct drm_framebuffer *fb = arcpgu->pipe.plane.state->fb;
- uint32_t pixel_format = fb->format->format;
- u32 format = DRM_FORMAT_INVALID;
- int i;
- u32 reg_ctrl;
-
- for (i = 0; i < ARRAY_SIZE(arc_pgu_supported_formats); i++) {
- if (arc_pgu_supported_formats[i] == pixel_format)
- format = arc_pgu_supported_formats[i];
- }
-
- if (WARN_ON(format == DRM_FORMAT_INVALID))
- return;
-
- reg_ctrl = arc_pgu_read(arcpgu, ARCPGU_REG_CTRL);
- if (format == DRM_FORMAT_RGB565)
- reg_ctrl &= ~ARCPGU_MODE_XRGB;
- else
- reg_ctrl |= ARCPGU_MODE_XRGB;
- arc_pgu_write(arcpgu, ARCPGU_REG_CTRL, reg_ctrl);
-}
-
-static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
- .destroy = drm_crtc_cleanup,
- .set_config = drm_atomic_helper_set_config,
- .page_flip = drm_atomic_helper_page_flip,
- .reset = drm_atomic_helper_crtc_reset,
- .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
-};
-
-static enum drm_mode_status arc_pgu_mode_valid(struct drm_simple_display_pipe
*pipe,
- const struct drm_display_mode
*mode)
-{
- struct arcpgu_drm_private *arcpgu = pipe_to_arcpgu_priv(pipe);
- long rate, clk_rate = mode->clock * 1000;
- long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */
-
- rate = clk_round_rate(arcpgu->clk, clk_rate);
- if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0))
- return MODE_OK;
-
- return MODE_NOCLOCK;
-}
-
-static void arc_pgu_mode_set(struct arcpgu_drm_private *arcpgu)
-{
- struct drm_display_mode *m = >pipe.crtc.state->adjusted_mode;
- u32 val;
-
- arc_pgu_write(arcpgu, ARCPGU_REG_FMT,
- ENCODE_PGU_XY(m->crtc_htotal, m->crtc_vtotal));
-
- arc_pgu_write(arcpgu, ARCPGU_REG_HSYNC,
- ENCODE_PGU_XY(m->crtc_hsync_start - m->crtc_hdisplay,
- m->crtc_hsync_end - m->crtc_hdisplay));
-
- arc_pgu_write(arcpgu, ARCPGU_REG_VSYNC,
- ENCODE_PGU_XY(m->crtc_vsync_start - m->crtc_vdisplay,
- m->crtc_vsync_end - m->crtc_vdisplay));
-
- arc_pgu_write(arcpgu, ARCPGU_REG_ACTIVE,
- ENCODE_PGU_XY(m->crtc_hblank_end - m->crtc_hblank_start,
- m->crtc_vblank_end - m->crtc_vblank_start));
-
- val = arc_pgu_read(arcpgu, ARCPGU_REG_CTRL);
-
- if (m->flags & DRM_MODE_FLAG_PVSYNC)
- val |= ARCPGU_CTRL_VS_POL_MASK << ARCPGU_CTRL_VS_POL_OFST;
-
[PATCH 09/18] drm/arc: Use drmm_mode_config_cleanup
With autocleanup through drm_device management we can delete all the
code. Possible now that there's no confusion against devm_kzalloc'ed
structures anymore.
I inlined arcpgu_setup_mode_config because it's tiny and the newly
needed return value handling would have been more ...
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 4 +---
drivers/gpu/drm/arc/arcpgu_drv.c | 21 +
drivers/gpu/drm/arc/arcpgu_hdmi.c | 6 +-
drivers/gpu/drm/arc/arcpgu_sim.c | 11 ++-
4 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 88ba2e284fc0..72719556debb 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -209,10 +209,8 @@ int arc_pgu_setup_crtc(struct drm_device *drm)
ret = drm_crtc_init_with_planes(drm, >pipe.crtc, primary, NULL,
_pgu_crtc_funcs, NULL);
- if (ret) {
- arc_pgu_plane_destroy(primary);
+ if (ret)
return ret;
- }
drm_crtc_helper_add(>pipe.crtc, _pgu_crtc_helper_funcs);
return 0;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 9020352816fa..6349e9dc770e 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -30,16 +30,6 @@ static const struct drm_mode_config_funcs
arcpgu_drm_modecfg_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static void arcpgu_setup_mode_config(struct drm_device *drm)
-{
- drm_mode_config_init(drm);
- drm->mode_config.min_width = 0;
- drm->mode_config.min_height = 0;
- drm->mode_config.max_width = 1920;
- drm->mode_config.max_height = 1080;
- drm->mode_config.funcs = _drm_modecfg_funcs;
-}
-
DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
@@ -54,7 +44,15 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
if (IS_ERR(arcpgu->clk))
return PTR_ERR(arcpgu->clk);
- arcpgu_setup_mode_config(drm);
+ ret = drmm_mode_config_init(drm);
+ if (ret)
+ return ret;
+
+ drm->mode_config.min_width = 0;
+ drm->mode_config.min_height = 0;
+ drm->mode_config.max_width = 1920;
+ drm->mode_config.max_height = 1080;
+ drm->mode_config.funcs = _drm_modecfg_funcs;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
arcpgu->regs = devm_ioremap_resource(>dev, res);
@@ -108,7 +106,6 @@ static int arcpgu_unload(struct drm_device *drm)
{
drm_kms_helper_poll_fini(drm);
drm_atomic_helper_shutdown(drm);
- drm_mode_config_cleanup(drm);
return 0;
}
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index dbad2c9237fe..925d6d31bb78 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -39,9 +39,5 @@ int arcpgu_drm_hdmi_init(struct drm_device *drm, struct
device_node *np)
return ret;
/* Link drm_bridge to encoder */
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
- if (ret)
- drm_encoder_cleanup(encoder);
-
- return ret;
+ return drm_bridge_attach(encoder, bridge, NULL, 0);
}
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 3772df1647aa..afc34f8b4de0 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -73,21 +73,14 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
device_node *np)
DRM_MODE_CONNECTOR_VIRTUAL);
if (ret < 0) {
dev_err(drm->dev, "failed to initialize drm connector\n");
- goto error_encoder_cleanup;
+ return ret;
}
ret = drm_connector_attach_encoder(connector, encoder);
if (ret < 0) {
dev_err(drm->dev, "could not attach connector to encoder\n");
- goto error_connector_cleanup;
+ return ret;
}
return 0;
-
-error_connector_cleanup:
- drm_connector_cleanup(connector);
-
-error_encoder_cleanup:
- drm_encoder_cleanup(encoder);
- return ret;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/18] drm/arc: Switch to devm_drm_dev_alloc
- Need to embedded the drm_device, but for now we keep the usual
pointer chasing.
- No more devm_kzalloc, which fixes a lifetime issues on driver
remove.
- No more drm_dev_put, that's done by devm_ now.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 +
drivers/gpu/drm/arc/arcpgu_drv.c | 33 +---
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 6aac44b953ad..cd9e932f501e 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -9,6 +9,7 @@
#define _ARCPGU_H_
struct arcpgu_drm_private {
+ struct drm_device drm;
void __iomem*regs;
struct clk *clk;
struct drm_framebuffer *fb;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index f164818ec477..68eb4a31c54b 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -42,18 +42,14 @@ static void arcpgu_setup_mode_config(struct drm_device *drm)
DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
-static int arcpgu_load(struct drm_device *drm)
+static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
{
- struct platform_device *pdev = to_platform_device(drm->dev);
- struct arcpgu_drm_private *arcpgu;
+ struct platform_device *pdev = to_platform_device(arcpgu->drm.dev);
struct device_node *encoder_node = NULL, *endpoint_node = NULL;
+ struct drm_device *drm = >drm;
struct resource *res;
int ret;
- arcpgu = devm_kzalloc(>dev, sizeof(*arcpgu), GFP_KERNEL);
- if (arcpgu == NULL)
- return -ENOMEM;
-
drm->dev_private = arcpgu;
arcpgu->clk = devm_clk_get(drm->dev, "pxlclk");
@@ -162,30 +158,28 @@ static struct drm_driver arcpgu_drm_driver = {
static int arcpgu_probe(struct platform_device *pdev)
{
- struct drm_device *drm;
+ struct arcpgu_drm_private *arcpgu;
int ret;
- drm = drm_dev_alloc(_drm_driver, >dev);
- if (IS_ERR(drm))
- return PTR_ERR(drm);
+ arcpgu = devm_drm_dev_alloc(>dev, _drm_driver,
+ struct arcpgu_drm_private, drm);
+ if (IS_ERR(arcpgu))
+ return PTR_ERR(arcpgu);
- ret = arcpgu_load(drm);
+ ret = arcpgu_load(arcpgu);
if (ret)
- goto err_unref;
+ return ret;
- ret = drm_dev_register(drm, 0);
+ ret = drm_dev_register(>drm, 0);
if (ret)
goto err_unload;
- drm_fbdev_generic_setup(drm, 16);
+ drm_fbdev_generic_setup(>drm, 16);
return 0;
err_unload:
- arcpgu_unload(drm);
-
-err_unref:
- drm_dev_put(drm);
+ arcpgu_unload(>drm);
return ret;
}
@@ -196,7 +190,6 @@ static int arcpgu_remove(struct platform_device *pdev)
drm_dev_unregister(drm);
arcpgu_unload(drm);
- drm_dev_put(drm);
return 0;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/18] drm/arc: Inline arcpgu_drm_hdmi_init
Really not worth the function, much less the separate file now that
almost all the code is gone.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_drv.c | 12 +---
drivers/gpu/drm/arc/arcpgu_hdmi.c | 27 ---
4 files changed, 10 insertions(+), 32 deletions(-)
delete mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index c686e0287a71..379a1145bc2f 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-arcpgu-y := arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
+arcpgu-y := arcpgu_sim.o arcpgu_drv.o
obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index cee2448a07d6..7dce0c2313ba 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -34,7 +34,6 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private
*arcpgu,
return ioread32(arcpgu->regs + reg);
}
-int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
#endif
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 25edb4e4dff2..40697cab0d03 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -230,9 +230,15 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
}
if (encoder_node) {
- ret = arcpgu_drm_hdmi_init(drm, encoder_node);
- of_node_put(encoder_node);
- if (ret < 0)
+ struct drm_bridge *bridge;
+
+ /* Locate drm bridge from the hdmi encoder DT node */
+ bridge = of_drm_find_bridge(encoder_node);
+ if (!bridge)
+ return -EPROBE_DEFER;
+
+ ret = drm_simple_display_pipe_attach_bridge(>pipe,
bridge);
+ if (ret)
return ret;
} else {
dev_info(drm->dev, "no encoder found. Assumed virtual LCD on
simulation platform\n");
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
deleted file mode 100644
index d430af686cbc..
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ /dev/null
@@ -1,27 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * ARC PGU DRM driver.
- *
- * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
- */
-
-#include
-#include
-#include
-#include
-
-#include "arcpgu.h"
-
-int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np)
-{
- struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
- struct drm_bridge *bridge;
-
- /* Locate drm bridge from the hdmi encoder DT node */
- bridge = of_drm_find_bridge(np);
- if (!bridge)
- return -EPROBE_DEFER;
-
- /* Link drm_bridge to encoder */
- return drm_simple_display_pipe_attach_bridge(>pipe, bridge);
-}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/18] drm/arc: Initialize sim connector before display pipe
That way we can get rid of this final piece of init code, and use the
simple pipe helpers as intended.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_drv.c | 51 ++--
1 file changed, 16 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 3c44b9b4acec..788101401701 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -95,32 +95,11 @@ static const struct drm_connector_funcs
arcpgu_drm_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
+static int arcpgu_drm_sim_init(struct drm_device *drm, struct drm_connector
*connector)
{
- struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
- struct drm_encoder *encoder;
- struct drm_connector *connector;
- int ret;
-
- encoder = >pipe.encoder;
-
- connector = >sim_conn;
drm_connector_helper_add(connector, _drm_connector_helper_funcs);
-
- ret = drm_connector_init(drm, connector, _drm_connector_funcs,
+ return drm_connector_init(drm, connector, _drm_connector_funcs,
DRM_MODE_CONNECTOR_VIRTUAL);
- if (ret < 0) {
- dev_err(drm->dev, "failed to initialize drm connector\n");
- return ret;
- }
-
- ret = drm_connector_attach_encoder(connector, encoder);
- if (ret < 0) {
- dev_err(drm->dev, "could not attach connector to encoder\n");
- return ret;
- }
-
- return 0;
}
#define ENCODE_PGU_XY(x, y)x) - 1) << 16) | ((y) - 1))
@@ -276,6 +255,7 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
{
struct platform_device *pdev = to_platform_device(arcpgu->drm.dev);
struct device_node *encoder_node = NULL, *endpoint_node = NULL;
+ struct drm_connector *connector = NULL;
struct drm_device *drm = >drm;
struct resource *res;
int ret;
@@ -310,13 +290,6 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
if (dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32)))
return -ENODEV;
- ret = drm_simple_display_pipe_init(drm, >pipe,
_pgu_pipe_funcs,
- arc_pgu_supported_formats,
-
ARRAY_SIZE(arc_pgu_supported_formats),
- NULL, NULL);
- if (ret)
- return ret;
-
/*
* There is only one output port inside each device. It is linked with
* encoder endpoint.
@@ -325,8 +298,21 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
if (endpoint_node) {
encoder_node = of_graph_get_remote_port_parent(endpoint_node);
of_node_put(endpoint_node);
+ } else {
+ connector = >sim_conn;
+ dev_info(drm->dev, "no encoder found. Assumed virtual LCD on
simulation platform\n");
+ ret = arcpgu_drm_sim_init(drm, connector);
+ if (ret < 0)
+ return ret;
}
+ ret = drm_simple_display_pipe_init(drm, >pipe,
_pgu_pipe_funcs,
+ arc_pgu_supported_formats,
+
ARRAY_SIZE(arc_pgu_supported_formats),
+ NULL, connector);
+ if (ret)
+ return ret;
+
if (encoder_node) {
struct drm_bridge *bridge;
@@ -338,11 +324,6 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
ret = drm_simple_display_pipe_attach_bridge(>pipe,
bridge);
if (ret)
return ret;
- } else {
- dev_info(drm->dev, "no encoder found. Assumed virtual LCD on
simulation platform\n");
- ret = arcpgu_drm_sim_init(drm, NULL);
- if (ret < 0)
- return ret;
}
drm_mode_config_reset(drm);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/18] drm/arc: Embedd a drm_connector for sim case
Removes the last devm_kzalloc, which means we're now prepared to use
drmm_mode_config_cleanup!
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 +
drivers/gpu/drm/arc/arcpgu_sim.c | 14 +-
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 52afd638a4d2..c52cdd2274e1 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -15,6 +15,7 @@ struct arcpgu_drm_private {
void __iomem*regs;
struct clk *clk;
struct drm_simple_display_pipe pipe;
+ struct drm_connectorsim_conn;
};
#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 134afb9fa625..e42fe5d05a3d 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -18,10 +18,6 @@
#define YRES_MAX 8192
-struct arcpgu_drm_connector {
- struct drm_connector connector;
-};
-
static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
{
int count;
@@ -57,7 +53,6 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
{
struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
- struct arcpgu_drm_connector *arcpgu_connector;
struct drm_encoder *encoder;
struct drm_connector *connector;
int ret;
@@ -72,14 +67,7 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
device_node *np)
if (ret)
return ret;
- arcpgu_connector = devm_kzalloc(drm->dev, sizeof(*arcpgu_connector),
- GFP_KERNEL);
- if (!arcpgu_connector) {
- ret = -ENOMEM;
- goto error_encoder_cleanup;
- }
-
- connector = _connector->connector;
+ connector = >sim_conn;
drm_connector_helper_add(connector, _drm_connector_helper_funcs);
ret = drm_connector_init(drm, connector, _drm_connector_funcs,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/18] drm/arc: Drop crtc check in arc_pgu_update
It's redundant, drm core guarantees that state->fb is set iff state->crtc is set. v2: I had a misconception about simple helpers here and thought they filter this out. They don't. Issue reported by Eugeniy. Cc: Eugeniy Paltsev Signed-off-by: Daniel Vetter Cc: Alexey Brodkin --- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c b/drivers/gpu/drm/arc/arcpgu_crtc.c index 5c6d7e34ca73..a72136ee4e46 100644 --- a/drivers/gpu/drm/arc/arcpgu_crtc.c +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c @@ -143,7 +143,7 @@ static void arc_pgu_update(struct drm_simple_display_pipe *pipe, struct arcpgu_drm_private *arcpgu; struct drm_gem_cma_object *gem; - if (!pipe->plane.state->crtc || !pipe->plane.state->fb) + if (!pipe->plane.state->fb) return; arcpgu = pipe_to_arcpgu_priv(pipe); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/18] drm/arc: Embedded a drm_simple_display_pipe
This is a prep step to convert arc over to the simple kms helpers, for
now we just use this as an embedding container to drop all the various
allocations. Big change is the removal of the various devm_kzalloc,
which have the wrong lifetimes anyway.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 7 ---
drivers/gpu/drm/arc/arcpgu_crtc.c | 9 +++--
drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
drivers/gpu/drm/arc/arcpgu_hdmi.c | 5 ++---
drivers/gpu/drm/arc/arcpgu_sim.c | 5 ++---
5 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index ed77dd5dd5cb..52afd638a4d2 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -8,17 +8,18 @@
#ifndef _ARCPGU_H_
#define _ARCPGU_H_
+#include
+
struct arcpgu_drm_private {
struct drm_device drm;
void __iomem*regs;
struct clk *clk;
- struct drm_crtc crtc;
- struct drm_plane*plane;
+ struct drm_simple_display_pipe pipe;
};
#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
-#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
+#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private,
pipe.crtc)
static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
unsigned int reg, u32 value)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ba796a216244..88ba2e284fc0 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -182,9 +182,7 @@ static struct drm_plane *arc_pgu_plane_init(struct
drm_device *drm)
struct drm_plane *plane = NULL;
int ret;
- plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
- if (!plane)
- return ERR_PTR(-ENOMEM);
+ plane = >pipe.plane;
ret = drm_universal_plane_init(drm, plane, 0xff, _pgu_plane_funcs,
arc_pgu_supported_formats,
@@ -195,7 +193,6 @@ static struct drm_plane *arc_pgu_plane_init(struct
drm_device *drm)
return ERR_PTR(ret);
drm_plane_helper_add(plane, _pgu_plane_helper_funcs);
- arcpgu->plane = plane;
return plane;
}
@@ -210,13 +207,13 @@ int arc_pgu_setup_crtc(struct drm_device *drm)
if (IS_ERR(primary))
return PTR_ERR(primary);
- ret = drm_crtc_init_with_planes(drm, >crtc, primary, NULL,
+ ret = drm_crtc_init_with_planes(drm, >pipe.crtc, primary, NULL,
_pgu_crtc_funcs, NULL);
if (ret) {
arc_pgu_plane_destroy(primary);
return ret;
}
- drm_crtc_helper_add(>crtc, _pgu_crtc_helper_funcs);
+ drm_crtc_helper_add(>pipe.crtc, _pgu_crtc_helper_funcs);
return 0;
}
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index c6a8deb56b0f..9020352816fa 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -120,7 +120,7 @@ static int arcpgu_show_pxlclock(struct seq_file *m, void
*arg)
struct drm_device *drm = node->minor->dev;
struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
unsigned long clkrate = clk_get_rate(arcpgu->clk);
- unsigned long mode_clock = arcpgu->crtc.mode.crtc_clock * 1000;
+ unsigned long mode_clock = arcpgu->pipe.crtc.mode.crtc_clock * 1000;
seq_printf(m, "hw : %lu\n", clkrate);
seq_printf(m, "mode: %lu\n", mode_clock);
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index 52839934f2fb..dbad2c9237fe 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -18,14 +18,13 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np)
{
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
struct drm_encoder *encoder;
struct drm_bridge *bridge;
int ret = 0;
- encoder = devm_kzalloc(drm->dev, sizeof(*encoder), GFP_KERNEL);
- if (encoder == NULL)
- return -ENOMEM;
+ encoder = >pipe.encoder;
/* Locate drm bridge from the hdmi encoder DT node */
bridge = of_drm_find_bridge(np);
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 37d961668dfe..134afb9fa625 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -56,14 +56,13 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
{
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
struct arcpgu_drm_connector *arcpgu_connector;
struct drm_encoder
[PATCH 11/18] drm/arc: Convert to drm_simple_kms_pipe_helper
Really straighforward, only slight issue is that the sim connector is
created after the pipe is set up, so can't use the helpers perfectly
yet. Subsequent patches will fix that.
Aside from lots of deleting code no functional changes in here.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 4 +-
drivers/gpu/drm/arc/arcpgu_crtc.c | 102 --
drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
drivers/gpu/drm/arc/arcpgu_hdmi.c | 18 +-
4 files changed, 31 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index c52cdd2274e1..b5c699d14f27 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -20,7 +20,7 @@ struct arcpgu_drm_private {
#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
-#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private,
pipe.crtc)
+#define pipe_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, pipe)
static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
unsigned int reg, u32 value)
@@ -34,7 +34,7 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private
*arcpgu,
return ioread32(arcpgu->regs + reg);
}
-int arc_pgu_setup_crtc(struct drm_device *dev);
+int arc_pgu_setup_pipe(struct drm_device *dev);
int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index c7769edeefdf..5c6d7e34ca73 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -25,10 +25,9 @@ static const u32 arc_pgu_supported_formats[] = {
DRM_FORMAT_ARGB,
};
-static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
+static void arc_pgu_set_pxl_fmt(struct arcpgu_drm_private *arcpgu)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
- const struct drm_framebuffer *fb = crtc->primary->state->fb;
+ const struct drm_framebuffer *fb = arcpgu->pipe.plane.state->fb;
uint32_t pixel_format = fb->format->format;
u32 format = DRM_FORMAT_INVALID;
int i;
@@ -59,10 +58,10 @@ static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
-static enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
- const struct
drm_display_mode *mode)
+static enum drm_mode_status arc_pgu_mode_valid(struct drm_simple_display_pipe
*pipe,
+ const struct drm_display_mode
*mode)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+ struct arcpgu_drm_private *arcpgu = pipe_to_arcpgu_priv(pipe);
long rate, clk_rate = mode->clock * 1000;
long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */
@@ -109,15 +108,16 @@ static void arc_pgu_mode_set(struct arcpgu_drm_private
*arcpgu)
arc_pgu_write(arcpgu, ARCPGU_REG_STRIDE, 0);
arc_pgu_write(arcpgu, ARCPGU_REG_START_SET, 1);
- arc_pgu_set_pxl_fmt(>pipe.crtc);
+ arc_pgu_set_pxl_fmt(arcpgu);
clk_set_rate(arcpgu->clk, m->crtc_clock * 1000);
}
-static void arc_pgu_crtc_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+static void arc_pgu_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+ struct arcpgu_drm_private *arcpgu = pipe_to_arcpgu_priv(pipe);
arc_pgu_mode_set(arcpgu);
@@ -127,10 +127,9 @@ static void arc_pgu_crtc_atomic_enable(struct drm_crtc
*crtc,
ARCPGU_CTRL_ENABLE_MASK);
}
-static void arc_pgu_crtc_atomic_disable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+static void arc_pgu_disable(struct drm_simple_display_pipe *pipe)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+ struct arcpgu_drm_private *arcpgu = pipe_to_arcpgu_priv(pipe);
clk_disable_unprepare(arcpgu->clk);
arc_pgu_write(arcpgu, ARCPGU_REG_CTRL,
@@ -138,80 +137,33 @@ static void arc_pgu_crtc_atomic_disable(struct drm_crtc
*crtc,
~ARCPGU_CTRL_ENABLE_MASK);
}
-static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
- .mode_valid = arc_pgu_crtc_mode_valid,
- .atomic_enable = arc_pgu_crtc_atomic_enable,
- .atomic_disable = arc_pgu_crtc_atomic_disable,
-};
-
-static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
- struct
Re: [PATCH 53/59] drm/arc: Move to drm/tiny
On Tue, Jun 09, 2020 at 03:02:14PM +0200, Daniel Vetter wrote: > Hi Eugeniy, > > Very much appreciated, and kinda expected. That 2nd backtrace really > confuses me, so "something strange is going on" and the bisect looks > funny is within expectations. Hopefully we can track down what's going > on. I'm going to resend the entire pile with the bugfix below and all rebased, I think retesting it all is probably a good idea now, since quite some time passed. Cheers, Daniel > > Thanks, Daniel > > On Tue, Jun 9, 2020 at 2:08 PM Eugeniy Paltsev > wrote: > > > > Hi Daniel, > > > > I've got pretty strange results so I need some time to investigate it and > > probably retest. > > I'll send you update in a few days. > > > > --- > > Eugeniy Paltsev > > > > > > > > From: Daniel Vetter > > Sent: Friday, June 5, 2020 22:55 > > To: Eugeniy Paltsev > > Cc: Intel Graphics Development; DRI Development; Daniel Vetter; Sam > > Ravnborg; Alexey Brodkin; snps-...@lists.infradead.org > > Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny > > > > Hi Eugeniy, > > > > Thanks for testing. I looked at the second one (I hoped it would just > > magically disappear) and I still don't understand what's going on > > there. My patch series isn't touching that area at all, so really > > confused. > > > > I squashed in the bugfix from the previous round into the right > > patches, and pushed a branch with just the arcpgu changes here: > > https://urldefense.com/v3/__https://cgit.freedesktop.org/*danvet/drm/log/?h=for-eugeniy__;fg!!A4F2R9G_pg!IJ1o4XiXVdStPu--Q-SCTUpRbsbqrjX255R34nuD7L7ptPywOy4SKr21dwSpfOkXIVqH5pM$ > > > > Maybe it's something in my pile of not-so-tested stuff :-) > > > > Can you pls test this? And if it still fails, try to bisect where it breaks? > > > > Thanks, Daniel > > > > On Thu, Jun 4, 2020 at 9:00 PM Eugeniy Paltsev > > wrote: > > > > > > I've tested your change and one issue gone. > > > > > > However I still see kernel crash (due to invalid read in kernel mode by > > > 0x0 address) on weston stop: > > > --->8--- > > > Oops > > > Path: (null) > > > CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted > > > 5.7.0-rc6-01594-g4ceda91a4176-dirty #6 > > > Workqueue: events drm_mode_rmfb_work_fn > > > Invalid Read @ 0x by insn @ drm_gem_fb_destroy+0x32/0x130 > > > ECR: 0x00050100 EFA: 0x ERET: 0x813b9a76 > > > STAT32: 0x80080602 [IE K ] BTA: 0x813b9a72 > > > BLK: drm_gem_fb_destroy+0xc0/0x130 > > > SP: 0x9f055ea4 FP: 0x > > > LPS: 0x813560ec LPE: 0x813560f0 LPC: 0x > > > r00: 0x r01: 0x9f6a6100 r02: 0x0001 > > > r03: 0x9fd5dde8 r04: 0x810f5de8 r05: 0x > > > r06: 0x r07: 0x r08: 0x00e1 > > > r09: 0x r10: 0x r11: 0x00e1 > > > r12: 0x813b9b04 > > > > > > Stack Trace: > > > drm_gem_fb_destroy+0x32/0x130 > > > drm_framebuffer_remove+0x1d2/0x358 > > > drm_mode_rmfb_work_fn+0x28/0x38 > > > process_one_work+0x19a/0x358 > > > worker_thread+0x2c4/0x494 > > > kthread+0xec/0x100 > > > ret_from_fork+0x18/0x1c > > > --->8--- > > > > > > > > > The stack traces may vary but always end in drm_gem_fb_destroy: > > > --->8--- > > > Stack Trace: > > > drm_gem_fb_destroy+0x32/0x130 > > > drm_mode_rmfb+0x10e/0x148 > > > drm_ioctl_kernel+0x70/0xa0 > > > drm_ioctl+0x284/0x410 > > > ksys_ioctl+0xea/0xa3c > > > EV_Trap+0xcc/0xd0 > > > --->8--- > > > Stack Trace: > > > drm_gem_fb_destroy+0x32/0x130 > > > drm_fb_release+0x66/0xb0 > > > drm_file_free.part.11+0x112/0x1bc > > > drm_release+0x80/0x120 > > > __fput+0x98/0x1bc > > > task_work_run+0x6e/0xa8 > > > do_exit+0x2b4/0x7fc > > > do_group_exit+0x2a/0x8c > > > get_signal+0x9a/0x5f0 > > > do_signal+0x86/0x23c > > > resume_user_mode_begin+0x88/0xd0 > > > --->8--- > > > > > > > > > --- > > > Eugeniy Paltsev > > > > > > > > > > > > From: Daniel Vetter > > > Sent: Thursday, June 4, 2020 14:19 > > > To: Eugeniy Paltsev > > > Cc: Intel Graphics Development; DRI Development; Daniel Vetter; Sam > > > Ravnborg; Alexey Brodkin > > > Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny > > > > > > Hi Eugeniy, > > > > > > Apologies, somehow I missed your mail. I looked at the code again, and I > > > think I fumbled something. Does the below diff help to prevent the issues? > > > > > > Thanks, Daniel > > > > > > > > > diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c > > > index 857812f25bec..33d812a5ad7f 100644 > > > --- a/drivers/gpu/drm/tiny/arcpgu.c > > > +++ b/drivers/gpu/drm/tiny/arcpgu.c > > > @@
Re: [PATCH v5 0/4] Add support for iMX8MQ Display Controller Subsystem
On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach wrote: > > Hi Laurentiu, > > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu: > > From: Laurentiu Palcu > > > > Hi, > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > includes only graphics plane support (no video planes), no HDR10 > > capabilities, > > no graphics decompression (only linear, tiled and super-tiled buffers > > allowed). > > > > Support for the rest of the features will be added incrementally, in > > subsequent > > patches. > > > > The patchset was tested with both HDP driver (in the downstream tree) and > > the upstream > > MIPI-DSI driver (with a couple of patches on top, to make it work correctly > > with DCSS). > > I think the series (minus 3/5 and minor correction to the DT binding) > is fine to go in now. So just some formal questions: are you going to > maintain this driver in upstream? If so we should add a MAINTAINERS > entry to that effect. I can offer to act as a reviewer in this case. > > How do you intend to merge this? IMO pushing this through drm-misc > seems like the right thing to do. If you agree I can help you get this > applied. If you are going to maintain the driver on your own, I think > you should then apply for commit rights to drm-misc. drm/imx isn't listed yet as under the drm-misc umbrella, maybe we should put the entire collective of imx drivers under drm-misc? Or maybe it's just an oversight that the git repo isn't specified in the MAINTAINERS entry. Also maybe we should add the pengutronix kernel team alias there too? -Daniel > Regards, > Lucas > > > Thanks, > > Laurentiu > > > > Changes in v5: > > * Rebased to latest; > > * Took out component framework support and made it a separate patch so > >that people can still test with HDP driver, which makes use of it. > >But the idea is to get rid of it once HDP driver's next versions > >will remove component framework as well; > > * Slight improvement to modesetting: avoid cutting off the pixel clock > >if the new mode and the old one are equal. Also, in this case, is > >not necessary to wait for DTG to shut off. This would allow to switch > >from 8b RGB to 12b YUV422, for example, with no interruptions (at least > >from DCSS point of view); > > * Do not fire off CTXLD when going to suspend, unless it still has > >entries that need to be committed to DCSS; > > * Addressed Rob's comments on bindings; > > > > Changes in v4: > > * Addressed Lucas and Philipp's comments: > >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; > >* Removed usage of devm_ functions since I'm already doing all the > > clean-up in the submodules_deinit(); > >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); > >* Removed en_completion variable from dcss_crtc since this was > > introduced mainly to avoid vblank timeout warnings which were fixed > > by arming the vblank event in flush() instead of begin(); > >* Removed clks_on and irq_enabled flags since all the calls to > > enabling/disabling clocks and interrupts were balanced; > >* Removed the custom atomic_commit callback and used the DRM core > > helper and, in the process, got rid of a workqueue that wasn't > > necessary anymore; > >* Fixed some minor DT binding issues flagged by Philipp; > >* Some other minor changes suggested by Lucas; > > * Removed YUV formats from the supported formats as these cannot work > >without the HDR10 module CSCs and LUTs. Will add them back when I > >will add support for video planes; > > > > Changes in v3: > > * rebased to latest linux-next and made it compile as drmP.h was > >removed; > > * removed the patch adding the VIDEO2_PLL clock. It's already applied; > > * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set(); > > * fixed a a spurious hang reported by Lukas Hartmann and encountered > >by me several times; > > * mask DPR and DTG interrupts by default, as they may come enabled from > >U-boot; > > > > Changes in v2: > > * Removed '0x' in node's unit-address both in DT and yaml; > > * Made the address region size lowercase, to be consistent; > > * Removed some left-over references to P010; > > * Added a Kconfig dependency of DRM && ARCH_MXC. This will also silence > > compilation > >issues reported by kbuild for other architectures; > > > > Laurentiu Palcu (5): > > drm/imx: compile imx directory by default > > drm/imx: Add initial support for DCSS on iMX8MQ > > drm/imx/dcss: add component framework functionality > > dt-bindings: display: imx: add bindings for DCSS > > arm64: dts: imx8mq: add DCSS node > > > > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 84 ++ > > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 + > > drivers/gpu/drm/Makefile | 2 +- > > drivers/gpu/drm/imx/Kconfig | 2 + > > drivers/gpu/drm/imx/Makefile
Re: [PATCH v5 0/4] Add support for iMX8MQ Display Controller Subsystem
Hi Laurentiu, Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu: > From: Laurentiu Palcu > > Hi, > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > includes only graphics plane support (no video planes), no HDR10 capabilities, > no graphics decompression (only linear, tiled and super-tiled buffers > allowed). > > Support for the rest of the features will be added incrementally, in > subsequent > patches. > > The patchset was tested with both HDP driver (in the downstream tree) and the > upstream > MIPI-DSI driver (with a couple of patches on top, to make it work correctly > with DCSS). I think the series (minus 3/5 and minor correction to the DT binding) is fine to go in now. So just some formal questions: are you going to maintain this driver in upstream? If so we should add a MAINTAINERS entry to that effect. I can offer to act as a reviewer in this case. How do you intend to merge this? IMO pushing this through drm-misc seems like the right thing to do. If you agree I can help you get this applied. If you are going to maintain the driver on your own, I think you should then apply for commit rights to drm-misc. Regards, Lucas > Thanks, > Laurentiu > > Changes in v5: > * Rebased to latest; > * Took out component framework support and made it a separate patch so >that people can still test with HDP driver, which makes use of it. >But the idea is to get rid of it once HDP driver's next versions >will remove component framework as well; > * Slight improvement to modesetting: avoid cutting off the pixel clock >if the new mode and the old one are equal. Also, in this case, is >not necessary to wait for DTG to shut off. This would allow to switch >from 8b RGB to 12b YUV422, for example, with no interruptions (at least >from DCSS point of view); > * Do not fire off CTXLD when going to suspend, unless it still has >entries that need to be committed to DCSS; > * Addressed Rob's comments on bindings; > > Changes in v4: > * Addressed Lucas and Philipp's comments: >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; >* Removed usage of devm_ functions since I'm already doing all the > clean-up in the submodules_deinit(); >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); >* Removed en_completion variable from dcss_crtc since this was > introduced mainly to avoid vblank timeout warnings which were fixed > by arming the vblank event in flush() instead of begin(); >* Removed clks_on and irq_enabled flags since all the calls to > enabling/disabling clocks and interrupts were balanced; >* Removed the custom atomic_commit callback and used the DRM core > helper and, in the process, got rid of a workqueue that wasn't > necessary anymore; >* Fixed some minor DT binding issues flagged by Philipp; >* Some other minor changes suggested by Lucas; > * Removed YUV formats from the supported formats as these cannot work >without the HDR10 module CSCs and LUTs. Will add them back when I >will add support for video planes; > > Changes in v3: > * rebased to latest linux-next and made it compile as drmP.h was >removed; > * removed the patch adding the VIDEO2_PLL clock. It's already applied; > * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set(); > * fixed a a spurious hang reported by Lukas Hartmann and encountered >by me several times; > * mask DPR and DTG interrupts by default, as they may come enabled from >U-boot; > > Changes in v2: > * Removed '0x' in node's unit-address both in DT and yaml; > * Made the address region size lowercase, to be consistent; > * Removed some left-over references to P010; > * Added a Kconfig dependency of DRM && ARCH_MXC. This will also silence > compilation >issues reported by kbuild for other architectures; > > Laurentiu Palcu (5): > drm/imx: compile imx directory by default > drm/imx: Add initial support for DCSS on iMX8MQ > drm/imx/dcss: add component framework functionality > dt-bindings: display: imx: add bindings for DCSS > arm64: dts: imx8mq: add DCSS node > > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 84 ++ > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 + > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/imx/Kconfig | 2 + > drivers/gpu/drm/imx/Makefile | 1 + > drivers/gpu/drm/imx/dcss/Kconfig | 9 + > drivers/gpu/drm/imx/dcss/Makefile | 6 + > drivers/gpu/drm/imx/dcss/dcss-blkctl.c| 70 ++ > drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 + > drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 + > drivers/gpu/drm/imx/dcss/dcss-dev.c | 314 +++ > drivers/gpu/drm/imx/dcss/dcss-dev.h | 177 > drivers/gpu/drm/imx/dcss/dcss-dpr.c | 562 > drivers/gpu/drm/imx/dcss/dcss-drv.c
Re: [PATCH -next] drm/komeda: Convert to DEFINE_SHOW_ATTRIBUTE
On Fri, Jul 17, 2020 at 09:06:57AM +0200, Daniel Vetter wrote:
> On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
> wrote:
> >
> > On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> > > From: Liu Shixin
> > >
> > > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> > >
> > > Signed-off-by: Liu Shixin
> > > ---
> > > drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 13 +
> > > 1 file changed, 1 insertion(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > > index 0246b2e94..4a10e6b9e 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > > @@ -41,18 +41,7 @@ static int komeda_register_show(struct seq_file *sf,
> > > void *x)
> > > return 0;
> > > }
> > >
> > > -static int komeda_register_open(struct inode *inode, struct file *filp)
> > > -{
> > > - return single_open(filp, komeda_register_show, inode->i_private);
> > > -}
> > > -
> > > -static const struct file_operations komeda_register_fops = {
> > > - .owner = THIS_MODULE,
> > > - .open = komeda_register_open,
> > > - .read_iter = seq_read_iter,
- .read = seq_read,
+ .read_iter = seq_read_iter,
> > > - .llseek = seq_lseek,
> > > - .release= single_release,
> > > -};
> > > +DEFINE_SHOW_ATTRIBUTE(komeda_register);
> > >
> >
> > Hi Shixin & Qinglang
> >
> > Thanks for your patch.
> >
> > Reviewed-by: James Qian Wang
> >
> > Since your patch is not for drm-misc-next, so seems better
> > to leave it to you to merge it. :)
>
> I do think it's for drm-misc-next, what other tree would it be for?
> Some people put -next in their patch tag to differentiate from -fixes,
> so maintainers know what to do with the patch. It's also not part of a
> series, hence I think this is on you to apply it.
>
> Cheers, Daniel
Hi Daniel:
I tried to apply this patch to drm-misc-next, but failed, and found
this patch is actually based on linux-next, and the code base of
linux-next is a little different with our drm-misc-next.
and one of the difference is linux-next has a patch (call it patch-A):
seq_file: switch over direct seq_read method calls to seq_read_iter
https://lkml.org/lkml/2020/7/7/1267
which changed code like below:
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 1d767473ba8a06..0246b2e94d8cbd 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -49,7 +49,7 @@ static int komeda_register_open(struct inode *inode, struct
file *filp)
static const struct file_operations komeda_register_fops = {
.owner = THIS_MODULE,
.open = komeda_register_open,
- .read = seq_read,
+ .read_iter = seq_read_iter,
.llseek = seq_lseek,
.release= single_release,
};
And these code will be deleted by this patch, if we merge this patch into
drm-misc-next firstly before the patch-A, that may import a conflict when
we merge our misc into upstreams.
if we want it to be merged into drm-misc, I think we'd better to wait the
upstream (the patch-A) has been synced back to drm-misc.
And what's your opinion ?
Thanks
James
> >
> > Thanks
> > James
> >
> > > #ifdef CONFIG_DEBUG_FS
> > > static void komeda_debugfs_init(struct komeda_dev *mdev)
> > > --
> > > 2.17.1
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 3/4] ARM: dts: omap4-droid4: add panel compatible
Add Droid 4 specific compatible value in addition to the
generic one, so that we have the ability to add panel
specific quirks in the future.
Reviewed-by: Laurent Pinchart
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/motorola-mapphone-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/motorola-mapphone-common.dtsi
b/arch/arm/boot/dts/motorola-mapphone-common.dtsi
index 4ffe461c3808..0e22fdfa42aa 100644
--- a/arch/arm/boot/dts/motorola-mapphone-common.dtsi
+++ b/arch/arm/boot/dts/motorola-mapphone-common.dtsi
@@ -208,7 +208,7 @@ dsi1_out_ep: endpoint {
};
lcd0: panel@0 {
- compatible = "panel-dsi-cm";
+ compatible = "motorola,droid4-panel", "panel-dsi-cm";
reg = <0>;
label = "lcd0";
vddi-supply = <_regulator>;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/panel-simple: Fix inverted V/H SYNC for Frida FRD350H54004 panel
The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC
signals, which sorts-of worked, but resulted in the picture fading out
under certain circumstances.
Fix this issue by marking VSYNC and HSYNC signals active-low.
v2: Rebase on drm-misc-next
Fixes: 7b6bd8433609 ("drm/panel: simple: Add support for the Frida FRD350H54004
panel")
Cc: sta...@vger.kernel.org # v5.5
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f42249b72548..8b0bab9dd075 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1763,7 +1763,7 @@ static const struct drm_display_mode
frida_frd350h54004_mode = {
.vsync_start = 240 + 2,
.vsync_end = 240 + 2 + 6,
.vtotal = 240 + 2 + 6 + 2,
- .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
static const struct panel_desc frida_frd350h54004 = {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] arm64: dts: sc7180: add interconnect bindings for display
From: Krishna Manikandan This change adds the interconnect bindings to the MDSS node. This will establish Display to DDR path for bus bandwidth voting. Changes in v2: - Change in commit message(Matthias Kaehlcke) Changes in v3: - Updated commit message to include reviewer's name in v2 Signed-off-by: Krishna Manikandan --- arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi index 998f101..4f2c0d1 100644 --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi @@ -1522,6 +1522,9 @@ interrupt-controller; #interrupt-cells = <1>; + interconnects = <_noc MASTER_MDP0 _virt SLAVE_EBI1>; + interconnect-names = "mdp0-mem"; + iommus = <_smmu 0x800 0x2>; #address-cells = <2>; -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 0/4] Subject: panel-dsi-cm: update bindings
The cleanup series for omapdrm's DSI code got too big. Reviewing
this is not fun and the same goes for keeping track of the change
requests. Let's do the cleanup in smaller steps instead. This is
the first batch, which updates the binding (txt -> yaml) and
modifies the DT slightly.
Changes since PATCHv1 [0]:
PATCHv1..PATCHv2:
* Update binding as suggested by Sam
* Remove 'port' from required list
* Drop 'lanes' and 'port' from example ('lanes' is a port property
used by OMAP's DSI controller)
* Drop the label from example
* Add '...' at end of file
* Fix , in patch description from patch 2
* Apply Reviewed-by tags
[0]
https://lore.kernel.org/dri-devel/20200629223315.118256-1-sebastian.reic...@collabora.com/
-- Sebastian
Sebastian Reichel (4):
dt-bindings: display: panel-dsi-cm: convert to YAML
ARM: dts: omap: add channel to DSI panels
ARM: dts: omap4-droid4: add panel compatible
ARM: dts: omap4-droid4: add panel orientation
.../bindings/display/panel/panel-dsi-cm.txt | 29 ---
.../bindings/display/panel/panel-dsi-cm.yaml | 86 +++
.../boot/dts/motorola-mapphone-common.dtsi| 6 +-
arch/arm/boot/dts/omap3-n950.dts | 3 +-
arch/arm/boot/dts/omap3.dtsi | 3 +
arch/arm/boot/dts/omap4-sdp.dts | 6 +-
arch/arm/boot/dts/omap4.dtsi | 6 ++
arch/arm/boot/dts/omap5.dtsi | 6 ++
8 files changed, 111 insertions(+), 34 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
