Re: [PATCH v7 0/9] backlight: gpio: simplify the driver
On Fri, 08 Nov 2019, Bartosz Golaszewski wrote:
> pon., 4 lis 2019 o 10:22 Bartosz Golaszewski napisał(a):
> >
> > pt., 1 lis 2019 o 16:39 Jacopo Mondi napisał(a):
> > >
> > > Hello,
> > > as promised...
> > >
> > > On Fri, Nov 01, 2019 at 08:58:03AM +, Lee Jones wrote:
> > > > On Thu, 24 Oct 2019, Jacopo Mondi wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > On Thu, Oct 24, 2019 at 07:47:26AM +0100, Lee Jones wrote:
> > > > > > On Wed, 23 Oct 2019, Daniel Thompson wrote:
> > > > > >
> > > > > > > On Tue, Oct 22, 2019 at 11:29:54AM +0200, Bartosz Golaszewski
> > > > > > > wrote:
> > > > > > > > wt., 22 paź 2019 o 10:36 Bartosz Golaszewski
> > > > > > > > napisał(a):
> > > > > > > > >
> > > > > > > > > From: Bartosz Golaszewski
> > > > > > > > >
> > > > > > > > > While working on my other series related to gpio-backlight[1]
> > > > > > > > > I noticed
> > > > > > > > > that we could simplify the driver if we made the only user of
> > > > > > > > > platform
> > > > > > > > > data use GPIO lookups and device properties. This series
> > > > > > > > > tries to do
> > > > > > > > > that.
> > > > > > > > >
> > > > > > > > > First two patches contain minor fixes. Third patch makes the
> > > > > > > > > driver
> > > > > > > > > explicitly drive the GPIO line. Fourth patch adds all
> > > > > > > > > necessary data
> > > > > > > > > structures to ecovec24. Patch 5/9 unifies much of the code
> > > > > > > > > for both
> > > > > > > > > pdata and non-pdata cases. Patches 6-7/9 remove unused
> > > > > > > > > platform data
> > > > > > > > > fields. Last two patches contain additional improvements for
> > > > > > > > > the GPIO
> > > > > > > > > backlight driver while we're already modifying it.
> > > > > > > > >
> > > > > > > > > I don't have access to this HW but hopefully this works. Only
> > > > > > > > > compile
> > > > > > > > > tested.
> > > > > > > > >
> > > > > > > > > [1] https://lkml.org/lkml/2019/6/25/900
> > > > > > > > >
> > > > > > > > > v1 -> v2:
> > > > > > > > > - rebased on top of v5.3-rc1 and adjusted to the recent
> > > > > > > > > changes from Andy
> > > > > > > > > - added additional two patches with minor improvements
> > > > > > > > >
> > > > > > > > > v2 -> v3:
> > > > > > > > > - in patch 7/7: used initializers to set values for pdata and
> > > > > > > > > dev local vars
> > > > > > > > >
> > > > > > > > > v3 -> v4:
> > > > > > > > > - rebased on top of v5.4-rc1
> > > > > > > > > - removed changes that are no longer relevant after commit
> > > > > > > > > ec665b756e6f
> > > > > > > > > ("backlight: gpio-backlight: Correct initial power state
> > > > > > > > > handling")
> > > > > > > > > - added patch 7/7
> > > > > > > > >
> > > > > > > > > v4 -> v5:
> > > > > > > > > - in patch 7/7: added a comment replacing the name of the
> > > > > > > > > function being
> > > > > > > > > pulled into probe()
> > > > > > > > >
> > > > > > > > > v5 -> v6:
> > > > > > > > > - added a patch making the driver explicitly set the
> > > > > > > > > direction of the GPIO
> > > > > > > > > to output
> > > > > > > > > - added a patch removing a redundant newline
> > > > > > > > >
> > > > > > > > > v6 -> v7:
> > > > > > > > > - renamed the function calculating the new GPIO value for
> > > > > > > > > status update
> > > > > > > > > - collected more tags
> > > > > > > > >
> > > > > > > > > Bartosz Golaszewski (9):
> > > > > > > > > backlight: gpio: remove unneeded include
> > > > > > > > > backlight: gpio: remove stray newline
> > > > > > > > > backlight: gpio: explicitly set the direction of the GPIO
> > > > > > > > > sh: ecovec24: add additional properties to the backlight
> > > > > > > > > device
> > > > > > > > > backlight: gpio: simplify the platform data handling
> > > > > > > > > sh: ecovec24: don't set unused fields in platform data
> > > > > > > > > backlight: gpio: remove unused fields from platform data
> > > > > > > > > backlight: gpio: use a helper variable for &pdev->dev
> > > > > > > > > backlight: gpio: pull gpio_backlight_initial_power_state()
> > > > > > > > > into probe
> > > > > > > > >
> > > > > > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 +++--
> > > > > > > > > drivers/video/backlight/gpio_backlight.c | 128
> > > > > > > > > +++
> > > > > > > > > include/linux/platform_data/gpio_backlight.h | 3 -
> > > > > > > > > 3 files changed, 69 insertions(+), 95 deletions(-)
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > Lee, Daniel, Jingoo,
> > > > > > > >
> > > > > > > > Jacopo is travelling until November 1st and won't be able to
> > > > > > > > test this
> > > > > > > > again before this date. Do you think you can pick it up and in
> > > > > > > > case
> > > > > > > > anything's broken on SH, we can fix it after v5.5-rc1, so that
> > > > > > > > it
> > > > > > > > doesn't miss another merge window?
> > > > > >
> > > > > > November 1st (-rc6) will be fine.
> > > > > >
> > > > > > I'd r
[Bug 205177] [amdgpu] driver crash - Vega10
https://bugzilla.kernel.org/show_bug.cgi?id=205177 Michael (lkb...@deegan.id.au) changed: What|Removed |Added CC||lkb...@deegan.id.au --- Comment #1 from Michael (lkb...@deegan.id.au) --- I believe I've just experienced the same crash, guessing from the extremely similar backtrace. Nov 11 14:42:18 joyola kernel: [19179.118055] general protection fault: [#1] SMP PTI Nov 11 14:42:18 joyola kernel: [19179.118059] CPU: 3 PID: 8126 Comm: chromium:cs0 Not tainted 5.3.0-2-amd64 #1 Debian 5.3.9-1 Nov 11 14:42:18 joyola kernel: [19179.118060] Hardware name: System manufacturer System Product Name/Z170M-PLUS, BIOS 3805 05/16/2018 Nov 11 14:42:18 joyola kernel: [19179.118065] RIP: 0010:ttm_bo_del_from_lru+0x17/0x120 [ttm] Nov 11 14:42:18 joyola kernel: [19179.118067] Code: 02 65 f3 eb d2 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 41 56 41 55 41 54 4c 8d a7 a8 00 00 00 55 48 89 fd 53 <48> 8b 87 c8 00 00 00 48 8d 9f c8 00 00 00 4c 8b 37 48 39 c 3 0f 84 Nov 11 14:42:18 joyola kernel: [19179.118068] RSP: 0018:bc4f42defac8 EFLAGS: 00010286 Nov 11 14:42:18 joyola kernel: [19179.118069] RAX: RBX: ffdf98732571c050 RCX: 98733af1b000 Nov 11 14:42:18 joyola kernel: [19179.118070] RDX: 0002 RSI: 98734b5275d8 RDI: ffdf98732571c050 Nov 11 14:42:18 joyola kernel: [19179.118071] RBP: ffdf98732571c050 R08: 98734f5c4298 R09: 98734f5c4298 Nov 11 14:42:18 joyola kernel: [19179.118071] R10: 0dc0 R11: R12: ffdf98732571c0f8 Nov 11 14:42:18 joyola kernel: [19179.118072] R13: 98734b527040 R14: 98734b527000 R15: c094cf90 Nov 11 14:42:18 joyola kernel: [19179.118073] FS: 7f7fed5ac700() GS:987356b8() knlGS: Nov 11 14:42:18 joyola kernel: [19179.118074] CS: 0010 DS: ES: CR0: 80050033 Nov 11 14:42:18 joyola kernel: [19179.118075] CR2: 18b8987eb800 CR3: 0007d1228001 CR4: 003606e0 Nov 11 14:42:18 joyola kernel: [19179.118076] DR0: DR1: DR2: Nov 11 14:42:18 joyola kernel: [19179.118077] DR3: DR6: fffe0ff0 DR7: 0400 Nov 11 14:42:18 joyola kernel: [19179.118077] Call Trace: Nov 11 14:42:18 joyola kernel: [19179.118082] ttm_bo_move_to_lru_tail+0x12/0xb0 [ttm] Nov 11 14:42:18 joyola kernel: [19179.118123] amdgpu_vm_move_to_lru_tail+0xa4/0xd0 [amdgpu] Nov 11 14:42:18 joyola kernel: [19179.118159] amdgpu_cs_ioctl+0x165f/0x1ba0 [amdgpu] Nov 11 14:42:18 joyola kernel: [19179.118162] ? __switch_to_asm+0x34/0x70 Nov 11 14:42:18 joyola kernel: [19179.118191] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] Nov 11 14:42:18 joyola kernel: [19179.118199] drm_ioctl_kernel+0xaa/0xf0 [drm] Nov 11 14:42:18 joyola kernel: [19179.118206] drm_ioctl+0x208/0x390 [drm] Nov 11 14:42:18 joyola kernel: [19179.118234] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] Nov 11 14:42:18 joyola kernel: [19179.118260] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Nov 11 14:42:18 joyola kernel: [19179.118263] do_vfs_ioctl+0x40e/0x670 Nov 11 14:42:18 joyola kernel: [19179.118265] ksys_ioctl+0x5e/0x90 Nov 11 14:42:18 joyola kernel: [19179.118267] __x64_sys_ioctl+0x16/0x20 Nov 11 14:42:18 joyola kernel: [19179.118269] do_syscall_64+0x53/0x140 Nov 11 14:42:18 joyola kernel: [19179.118271] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Nov 11 14:42:18 joyola kernel: [19179.118273] RIP: 0033:0x7f7ff53b85b7 Nov 11 14:42:18 joyola kernel: [19179.118274] Code: 00 00 90 48 8b 05 d9 78 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 78 0c 00 f7 d8 64 89 01 48 Nov 11 14:42:18 joyola kernel: [19179.118275] RSP: 002b:7f7fed5ab438 EFLAGS: 0246 ORIG_RAX: 0010 Nov 11 14:42:18 joyola kernel: [19179.118276] RAX: ffda RBX: 7f7fed5ab558 RCX: 7f7ff53b85b7 Nov 11 14:42:18 joyola kernel: [19179.118277] RDX: 7f7fed5ab4a0 RSI: c0186444 RDI: 00b7 Nov 11 14:42:18 joyola kernel: [19179.118278] RBP: 7f7fed5ab4a0 R08: 7f7fed5ab5b0 R09: 0020 Nov 11 14:42:18 joyola kernel: [19179.118278] R10: 7f7fed5ab5b0 R11: 0246 R12: c0186444 Nov 11 14:42:18 joyola kernel: [19179.118279] R13: 00b7 R14: 558005d382fc R15: 558005d341f0 Nov 11 14:42:18 joyola kernel: [19179.118280] Modules linked in: md4 sha512_ssse3 sha512_generic cmac nls_utf8 cifs gcm libarc4 nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache nf_tables nfnetlink psnap cfg80211 8021q garp stp mrp llc binfmt_misc joydev snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device mc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm irqbypass amdgpu crct10dif_pclmul c
RE: [PATCH 0/2] remove some set but not used variables in hwmgr
Series is reviewed-by: Evan Quan > -Original Message- > From: zhengbin > Sent: Monday, November 11, 2019 11:46 AM > To: rex@amd.com; Quan, Evan ; Deucher, > Alexander ; Koenig, Christian > ; Zhou, David(ChunMing) > ; airl...@linux.ie; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Cc: zhengbi...@huawei.com > Subject: [PATCH 0/2] remove some set but not used variables in hwmgr > > zhengbin (2): > drm/amd/powerplay: remove set but not used variable > 'vbios_version','data' > drm/amd/powerplay: remove set but not used variable 'data' > > drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 > drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 -- > 2 files changed, 6 deletions(-) > > -- > 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #228 from Shmerl --- (In reply to John H from comment #227) > > specific one I can reproduce EVERY. SINGLE. TIME. was when playing Unreal > Tournament 3 via Steam proton. The "Shangri La" map i encountered lockups > anywhere from a few seconds to a few minutes into the game. Forcing me to > hit the reset button. This could be a llvm / Mesa bug, not the kernel one. If you can reproduce it, please report it for that game individually to the Mesa bug tracker, with an apitrace. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #227 from John H --- Hi all. For the last couple weeks I have been following this thread and just wanted to reprot my experiences findings. First off, my machine's specs: AMD Ryzen 3700X Aorus X570 Pro Wifi motherboard 32 GB (16x2) DDR4 3200 RAM PowerColor Red Devil 5700XT Graphics Various SSD / HDD all on SATA. Windows 10 / Debian Sid Debian Sid: Kernel 5.3.10, Mesa 19.2.3, LLVM 9 as of writing this. In the whole time I have had this graphics card (October 21 onwards) I dont think I have had any crashes / freezes on the desktop or during browsing through Chromium. However, I have hard freezes when playing games. A specific one I can reproduce EVERY. SINGLE. TIME. was when playing Unreal Tournament 3 via Steam proton. The "Shangri La" map i encountered lockups anywhere from a few seconds to a few minutes into the game. Forcing me to hit the reset button. I was able to SSH in via my phone before resetting and looking at dmesg said something about amdgpu GPU recovery failed. My 5700XT, has a dual BIOS's. One overclocked, the other for "silent". By default the switch was in the OC position, earlier today I flipped it to silent. and since then, NO freezes in UT whatsoever! I figured the factory overclock PowerColor implemented on this card was just a touch too high and is therefore unstable. Forza 6 Apex in Windows 10 also hard freezes my PC, forcing me to reset. That problem also has been eliminated since flipping the switch. A slight performance loss but I'll take the stability anyday. TL;DR - If your Navi card has dual BIOS, try switching to the lower clocked BIOS if you haven't already. it may just help. Certainly, I'll report back if I find any other issues in Debian that is linked to this gfx card -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: use DRM_DEV_ERROR for log output
On Fri, 8 Nov 2019, Sean Paul wrote:
On Fri, Nov 08, 2019 at 03:06:44PM +0100, Heiko Stübner wrote:
Hi,
[it seems your Reply-To mail header is set strangely as
Reply-To: 20191107133851.GF63329@art_vandelay
which confuses my MTA]
Am Freitag, 8. November 2019, 13:46:30 CET schrieb Wambui Karuga:
On Thu, Nov 07, 2019 at 08:38:51AM -0500, Sean Paul wrote:
On Thu, Nov 07, 2019 at 01:54:22AM -0800, Joe Perches wrote:
On Thu, 2019-11-07 at 12:29 +0300, Wambui Karuga wrote:
Replace the use of the dev_err macro with the DRM_DEV_ERROR
DRM helper macro.
The commit message should show the reason _why_ you are doing
this instead of just stating that you are doing this.
It's not that dev_err is uncommon in drivers/gpu/drm.
It is uncommon (this is the sole instance) in rockchip, however. So it makes
sense to convert the dev_* prints in rockchip to DRM_DEV for consistency.
Wambui, could you also please convert the dev_warn instance as well?
Hey, Sean.
Trying to convert this dev_warn instance, but the corresponding DRM_WARN
macro does not take the dev parameter which seems to be useful in the
original output.
Should I still convert it to DRM_WARN without the hdmi->dev parameter?
There exists DRM_DEV_ERROR, DRM_DEV_INFO and DRM_DEV_DEBUG to
handle actual devices. Interestingly there is no DRM_DEV_WARN though.
So depending on what Sean suggest another option would be to add the
missing DRM_DEV_WARN and then use it to replace the dev_warn.
Yep, this sounds good to me me.
Sean
Okay, I can add DRM_DEV_WARN and replace it there.
wambui
Heiko
Thanks,
wambui
I'll apply this to drm-misc-next and expand on the commit message a bit.
Thanks,
Sean
$ git grep -w dev_err drivers/gpu/drm | wc -l
1950
$ git grep -w DRM_DEV_ERROR drivers/gpu/drm | wc -l
756
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
[]
@@ -916,7 +916,7 @@ static int dw_mipi_dsi_rockchip_probe(struct
platform_device *pdev)
}
if (!dsi->cdata) {
- dev_err(dev, "no dsi-config for %s node\n", np->name);
+ DRM_DEV_ERROR(dev, "no dsi-config for %s node\n", np->name);
return -EINVAL;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
On Sun, Nov 10, 2019 at 6:53 AM Brian Masney wrote:
>
> On Fri, Nov 08, 2019 at 07:56:25AM -0700, Jeffrey Hugo wrote:
> > On Thu, Nov 7, 2019 at 7:03 PM Rob Clark wrote:
> > >
> > > On Thu, Nov 7, 2019 at 9:40 AM Jeffrey Hugo
> > > wrote:
> > > >
> > > > On Thu, Nov 7, 2019 at 9:17 AM Rob Clark wrote:
> > > > >
> > > > > On Thu, Nov 7, 2019 at 3:10 AM Brian Masney
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Nov 06, 2019 at 08:58:59AM -0800, Rob Clark wrote:
> > > > > > > On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Wed, Nov 6, 2019 at 9:30 AM Rob Clark
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > > > > > > > > > > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney
> > > > > > > > > > > wrote:
> > > > > > > > > > > > The 'pp done time out' errors go away if I revert the
> > > > > > > > > > > > following three
> > > > > > > > > > > > commits:
> > > > > > > > > > > >
> > > > > > > > > > > > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > > > > > > > > > > > d934a712c5e6 ("drm/msm: add atomic traces")
> > > > > > > > > > > > 2d99ced787e3 ("drm/msm: async commit support")
> > > > > > > > > > > >
> > > > > > > > > > > > I reverted the first one to fix a compiler error, and
> > > > > > > > > > > > the second one so
> > > > > > > > > > > > that the last patch can be reverted without any merge
> > > > > > > > > > > > conflicts.
> > > > > > > > > > > >
> > > > > > > > > > > > I see that crtc_flush() calls mdp5_ctl_commit(). I
> > > > > > > > > > > > tried to use
> > > > > > > > > > > > crtc_flush_all() in mdp5_flush_commit() and the
> > > > > > > > > > > > contents of the frame
> > > > > > > > > > > > buffer dance around the screen like its out of sync. I
> > > > > > > > > > > > renamed
> > > > > > > > > > > > crtc_flush_all() to mdp5_crtc_flush_all() and removed
> > > > > > > > > > > > the static
> > > > > > > > > > > > declaration. Here's the relevant part of what I tried:
> > > > > > > > > > > >
> > > > > > > > > > > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > > > > > > > > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > > > > > > > > > @@ -171,7 +171,15 @@ static void
> > > > > > > > > > > > mdp5_prepare_commit(struct msm_kms *kms, struct
> > > > > > > > > > > > drm_atomic_state *st
> > > > > > > > > > > >
> > > > > > > > > > > > static void mdp5_flush_commit(struct msm_kms *kms,
> > > > > > > > > > > > unsigned crtc_mask)
> > > > > > > > > > > > {
> > > > > > > > > > > > - /* TODO */
> > > > > > > > > > > > + struct mdp5_kms *mdp5_kms =
> > > > > > > > > > > > to_mdp5_kms(to_mdp_kms(kms));
> > > > > > > > > > > > + struct drm_crtc *crtc;
> > > > > > > > > > > > +
> > > > > > > > > > > > + for_each_crtc_mask(mdp5_kms->dev, crtc,
> > > > > > > > > > > > crtc_mask) {
> > > > > > > > > > > > + if (!crtc->state->active)
> > > > > > > > > > > > + continue;
> > > > > > > > > > > > +
> > > > > > > > > > > > + mdp5_crtc_flush_all(crtc);
> > > > > > > > > > > > + }
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > Any tips would be appreciated.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I think this is along the lines of what we need to enable
> > > > > > > > > > > async commit
> > > > > > > > > > > for mdp5 (but also removing the flush from the
> > > > > > > > > > > atomic-commit path)..
> > > > > > > > > > > the principle behind the async commit is to do all the
> > > > > > > > > > > atomic state
> > > > > > > > > > > commit normally, but defer writing the flush bits. This
> > > > > > > > > > > way, if you
> > > > > > > > > > > get another async update before the next vblank, you just
> > > > > > > > > > > apply it
> > > > > > > > > > > immediately instead of waiting for vblank.
> > > > > > > > > > >
> > > > > > > > > > > But I guess you are on a command mode panel, if I
> > > > > > > > > > > remember? Which is
> > > > > > > > > > > a case I didn't have a way to test. And I'm not entirely
> > > > > > > > > > > about how
> > > > > > > > > > > kms_funcs->vsync_time() should be implemented for cmd
> > > > > > > > > > > mode panels.
> > > > > > > > > >
> > > > > > > > > > Yes, this is a command-mode panel and there's no hardware
> > > > > > > > > > frame counter
> > > > > > > > > > available. The key to getting the display working on this
> > > > > > > > > > phone was this
> > > > > > > > > > patch:
> > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> > > > > > > > > >
> > > > > > > > > > > That all said, I think we should first fix what is
> > > > > > > > > > > broken, before
> > > > > > > > > > > worryin
Re: Overlay support in the i.MX7 display
Le lundi 04 novembre 2019 à 14:58 +0200, Laurent Pinchart a écrit : > Hello, > > On Mon, Nov 04, 2019 at 10:09:47AM +0200, Pekka Paalanen wrote: > > On Sun, 03 Nov 2019 19:15:49 +0100 Stefan Agner wrote: > > > On 2019-11-01 09:43, Laurent Pinchart wrote: > > > > Hello, > > > > > > > > I'm looking at the available options to support overlays in the display > > > > pipeline of the i.MX7. The LCDIF itself unfortunaltey doesn't support > > > > overlays, the feature being implemented in the PXP. A driver for the PXP > > > > is available but only supports older SoCs whose PXP doesn't support > > > > overlays. This driver is implemented as a V4L2 mem2mem driver, which > > > > makes support of additional input channels impossible. > > > > > > Thanks for bringing this up, it is a topic I have wondered too: > > > Interaction between PXP and mxsfb. > > > > > > I am not very familiar with the V4L2 subsystem so take my opinions with > > > a grain of salt. > > > > > > > Here are the options I can envision: > > > > > > > > - Extend the existing PXP driver to support multiple channels. This is > > > > technically feasible, but will require moving away from the V4L2 > > > > mem2mem framework, which would break userspace. I don't think this > > > > path could lead anywhere. > > > > > > > > - Write a new PXP driver for the i.MX7, still using V4L2, but with > > > > multiple video nodes. This would allow blending multiple layers, but > > > > would require writing the output to memory, while the PXP has support > > > > for direct connections to the LCDIF (through small SRAM buffers). > > > > Performances would thus be suboptimal. The API would also be awkward, > > > > as using the PXP for display would require usage of V4L2 in > > > > applications. > > > > > > So the video nodes would be sinks? I would expect overlays to be usable > > > through KMS, I guess that would then not work, correct? > > There would be sink video nodes for the PXP inputs, and one source video > node for the PXP output. The PXP can be used stand-alone, in > memory-to-memory mode, and V4L2 is a good fit for that. > > > > > - Extend the mxsfb driver with PXP support, and expose the PXP inputs as > > > > KMS planes. The PXP would only be used when available, and would be > > > > transparent to applications. This would however prevent using it > > > > separately from the display (to perform multi-pass alpha blending for > > > > instance). > > > > > > KMS planes are well defined and are well integrated with the KMS API, so > > > I prefer this option. But is this compatible with the currently > > > supported video use-case? E.g. could we make PXP available through V4L2 > > > and through DRM/mxsfb? > > That's the issue, it's not easily doable. I think we could do so, but > how to ensure mutual exclusion between the two APIs needs to be > researched. I fear it will result in an awkward solution with fuzzy > semantics. A module parameter could be an option, but wouldn't be very > flexible. > > > > Not sure what your use case is exactly, but when playing a video I > > > wonder where is the higher value using PXP: Color conversion and scaling > > > or compositing...? I would expect higher value in the former use case. > > I think it's highly use-case-dependent. > > > mind, with Wayland architecture, color conversion and scaling could be > > at the same level/step as compositing, in the display server instead of > > an application. Hence if the PXP capabilities were advertised as KMS > > planes, there should be nothing to patch in Wayland-designed > > applications to make use of them, assuming the applications did not > > already rely on V4L2 M2M devices. > > > > Would it not be possible to expose PXP through both uAPI interfaces? At > > least KMS atomic's TEST_ONLY feature would make it easy to say "no" to > > userspace if another bit of userspace already reserved the device via > > e.g. V4L2. > > We would also need to figure out how to do it the other way around, > reporting properly through V4L2 that the device is busy. I think it's > feasible, but I doubt it would result in anything usable for userspace. We already have this needs for decoders with fixed number of streams. > If the KMS device exposes multiple planes unconditionally and fails the > atomic commit if the PXP is used through V4L2, I think it would be hard > for Wayland to use this consistently. Given that I expect the PXP to be > mostly used for display purpose I'm tempted to allocate it for display > unconditionally, or, possibly, decide how to expose it through a module > parameter. It's a strange statement "mostly used for display purpose", considering the upstream driver exist for video scaling and color conversion, and no one have yet implement the "display purpose" driver. My impression is that the complication is kernel specific (the fact we very have two subsystems for the same IPs). Since software wise, sharing and allocating resources se
Re: [PATCH v3 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Hi Pi-Hsun Shih, I'll fix the issue on version v4.
Thanks,
Xin
On Fri, Nov 08, 2019 at 02:50:36PM +0800, Pi-Hsun Shih wrote:
> Hi,
>
> On Tue, Oct 15, 2019 at 5:52 PM Xin Ji wrote:
> >
> > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> > for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
> >
> > The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
> > to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
> >
> > Signed-off-by: Xin Ji
> > ---
> > drivers/gpu/drm/bridge/Makefile |2 +-
> > drivers/gpu/drm/bridge/analogix/Kconfig |6 +
> > drivers/gpu/drm/bridge/analogix/Makefile |1 +
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 2043
> > +
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 406 ++
> > 5 files changed, 2457 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
> > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
> >
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf..bcd388a 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
> > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> > -obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> > +obj-y += analogix/
> > obj-y += synopsys/
> > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> > b/drivers/gpu/drm/bridge/analogix/Kconfig
> > index e930ff9..b2f127e 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -2,3 +2,9 @@
> > config DRM_ANALOGIX_DP
> > tristate
> > depends on DRM
> > +
> > +config ANALOGIX_ANX7625
> > + tristate "Analogix MIPI to DP interface support"
> > + help
> > + ANX7625 is an ultra-low power 4K mobile HD transmitter
> > designed
> > + for portable devices. It converts MIPI/DPI to
> > DisplayPort1.3 4K.
> > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> > b/drivers/gpu/drm/bridge/analogix/Makefile
> > index fdbf3fd..8a52867 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Makefile
> > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > @@ -1,3 +1,4 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > +obj-$(CONFIG_ANALOGIX_ANX7625) += anx7625.o
> > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > new file mode 100644
> > index 000..456b95c
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -0,0 +1,2043 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
> > + *
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "anx7625.h"
> > +
> > +/*
> > + * there is a sync issue while access I2C register between AP(CPU) and
> > + * internal firmware(OCM), to avoid the race condition, AP should access
> > + * the reserved slave address before slave address occurs changes.
> > + */
> > +static int i2c_access_workaround(struct anx7625_data *ctx,
> > +struct i2c_client *client)
> > +{
> > + u8 offset;
> > + struct device *dev = &client->dev;
> > + int ret;
> > +
> > + if (client == ctx->last_client)
> > + return 0;
> > +
> > + ctx->last_client = client;
> > +
> > + if (client == ctx->i2c.tcpc_client)
> > + offset = RSVD_00_ADDR;
> > + else if (client == ctx->i2c.tx_p0_client)
> > + offset = RSVD_D1_ADDR;
> > + else if (client == ctx->i2c.tx_p1_client)
> > + offset = RSVD_60_ADDR;
> > + else if (client == ctx->i2c.rx_p0_client)
> > + offset = RSVD_39_ADDR;
> > + else if (client == ctx->i2c.rx_p1_client)
> > + offset = RSVD_7F_ADDR;
> > + else
> > + offset = RSVD_00_ADDR;
> > +
> > + ret = i2c_smbus_write_byte_data(client, offset, 0x00);
> > + if (ret < 0)
> > + DRM_DEV_ERROR(dev,
> > + "failed to access i2c id=%x\n:%x",
> > +
Re: [Freedreno] [PATCH] drm/msm/dsi: Delay drm_panel_enable() until dsi_mgr_bridge_enable()
On Fri, Nov 8, 2019 at 4:47 PM Stephan Gerhold wrote: > > On Fri, Nov 08, 2019 at 03:12:28PM -0700, Jeffrey Hugo wrote: > > On Fri, Nov 8, 2019 at 2:29 PM Stephan Gerhold wrote: > > > > > > At the moment, the MSM DSI driver calls drm_panel_enable() rather early > > > from the DSI bridge pre_enable() function. At this point, the encoder > > > (e.g. MDP5) is not enabled, so we have not started transmitting > > > video data. > > > > > > However, the drm_panel_funcs documentation states that enable() > > > should be called on the panel *after* video data is being transmitted: > > > > > > The .prepare() function is typically called before the display > > > controller > > > starts to transmit video data. [...] After the display controller has > > > started transmitting video data, it's safe to call the .enable() > > > function. > > > This will typically enable the backlight to make the image on screen > > > visible. > > > > > > Calling drm_panel_enable() too early causes problems for some panels: > > > The TFT LCD panel used in the Samsung Galaxy Tab A 9.7 (2015) (APQ8016) > > > uses the MIPI_DCS_SET_DISPLAY_BRIGHTNESS command to control > > > backlight/brightness of the screen. The enable sequence is therefore: > > > > > > drm_panel_enable() > > > drm_panel_funcs.enable(): > > > backlight_enable() > > > backlight_ops.update_status(): > > > mipi_dsi_dcs_set_display_brightness(dsi, bl->props.brightness); > > > > > > The panel seems to silently ignore the MIPI_DCS_SET_DISPLAY_BRIGHTNESS > > > command if it is sent too early. This prevents setting the initial > > > brightness, > > > causing the display to be enabled with minimum brightness instead. > > > Adding various delays in the panel initialization code does not result > > > in any difference. > > > > > > On the other hand, moving drm_panel_enable() to dsi_mgr_bridge_enable() > > > fixes the problem, indicating that the panel requires the video stream > > > to be active before the brightness command is accepted. > > > > > > Therefore: Move drm_panel_enable() to dsi_mgr_bridge_enable() to > > > delay calling it until video data is being transmitted. > > > > > > Move drm_panel_disable() to dsi_mgr_bridge_disable() for similar reasons. > > > (This is not strictly required for the panel affected above...) > > > > > > Tested-by: Jasper Korten > > > Signed-off-by: Stephan Gerhold > > > --- > > > Since this is a core change I thought it would be better to send this > > > early. I believe Jasper still wants to finish some other changes before > > > submitting the initial device tree for the Samsung Galaxy Tab A 9.7 > > > (2015). ;) > > > > > > I also tested it on msm8916-samsung-a5u-eur, its display is working fine > > > with or without this patch. > > > > Nack, please. I was curious so I threw this on the Lenovo Miix 630 > > laptop. I don't get a display back with this patch. I'll try to > > figure out why, but currently I can't get into the machine. > > Thanks for testing the patch! Let's try to figure that out... > > I'm a bit confused, but this might be because I'm not very familiar with > the MSM8998 laptops. It does not seem to have display in mainline yet, > so do you have a link to all the patches you are using at the moment? The mdp5 support is there. Some of the dependencies have dragged out. I'd have to make sense of my development tree as to what is relevant. > > Judging from the patches I was able to find, the Lenovo Miix 630 is > using a DSI to eDP bridge. > Isn't the panel managed by the bridge driver in that case? It uses the TI SN65 bridge. > > struct msm_dsi contains: > /* > * panel/external_bridge connected to dsi bridge output, only one of > the > * two can be valid at a time > */ > struct drm_panel *panel; > struct drm_bridge *external_bridge; > > So if you have "external_bridge" set in your case, "panel" should be NULL. > I have only moved code that uses msm_dsi->panel, so my patch really > shouldn't make any difference for you. > > Am I confusing something here? I don't think panel is null in my case. I need to trace a few things through to be sure. Taking a quick look at the datasheet for the bridge, I suspect that operations are occurring in the enable() phase of the bridge, that need to occur before video data is transmitted. Based on your analysis in the commit message, I suspect these operations need to be moved to pre_enable(). I'm hoping to gather more data this weekend, which will hopefully identify what we need to do to move this forward without causing regressions. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm/msm/dsi: Delay drm_panel_enable() until dsi_mgr_bridge_enable()
On Sat, Nov 9, 2019 at 5:02 AM Stephan Gerhold wrote: > > On Fri, Nov 08, 2019 at 08:47:08PM -0700, Jeffrey Hugo wrote: > > On Fri, Nov 8, 2019 at 4:47 PM Stephan Gerhold wrote: > > > > > > On Fri, Nov 08, 2019 at 03:12:28PM -0700, Jeffrey Hugo wrote: > > > > On Fri, Nov 8, 2019 at 2:29 PM Stephan Gerhold > > > > wrote: > > > > > > > > > > At the moment, the MSM DSI driver calls drm_panel_enable() rather > > > > > early > > > > > from the DSI bridge pre_enable() function. At this point, the encoder > > > > > (e.g. MDP5) is not enabled, so we have not started transmitting > > > > > video data. > > > > > > > > > > However, the drm_panel_funcs documentation states that enable() > > > > > should be called on the panel *after* video data is being transmitted: > > > > > > > > > > The .prepare() function is typically called before the display > > > > > controller > > > > > starts to transmit video data. [...] After the display controller > > > > > has > > > > > started transmitting video data, it's safe to call the .enable() > > > > > function. > > > > > This will typically enable the backlight to make the image on > > > > > screen visible. > > > > > > > > > > Calling drm_panel_enable() too early causes problems for some panels: > > > > > The TFT LCD panel used in the Samsung Galaxy Tab A 9.7 (2015) > > > > > (APQ8016) > > > > > uses the MIPI_DCS_SET_DISPLAY_BRIGHTNESS command to control > > > > > backlight/brightness of the screen. The enable sequence is therefore: > > > > > > > > > > drm_panel_enable() > > > > > drm_panel_funcs.enable(): > > > > > backlight_enable() > > > > > backlight_ops.update_status(): > > > > > mipi_dsi_dcs_set_display_brightness(dsi, > > > > > bl->props.brightness); > > > > > > > > > > The panel seems to silently ignore the MIPI_DCS_SET_DISPLAY_BRIGHTNESS > > > > > command if it is sent too early. This prevents setting the initial > > > > > brightness, > > > > > causing the display to be enabled with minimum brightness instead. > > > > > Adding various delays in the panel initialization code does not result > > > > > in any difference. > > > > > > > > > > On the other hand, moving drm_panel_enable() to > > > > > dsi_mgr_bridge_enable() > > > > > fixes the problem, indicating that the panel requires the video stream > > > > > to be active before the brightness command is accepted. > > > > > > > > > > Therefore: Move drm_panel_enable() to dsi_mgr_bridge_enable() to > > > > > delay calling it until video data is being transmitted. > > > > > > > > > > Move drm_panel_disable() to dsi_mgr_bridge_disable() for similar > > > > > reasons. > > > > > (This is not strictly required for the panel affected above...) > > > > > > > > > > Tested-by: Jasper Korten > > > > > Signed-off-by: Stephan Gerhold > > > > > --- > > > > > Since this is a core change I thought it would be better to send this > > > > > early. I believe Jasper still wants to finish some other changes > > > > > before > > > > > submitting the initial device tree for the Samsung Galaxy Tab A 9.7 > > > > > (2015). ;) > > > > > > > > > > I also tested it on msm8916-samsung-a5u-eur, its display is working > > > > > fine > > > > > with or without this patch. > > > > > > > > Nack, please. I was curious so I threw this on the Lenovo Miix 630 > > > > laptop. I don't get a display back with this patch. I'll try to > > > > figure out why, but currently I can't get into the machine. > > > > > > Thanks for testing the patch! Let's try to figure that out... > > > > > > I'm a bit confused, but this might be because I'm not very familiar with > > > the MSM8998 laptops. It does not seem to have display in mainline yet, > > > so do you have a link to all the patches you are using at the moment? > > > > The mdp5 support is there. Some of the dependencies have dragged out. > > I'd have to make sense of my development tree as to what is relevant. > > A dump of all the patches (whether still relevant or not) would be > helpful too. Actually I was mostly looking for the device tree part to > see which components are involved. DSI0 to "ti,sn65dsi86" (bridge) to "sharp,ld-d5116z01b" (panel). > > > > > > > Judging from the patches I was able to find, the Lenovo Miix 630 is > > > using a DSI to eDP bridge. > > > Isn't the panel managed by the bridge driver in that case? > > > > It uses the TI SN65 bridge. > > > > It is covered by the ti-sn65dsi86 driver I assume? Yes > > > > > > > struct msm_dsi contains: > > > /* > > > * panel/external_bridge connected to dsi bridge output, only one > > > of the > > > * two can be valid at a time > > > */ > > > struct drm_panel *panel; > > > struct drm_bridge *external_bridge; > > > > > > So if you have "external_bridge" set in your case, "panel" should be NULL. > > > I have only moved code that uses msm_dsi->panel, so my patch really > > > shouldn't make any difference for you. > > > > > > Am I confusing somethin
[PATCH] staging: fbtft: Remove set but not used variable 'ret'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/staging/fbtft/fb_ili9320.c: In function read_devicecode:
drivers/staging/fbtft/fb_ili9320.c:25:6: warning: variable ret set but not used
[-Wunused-but-set-variable]
ret is never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: Zheng Yongjun
---
drivers/staging/fbtft/fb_ili9320.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ili9320.c
b/drivers/staging/fbtft/fb_ili9320.c
index f2e72d14431d..f0ebc40857b3 100644
--- a/drivers/staging/fbtft/fb_ili9320.c
+++ b/drivers/staging/fbtft/fb_ili9320.c
@@ -22,11 +22,10 @@
static unsigned int read_devicecode(struct fbtft_par *par)
{
- int ret;
u8 rxbuf[8] = {0, };
write_reg(par, 0x);
- ret = par->fbtftops.read(par, rxbuf, 4);
+ par->fbtftops.read(par, rxbuf, 4);
return (rxbuf[2] << 8) | rxbuf[3];
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Overlay support in the i.MX7 display
Le mardi 05 novembre 2019 à 10:17 +0100, Philipp Zabel a écrit : > Hi Laurent, > > On Fri, 2019-11-01 at 10:43 +0200, Laurent Pinchart wrote: > > Hello, > > > > I'm looking at the available options to support overlays in the display > > pipeline of the i.MX7. The LCDIF itself unfortunaltey doesn't support > > overlays, the feature being implemented in the PXP. A driver for the PXP > > is available but only supports older SoCs whose PXP doesn't support > > overlays. This driver is implemented as a V4L2 mem2mem driver, which > > makes support of additional input channels impossible. > > > > Here are the options I can envision: > > > > - Extend the existing PXP driver to support multiple channels. This is > > technically feasible, but will require moving away from the V4L2 > > mem2mem framework, which would break userspace. I don't think this > > path could lead anywhere. > > I may be biased, but please don't break the V4L2 mem2mem usecase :) > > > - Write a new PXP driver for the i.MX7, still using V4L2, but with > > multiple video nodes. This would allow blending multiple layers, but > > would require writing the output to memory, while the PXP has support > > for direct connections to the LCDIF (through small SRAM buffers). > > Performances would thus be suboptimal. The API would also be awkward, > > as using the PXP for display would require usage of V4L2 in > > applications. > > I'm not sure V4L2 is the best API for multi-pass 2D composition, > especially as the PXP is able to blit an overlay onto a background in > place. There was some userspace (GStreamer element) doing exactly that with v4l2 m2m using the imx6 driver. The API was fine, even though fences would have made programming it easier. https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/308 (not merge as we don't have an agreement on kernel side, notably we don't even have a way to control the blend function, so the result is likely dependant on the use case the driver was written for) The real limitation was that these IP usually supports more then just blit/blend over another surface, and as you said, supports background. And to support this use case, we'd need an m2m driver with multiple queues per direction. That was discussed in that last workshop at ELCE, and applies to other m2m IP like muxers and demuxers which exist on STB kind of SoC. > > > - Extend the mxsfb driver with PXP support, and expose the PXP inputs as > > KMS planes. The PXP would only be used when available, and would be > > transparent to applications. This would however prevent using it > > separately from the display (to perform multi-pass alpha blending for > > instance). > > For the SRAM block row buffer path to the LCDIF, I think the KMS plane > abstraction is the way to go. The DRM and V4L2 drivers could be made to > use a shared backend, such that only one of plane composition and V4L2 > scaling/CSC functions can work at the same time. > > > What would be the best option going forward ? Would any of you, by any > > chance, have already started work in this area ? > > I have not worked on this. > > regards > Philipp > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] allow DRM drivers to limit creation of blobs
On 2019-11-08 03:34, Daniel Vetter wrote: On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote: Fuzzers used in Android compliance testing repeatedly call the create blob IOCTL which eventually exhausts the system memory. This series adds a hook which allows drivers to impose their own limitations on the size and/or number of blobs created. Pretty sure this isn't just a problem for msm/dpu alone, why this very limited approach? I'm not familiar enough with the blob requirements for other vendor's drivers to impose any restrictions on them. The idea was to provide the hook for vendors to implement their own checks. Support for msm/mdp* drivers will be added in v2 if this approach is acceptable. Also, why are your fuzzers not also allocating enormous amounts of gem buffers, which will also exhaust memory eventually? Excellent question... This will likely come in a follow-up series. -Daniel Steve Cohen (3): drm: add driver hook for create blob limitations drm/msm: add support for createblob_check driver hook drm/msm/dpu: check blob limitations during create blob ioctl drivers/gpu/drm/drm_property.c | 7 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 ++ drivers/gpu/drm/msm/msm_drv.c | 25 + drivers/gpu/drm/msm/msm_kms.h | 1 + include/drm/drm_drv.h | 9 + 5 files changed, 56 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Overlay support in the i.MX7 display
Le lundi 04 novembre 2019 à 10:09 +0200, Pekka Paalanen a écrit : > On Sun, 03 Nov 2019 19:15:49 +0100 > Stefan Agner wrote: > > > Hi Laurent, > > > > On 2019-11-01 09:43, Laurent Pinchart wrote: > > > Hello, > > > > > > I'm looking at the available options to support overlays in the display > > > pipeline of the i.MX7. The LCDIF itself unfortunaltey doesn't support > > > overlays, the feature being implemented in the PXP. A driver for the PXP > > > is available but only supports older SoCs whose PXP doesn't support > > > overlays. This driver is implemented as a V4L2 mem2mem driver, which > > > makes support of additional input channels impossible. > > > > Thanks for bringing this up, it is a topic I have wondered too: > > Interaction between PXP and mxsfb. > > > > I am not very familiar with the V4L2 subsystem so take my opinions with > > a grain of salt. > > > > > Here are the options I can envision: > > > > > > - Extend the existing PXP driver to support multiple channels. This is > > > technically feasible, but will require moving away from the V4L2 > > > mem2mem framework, which would break userspace. I don't think this > > > path could lead anywhere. > > > > > > - Write a new PXP driver for the i.MX7, still using V4L2, but with > > > multiple video nodes. This would allow blending multiple layers, but > > > would require writing the output to memory, while the PXP has support > > > for direct connections to the LCDIF (through small SRAM buffers). > > > Performances would thus be suboptimal. The API would also be awkward, > > > as using the PXP for display would require usage of V4L2 in > > > applications. > > > > So the video nodes would be sinks? I would expect overlays to be usable > > through KMS, I guess that would then not work, correct? > > > > > - Extend the mxsfb driver with PXP support, and expose the PXP inputs as > > > KMS planes. The PXP would only be used when available, and would be > > > transparent to applications. This would however prevent using it > > > separately from the display (to perform multi-pass alpha blending for > > > instance). > > > > KMS planes are well defined and are well integrated with the KMS API, so > > I prefer this option. But is this compatible with the currently > > supported video use-case? E.g. could we make PXP available through V4L2 > > and through DRM/mxsfb? > > > > Not sure what your use case is exactly, but when playing a video I > > wonder where is the higher value using PXP: Color conversion and scaling > > or compositing...? I would expect higher value in the former use case. > > Hi, > > mind, with Wayland architecture, color conversion and scaling could be > at the same level/step as compositing, in the display server instead of > an application. Hence if the PXP capabilities were advertised as KMS > planes, there should be nothing to patch in Wayland-designed > applications to make use of them, assuming the applications did not > already rely on V4L2 M2M devices. The PXP can already be used with GStreamer v4l2convert element, for CSC and scaling. > > Would it not be possible to expose PXP through both uAPI interfaces? At > least KMS atomic's TEST_ONLY feature would make it easy to say "no" to > userspace if another bit of userspace already reserved the device via > e.g. V4L2. Same exist for decoders with fixed number of streams/instances I think. > > > Thanks, > pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
On Thu, Nov 7, 2019 at 7:03 PM Rob Clark wrote:
>
> On Thu, Nov 7, 2019 at 9:40 AM Jeffrey Hugo wrote:
> >
> > On Thu, Nov 7, 2019 at 9:17 AM Rob Clark wrote:
> > >
> > > On Thu, Nov 7, 2019 at 3:10 AM Brian Masney wrote:
> > > >
> > > > On Wed, Nov 06, 2019 at 08:58:59AM -0800, Rob Clark wrote:
> > > > > On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Nov 6, 2019 at 9:30 AM Rob Clark
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > > > > > > > > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney
> > > > > > > > > wrote:
> > > > > > > > > > The 'pp done time out' errors go away if I revert the
> > > > > > > > > > following three
> > > > > > > > > > commits:
> > > > > > > > > >
> > > > > > > > > > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > > > > > > > > > d934a712c5e6 ("drm/msm: add atomic traces")
> > > > > > > > > > 2d99ced787e3 ("drm/msm: async commit support")
> > > > > > > > > >
> > > > > > > > > > I reverted the first one to fix a compiler error, and the
> > > > > > > > > > second one so
> > > > > > > > > > that the last patch can be reverted without any merge
> > > > > > > > > > conflicts.
> > > > > > > > > >
> > > > > > > > > > I see that crtc_flush() calls mdp5_ctl_commit(). I tried to
> > > > > > > > > > use
> > > > > > > > > > crtc_flush_all() in mdp5_flush_commit() and the contents of
> > > > > > > > > > the frame
> > > > > > > > > > buffer dance around the screen like its out of sync. I
> > > > > > > > > > renamed
> > > > > > > > > > crtc_flush_all() to mdp5_crtc_flush_all() and removed the
> > > > > > > > > > static
> > > > > > > > > > declaration. Here's the relevant part of what I tried:
> > > > > > > > > >
> > > > > > > > > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > > > > > > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > > > > > > > @@ -171,7 +171,15 @@ static void mdp5_prepare_commit(struct
> > > > > > > > > > msm_kms *kms, struct drm_atomic_state *st
> > > > > > > > > >
> > > > > > > > > > static void mdp5_flush_commit(struct msm_kms *kms,
> > > > > > > > > > unsigned crtc_mask)
> > > > > > > > > > {
> > > > > > > > > > - /* TODO */
> > > > > > > > > > + struct mdp5_kms *mdp5_kms =
> > > > > > > > > > to_mdp5_kms(to_mdp_kms(kms));
> > > > > > > > > > + struct drm_crtc *crtc;
> > > > > > > > > > +
> > > > > > > > > > + for_each_crtc_mask(mdp5_kms->dev, crtc, crtc_mask) {
> > > > > > > > > > + if (!crtc->state->active)
> > > > > > > > > > + continue;
> > > > > > > > > > +
> > > > > > > > > > + mdp5_crtc_flush_all(crtc);
> > > > > > > > > > + }
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > Any tips would be appreciated.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think this is along the lines of what we need to enable
> > > > > > > > > async commit
> > > > > > > > > for mdp5 (but also removing the flush from the atomic-commit
> > > > > > > > > path)..
> > > > > > > > > the principle behind the async commit is to do all the atomic
> > > > > > > > > state
> > > > > > > > > commit normally, but defer writing the flush bits. This way,
> > > > > > > > > if you
> > > > > > > > > get another async update before the next vblank, you just
> > > > > > > > > apply it
> > > > > > > > > immediately instead of waiting for vblank.
> > > > > > > > >
> > > > > > > > > But I guess you are on a command mode panel, if I remember?
> > > > > > > > > Which is
> > > > > > > > > a case I didn't have a way to test. And I'm not entirely
> > > > > > > > > about how
> > > > > > > > > kms_funcs->vsync_time() should be implemented for cmd mode
> > > > > > > > > panels.
> > > > > > > >
> > > > > > > > Yes, this is a command-mode panel and there's no hardware frame
> > > > > > > > counter
> > > > > > > > available. The key to getting the display working on this phone
> > > > > > > > was this
> > > > > > > > patch:
> > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> > > > > > > >
> > > > > > > > > That all said, I think we should first fix what is broken,
> > > > > > > > > before
> > > > > > > > > worrying about extending async commit support to mdp5.. which
> > > > > > > > > shouldn't hit the async==true path, due to not implementing
> > > > > > > > > kms_funcs->vsync_time().
> > > > > > > > >
> > > > > > > > > What I think is going on is that, in the cmd mode case,
> > > > > > > > > mdp5_wait_flush() (indirectly) calls
> > > > > > > > > mdp5_crtc_wait_for_pp_done(),
> > > > > > > > > which waits for a pp-done irq regardless of whether there is
> > > > > > > > > a flush
> > > > > > > > > in progress. Since there is no flush pending, the irq never
> > > > > > > > >
[PATCH -next] drm/amd/display: remove set but not used variable 'bpc'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
get_pbn_from_timing:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2364:11: warning:
variable bpc set but not used [-Wunused-but-set-variable]
It is not used since commit e49f69363adf ("drm/amd/display: use
proper formula to calculate bandwidth from timing")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index bdc8be3..53394e2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2653,13 +2653,11 @@ static int get_color_depth(enum dc_color_depth
color_depth)
static struct fixed31_32 get_pbn_from_timing(struct pipe_ctx *pipe_ctx)
{
- uint32_t bpc;
uint64_t kbps;
struct fixed31_32 peak_kbps;
uint32_t numerator;
uint32_t denominator;
- bpc = get_color_depth(pipe_ctx->stream_res.pix_clk_params.color_depth);
kbps = dc_bandwidth_in_kbps_from_timing(&pipe_ctx->stream->timing);
/*
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/8] RFC: dt-bindings: add img,pvrsgx.yaml for Imagination GPUs
* H. Nikolaus Schaller [191107 16:56]: > > Am 07.11.2019 um 15:35 schrieb Rob Herring : > > On Thu, Nov 7, 2019 at 5:06 AM H. Nikolaus Schaller > > wrote: > >> Clock, Reset and power management should be handled > >> by a parent node or elsewhere. > > > > That's probably TI specific... > > Yes and no. > > For example the img4780 seems to need a clock reference in the > gpu node. But it could maybe connected in a parent node like recent > TI SoC do with the target-module approach. The clocks are implemented at the SoC glue layer and/or the interconnect layer, and then the device probably has it's own clock gate controls. > And our goal is to end up with a common driver for all SoC and architectures > in far future. Then, probably clock, reset and power management should > be handled in the same way. Yeah so that's standard Linux features such as PM runtime and genpd basically :) So you can just leave out the clocks paragraph from the binding. Then if clocks are really needed beyond PM runtime and genpd, those can always be added later. We just need a super minimal binding to start with that only uses standard properties, then more can be added later if needed. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915: make more headers self-contained
The headers in the gem/selftests/, gt/selftests, gvt/, selftests/
directories have never been compile-tested, but it would be possible
to make them self-contained.
This commit only addresses missing and forward
struct declarations.
Signed-off-by: Masahiro Yamada
---
Rebase on git://anongit.freedesktop.org/drm-tip
drivers/gpu/drm/i915/gem/selftests/mock_context.h | 3 +++
drivers/gpu/drm/i915/gt/selftests/mock_timeline.h | 2 ++
drivers/gpu/drm/i915/gvt/cmd_parser.h | 4
drivers/gpu/drm/i915/gvt/display.h| 5 +
drivers/gpu/drm/i915/gvt/edid.h | 4
drivers/gpu/drm/i915/gvt/execlist.h | 2 ++
drivers/gpu/drm/i915/gvt/fb_decoder.h | 2 ++
drivers/gpu/drm/i915/gvt/hypercall.h | 4
drivers/gpu/drm/i915/gvt/interrupt.h | 3 +++
drivers/gpu/drm/i915/gvt/mmio.h | 2 ++
drivers/gpu/drm/i915/gvt/page_track.h | 3 +++
drivers/gpu/drm/i915/gvt/sched_policy.h | 3 +++
drivers/gpu/drm/i915/selftests/mock_gtt.h | 3 +++
drivers/gpu/drm/i915/selftests/mock_region.h | 5 +
drivers/gpu/drm/i915/selftests/mock_uncore.h | 3 +++
15 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
index 0b926653914f..45de09ec28d1 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
@@ -7,6 +7,9 @@
#ifndef __MOCK_CONTEXT_H
#define __MOCK_CONTEXT_H
+struct drm_file;
+struct drm_i915_private;
+
void mock_init_contexts(struct drm_i915_private *i915);
struct i915_gem_context *
diff --git a/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
b/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
index 689efc66c908..d2bcc3df6183 100644
--- a/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
+++ b/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
@@ -7,6 +7,8 @@
#ifndef __MOCK_TIMELINE__
#define __MOCK_TIMELINE__
+#include
+
struct intel_timeline;
void mock_timeline_init(struct intel_timeline *timeline, u64 context);
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.h
b/drivers/gpu/drm/i915/gvt/cmd_parser.h
index 286703643002..ab25d151932a 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.h
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.h
@@ -38,6 +38,10 @@
#define GVT_CMD_HASH_BITS 7
+struct intel_gvt;
+struct intel_shadow_wa_ctx;
+struct intel_vgpu_workload;
+
void intel_gvt_clean_cmd_parser(struct intel_gvt *gvt);
int intel_gvt_init_cmd_parser(struct intel_gvt *gvt);
diff --git a/drivers/gpu/drm/i915/gvt/display.h
b/drivers/gpu/drm/i915/gvt/display.h
index a87f33e6a23c..b59b34046e1e 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -35,6 +35,11 @@
#ifndef _GVT_DISPLAY_H_
#define _GVT_DISPLAY_H_
+#include
+
+struct intel_gvt;
+struct intel_vgpu;
+
#define SBI_REG_MAX20
#define DPCD_SIZE 0x700
diff --git a/drivers/gpu/drm/i915/gvt/edid.h b/drivers/gpu/drm/i915/gvt/edid.h
index f6dfc8b795ec..dfe0cbc6aad8 100644
--- a/drivers/gpu/drm/i915/gvt/edid.h
+++ b/drivers/gpu/drm/i915/gvt/edid.h
@@ -35,6 +35,10 @@
#ifndef _GVT_EDID_H_
#define _GVT_EDID_H_
+#include
+
+struct intel_vgpu;
+
#define EDID_SIZE 128
#define EDID_ADDR 0x50 /* Linux hvm EDID addr */
diff --git a/drivers/gpu/drm/i915/gvt/execlist.h
b/drivers/gpu/drm/i915/gvt/execlist.h
index 5ccc2c695848..5c0c1fd30c83 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.h
+++ b/drivers/gpu/drm/i915/gvt/execlist.h
@@ -35,6 +35,8 @@
#ifndef _GVT_EXECLIST_H_
#define _GVT_EXECLIST_H_
+#include
+
struct execlist_ctx_descriptor_format {
union {
u32 ldw;
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.h
b/drivers/gpu/drm/i915/gvt/fb_decoder.h
index 60c155085029..67b6ede9e707 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.h
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.h
@@ -36,6 +36,8 @@
#ifndef _GVT_FB_DECODER_H_
#define _GVT_FB_DECODER_H_
+#include
+
#define _PLANE_CTL_FORMAT_SHIFT24
#define _PLANE_CTL_TILED_SHIFT 10
#define _PIPE_V_SRCSZ_SHIFT0
diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h
b/drivers/gpu/drm/i915/gvt/hypercall.h
index 4862fb12778e..9599c0a762b2 100644
--- a/drivers/gpu/drm/i915/gvt/hypercall.h
+++ b/drivers/gpu/drm/i915/gvt/hypercall.h
@@ -33,6 +33,10 @@
#ifndef _GVT_HYPERCALL_H_
#define _GVT_HYPERCALL_H_
+#include
+
+struct device;
+
enum hypervisor_type {
INTEL_GVT_HYPERVISOR_XEN = 0,
INTEL_GVT_HYPERVISOR_KVM,
diff --git a/drivers/gpu/drm/i915/gvt/interrupt.h
b/drivers/gpu/drm/i915/gvt/interrupt.h
index 5313fb1b33e1..fcd663811d37 100644
--- a/drivers/gpu/drm/i915/gvt/interrupt.h
+++ b/drivers/gpu/drm/i915/gvt/interrupt.h
@@ -32,6 +32,8 @@
#ifndef _GVT_INTERRUPT_H_
#define _GVT_INTERRUPT_H_
+#include
+
enum intel_gvt_event_type {
Re: [PATCH v2 1/8] RFC: dt-bindings: add img,pvrsgx.yaml for Imagination GPUs
* H. Nikolaus Schaller [191107 11:07]: > +- const: "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530", > "img,sgx5" I did a quick probe test for the module and am4 is the same as am335x, so please also add this for the next version: "ti,am4-sgx530-125" Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm/msm/dsi: Delay drm_panel_enable() until dsi_mgr_bridge_enable()
On Fri, Nov 8, 2019 at 2:29 PM Stephan Gerhold wrote: > > At the moment, the MSM DSI driver calls drm_panel_enable() rather early > from the DSI bridge pre_enable() function. At this point, the encoder > (e.g. MDP5) is not enabled, so we have not started transmitting > video data. > > However, the drm_panel_funcs documentation states that enable() > should be called on the panel *after* video data is being transmitted: > > The .prepare() function is typically called before the display controller > starts to transmit video data. [...] After the display controller has > started transmitting video data, it's safe to call the .enable() function. > This will typically enable the backlight to make the image on screen > visible. > > Calling drm_panel_enable() too early causes problems for some panels: > The TFT LCD panel used in the Samsung Galaxy Tab A 9.7 (2015) (APQ8016) > uses the MIPI_DCS_SET_DISPLAY_BRIGHTNESS command to control > backlight/brightness of the screen. The enable sequence is therefore: > > drm_panel_enable() > drm_panel_funcs.enable(): > backlight_enable() > backlight_ops.update_status(): > mipi_dsi_dcs_set_display_brightness(dsi, bl->props.brightness); > > The panel seems to silently ignore the MIPI_DCS_SET_DISPLAY_BRIGHTNESS > command if it is sent too early. This prevents setting the initial brightness, > causing the display to be enabled with minimum brightness instead. > Adding various delays in the panel initialization code does not result > in any difference. > > On the other hand, moving drm_panel_enable() to dsi_mgr_bridge_enable() > fixes the problem, indicating that the panel requires the video stream > to be active before the brightness command is accepted. > > Therefore: Move drm_panel_enable() to dsi_mgr_bridge_enable() to > delay calling it until video data is being transmitted. > > Move drm_panel_disable() to dsi_mgr_bridge_disable() for similar reasons. > (This is not strictly required for the panel affected above...) > > Tested-by: Jasper Korten > Signed-off-by: Stephan Gerhold > --- > Since this is a core change I thought it would be better to send this > early. I believe Jasper still wants to finish some other changes before > submitting the initial device tree for the Samsung Galaxy Tab A 9.7 (2015). ;) > > I also tested it on msm8916-samsung-a5u-eur, its display is working fine > with or without this patch. Nack, please. I was curious so I threw this on the Lenovo Miix 630 laptop. I don't get a display back with this patch. I'll try to figure out why, but currently I can't get into the machine. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 6/7] ARM: dts: iwg20d-q7-common: Add LCD support
Hi Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:55
> Subject: Re: [PATCH v3 6/7] ARM: dts: iwg20d-q7-common: Add LCD support
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:11:02PM +, Fabrizio Castro wrote:
> > The iwg20d comes with a 7" capacitive touch screen, therefore
> > add support for it.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * No change
> > v1->v2:
> > * No change
> > ---
> > arch/arm/boot/dts/iwg20d-q7-common.dtsi | 85
> >
> > arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
> > 2 files changed, 85 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > index ae75a1db..3428b8d 100644
> > --- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > +++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > @@ -46,6 +46,49 @@
> > clock-frequency = <2600>;
> > };
> >
> > + lcd_backlight: backlight {
> > + compatible = "pwm-backlight";
> > +
> > + pwms = <&pwm3 0 500 0>;
> > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > + default-brightness-level = <7>;
> > + enable-gpios = <&gpio5 14 GPIO_ACTIVE_HIGH>;
> > + };
> > +
> > + lvds-receiver {
> > + compatible = "lvds-decoder";
>
> A specific compatible string is required.
Will document the specific compatible in the binding doc
>
> I think the lvds-decoder driver should error out at probe time if only
> one compatible string is listed.
Ok, will modify the driver accordingly
>
> > + powerdown = <&gpio7 25 GPIO_ACTIVE_LOW>;
>
> powerdown-gpios ?
That's a bug, well spotted.
>
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + lvds_receiver_in: endpoint {
> > + remote-endpoint = <&lvds0_out>;
> > + };
> > + };
> > + port@1 {
> > + reg = <1>;
> > + lvds_receiver_out: endpoint {
> > + remote-endpoint = <&panel_in>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + panel {
> > + compatible = "edt,etm0700g0dh6", "simple-panel";
>
> There's no "simple-panel" compatible string defined anywhere as far as I
> can tell.
The usage of "simple-panel" as a compatible is widespread and really confusing.
The fact that you made this comment is good enough for me to say we don't
need it, I'll take it out.
>
> > + backlight = <&lcd_backlight>;
> > +
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&lvds_receiver_out>;
> > + };
> > + };
> > + };
> > +
> > reg_1p5v: 1p5v {
> > compatible = "regulator-fixed";
> > regulator-name = "1P5V";
> > @@ -120,6 +163,18 @@
> > status = "okay";
> > };
> >
> > +&du {
> > + status = "okay";
> > +};
> > +
> > +&gpio2 {
> > + touch-interrupt {
> > + gpio-hog;
> > + gpios = <12 GPIO_ACTIVE_LOW>;
> > + input;
> > + };
>
> Do you need this, with the touchpanel@38 node already listing the
> interrupt ?
Yes, unfortunately we do need this as the bootloader is poking with the gpio.
I can't fix this in the bootloader as we have no control over it.
Thanks,
Fab
>
> > +};
> > +
> > &hsusb {
> > status = "okay";
> > pinctrl-0 = <&usb0_pins>;
> > @@ -147,6 +202,25 @@
> > VDDIO-supply = <®_3p3v>;
> > VDDD-supply = <®_1p5v>;
> > };
> > +
> > + touch: touchpanel@38 {
> > + compatible = "edt,edt-ft5406";
> > + reg = <0x38>;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
> > + };
> > +};
> > +
> > +&lvds0 {
> > + status = "okay";
> > +
> > + ports {
> > + port@1 {
> > + lvds0_out: endpoint {
> > + remote-endpoint = <&lvds_receiver_in>;
> > + };
> > + };
> > + };
> > };
> >
> > &pci0 {
> > @@ -180,6 +254,11 @@
> > function = "i2c2";
> > };
> >
> > + pwm3_pins: pwm3 {
> > + groups = "pwm3";
> > + function = "pwm3";
> > + };
> > +
> > scif0_pins: scif0 {
> > groups = "scif0_data_d";
> > function = "scif0";
> > @@ -218,6 +297,12 @@
> > };
> > };
> >
> > +&pwm3 {
> > + pinctrl-0 = <&pwm3_pins>;
> > + pinctrl-names = "default";
> > + status = "okay";
> > +};
> > +
> > &rcar_sound {
> > pinctrl-
RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic
Hi Ville Syrjälä
Thanks for your suggestion and I have replied two comments below.
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Thursday, November 07, 2019 11:42 PM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; open list; open list:DRM DRIVERS;
David Airlie; Pi-Hsun Shih; Sean Paul
Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking
timings logic
On Mon, Nov 04, 2019 at 04:42:49PM +0800, allen wrote:
> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
> (Defines EDID Structure Version 1, Revision 4) page: 39
> How to determine whether the monitor support RB timing or not?
> EDID 1.4
> First: read detailed timing descriptor and make sure byte0 = 0,
> byte1 = 0, byte2 = 0 and byte3 = 0xFD
That should probably be some new function:
bool is_display_descriptor(const u8 *desc, u8 tag);
is_display_descriptor(EDID_DETAIL_MONITOR_RANGE)
or something along those lines
We don't seem to check that in most places so should be rolled out all
over. The usage of struct detailed_timing all over also makes everything
rather confusing.
> Second: read detailed timing descriptor byte10 = 0x04 and
> EDID byte18h bit0 = 1
Indicates CVT support. Should give these things real names so
one wouldn't have to decode by hand.
> Third: if EDID byte18h bit0 == 1 && byte10 == 0x04,
> then we can check byte15, if byte15 bit4 =1 is support RB
> if EDID byte18h bit0 != 1 || byte10 != 0x04,
> then byte15 can not be used
>
> The linux code is_rb function not follow the VESA's rule
>
> EDID 1.3
> LCD flat panels do not require long blanking intervals as a retrace
> period so default support reduced-blanking timings.
>
> Signed-off-by: Allen Chen
> Reported-by: kbuild test robot
> ---
> drivers/gpu/drm/drm_edid.c | 28 +---
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e5e7e65..9b67b80 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -93,6 +93,11 @@ struct detailed_mode_closure {
> int modes;
> };
>
> +struct edid_support_rb_closure {
> + struct edid *edid;
> + s8 support_rb;
bool
==> ITE: If use bool, we could not return EDID1.3 when EDID1.4 logic can not
be applied
> +};
> +
> #define LEVEL_DMT0
> #define LEVEL_GTF1
> #define LEVEL_GTF2 2
> @@ -2018,22 +2023,31 @@ struct drm_display_mode *drm_mode_find_dmt(struct
> drm_device *dev,
> is_rb(struct detailed_timing *t, void *data)
> {
> u8 *r = (u8 *)t;
> - if (r[3] == EDID_DETAIL_MONITOR_RANGE)
> - if (r[15] & 0x10)
> - *(bool *)data = true;
> + struct edid_support_rb_closure *closure = data;
> + struct edid *edid = closure->edid;
> +
> + if (!r[0] && !r[1] && !r[2] && r[3] == EDID_DETAIL_MONITOR_RANGE) {
> + if (edid->features & BIT(0) && r[10] == BIT(2))
> + closure->support_rb = (r[15] & 0x10) ? 1 : 0;
With the bool the ternary operator is not needed. Also should maybe
be |= in case we have multiple range descriptors? Not sure that is
legal.
> + }
> }
>
> /* EDID 1.4 defines this explicitly. For EDID 1.3, we guess, badly. */
> static bool
> drm_monitor_supports_rb(struct edid *edid)
> {
> + struct edid_support_rb_closure closure = {
> + .edid = edid,
> + .support_rb = -1,
> + };
> +
> if (edid->revision >= 4) {
> - bool ret = false;
> - drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
> - return ret;
> + drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);
> + if (closure.support_rb >= 0)
> + return closure.support_rb;
> }
>
> - return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);
> + return true;
Why are we now assuming rb for all pre 1.4 EDIDs?
==> ITE: Today, most of the monitor are LCD and LCD monitor do not require long
blanking intervals as a retrace period so default support reduced-blanking
timings.
> }
>
> static void
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/Makefile |2 +-
drivers/gpu/drm/bridge/analogix/Kconfig |6 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 2042 +
drivers/gpu/drm/bridge/analogix/anx7625.h | 406 ++
5 files changed, 2456 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..bcd388a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e930ff9..b2f127e 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -2,3 +2,9 @@
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config ANALOGIX_ANX7625
+ tristate "Analogix MIPI to DP interface support"
+ help
+ ANX7625 is an ultra-low power 4K mobile HD transmitter designed
+ for portable devices. It converts MIPI/DPI to DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index fdbf3fd..8a52867 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ANALOGIX_ANX7625) += anx7625.o
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..ad73317
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,2042 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "anx7625.h"
+
+/*
+ * there is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+ u8 offset;
+ struct device *dev = &client->dev;
+ int ret;
+
+ if (client == ctx->last_client)
+ return 0;
+
+ ctx->last_client = client;
+
+ if (client == ctx->i2c.tcpc_client)
+ offset = RSVD_00_ADDR;
+ else if (client == ctx->i2c.tx_p0_client)
+ offset = RSVD_D1_ADDR;
+ else if (client == ctx->i2c.tx_p1_client)
+ offset = RSVD_60_ADDR;
+ else if (client == ctx->i2c.rx_p0_client)
+ offset = RSVD_39_ADDR;
+ else if (client == ctx->i2c.rx_p1_client)
+ offset = RSVD_7F_ADDR;
+ else
+ offset = RSVD_00_ADDR;
+
+ ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev,
+ "failed to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+ return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+ struct i2c_client *client, u8 reg_addr)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_byte_data(client, reg_addr);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c failed id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+ int ret;
+ str
RE: [PATCH v3 1/7] dt-bindings: display: bridge: Convert lvds-transmitter binding to json-schema
Hello Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:21
> Subject: Re: [PATCH v3 1/7] dt-bindings: display: bridge: Convert
> lvds-transmitter binding to json-schema
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:10:57PM +, Fabrizio Castro wrote:
> > Convert the lvds-transmitter binding to DT schema format using
> > json-schema.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * Extracted conversion to dt-schema as per Rob's comment
> > v1->v2:
> > * Converted to dt-schema as per Neil's comment
> > ---
> > .../bindings/display/bridge/lvds-transmitter.txt | 66
> > .../bindings/display/bridge/lvds-transmitter.yaml | 91
> > ++
> > 2 files changed, 91 insertions(+), 66 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > deleted file mode 100644
> > index 60091db..000
> > --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > +++ /dev/null
> > @@ -1,66 +0,0 @@
> > -Parallel to LVDS Encoder
> > -
> > -
> > -This binding supports the parallel to LVDS encoders that don't require any
> > -configuration.
> > -
> > -LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple
> > -incompatible data link layers have been used over time to transmit image
> > data
> > -to LVDS panels. This binding targets devices compatible with the following
> > -specifications only.
> > -
> > -[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
> > -1999 (Version 1.0), Japan Electronic Industry Development Association
> > (JEIDA)
> > -[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
> > -Semiconductor
> > -[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
> > -Electronics Standards Association (VESA)
> > -
> > -Those devices have been marketed under the FPD-Link and FlatLink brand
> > names
> > -among others.
> > -
> > -
> > -Required properties:
> > -
> > -- compatible: Must be "lvds-encoder"
> > -
> > - Any encoder compatible with this generic binding, but with additional
> > - properties not listed here, must list a device specific compatible first
> > - followed by this generic compatible.
> > -
> > -Required nodes:
> > -
> > -This device has two video ports. Their connections are modeled using the OF
> > -graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > -
> > -- Video port 0 for parallel input
> > -- Video port 1 for LVDS output
> > -
> > -
> > -Example
> >
> > -
> > -lvds-encoder {
> > - compatible = "lvds-encoder";
> > -
> > - ports {
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > - port@0 {
> > - reg = <0>;
> > -
> > - lvds_enc_in: endpoint {
> > - remote-endpoint = <&display_out_rgb>;
> > - };
> > - };
> > -
> > - port@1 {
> > - reg = <1>;
> > -
> > - lvds_enc_out: endpoint {
> > - remote-endpoint = <&lvds_panel_in>;
> > - };
> > - };
> > - };
> > -};
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > new file mode 100644
> > index 000..5be163a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Parallel to LVDS Encoder
> > +
> > +maintainers:
> > + - Laurent Pinchart
> > +
> > +description: |
> > + This binding supports the parallel to LVDS encoders that don't require
> > any
> > + configuration.
> > +
> > + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple
> > + incompatible data link layers have been used over time to transmit image
> > data
> > + to LVDS panels. This binding targets devices compatible with the
> > following
> > + specifications only.
> > +
> > + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
> > February
> > + 1999 (Version 1.0), Japan Electronic Industry Development Association
> > (JEIDA)
> > + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
> > + Semiconduct
Re: [PATCH] drm/rockchip: use DRM_DEV_ERROR for log output
On Thu, Nov 07, 2019 at 08:38:51AM -0500, Sean Paul wrote:
> On Thu, Nov 07, 2019 at 01:54:22AM -0800, Joe Perches wrote:
> > On Thu, 2019-11-07 at 12:29 +0300, Wambui Karuga wrote:
> > > Replace the use of the dev_err macro with the DRM_DEV_ERROR
> > > DRM helper macro.
> >
> > The commit message should show the reason _why_ you are doing
> > this instead of just stating that you are doing this.
> >
> > It's not that dev_err is uncommon in drivers/gpu/drm.
> >
>
> It is uncommon (this is the sole instance) in rockchip, however. So it makes
> sense to convert the dev_* prints in rockchip to DRM_DEV for consistency.
>
> Wambui, could you also please convert the dev_warn instance as well?
>
Hey, Sean.
Trying to convert this dev_warn instance, but the corresponding DRM_WARN
macro does not take the dev parameter which seems to be useful in the
original output.
Should I still convert it to DRM_WARN without the hdmi->dev parameter?
Thanks,
wambui
> I'll apply this to drm-misc-next and expand on the commit message a bit.
>
> Thanks,
>
> Sean
>
> > $ git grep -w dev_err drivers/gpu/drm | wc -l
> > 1950
> > $ git grep -w DRM_DEV_ERROR drivers/gpu/drm | wc -l
> > 756
> >
> > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> > > b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> > []
> > > @@ -916,7 +916,7 @@ static int dw_mipi_dsi_rockchip_probe(struct
> > > platform_device *pdev)
> > > }
> > >
> > > if (!dsi->cdata) {
> > > - dev_err(dev, "no dsi-config for %s node\n", np->name);
> > > + DRM_DEV_ERROR(dev, "no dsi-config for %s node\n", np->name);
> > > return -EINVAL;
> > > }
> >
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Overlay support in the i.MX7 display
Le lundi 04 novembre 2019 à 19:24 +0100, Daniel Vetter a écrit : > On Mon, Nov 04, 2019 at 02:58:29PM +0200, Laurent Pinchart wrote: > > Hello, > > > > On Mon, Nov 04, 2019 at 10:09:47AM +0200, Pekka Paalanen wrote: > > > On Sun, 03 Nov 2019 19:15:49 +0100 Stefan Agner wrote: > > > > On 2019-11-01 09:43, Laurent Pinchart wrote: > > > > > Hello, > > > > > > > > > > I'm looking at the available options to support overlays in the > > > > > display > > > > > pipeline of the i.MX7. The LCDIF itself unfortunaltey doesn't support > > > > > overlays, the feature being implemented in the PXP. A driver for the > > > > > PXP > > > > > is available but only supports older SoCs whose PXP doesn't support > > > > > overlays. This driver is implemented as a V4L2 mem2mem driver, which > > > > > makes support of additional input channels impossible. > > > > > > > > Thanks for bringing this up, it is a topic I have wondered too: > > > > Interaction between PXP and mxsfb. > > > > > > > > I am not very familiar with the V4L2 subsystem so take my opinions with > > > > a grain of salt. > > > > > > > > > Here are the options I can envision: > > > > > > > > > > - Extend the existing PXP driver to support multiple channels. This is > > > > > technically feasible, but will require moving away from the V4L2 > > > > > mem2mem framework, which would break userspace. I don't think this > > > > > path could lead anywhere. > > > > > > > > > > - Write a new PXP driver for the i.MX7, still using V4L2, but with > > > > > multiple video nodes. This would allow blending multiple layers, but > > > > > would require writing the output to memory, while the PXP has > > > > > support > > > > > for direct connections to the LCDIF (through small SRAM buffers). > > > > > Performances would thus be suboptimal. The API would also be > > > > > awkward, > > > > > as using the PXP for display would require usage of V4L2 in > > > > > applications. > > > > > > > > So the video nodes would be sinks? I would expect overlays to be usable > > > > through KMS, I guess that would then not work, correct? > > > > There would be sink video nodes for the PXP inputs, and one source video > > node for the PXP output. The PXP can be used stand-alone, in > > memory-to-memory mode, and V4L2 is a good fit for that. > > > > > > > - Extend the mxsfb driver with PXP support, and expose the PXP inputs > > > > > as > > > > > KMS planes. The PXP would only be used when available, and would be > > > > > transparent to applications. This would however prevent using it > > > > > separately from the display (to perform multi-pass alpha blending > > > > > for > > > > > instance). > > > > > > > > KMS planes are well defined and are well integrated with the KMS API, so > > > > I prefer this option. But is this compatible with the currently > > > > supported video use-case? E.g. could we make PXP available through V4L2 > > > > and through DRM/mxsfb? > > > > That's the issue, it's not easily doable. I think we could do so, but > > how to ensure mutual exclusion between the two APIs needs to be > > researched. I fear it will result in an awkward solution with fuzzy > > semantics. A module parameter could be an option, but wouldn't be very > > flexible. > > > > > > Not sure what your use case is exactly, but when playing a video I > > > > wonder where is the higher value using PXP: Color conversion and scaling > > > > or compositing...? I would expect higher value in the former use case. > > > > I think it's highly use-case-dependent. > > > > > mind, with Wayland architecture, color conversion and scaling could be > > > at the same level/step as compositing, in the display server instead of > > > an application. Hence if the PXP capabilities were advertised as KMS > > > planes, there should be nothing to patch in Wayland-designed > > > applications to make use of them, assuming the applications did not > > > already rely on V4L2 M2M devices. > > > > > > Would it not be possible to expose PXP through both uAPI interfaces? At > > > least KMS atomic's TEST_ONLY feature would make it easy to say "no" to > > > userspace if another bit of userspace already reserved the device via > > > e.g. V4L2. > > > > We would also need to figure out how to do it the other way around, > > reporting properly through V4L2 that the device is busy. I think it's > > feasible, but I doubt it would result in anything usable for userspace. > > If the KMS device exposes multiple planes unconditionally and fails the > > atomic commit if the PXP is used through V4L2, I think it would be hard > > for Wayland to use this consistently. Given that I expect the PXP to be > > mostly used for display purpose I'm tempted to allocate it for display > > unconditionally, or, possibly, decide how to expose it through a module > > parameter. > > KMS should be fine if planes are missing, userspace is supposed to be able > to cope with that. Not all userspace does, but welp. > >
RE: [PATCH v3 5/7] drm/panel: panel-simple: Add connector type for etm0700g0dh6
Hi Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:49
> Subject: Re: [PATCH v3 5/7] drm/panel: panel-simple: Add connector type for
> etm0700g0dh6
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:11:01PM +, Fabrizio Castro wrote:
> > Add connector type for the etm0700g0dh6 from Emerging Display
> > Technologies (EDT).
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * New patch
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 5d48768..82065ff 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1342,6 +1342,7 @@ static const struct panel_desc edt_etm0700g0dh6 = {
> > },
> > .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
> > + .connector_type = DRM_MODE_CONNECTOR_PARALLEL,
>
> I still think we should have a DRM_MODE_CONNECTOR_PANEL, but regardless,
> this panel seems to match DRM_MODE_CONNECTOR_DPI.
Thank you! I wasn't really sure about which definition to pick,
DRM_MODE_CONNECTOR_DPI
will surely work just fine.
Thanks,
Fab
>
> > };
> >
> > static const struct panel_desc edt_etm0700g0bdh6 = {
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/tegra: Turn off and reset hardware across suspend-resume
11.08.2019 21:39, Dmitry Osipenko пишет: > The drivers core bumps runtime PM refcount during of entering into > suspend to workaround some problem where parent device may become turned > off before its children. In order to disable and reset CRTCs/HDMI/etc > hardware, the runtime PM needs to be "forced" into suspend mode. > > Signed-off-by: Dmitry Osipenko > --- Hello Thierry, Is there any particular reason why you're skipping this patch? The driver's suspend-resume doesn't work properly without it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/virtgpu: fix double unregistration
drm_put_dev also calls drm_dev_unregister, so dev will be unregistered twice. Replace it with drm_dev_put to fix it. Signed-off-by: Chuhong Yuan --- drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index 0fc32fa0b3c0..fccc24e21af8 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -138,7 +138,7 @@ static void virtio_gpu_remove(struct virtio_device *vdev) drm_dev_unregister(dev); virtio_gpu_deinit(dev); - drm_put_dev(dev); + drm_dev_put(dev); } static void virtio_gpu_config_changed(struct virtio_device *vdev) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 4/7] drm: Define DRM_MODE_CONNECTOR_PARALLEL
Hi Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:47
> Subject: Re: [PATCH v3 4/7] drm: Define DRM_MODE_CONNECTOR_PARALLEL
>
> Hi Fabrizio,
>
> (CC'ing Sam)
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:11:00PM +, Fabrizio Castro wrote:
> > The existing DRM_MODE_CONNECTOR_ definitions don't seem to
> > describe the connector for RGB/Parallel embedded displays,
> > hence add DRM_MODE_CONNECTOR_PARALLEL.
>
> Please, no. We already have too many connector types for panels, when
> userspace should really not care. DRM_MODE_CONNECTOR_LVDS,
> DRM_MODE_CONNECTOR_eDP, DRM_MODE_CONNECTOR_DSI, DRM_MODE_CONNECTOR_DPI
> and probably DRM_MODE_CONNECTOR_SPI should have been
> DRM_MODE_CONNECTOR_PANEL.
>
> This has been discussed in [1]. Let's instead define a
> DRM_MODE_CONNECTOR_PANEL, possibly as an alias to one of the existing
> types, and deprecate the other types.
>
> [1] https://www.spinics.net/lists/dri-devel/msg224638.html
Thank you for the pointer and the for the details. That clarifies things a lot.
In my case, as you mentioned in the patch to simple panel, I can use an
existing definition, therefore I think it's best if DRM_MODE_CONNECTOR_PANEL
gets added when there is a valid use case.
Thanks,
Fab
>
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * New patch
> > ---
> > drivers/gpu/drm/drm_connector.c | 1 +
> > include/uapi/drm/drm_mode.h | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 2166000..b233029 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -93,6 +93,7 @@ static struct drm_conn_prop_enum_list
> > drm_connector_enum_list[] = {
> > { DRM_MODE_CONNECTOR_DPI, "DPI" },
> > { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
> > { DRM_MODE_CONNECTOR_SPI, "SPI" },
> > + { DRM_MODE_CONNECTOR_PARALLEL, "Parallel" },
> > };
> >
> > void drm_connector_ida_init(void)
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 735c8cf..5852f47 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -362,6 +362,7 @@ enum drm_mode_subconnector {
> > #define DRM_MODE_CONNECTOR_DPI 17
> > #define DRM_MODE_CONNECTOR_WRITEBACK 18
> > #define DRM_MODE_CONNECTOR_SPI 19
> > +#define DRM_MODE_CONNECTOR_PARALLEL20
> >
> > struct drm_mode_get_connector {
> >
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/amd/display: remove set but not used variable 'ds_port'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
dp_wa_power_up_0010FA:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:2320:35: warning:
variable ds_port set but not used [-Wunused-but-set-variable]
It is never used, so can be removed.
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 65de32f..b814b74 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2910,7 +2910,6 @@ static void dp_wa_power_up_0010FA(struct dc_link *link,
uint8_t *dpcd_data,
int length)
{
int retry = 0;
- union dp_downstream_port_present ds_port = { 0 };
if (!link->dpcd_caps.dpcd_rev.raw) {
do {
@@ -2923,9 +2922,6 @@ static void dp_wa_power_up_0010FA(struct dc_link *link,
uint8_t *dpcd_data,
} while (retry++ < 4 && !link->dpcd_caps.dpcd_rev.raw);
}
- ds_port.byte = dpcd_data[DP_DOWNSTREAMPORT_PRESENT -
-DP_DPCD_REV];
-
if (link->dpcd_caps.dongle_type == DISPLAY_DONGLE_DP_VGA_CONVERTER) {
switch (link->dpcd_caps.branch_dev_id) {
/* 0010FA active dongles (DP-VGA, DP-DLDVI converters) power
down
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI to DisplayPort 1.3 4K.
You can add support to your board with binding.
Example:
anx7625_bridge: encoder@58 {
compatible = "analogix,anx7625";
reg = <0x58>;
status = "okay";
panel-flags = <1>;
enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
anx_1_in: endpoint {
remote-endpoint = <&mipi_dsi>;
};
};
port@2 {
reg = <2>;
anx_1_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/anx7625.yaml | 91 ++
1 file changed, 91 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/anx7625.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
new file mode 100644
index 000..1149ebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ "#address-cells": true
+ "#size-cells": true
+
+ compatible:
+items:
+ - const: analogix,anx7625
+
+ reg:
+maxItems: 1
+
+ panel-flags:
+description: indicate the panel is internal or external.
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+ reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+ port@0:
+type: object
+description:
+ A port node pointing to MIPI DSI host port node.
+
+ port@1:
+type: object
+description:
+ A port node pointing to MIPI DPI host port node.
+
+ port@2:
+type: object
+description:
+ A port node pointing to panel port node.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - compatible
+ - reg
+ - port@0
+ - port@2
+
+example:
+ - |
+anx7625_bridge: encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+status = "okay";
+panel-flags = <1>;
+enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+ anx_1_in: endpoint {
+remote-endpoint = <&mipi_dsi>;
+ };
+};
+
+port@2 {
+ reg = <2>;
+ anx_1_out: endpoint {
+remote-endpoint = <&panel_in>;
+ };
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 3/7] dt-bindings: display: bridge: Repurpose lvds-encoder
Hello Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:38
> Subject: Re: [PATCH v3 3/7] dt-bindings: display: bridge: Repurpose
> lvds-encoder
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:10:59PM +, Fabrizio Castro wrote:
> > In an effort to repurpose lvds-encoder.c to also serve the
> > function of LVDS decoders, we ended up defining a new "generic"
> > compatible string, therefore adapt the dt-bindings to fit the
> > new purpose.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * Extracted conversion to lvds-codec as per Rob's comment
> > v1->v2:
> > * Converted to dt-schema as per Neil's comment
> > ---
> > .../bindings/display/bridge/lvds-codec.yaml| 120
> > +
> > .../bindings/display/bridge/lvds-transmitter.yaml | 91
>
> -M1 would also help a lot here.
Will do
>
> > 2 files changed, 120 insertions(+), 91 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > delete mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > new file mode 100644
> > index 000..3ebdf96
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > @@ -0,0 +1,120 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Transparent LVDS encoders and LVDS decoders
>
> s/LVDS decoders/decoders/ ?
Will replace
>
> > +
> > +maintainers:
> > + - Laurent Pinchart
> > +
> > +description: |
> > + This binding supports transparent LVDS encoders and LVDS decoders that
> > don't
>
> Same here.
Will do
Thanks,
Fab
>
> Reviewed-by: Laurent Pinchart
>
> > + require any configuration.
> > +
> > + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple
> > + incompatible data link layers have been used over time to transmit image
> > data
> > + to LVDS panels. This binding targets devices compatible with the
> > following
> > + specifications only.
> > +
> > + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
> > February
> > + 1999 (Version 1.0), Japan Electronic Industry Development Association
> > (JEIDA)
> > + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
> > + Semiconductor
> > + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
> > + Electronics Standards Association (VESA)
> > +
> > + Those devices have been marketed under the FPD-Link and FlatLink brand
> > names
> > + among others.
> > +
> > +properties:
> > + compatible:
> > +description: |
> > + Any encoder or decoder compatible with this generic binding, but with
> > + additional properties not listed here, must define its own binding
> > and
> > + list a device specific compatible first followed by the generic
> > compatible
> > +enum:
> > + - lvds-encoder # for LVDS encoders
> > + - lvds-decoder # for LVDS decoders
> > +
> > + ports:
> > +type: object
> > +description: |
> > + This device has two video ports. Their connections are modeled using
> > the
> > + OF graph bindings specified in
> > Documentation/devicetree/bindings/graph.txt
> > +properties:
> > + port@0:
> > +type: object
> > +description: |
> > + With LVDS encoders port 0 is for parallel input
> > + With LVDS decoders port 0 is for LVDS input
> > +
> > + port@1:
> > +type: object
> > +description: |
> > + With LVDS encoders port 1 is for LVDS output
> > + With LVDS decoders port 1 is for parallel output
> > +
> > +required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - ports
> > +
> > +examples:
> > + - |
> > +lvds-encoder {
> > + compatible = "lvds-encoder";
> > +
> > + ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > + reg = <0>;
> > +
> > + lvds_enc_in: endpoint {
> > +remote-endpoint = <&display_out_rgb>;
> > + };
> > +};
> > +
> > +port@1 {
> > + reg = <1>;
> > +
> > + lvds_enc_out: endpoint {
> > +remote-endpoint = <&lvds_panel_in>;
> > + };
> > +};
> > + };
> > +};
> > +
> > + - |
> > +lvds-decoder {
> > + compatible = "lvds-decoder";
> > +
> > + ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +
Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
On Fri, Nov 08, 2019 at 07:56:25AM -0700, Jeffrey Hugo wrote:
> On Thu, Nov 7, 2019 at 7:03 PM Rob Clark wrote:
> >
> > On Thu, Nov 7, 2019 at 9:40 AM Jeffrey Hugo
> > wrote:
> > >
> > > On Thu, Nov 7, 2019 at 9:17 AM Rob Clark wrote:
> > > >
> > > > On Thu, Nov 7, 2019 at 3:10 AM Brian Masney
> > > > wrote:
> > > > >
> > > > > On Wed, Nov 06, 2019 at 08:58:59AM -0800, Rob Clark wrote:
> > > > > > On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Nov 6, 2019 at 9:30 AM Rob Clark
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > > > > > > > > > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney
> > > > > > > > > > wrote:
> > > > > > > > > > > The 'pp done time out' errors go away if I revert the
> > > > > > > > > > > following three
> > > > > > > > > > > commits:
> > > > > > > > > > >
> > > > > > > > > > > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > > > > > > > > > > d934a712c5e6 ("drm/msm: add atomic traces")
> > > > > > > > > > > 2d99ced787e3 ("drm/msm: async commit support")
> > > > > > > > > > >
> > > > > > > > > > > I reverted the first one to fix a compiler error, and the
> > > > > > > > > > > second one so
> > > > > > > > > > > that the last patch can be reverted without any merge
> > > > > > > > > > > conflicts.
> > > > > > > > > > >
> > > > > > > > > > > I see that crtc_flush() calls mdp5_ctl_commit(). I tried
> > > > > > > > > > > to use
> > > > > > > > > > > crtc_flush_all() in mdp5_flush_commit() and the contents
> > > > > > > > > > > of the frame
> > > > > > > > > > > buffer dance around the screen like its out of sync. I
> > > > > > > > > > > renamed
> > > > > > > > > > > crtc_flush_all() to mdp5_crtc_flush_all() and removed the
> > > > > > > > > > > static
> > > > > > > > > > > declaration. Here's the relevant part of what I tried:
> > > > > > > > > > >
> > > > > > > > > > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > > > > > > > > @@ -171,7 +171,15 @@ static void
> > > > > > > > > > > mdp5_prepare_commit(struct msm_kms *kms, struct
> > > > > > > > > > > drm_atomic_state *st
> > > > > > > > > > >
> > > > > > > > > > > static void mdp5_flush_commit(struct msm_kms *kms,
> > > > > > > > > > > unsigned crtc_mask)
> > > > > > > > > > > {
> > > > > > > > > > > - /* TODO */
> > > > > > > > > > > + struct mdp5_kms *mdp5_kms =
> > > > > > > > > > > to_mdp5_kms(to_mdp_kms(kms));
> > > > > > > > > > > + struct drm_crtc *crtc;
> > > > > > > > > > > +
> > > > > > > > > > > + for_each_crtc_mask(mdp5_kms->dev, crtc,
> > > > > > > > > > > crtc_mask) {
> > > > > > > > > > > + if (!crtc->state->active)
> > > > > > > > > > > + continue;
> > > > > > > > > > > +
> > > > > > > > > > > + mdp5_crtc_flush_all(crtc);
> > > > > > > > > > > + }
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > Any tips would be appreciated.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I think this is along the lines of what we need to enable
> > > > > > > > > > async commit
> > > > > > > > > > for mdp5 (but also removing the flush from the
> > > > > > > > > > atomic-commit path)..
> > > > > > > > > > the principle behind the async commit is to do all the
> > > > > > > > > > atomic state
> > > > > > > > > > commit normally, but defer writing the flush bits. This
> > > > > > > > > > way, if you
> > > > > > > > > > get another async update before the next vblank, you just
> > > > > > > > > > apply it
> > > > > > > > > > immediately instead of waiting for vblank.
> > > > > > > > > >
> > > > > > > > > > But I guess you are on a command mode panel, if I remember?
> > > > > > > > > > Which is
> > > > > > > > > > a case I didn't have a way to test. And I'm not entirely
> > > > > > > > > > about how
> > > > > > > > > > kms_funcs->vsync_time() should be implemented for cmd mode
> > > > > > > > > > panels.
> > > > > > > > >
> > > > > > > > > Yes, this is a command-mode panel and there's no hardware
> > > > > > > > > frame counter
> > > > > > > > > available. The key to getting the display working on this
> > > > > > > > > phone was this
> > > > > > > > > patch:
> > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> > > > > > > > >
> > > > > > > > > > That all said, I think we should first fix what is broken,
> > > > > > > > > > before
> > > > > > > > > > worrying about extending async commit support to mdp5..
> > > > > > > > > > which
> > > > > > > > > > shouldn't hit the async==true path, due to not implementing
> > > > > > > > > > kms_funcs->vsync_time().
> > > > > > > > > >
> > > > > > > > > > What I think is go
[PATCH v3 0/2] Add initial support for slimport anx7625
Hi all, The following series add initial support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the initial version, any mistakes, please let me know, I will fix it in the next series. Thanks, Xin Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver .../bindings/display/bridge/anx7625.yaml | 91 + drivers/gpu/drm/bridge/Makefile|2 +- drivers/gpu/drm/bridge/analogix/Kconfig|6 + drivers/gpu/drm/bridge/analogix/Makefile |1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 2042 drivers/gpu/drm/bridge/analogix/anx7625.h | 406 6 files changed, 2547 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7625.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/9] backlight: gpio: simplify the driver
pon., 4 lis 2019 o 10:22 Bartosz Golaszewski napisał(a):
>
> pt., 1 lis 2019 o 16:39 Jacopo Mondi napisał(a):
> >
> > Hello,
> > as promised...
> >
> > On Fri, Nov 01, 2019 at 08:58:03AM +, Lee Jones wrote:
> > > On Thu, 24 Oct 2019, Jacopo Mondi wrote:
> > >
> > > > Hello,
> > > >
> > > > On Thu, Oct 24, 2019 at 07:47:26AM +0100, Lee Jones wrote:
> > > > > On Wed, 23 Oct 2019, Daniel Thompson wrote:
> > > > >
> > > > > > On Tue, Oct 22, 2019 at 11:29:54AM +0200, Bartosz Golaszewski wrote:
> > > > > > > wt., 22 paź 2019 o 10:36 Bartosz Golaszewski
> > > > > > > napisał(a):
> > > > > > > >
> > > > > > > > From: Bartosz Golaszewski
> > > > > > > >
> > > > > > > > While working on my other series related to gpio-backlight[1] I
> > > > > > > > noticed
> > > > > > > > that we could simplify the driver if we made the only user of
> > > > > > > > platform
> > > > > > > > data use GPIO lookups and device properties. This series tries
> > > > > > > > to do
> > > > > > > > that.
> > > > > > > >
> > > > > > > > First two patches contain minor fixes. Third patch makes the
> > > > > > > > driver
> > > > > > > > explicitly drive the GPIO line. Fourth patch adds all necessary
> > > > > > > > data
> > > > > > > > structures to ecovec24. Patch 5/9 unifies much of the code for
> > > > > > > > both
> > > > > > > > pdata and non-pdata cases. Patches 6-7/9 remove unused platform
> > > > > > > > data
> > > > > > > > fields. Last two patches contain additional improvements for
> > > > > > > > the GPIO
> > > > > > > > backlight driver while we're already modifying it.
> > > > > > > >
> > > > > > > > I don't have access to this HW but hopefully this works. Only
> > > > > > > > compile
> > > > > > > > tested.
> > > > > > > >
> > > > > > > > [1] https://lkml.org/lkml/2019/6/25/900
> > > > > > > >
> > > > > > > > v1 -> v2:
> > > > > > > > - rebased on top of v5.3-rc1 and adjusted to the recent changes
> > > > > > > > from Andy
> > > > > > > > - added additional two patches with minor improvements
> > > > > > > >
> > > > > > > > v2 -> v3:
> > > > > > > > - in patch 7/7: used initializers to set values for pdata and
> > > > > > > > dev local vars
> > > > > > > >
> > > > > > > > v3 -> v4:
> > > > > > > > - rebased on top of v5.4-rc1
> > > > > > > > - removed changes that are no longer relevant after commit
> > > > > > > > ec665b756e6f
> > > > > > > > ("backlight: gpio-backlight: Correct initial power state
> > > > > > > > handling")
> > > > > > > > - added patch 7/7
> > > > > > > >
> > > > > > > > v4 -> v5:
> > > > > > > > - in patch 7/7: added a comment replacing the name of the
> > > > > > > > function being
> > > > > > > > pulled into probe()
> > > > > > > >
> > > > > > > > v5 -> v6:
> > > > > > > > - added a patch making the driver explicitly set the direction
> > > > > > > > of the GPIO
> > > > > > > > to output
> > > > > > > > - added a patch removing a redundant newline
> > > > > > > >
> > > > > > > > v6 -> v7:
> > > > > > > > - renamed the function calculating the new GPIO value for
> > > > > > > > status update
> > > > > > > > - collected more tags
> > > > > > > >
> > > > > > > > Bartosz Golaszewski (9):
> > > > > > > > backlight: gpio: remove unneeded include
> > > > > > > > backlight: gpio: remove stray newline
> > > > > > > > backlight: gpio: explicitly set the direction of the GPIO
> > > > > > > > sh: ecovec24: add additional properties to the backlight
> > > > > > > > device
> > > > > > > > backlight: gpio: simplify the platform data handling
> > > > > > > > sh: ecovec24: don't set unused fields in platform data
> > > > > > > > backlight: gpio: remove unused fields from platform data
> > > > > > > > backlight: gpio: use a helper variable for &pdev->dev
> > > > > > > > backlight: gpio: pull gpio_backlight_initial_power_state()
> > > > > > > > into probe
> > > > > > > >
> > > > > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 +++--
> > > > > > > > drivers/video/backlight/gpio_backlight.c | 128
> > > > > > > > +++
> > > > > > > > include/linux/platform_data/gpio_backlight.h | 3 -
> > > > > > > > 3 files changed, 69 insertions(+), 95 deletions(-)
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Lee, Daniel, Jingoo,
> > > > > > >
> > > > > > > Jacopo is travelling until November 1st and won't be able to test
> > > > > > > this
> > > > > > > again before this date. Do you think you can pick it up and in
> > > > > > > case
> > > > > > > anything's broken on SH, we can fix it after v5.5-rc1, so that it
> > > > > > > doesn't miss another merge window?
> > > > >
> > > > > November 1st (-rc6) will be fine.
> > > > >
> > > > > I'd rather apply it late-tested than early-non-tested.
> > > > >
> > > > > Hopefully Jacopo can prioritise testing this on Thursday or Friday,
> > > > > since Monday will be -rc7 which is really cutting it fine.
> > > >
> > > > I'll do my best, I'll get home Friday late afternoon :)
> > >
> > > Welcome home!
>
RE: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
Hi Geert,
Thank you for your feedback!
> From: Geert Uytterhoeven
> Sent: 08 November 2019 09:21
> Subject: Re: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
>
> Hi Fabrizio,
>
> On Mon, Nov 4, 2019 at 11:42 AM Fabrizio Castro
> wrote:
> > > From: Neil Armstrong
> > > Sent: 04 November 2019 09:18
> > > Subject: Re: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
> > >
> > > On 30/10/2019 14:43, Fabrizio Castro wrote:
> > > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > > not just LVDS encoders.
> > > > Instead of creating a new driver for addressing support for
> > > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > > good.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > > ---
> > > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > > drivers/gpu/drm/bridge/lvds-codec.c | 169
> > > > ++
> > > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > > ---
> > > > 4 files changed, 174 insertions(+), 160 deletions(-)
> > > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > index 3436297..9e75ca4e 100644
> > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> > > >
> > > > -config DRM_LVDS_ENCODER
> > > > - tristate "Transparent parallel to LVDS encoder support"
> > > > +config DRM_LVDS_CODEC
> > >
> > >
> > > I'm not CCed on other patches, but I'm pretty sure you should fix other
> > > Kconfig and defconfigs selecting this config in this patch to avoid
> > > breaking bisect.
> >
> > My understanding is that no defconfig and no other option refer directly to
> > DRM_LVDS_ENCODER, do you mind being a little bit
> more specific here?
>
> Sidenote: it looks like CONFIG_DRM_LVDS_ENCODER should have been enabled
> in shmobile_defconfig since commits 381ddfe478871588 ("drm: rcar-du:
> Hardcode encoders types to DRM_MODE_ENCODER_NONE") and 7160d57b6f81185c
> ("drm: bridge: lvds-encoder: Add thine,thc63lvdm83d compatible string"),
> to support thine,thc63lvdm83d in arch/arm/boot/dts/r8a7779-marzen.dts?
Interesting, well the defconfig patch from this series should help then.
Thanks,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hello Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 07 November 2019 20:35
> Subject: Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > not just LVDS encoders.
> > Instead of creating a new driver for addressing support for
> > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > good.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * No change
> > v1->v2:
> > * No change
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > drivers/gpu/drm/bridge/Makefile | 2 +-
> > drivers/gpu/drm/bridge/lvds-codec.c | 131
> > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > --
> > 4 files changed, 136 insertions(+), 160 deletions(-)
>
> It would help if you added the -M1 option to git-format-patch to detect
> the rename, the result would be easier to review.
Will do, thank you for the hint
>
> > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3436297..9e75ca4e 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> >
> > -config DRM_LVDS_ENCODER
> > - tristate "Transparent parallel to LVDS encoder support"
> > +config DRM_LVDS_CODEC
> > + tristate "Transparent LVDS encoders and decoders support"
> > depends on OF
> > select DRM_KMS_HELPER
> > select DRM_PANEL_BRIDGE
> > help
> > - Support for transparent parallel to LVDS encoders that don't require
> > - any configuration.
> > + Support for transparent LVDS encoders and LVDS decoders that don't
> > + require any configuration.
> >
> > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf..8a9178a 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,7 +2,7 @@
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > megachips-stdp-ge-b850v3-fw.o
> > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > new file mode 100644
> > index 000..d57a8eb
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -0,0 +1,131 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2019 Renesas Electronics Corporation
> > + * Copyright (C) 2016 Laurent Pinchart
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +struct lvds_codec {
> > + struct drm_bridge bridge;
> > + struct drm_bridge *panel_bridge;
> > + struct gpio_desc *powerdown_gpio;
> > +};
> > +
> > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec, bridge);
> > +
> > + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> > +bridge);
> > +}
> > +
> > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec, bridge);
> > +
> > + if (lvds_codec->powerdown_gpio)
> > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
> > +}
> > +
> > +static void lvds_codec_disable(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec, bridge);
> > +
> > + if (lvds_codec->powerdown_gpio)
> > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
> > +}
> > +
> > +static struct drm_bridge_funcs funcs = {
> > + .attach = lvds_codec_attach,
> > + .enable = lvds_codec_enable,
> > + .disable = lvds_codec_disable,
> > +};
> > +
> > +static int lvds_codec_probe(struct plat
Re: [PATCH 0/3] allow DRM drivers to limit creation of blobs
On Sat, Nov 9, 2019 at 1:01 AM wrote: > > On 2019-11-08 03:34, Daniel Vetter wrote: > > On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote: > >> Fuzzers used in Android compliance testing repeatedly call the > >> create blob IOCTL which eventually exhausts the system memory. > >> This series adds a hook which allows drivers to impose their own > >> limitations on the size and/or number of blobs created. > > > > Pretty sure this isn't just a problem for msm/dpu alone, why this very > > limited approach? > > > I'm not familiar enough with the blob requirements for other > vendor's drivers to impose any restrictions on them. The idea > was to provide the hook for vendors to implement their own > checks. Support for msm/mdp* drivers will be added in v2 if this > approach is acceptable. Yeah, but I don't think different limits (and then maybe different tunables for these different limits) on drivers isn't a great idea. Plus I thought this kind of stuff was supposed to be catched by the kernel memory cgroup controller. Does that not work? The blob stuff is maybe a bit too direct way to allocate kernel memory, but there's many others I've thought. This all just feels a lot like busywork to check an android compliance checkbox, without really digging into the underlying problem and fixing it for real. One approach that would work I think would be: - Extended the blob property type to have min/max size (we might need a range for some), set it for all current blob properties. To do that we'd need to create a new property creation function for blobs, which takes those limits. There's not a hole lot of them, so should be doable. - In the create blob function we walk all property (or book-keep that somewhere) and check the blob isn't too big. - We also validate the size when setting the property, at least some of that code from various places. I think this would actually improve the situation here, instead of whack-a-mole. The cheaper cope-out would be if we simply limit the total property size to something big enough, but not unlimited, like 16MB or something like that. > > Also, why are your fuzzers not also allocating enormous amounts of gem > > buffers, which will also exhaust memory eventually? > > Excellent question... This will likely come in a follow-up series. Would be good to know that, so we can solve this for real, not just a one-off for the compliance checkbox. Also really wondering why cgroups doesn't catch this. -Daniel > > > -Daniel > > > >> > >> Steve Cohen (3): > >> drm: add driver hook for create blob limitations > >> drm/msm: add support for createblob_check driver hook > >> drm/msm/dpu: check blob limitations during create blob ioctl > >> > >> drivers/gpu/drm/drm_property.c | 7 +++ > >> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 ++ > >> drivers/gpu/drm/msm/msm_drv.c | 25 > >> + > >> drivers/gpu/drm/msm/msm_kms.h | 1 + > >> include/drm/drm_drv.h | 9 + > >> 5 files changed, 56 insertions(+) > >> > >> -- > >> The Qualcomm Innovation Center, Inc. is a member of the 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument
drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
a video= argument over calculating our own timings for the user specified
mode using CVT or GTF.
But userspace code which is auto-configuring the mode may want to know that
the user has specified that mode on the kernel commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.
This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_probe_helper.c | 2 ++
include/drm/drm_modes.h| 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index ef2c468205a2..4fed64be11f9 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -157,6 +157,8 @@ static int drm_helper_probe_add_cmdline_mode(struct
drm_connector *connector)
continue;
}
+ /* Mark the matching mode as being preferred by the user */
+ mode->type |= DRM_MODE_TYPE_USERDEF;
return 0;
}
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index e946e20c61d8..c7efb7487e9b 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -256,7 +256,8 @@ struct drm_display_mode {
* - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
*them really. Drivers must set this bit for all modes they create
*and expose to userspace.
-* - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
+* - DRM_MODE_TYPE_USERDEF: Mode defined or selected via the kernel
+*command line.
*
* Plus a big list of flags which shouldn't be used at all, but are
* still around since these flags are also used in the userspace ABI.
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #170 from Peter Hercek --- Maybe this helps since there is a stack trace. GUI stopped to respond so I shut it down over ssh. A kernel crash during the shutdown on 5.3.6-arch1-1-ARCH even when amdgpu.dpm=0. That is the option which is supposed to work. It has both the patch and also amdgpu.dpm=0. Nov 04 17:38:58 phnm kernel: [ cut here ] Nov 04 17:38:58 phnm kernel: WARNING: CPU: 6 PID: 640 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5804 amdgpu_dm_atomic_commit_tail.cold+0x82/0xed [amdgpu] Nov 04 17:38:58 phnm kernel: Modules linked in: fuse xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter tun bridge cfg80211 rfkill 8021q garp mrp stp llc intel_rapl_msr intel_rapl_common amdgpu x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel hid_microsoft radeon mousedev input_leds joydev ff_memless kvm gpu_sched snd_hda_codec_realtek snd_hda_codec_generic i2c_algo_bit irqbypass ledtrig_audio ttm crct10dif_pclmul snd_hda_intel crc32_pclmul hid_generic ghash_clmulni_intel cdc_acm drm_kms_helper snd_hda_codec aesni_intel usbhid iTCO_wdt iTCO_vendor_support snd_hda_core wmi_bmof aes_x86_64 hid crypto_simd cryptd mxm_wmi snd_hwdep glue_helper drm intel_cstate snd_pcm agpgart r8169 syscopyarea intel_uncore sysfillrect realtek sysimgblt snd_timer pcspkr i2c_i801 fb_sys_fops e1000e intel_rapl_perf Nov 04 17:38:58 phnm kernel: mei_me snd libphy mei soundcore lpc_ich wmi evdev mac_hid sg ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 crc32c_intel firewire_ohci xhci_pci xhci_hcd firewire_core ehci_pci crc_itu_t ehci_hcd sr_mod cdrom sd_mod ahci libahci libata scsi_mod Nov 04 17:38:58 phnm kernel: CPU: 6 PID: 640 Comm: Xorg Not tainted 5.3.6-arch1-1-ARCH #1 Nov 04 17:38:58 phnm kernel: Hardware name: System manufacturer System Product Name/P9X79, BIOS 4502 10/15/2013 Nov 04 17:38:58 phnm kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail.cold+0x82/0xed [amdgpu] Nov 04 17:38:58 phnm kernel: Code: c7 c7 08 1e db c0 e8 0f 59 a0 db 0f 0b 41 83 7c 24 08 00 0f 85 92 ff f1 ff e9 ad ff f1 ff 48 c7 c7 08 1e db c0 e8 f0 58 a0 db <0f> 0b e9 32 f5 f1 ff 48 8b 85 00 fd ff ff 4c 89 f2 48 c7 c6 0d 0f Nov 04 17:38:58 phnm kernel: RSP: 0018:a98c410475a0 EFLAGS: 00010046 Nov 04 17:38:58 phnm kernel: RAX: 0024 RBX: 894125e06000 RCX: Nov 04 17:38:58 phnm kernel: RDX: RSI: 0003 RDI: Nov 04 17:38:58 phnm kernel: RBP: a98c410478c0 R08: 16b622fb648e R09: 9deb3254 Nov 04 17:38:58 phnm kernel: R10: 0616 R11: 0001d890 R12: 0286 Nov 04 17:38:58 phnm kernel: R13: 8940f30b0400 R14: 894129c2 R15: 894075ba6a00 Nov 04 17:38:58 phnm kernel: FS: 7fbf9c35c500() GS:89413fb8() knlGS: Nov 04 17:38:58 phnm kernel: CS: 0010 DS: ES: CR0: 80050033 Nov 04 17:38:58 phnm kernel: CR2: 559991d31420 CR3: 00082a644002 CR4: 000606e0 Nov 04 17:38:58 phnm kernel: Call Trace: Nov 04 17:38:58 phnm kernel: ? commit_tail+0x3c/0x70 [drm_kms_helper] Nov 04 17:38:58 phnm kernel: commit_tail+0x3c/0x70 [drm_kms_helper] Nov 04 17:38:58 phnm kernel: drm_atomic_helper_commit+0x108/0x110 [drm_kms_helper] Nov 04 17:38:58 phnm kernel: drm_client_modeset_commit_atomic+0x1e8/0x200 [drm] Nov 04 17:38:58 phnm kernel: drm_client_modeset_commit_force+0x50/0x150 [drm] Nov 04 17:38:58 phnm kernel: drm_fb_helper_pan_display+0xc2/0x200 [drm_kms_helper] Nov 04 17:38:58 phnm kernel: fb_pan_display+0x83/0x100 Nov 04 17:38:58 phnm kernel: fb_set_var+0x1e8/0x3d0 Nov 04 17:38:58 phnm kernel: fbcon_blank+0x1dd/0x290 Nov 04 17:38:58 phnm kernel: do_unblank_screen+0x98/0x130 Nov 04 17:38:58 phnm kernel: vt_ioctl+0xeff/0x1290 Nov 04 17:38:58 phnm kernel: tty_ioctl+0x37b/0x900 Nov 04 17:38:58 phnm kernel: ? preempt_count_add+0x68/0xa0 Nov 04 17:38:58 phnm kernel: do_vfs_ioctl+0x43d/0x6c0 Nov 04 17:38:58 phnm kernel: ? syscall_trace_enter+0x1f2/0x2e0 Nov 04 17:38:58 phnm kernel: ksys_ioctl+0x5e/0x90 Nov 04 17:38:58 phnm kernel: __x64_sys_ioctl+0x16/0x20 Nov 04 17:38:58 phnm kernel: do_syscall_64+0x5f/0x1c0 Nov 04 17:38:58 phnm kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Nov 04 17:38:58 phnm kernel: RIP: 0033:0x7fbf9d7b425b Nov 04 17:38:58 phnm kernel: Code: 0f 1e fa 48 8b 05 25 9c 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f5 9b 0c 00 f7 d8 64 89 01 48 Nov 04 17:38:58 phnm kernel: RSP: 002b:7ffe21162798 EFLAGS: 0246 ORIG_RAX: 0010 Nov 04 17:38:58 phnm kernel: RAX: ffda RBX: 55d93ebf5180 RCX: 7fbf9d7b425b Nov 04 17:38:58
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #169 from picar...@live.de --- I am using a Radeon VII with Arch Linux, a 1440p144hz and a 4K60Hz monitor, and I had similar crashes to the others here if I tried running the 1440p144hz monitor at 144hz, at 60hz it was stable. This behavior stayed all the way from kernel 5.0 up to 5.3, and only stopped when I started using kernel 5.4.0 (5.4.0-rc6-mainline right now). Now I can run it at 144hz without crashes. The driver still isn't working that well, as games seem very stuttery, but at least it doesn't crash anymore. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] drm/modes: parse_cmdline: Allow specifying stand-alone options
Some options which can be specified on the commandline, such as
margin_right=..., margin_left=..., etc. are applied not only to the
specified mode, but to all modes. As such it would be nice if the user
can simply say e.g.
video=HDMI-1:margin_right=14,margin_left=24,margin_bottom=36,margin_top=42
This commit refactors drm_mode_parse_command_line_for_connector() to
add support for this, and as a nice side effect also cleans up the
function a bit.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 92 +++
.../gpu/drm/selftests/drm_cmdline_selftests.h | 2 +
.../drm/selftests/test-drm_cmdline_parser.c | 50 ++
3 files changed, 86 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 72828fa9fc91..2e82603f5d0a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1677,17 +1677,6 @@ static const char * const drm_named_modes_whitelist[] = {
"PAL",
};
-static bool drm_named_mode_is_in_whitelist(const char *mode, unsigned int size)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++)
- if (!strncmp(mode, drm_named_modes_whitelist[i], size))
- return true;
-
- return false;
-}
-
/**
* drm_mode_parse_command_line_for_connector - parse command line modeline for
connector
* @mode_option: optional per connector mode option
@@ -1718,7 +1707,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
struct drm_cmdline_mode *mode)
{
const char *name;
- bool named_mode = false, parse_extras = false;
+ bool freestanding = false, parse_extras = false;
unsigned int bpp_off = 0, refresh_off = 0, options_off = 0;
unsigned int mode_end = 0;
const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
@@ -1738,49 +1727,14 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
name = mode_option;
- /*
-* This is a bit convoluted. To differentiate between the
-* named modes and poorly formatted resolutions, we need a
-* bunch of things:
-* - We need to make sure that the first character (which
-* would be our resolution in X) is a digit.
-* - If not, then it's either a named mode or a force on/off.
-* To distinguish between the two, we need to run the
-* extra parsing function, and if not, then we consider it
-* a named mode.
-*
-* If this isn't enough, we should add more heuristics here,
-* and matching unit-tests.
-*/
- if (!isdigit(name[0]) && name[0] != 'x') {
- unsigned int namelen = strlen(name);
-
- /*
-* Only the force on/off options can be in that case,
-* and they all take a single character.
-*/
- if (namelen == 1) {
- ret = drm_mode_parse_cmdline_extra(name, namelen, true,
- connector, mode);
- if (!ret)
- return true;
- }
-
- named_mode = true;
- }
-
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strchr(name, '-');
if (bpp_ptr)
bpp_off = bpp_ptr - name;
refresh_ptr = strchr(name, '@');
- if (refresh_ptr) {
- if (named_mode)
- return false;
-
+ if (refresh_ptr)
refresh_off = refresh_ptr - name;
- }
/* Locate the start of named options */
options_ptr = strchr(name, ',');
@@ -1800,23 +1754,45 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
parse_extras = true;
}
- if (named_mode) {
- if (mode_end + 1 > DRM_DISPLAY_MODE_LEN)
- return false;
+ /* First check for a named mode */
+ for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+ ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+ if (ret == mode_end) {
+ if (refresh_ptr)
+ return false; /* named + refresh is invalid */
- if (!drm_named_mode_is_in_whitelist(name, mode_end))
- return false;
+ strcpy(mode->name, drm_named_modes_whitelist[i]);
+ mode->specified = true;
+ break;
+ }
+ }
- strscpy(mode->name, name, mode_end + 1);
- } else {
+ /* No named mode? Check for a normal mode argument, e.g. 1024x768 */
+ if (!mode->specified && isdigit(name[0])) {
ret = drm_mode_parse_cmdline_
[PATCH 06/12] drm/modes: parse_cmdline: Add freestanding argument to drm_mode_parse_cmdline_options()
Add a freestanding function argument to drm_mode_parse_cmdline_options()
similar to how drm_mode_parse_cmdline_extra() already has this.
This is a preparation patch for allowing parsing of stand-alone options
without a mode before them, e.g.: video=HDMI-1:margin_right=14,...
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 25e8edf4cfb8..80cb247c83c7 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1592,6 +1592,7 @@ static int drm_mode_parse_cmdline_int(const char *delim,
unsigned int *int_ret)
}
static int drm_mode_parse_cmdline_options(const char *str,
+ bool freestanding,
const struct drm_connector *connector,
struct drm_cmdline_mode *mode)
{
@@ -1663,6 +1664,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
option = sep + 1;
} while (sep);
+ if (rotation && freestanding)
+ return -EINVAL;
+
mode->rotation_reflection = rotation;
return 0;
@@ -1855,6 +1859,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
if (options_ptr) {
ret = drm_mode_parse_cmdline_options(options_ptr + 1,
+false,
connector, mode);
if (ret)
return false;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] drm/connector: Hookup the new drm_cmdline_mode panel_orientation member
If the new video=... panel_orientation option is set for a connector, honor
it and setup a matching "panel orientation" property on the connector.
BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 40a985c411a6..591914f01cd4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -140,6 +140,13 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
connector->force = mode->force;
}
+ if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
+ DRM_INFO("setting connector %s panel_orientation to %d\n",
+connector->name, mode->panel_orientation);
+ drm_connector_set_panel_orientation(connector,
+ mode->panel_orientation);
+ }
+
DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n",
connector->name, mode->name,
mode->xres, mode->yres,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] drm/connector: Split out orientation quirk detection (v2)
From: Derek Basehore
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Hans de Goede (changes in v2):
Rename the function from drm_connector_init_panel_orientation_property
to drm_connector_set_panel_orientation[_with_quirk] and pass in the
panel-orientation to set.
Beside the rename, also make the function set the passed in value
only once, if the value was set before (to a value other then
DRM_MODE_PANEL_ORIENTATION_UNKNOWN) make any further set calls a no-op.
This change is preparation for allowing the user to override the
panel-orientation for any connector from the kernel commandline.
When the panel-orientation is overridden this way, then we must ignore
the panel-orientation detection done by the driver.
Signed-off-by: Derek Basehore
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 74 ++---
drivers/gpu/drm/i915/display/icl_dsi.c | 5 +-
drivers/gpu/drm/i915/display/intel_dp.c | 9 ++-
drivers/gpu/drm/i915/display/vlv_dsi.c | 5 +-
include/drm/drm_connector.h | 9 ++-
5 files changed, 71 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..40a985c411a6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1114,7 +1114,8 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* coordinates, so if userspace rotates the picture to adjust for
* the orientation it must also apply the same transformation to the
* touchscreen input coordinates. This property is initialized by calling
- * drm_connector_init_panel_orientation_property().
+ * drm_connector_set_panel_orientation() or
+ * drm_connector_set_panel_orientation_with_quirk()
*
* scaling mode:
* This property defines how a non-native mode is upscaled to the native
@@ -1986,38 +1987,41 @@ void drm_connector_set_vrr_capable_property(
EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
/**
- * drm_connector_init_panel_orientation_property -
- * initialize the connecters panel_orientation property
- * @connector: connector for which to init the panel-orientation property.
- * @width: width in pixels of the panel, used for panel quirk detection
- * @height: height in pixels of the panel, used for panel quirk detection
+ * drm_connector_set_panel_orientation - sets the connecter's panel_orientation
+ * @connector: connector for which to set the panel-orientation property.
+ * @panel_orientation: drm_panel_orientation value to set
+ *
+ * This function sets the connector's panel_orientation and attaches
+ * a "panel orientation" property to the connector.
*
- * This function should only be called for built-in panels, after setting
- * connector->display_info.panel_orientation first (if known).
+ * Calling this function on a connector where the panel_orientation has
+ * already been set is a no-op (e.g. the orientation has been overridden with
+ * a kernel commandline option).
*
- * This function will check for platform specific (e.g. DMI based) quirks
- * overriding display_info.panel_orientation first, then if panel_orientation
- * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
- * "panel orientation" property to the connector.
+ * It is allowed to call this function with a panel_orientation of
+ * DRM_MODE_PANEL_ORIENTATION_UNKNOWN, in which case it is a no-op.
*
* Returns:
* Zero on success, negative errno on failure.
*/
-int drm_connector_init_panel_orientation_property(
- struct drm_connector *connector, int width, int height)
+int drm_connector_set_panel_orientation(
+ struct drm_connector *connector,
+ enum drm_panel_orientation panel_orientation)
{
struct drm_device *dev = connector->dev;
struct drm_display_info *info = &connector->display_info;
struct drm_property *prop;
- int orientation_quirk;
- orientation_quirk = drm_get_panel_orientation_quirk(width, height);
- if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
- info->panel_orientation = orientation_quirk;
+ /* Already set? */
+ if (info->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+ return 0;
- if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+ /* Don't attach the property if the orientation is unknown */
+ if (panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
+ info->panel_orientation = panel_orientation;
+
prop = dev->mode_config.panel_orientation_property;
if (!prop) {
prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
@@ -2034,7 +2038,37 @@ int drm_connector_init_panel_orientation_property(
[PATCH 07/12] drm/modes: parse_cmdline: Set bpp/refresh_specified after successful parsing
drm_connector_get_cmdline_mode() calls
drm_mode_parse_command_line_for_connector() with &connector->cmdline_mode
as mode argument, so anything which we store in the mode arguments gets
kept even if we return false.
Avoid storing a possibly false-postive bpp/refresh_specified setting
in connector->cmdline_mode by moving the setting of these to after
successful parsing of the bpp/refresh parts of the video= argument.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 80cb247c83c7..72828fa9fc91 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1771,10 +1771,8 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strchr(name, '-');
- if (bpp_ptr) {
+ if (bpp_ptr)
bpp_off = bpp_ptr - name;
- mode->bpp_specified = true;
- }
refresh_ptr = strchr(name, '@');
if (refresh_ptr) {
@@ -1782,7 +1780,6 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
return false;
refresh_off = refresh_ptr - name;
- mode->refresh_specified = true;
}
/* Locate the start of named options */
@@ -1825,6 +1822,8 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
ret = drm_mode_parse_cmdline_bpp(bpp_ptr, &bpp_end_ptr, mode);
if (ret)
return false;
+
+ mode->bpp_specified = true;
}
if (refresh_ptr) {
@@ -1832,6 +1831,8 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
&refresh_end_ptr, mode);
if (ret)
return false;
+
+ mode->refresh_specified = true;
}
/*
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] drm/modes: parse_cmdline: Rework drm_mode_parse_cmdline_options()
Refactor drm_mode_parse_cmdline_options() so that it takes a pointer
to the first option, rather then a pointer to the ',' before the first
option.
This is a preparation patch for allowing parsing of stand-alone options
without a mode before them, e.g.: video=HDMI-1:margin_right=14,...
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f49401124727..25e8edf4cfb8 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1591,23 +1591,21 @@ static int drm_mode_parse_cmdline_int(const char
*delim, unsigned int *int_ret)
return 0;
}
-static int drm_mode_parse_cmdline_options(const char *str, size_t len,
+static int drm_mode_parse_cmdline_options(const char *str,
const struct drm_connector *connector,
struct drm_cmdline_mode *mode)
{
unsigned int deg, margin, rotation = 0;
- const char *sep = str;
+ const char *delim, *option, *sep;
- while ((sep = strchr(sep, ','))) {
- const char *delim, *option;
-
- option = sep + 1;
+ option = str;
+ do {
delim = strchr(option, '=');
if (!delim) {
delim = strchr(option, ',');
if (!delim)
- delim = str + len;
+ delim = option + strlen(option);
}
if (!strncmp(option, "rotate", delim - option)) {
@@ -1661,8 +1659,9 @@ static int drm_mode_parse_cmdline_options(const char
*str, size_t len,
} else {
return -EINVAL;
}
- sep = delim;
- }
+ sep = strchr(delim, ',');
+ option = sep + 1;
+ } while (sep);
mode->rotation_reflection = rotation;
@@ -1855,9 +1854,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
}
if (options_ptr) {
- int len = strlen(name) - (options_ptr - name);
-
- ret = drm_mode_parse_cmdline_options(options_ptr, len,
+ ret = drm_mode_parse_cmdline_options(options_ptr + 1,
connector, mode);
if (ret)
return false;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/12] drm/modes: parse_cmdline: Remove some unnecessary code
Remove 2 bits of dead-code:
1) drm_mode_parse_command_line_for_connector() always gets called with a
zero-ed drm_cmdline_mode struct and assumes so in most places, so there is
no reason to set mode->specified to false if no mode_option is present.
2) fb_get_options() will return fb_mode_option if no video=
argument is present on the kernel commandline, so there is no need to also
do this in drm_mode_parse_command_line_for_connector() as our only caller
uses fb_get_options() to get the mode_option argument.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 119fed7ab815..0bf3cb8c08ff 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1747,15 +1747,8 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
-#ifdef CONFIG_FB
if (!mode_option)
- mode_option = fb_mode_option;
-#endif
-
- if (!mode_option) {
- mode->specified = false;
return false;
- }
name = mode_option;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] drm/modes: parse_cmdline: Add support for specifying panel_orientation
Sometimes we want to override a connector's panel_orientation from the
kernel commandline. Either for testing and for special cases, e.g. a kiosk
like setup which uses a TV mounted in portrait mode.
Users can already specify a "rotate" option through a video= kernel cmdline
option. But that only supports 0/180 degrees (see drm_client_modeset TODO)
and only works for in kernel modeset clients, not for userspace kms users.
The "panel-orientation" connector property OTOH does support 90/270 degrees
as it leaves dealing with the rotation up to userspace and this does work
for userspace kms clients (at least those which support this property).
BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Signed-off-by: Hans de Goede
---
Documentation/fb/modedb.rst | 3 ++
drivers/gpu/drm/drm_modes.c | 32 +++
.../gpu/drm/selftests/drm_cmdline_selftests.h | 1 +
.../drm/selftests/test-drm_cmdline_parser.c | 22 +
include/drm/drm_connector.h | 8 +
5 files changed, 66 insertions(+)
diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
index 9c4e3fd39e6d..624d08fd2856 100644
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@ -65,6 +65,9 @@ Valid options are::
- reflect_y (boolean): Perform an axial symmetry on the Y axis
- rotate (integer): Rotate the initial framebuffer by x
degrees. Valid values are 0, 90, 180 and 270.
+ - panel_orientation, one of "normal", "upside_down", "left_side_up", or
+"right_side_up". For KMS drivers only, this sets the "panel orientation"
+property on the kms connector as hint for kms users.
-
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 2e82603f5d0a..119fed7ab815 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1591,6 +1591,33 @@ static int drm_mode_parse_cmdline_int(const char *delim,
unsigned int *int_ret)
return 0;
}
+static int drm_mode_parse_panel_orientation(const char *delim,
+ struct drm_cmdline_mode *mode)
+{
+ const char *value;
+
+ if (*delim != '=')
+ return -EINVAL;
+
+ value = delim + 1;
+ delim = strchr(value, ',');
+ if (!delim)
+ delim = value + strlen(value);
+
+ if (!strncmp(value, "normal", delim - value))
+ mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+ else if (!strncmp(value, "upside_down", delim - value))
+ mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+ else if (!strncmp(value, "left_side_up", delim - value))
+ mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+ else if (!strncmp(value, "right_side_up", delim - value))
+ mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
static int drm_mode_parse_cmdline_options(const char *str,
bool freestanding,
const struct drm_connector *connector,
@@ -1657,6 +1684,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
return -EINVAL;
mode->tv_margins.bottom = margin;
+ } else if (!strncmp(option, "panel_orientation", delim -
option)) {
+ if (drm_mode_parse_panel_orientation(delim, mode))
+ return -EINVAL;
} else {
return -EINVAL;
}
@@ -1715,6 +1745,8 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int i, len, ret;
+ mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+
#ifdef CONFIG_FB
if (!mode_option)
mode_option = fb_mode_option;
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index aee92ac2cc21..ceac7af9a172 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -64,3 +64,4 @@ cmdline_test(drm_cmdline_test_bpp_extra_and_option)
cmdline_test(drm_cmdline_test_extra_and_option)
cmdline_test(drm_cmdline_test_freestanding_options)
cmdline_test(drm_cmdline_test_freestanding_force_e_and_options)
+cmdline_test(drm_cmdline_test_panel_orientation)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 8248d4aa5aaa..520f3e66a384 100644
--- a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -1092,6 +1092,28 @@ static int
drm_cmdline_test_
[PATCH 00/12] drm/modes: parse_cmdline: Add support for specifying panel_orientation on the kernel cmdline
Hi All, I've been thinking about adding support for overriding a connector's panel-orientation from the kernel commandline from a while now. Both for testing and for special cases, e.g. a kiosk like setup which uses a TV mounted in portrait mode. Then this plymouth merge-req came in: "Force display orientation using configuration file" https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83 Which was the trigger for me to actually do this. This turned out to be a bit more work then expected as I wanted users to be able to specify the new "panel_orientation" option as a freestanding option, without needing to prefix a resolution; and when working on that I stumbled over various things which could be improved in the cmdline parsing code. This patch-seet is the end result of all this. Amongst other tests, it has been tested with the test-drm_cmdline_parser.ko selftest and it adds some new tests to that in some of the patches. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/12] drm/modes: parse_cmdline: Fix possible reference past end of string
Before this commit, if the last option of a video=... option is for
example "rotate" without a "=" after it then delim will point to
the terminating 0 of the string, and value which is sets to
will point one position past the end of the string.
This commit fixes this by enforcing that the contents of delim equals '='
as it should be for options which take a value, this check is done in a
new drm_mode_parse_cmdline_int helper function which factors out the
common integer parsing code for all the options which take an int.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 68 -
1 file changed, 30 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 88232698d7a0..3c3c7435225f 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1568,11 +1568,34 @@ static int drm_mode_parse_cmdline_res_mode(const char
*str, unsigned int length,
return 0;
}
+static int drm_mode_parse_cmdline_int(const char *delim, unsigned int *int_ret)
+{
+ const char *value;
+ char *endp;
+
+ /*
+* delim must point to the '=', otherwise it is a syntax error and
+* if delim points to the terminating zero, then delim + 1 wil point
+* past the end of the string.
+*/
+ if (*delim != '=')
+ return -EINVAL;
+
+ value = delim + 1;
+ *int_ret = simple_strtol(value, &endp, 10);
+
+ /* Make sure we have parsed something */
+ if (endp == value)
+ return -EINVAL;
+
+ return 0;
+}
+
static int drm_mode_parse_cmdline_options(char *str, size_t len,
const struct drm_connector *connector,
struct drm_cmdline_mode *mode)
{
- unsigned int rotation = 0;
+ unsigned int deg, margin, rotation = 0;
char *sep = str;
while ((sep = strchr(sep, ','))) {
@@ -1588,13 +1611,7 @@ static int drm_mode_parse_cmdline_options(char *str,
size_t len,
}
if (!strncmp(option, "rotate", delim - option)) {
- const char *value = delim + 1;
- unsigned int deg;
-
- deg = simple_strtol(value, &sep, 10);
-
- /* Make sure we have parsed something */
- if (sep == value)
+ if (drm_mode_parse_cmdline_int(delim, °))
return -EINVAL;
switch (deg) {
@@ -1619,57 +1636,32 @@ static int drm_mode_parse_cmdline_options(char *str,
size_t len,
}
} else if (!strncmp(option, "reflect_x", delim - option)) {
rotation |= DRM_MODE_REFLECT_X;
- sep = delim;
} else if (!strncmp(option, "reflect_y", delim - option)) {
rotation |= DRM_MODE_REFLECT_Y;
- sep = delim;
} else if (!strncmp(option, "margin_right", delim - option)) {
- const char *value = delim + 1;
- unsigned int margin;
-
- margin = simple_strtol(value, &sep, 10);
-
- /* Make sure we have parsed something */
- if (sep == value)
+ if (drm_mode_parse_cmdline_int(delim, &margin))
return -EINVAL;
mode->tv_margins.right = margin;
} else if (!strncmp(option, "margin_left", delim - option)) {
- const char *value = delim + 1;
- unsigned int margin;
-
- margin = simple_strtol(value, &sep, 10);
-
- /* Make sure we have parsed something */
- if (sep == value)
+ if (drm_mode_parse_cmdline_int(delim, &margin))
return -EINVAL;
mode->tv_margins.left = margin;
} else if (!strncmp(option, "margin_top", delim - option)) {
- const char *value = delim + 1;
- unsigned int margin;
-
- margin = simple_strtol(value, &sep, 10);
-
- /* Make sure we have parsed something */
- if (sep == value)
+ if (drm_mode_parse_cmdline_int(delim, &margin))
return -EINVAL;
mode->tv_margins.top = margin;
} else if (!strncmp(option, "margin_bottom", delim - option)) {
- const char *value = delim + 1;
- unsigned int margin;
-
- margin = simple_strtol(value, &sep, 10);
-
- /* Make sure we have parsed something */
- if (sep == value)
[PATCH 04/12] drm/modes: parse_cmdline: Accept extras directly after mode combined with options
Before this commit it was impossible to combine an extra mode argument
specified directly after the resolution with an option, e.g.
video=HDMI-1:720x480e,rotate=180 would not work, either the "e" to force
enable would need to be dropped or the ",rotate=180", otherwise the
mode_option would not be accepted.
This commit fixes this by setting parse_extras to true in this case, so
that drm_mode_parse_cmdline_res_mode() parses the extra arguments directly
after the resolution.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 1 +
.../gpu/drm/selftests/drm_cmdline_selftests.h | 1 +
.../drm/selftests/test-drm_cmdline_parser.c | 24 +++
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a8aa7955fd45..f49401124727 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1794,6 +1794,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
mode_end = refresh_off;
} else if (options_ptr) {
mode_end = options_off;
+ parse_extras = true;
} else {
mode_end = strlen(name);
parse_extras = true;
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index ca1fc7a78953..003e2c3ffc39 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -61,3 +61,4 @@ cmdline_test(drm_cmdline_test_margin_options)
cmdline_test(drm_cmdline_test_multiple_options)
cmdline_test(drm_cmdline_test_invalid_option)
cmdline_test(drm_cmdline_test_bpp_extra_and_option)
+cmdline_test(drm_cmdline_test_extra_and_option)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 5b8dea922257..bc4db017e993 100644
--- a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -1018,6 +1018,30 @@ static int drm_cmdline_test_bpp_extra_and_option(void
*ignored)
return 0;
}
+static int drm_cmdline_test_extra_and_option(void *ignored)
+{
+ struct drm_cmdline_mode mode = { };
+
+
FAIL_ON(!drm_mode_parse_command_line_for_connector("720x480e,rotate=180",
+ &no_connector,
+ &mode));
+ FAIL_ON(!mode.specified);
+ FAIL_ON(mode.xres != 720);
+ FAIL_ON(mode.yres != 480);
+ FAIL_ON(mode.rotation_reflection != DRM_MODE_ROTATE_180);
+
+ FAIL_ON(mode.refresh_specified);
+ FAIL_ON(mode.bpp_specified);
+
+ FAIL_ON(mode.rb);
+ FAIL_ON(mode.cvt);
+ FAIL_ON(mode.interlace);
+ FAIL_ON(mode.margins);
+ FAIL_ON(mode.force != DRM_FORCE_ON);
+
+ return 0;
+}
+
#include "drm_selftest.c"
static int __init test_drm_cmdline_init(void)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/12] drm/modes: parse_cmdline: Stop parsing extras after bpp / refresh at ', '
Before this commit it was impossible to add an extra mode argument after
a bpp or refresh specifier, combined with an option, e.g.
video=HDMI-1:720x480-24e,rotate=180 would not work, either the "e" to
force enable would need to be dropped or the ",rotate=180", otherwise
the mode_option would not be accepted.
This commit fixes this by fixing the length calculation if extras_ptr
is set to stop the extra parsing at the start of the options (stop at the
',' options_ptr points to).
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 10 ---
.../gpu/drm/selftests/drm_cmdline_selftests.h | 1 +
.../drm/selftests/test-drm_cmdline_parser.c | 26 +++
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 654d4b6fecb3..a8aa7955fd45 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1721,7 +1721,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
const char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
- int ret;
+ int i, len, ret;
#ifdef CONFIG_FB
if (!mode_option)
@@ -1841,9 +1841,11 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
else if (refresh_ptr)
extra_ptr = refresh_end_ptr;
- if (extra_ptr &&
- extra_ptr != options_ptr) {
- int len = strlen(name) - (extra_ptr - name);
+ if (extra_ptr) {
+ if (options_ptr)
+ len = options_ptr - extra_ptr;
+ else
+ len = strlen(extra_ptr);
ret = drm_mode_parse_cmdline_extra(extra_ptr, len, false,
connector, mode);
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index 6d61a0eb5d64..ca1fc7a78953 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -60,3 +60,4 @@ cmdline_test(drm_cmdline_test_vmirror)
cmdline_test(drm_cmdline_test_margin_options)
cmdline_test(drm_cmdline_test_multiple_options)
cmdline_test(drm_cmdline_test_invalid_option)
+cmdline_test(drm_cmdline_test_bpp_extra_and_option)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 013de9d27c35..5b8dea922257 100644
--- a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -992,6 +992,32 @@ static int drm_cmdline_test_invalid_option(void *ignored)
return 0;
}
+static int drm_cmdline_test_bpp_extra_and_option(void *ignored)
+{
+ struct drm_cmdline_mode mode = { };
+
+
FAIL_ON(!drm_mode_parse_command_line_for_connector("720x480-24e,rotate=180",
+ &no_connector,
+ &mode));
+ FAIL_ON(!mode.specified);
+ FAIL_ON(mode.xres != 720);
+ FAIL_ON(mode.yres != 480);
+ FAIL_ON(mode.rotation_reflection != DRM_MODE_ROTATE_180);
+
+ FAIL_ON(mode.refresh_specified);
+
+ FAIL_ON(!mode.bpp_specified);
+ FAIL_ON(mode.bpp != 24);
+
+ FAIL_ON(mode.rb);
+ FAIL_ON(mode.cvt);
+ FAIL_ON(mode.interlace);
+ FAIL_ON(mode.margins);
+ FAIL_ON(mode.force != DRM_FORCE_ON);
+
+ return 0;
+}
+
#include "drm_selftest.c"
static int __init test_drm_cmdline_init(void)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] drm/modes: parse_cmdline: Make various char pointers const
We are not supposed to modify the passed in string, make char pointers
used in drm_mode_parse_cmdline_options() const char * where possible.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 3c3c7435225f..654d4b6fecb3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1591,15 +1591,15 @@ static int drm_mode_parse_cmdline_int(const char
*delim, unsigned int *int_ret)
return 0;
}
-static int drm_mode_parse_cmdline_options(char *str, size_t len,
+static int drm_mode_parse_cmdline_options(const char *str, size_t len,
const struct drm_connector *connector,
struct drm_cmdline_mode *mode)
{
unsigned int deg, margin, rotation = 0;
- char *sep = str;
+ const char *sep = str;
while ((sep = strchr(sep, ','))) {
- char *delim, *option;
+ const char *delim, *option;
option = sep + 1;
delim = strchr(option, '=');
@@ -1718,8 +1718,8 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
bool named_mode = false, parse_extras = false;
unsigned int bpp_off = 0, refresh_off = 0, options_off = 0;
unsigned int mode_end = 0;
- char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
- char *options_ptr = NULL;
+ const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
+ const char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int ret;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 William Casarin changed: What|Removed |Added CC|j...@jb55.com | --- Comment #226 from William Casarin --- (In reply to Marko Popovic from comment #222) > (In reply to William Casarin from comment #221) > > mesa 19.3.0-rc2 + RADV_PERFTEST=aco fixed this for me > > ACO should have no impact on SDMA. Firstly OpenGL still uses LLVM, and > OpenGL is the only one using SDMA in the first place, radv doesn't. So you > must be talking about some different kinds of hangs, probably the ring_gfx > types. you're right, I wasn't aware that this thread was only for sdma related hangs. The -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #35 from Daniel Suarez --- (In reply to Marko Popovic from comment #34) > (In reply to Daniel Suarez from comment #33) > > (In reply to Marko Popovic from comment #32) > > > (In reply to Daniel Suarez from comment #31) > > > > (In reply to Marko Popovic from comment #30) > > > > > (In reply to Daniel Suarez from comment #29) > > > > > > (In reply to Marko Popovic from comment #28) > > > > > > > I think this bug report can be closed now, Mesa 20 git basically > > > > > > > fixes radv > > > > > > > related ring_gfx hangs, there is still hang that happens in Citra > > > > > > > emulator > > > > > > > (ngg related) but AMD developers are aware of it so will probably > > > > > > > get fixed > > > > > > > too. > > > > > > > > > > > > Yeah.. "soon". Still waiting for them to fix bug 111481 > > > > > > > > > > SDMA hangs have nothing to do with ring_gfx hangs which were mostly > > > > > radv > > > > > related and are fixed now > > > > > > > > Still, I can't even play Vulkan titles reliably because the system > > > > constantly hangs even with the workarounds in the bug report. AMD really > > > > needs to fix them. > > > > > > Mesa 20.0 should fix Vulkan hangs for you, and with nodma SDMA is disabled > > > fully so you can't get any hangs that are SDMA related. > > > > That workaround delays the hangs af best, and I have gotten hangs from > > OpenGl Games and also by using amdvlk. > > > > Don't get me wrong I'm not saying this bug report shouldn't be closed, I'm > > just saying that you saying "soon" is very misleading. AMD hasn't still > > properly fixed bugs that lead to hangs by just watching Firefox, and it's > > been MONTHS. "soon" for them is months apperantly > > And where exactly did I say soon? My bad, I read "soon" instead of "too", apologies -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #34 from Marko Popovic --- (In reply to Daniel Suarez from comment #33) > (In reply to Marko Popovic from comment #32) > > (In reply to Daniel Suarez from comment #31) > > > (In reply to Marko Popovic from comment #30) > > > > (In reply to Daniel Suarez from comment #29) > > > > > (In reply to Marko Popovic from comment #28) > > > > > > I think this bug report can be closed now, Mesa 20 git basically > > > > > > fixes radv > > > > > > related ring_gfx hangs, there is still hang that happens in Citra > > > > > > emulator > > > > > > (ngg related) but AMD developers are aware of it so will probably > > > > > > get fixed > > > > > > too. > > > > > > > > > > Yeah.. "soon". Still waiting for them to fix bug 111481 > > > > > > > > SDMA hangs have nothing to do with ring_gfx hangs which were mostly radv > > > > related and are fixed now > > > > > > Still, I can't even play Vulkan titles reliably because the system > > > constantly hangs even with the workarounds in the bug report. AMD really > > > needs to fix them. > > > > Mesa 20.0 should fix Vulkan hangs for you, and with nodma SDMA is disabled > > fully so you can't get any hangs that are SDMA related. > > That workaround delays the hangs af best, and I have gotten hangs from > OpenGl Games and also by using amdvlk. > > Don't get me wrong I'm not saying this bug report shouldn't be closed, I'm > just saying that you saying "soon" is very misleading. AMD hasn't still > properly fixed bugs that lead to hangs by just watching Firefox, and it's > been MONTHS. "soon" for them is months apperantly And where exactly did I say soon? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #33 from Daniel Suarez --- (In reply to Marko Popovic from comment #32) > (In reply to Daniel Suarez from comment #31) > > (In reply to Marko Popovic from comment #30) > > > (In reply to Daniel Suarez from comment #29) > > > > (In reply to Marko Popovic from comment #28) > > > > > I think this bug report can be closed now, Mesa 20 git basically > > > > > fixes radv > > > > > related ring_gfx hangs, there is still hang that happens in Citra > > > > > emulator > > > > > (ngg related) but AMD developers are aware of it so will probably get > > > > > fixed > > > > > too. > > > > > > > > Yeah.. "soon". Still waiting for them to fix bug 111481 > > > > > > SDMA hangs have nothing to do with ring_gfx hangs which were mostly radv > > > related and are fixed now > > > > Still, I can't even play Vulkan titles reliably because the system > > constantly hangs even with the workarounds in the bug report. AMD really > > needs to fix them. > > Mesa 20.0 should fix Vulkan hangs for you, and with nodma SDMA is disabled > fully so you can't get any hangs that are SDMA related. That workaround delays the hangs af best, and I have gotten hangs from OpenGl Games and also by using amdvlk. Don't get me wrong I'm not saying this bug report shouldn't be closed, I'm just saying that you saying "soon" is very misleading. AMD hasn't still properly fixed bugs that lead to hangs by just watching Firefox, and it's been MONTHS. "soon" for them is months apperantly -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #32 from Marko Popovic --- (In reply to Daniel Suarez from comment #31) > (In reply to Marko Popovic from comment #30) > > (In reply to Daniel Suarez from comment #29) > > > (In reply to Marko Popovic from comment #28) > > > > I think this bug report can be closed now, Mesa 20 git basically fixes > > > > radv > > > > related ring_gfx hangs, there is still hang that happens in Citra > > > > emulator > > > > (ngg related) but AMD developers are aware of it so will probably get > > > > fixed > > > > too. > > > > > > Yeah.. "soon". Still waiting for them to fix bug 111481 > > > > SDMA hangs have nothing to do with ring_gfx hangs which were mostly radv > > related and are fixed now > > Still, I can't even play Vulkan titles reliably because the system > constantly hangs even with the workarounds in the bug report. AMD really > needs to fix them. Mesa 20.0 should fix Vulkan hangs for you, and with nodma SDMA is disabled fully so you can't get any hangs that are SDMA related. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #31 from Daniel Suarez --- (In reply to Marko Popovic from comment #30) > (In reply to Daniel Suarez from comment #29) > > (In reply to Marko Popovic from comment #28) > > > I think this bug report can be closed now, Mesa 20 git basically fixes > > > radv > > > related ring_gfx hangs, there is still hang that happens in Citra emulator > > > (ngg related) but AMD developers are aware of it so will probably get > > > fixed > > > too. > > > > Yeah.. "soon". Still waiting for them to fix bug 111481 > > SDMA hangs have nothing to do with ring_gfx hangs which were mostly radv > related and are fixed now Still, I can't even play Vulkan titles reliably because the system constantly hangs even with the workarounds in the bug report. AMD really needs to fix them. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #30 from Marko Popovic --- (In reply to Daniel Suarez from comment #29) > (In reply to Marko Popovic from comment #28) > > I think this bug report can be closed now, Mesa 20 git basically fixes radv > > related ring_gfx hangs, there is still hang that happens in Citra emulator > > (ngg related) but AMD developers are aware of it so will probably get fixed > > too. > > Yeah.. "soon". Still waiting for them to fix bug 111481 SDMA hangs have nothing to do with ring_gfx hangs which were mostly radv related and are fixed now -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #29 from Daniel Suarez --- (In reply to Marko Popovic from comment #28) > I think this bug report can be closed now, Mesa 20 git basically fixes radv > related ring_gfx hangs, there is still hang that happens in Citra emulator > (ngg related) but AMD developers are aware of it so will probably get fixed > too. Yeah.. "soon". Still waiting for them to fix bug 111481 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #225 from John Smith --- (In reply to Pierre-Eric Pelloux-Prayer from comment #141) > For radeonsi the AMD_DEBUG=nodma environment variable is a workaround until > we figure out a proper fix. Is this seriously what AMD calls "support"? No offense but this is ridiculous, this card has been out for four months and it still can't even browse firefox reliably, even after these "workarounds" and "patches". Then we waited two months for the drivers to even get properly released, and all this wait was for nothing because the drivers are useless, you can't even browse firefox or let alone play any actual games. What is the point of having open source drivers if they don't even work? Nvidia's GPUs have had day one support, and unlike AMD, "support" actually means the GPU works for something that is meaningful. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #224 from Marko Popovic --- (In reply to lptech1024 from comment #223) > Followup to #216: > > Fedora 31: Kernel 5.3.9, GNOME 3.34, Mesa 19.2.2, linux-firmware 20190923, > LLVM 9.0.0 > > The hang is 100% reproducible. > > It occurs running the Linux-native (Vulkan) version of Shadow of the Tomb > Raider (SotTR). I have never run SotTR under Proton/Wine, so that isn't a > confounding variable. > > The (unskippable) cutscene is for the Amazon River in Peru and occurs > anywhere between 15 seconds before the pilot is struck and the pilot is > struck. Even when the video hangs, you can usually hear fragments (sound > effects) of the game for a few seconds afterwords. > > I ran SotTR with vktrace and activated the Gnome (Wayland) overview to see > if there I could catch any relevant terminal output (none that I saw). The > game still had focus, so it continued playing. After the hang (when I > rebooted), there wasn't a vktrace file. I would assume this would be either > it didn't write it out due to the hang or it didn't have content to write. > > However, with it running visible in the overview (and a manual kernel > update), I got both ring gfx and sdma errors: > > Nov 07 [SNIP]:24 [SNIP] kernel: [drm] GPU recovery disabled. > Nov 07 [SNIP]:24 [SNIP] kernel: [drm] GPU recovery disabled. > Nov 07 [SNIP]:24 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* > Process information: process pid 0 thread pid 0 > Nov 07 [SNIP]:24 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* > Process information: process gnome-shell pid 1722 thread gnome-shel:cs0 pid > 1768 > Nov 07 [SNIP]:24 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* > ring sdma1 timeout, signaled seq=1049, emitted seq=1053 > Nov 07 [SNIP]:24 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* > ring sdma0 timeout, signaled seq=30017, emitted seq=30020 > Nov 07 [SNIP]:19 [SNIP] kernel: [drm] GPU recovery disabled. > Nov 07 [SNIP]:19 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* > Process information: process ShadowOfTheTomb pid 3890 thread WebViewRenderer > pid 4981 > Nov 07 [SNIP]:19 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* > ring gfx_0.0.0 timeout, signaled seq=75610, emitted seq=75612 > Nov 07 [SNIP]:19 [SNIP] kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] > *ERROR* Waiting for fences timed out or interrupted! > > As a workaround to proceed in the game, I downloaded the AMDVLD 2019.Q4.2 > .deb, extracted the contents, modified the JSON file (to point to the local > amdvlk64.so), and ran SotTR with the VK_ICD_FILENAMES variable set to the > AMDVLK JSON file. > > The AMDVLK graphics were terrible (significant percentage of random pixels > turning random colors, bad rendering of elements, etc), but I did not > experience any hangs during the cutscene. After reaching a known save point, > I switched back to mesa/RADV-llvm and haven't experienced a hang since > (haven't progressed that much further yet, but that's the only hang so far - > about 13% of the game has been completed). > > This would seem to point to a bug at least partially due to mesa/RADV-llvm. radv related hangs got fixed in Mesa 20 git series, this thread is more concerned with SDMA kernel-driver hangs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #28 from Marko Popovic --- I think this bug report can be closed now, Mesa 20 git basically fixes radv related ring_gfx hangs, there is still hang that happens in Citra emulator (ngg related) but AMD developers are aware of it so will probably get fixed too. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111922] amdgpu fails to resume on 5.2 kernel [regression]
https://bugs.freedesktop.org/show_bug.cgi?id=111922 --- Comment #7 from Pierre Ossman --- I finally got a build environment set up, and the winner is: > df8368be1382b442384507a5147c89978cd60702 is the first bad commit > commit df8368be1382b442384507a5147c89978cd60702 > Author: Nicholas Kazlauskas > Date: Wed Feb 27 12:56:36 2019 -0500 > > drm/amdgpu: Bump amdgpu version for per-flip plane tiling updates > > To help xf86-video-amdgpu and mesa know DC supports updating the > tiling attributes for a framebuffer per-flip. > > Cc: Michel Dänzer > Signed-off-by: Nicholas Kazlauskas > Acked-by: Alex Deucher > Reviewed-by: Marek Olšák > Signed-off-by: Alex Deucher > > :04 04 06a7975c484e74ebdaa4ccf9ee1dc5dac7a0abc9 > ab68acde511d49b3f96818066bba35f255ce1656 Mdrivers Which seems extremely odd given the contents of that commit. But I guess it makes userspace change behaviour in a way that provokes the bug? I don't think bisect will get me further. Help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: power: Convert Generic Power Domain bindings to json-schema
On 10/2/19 6:06 PM, Krzysztof Kozlowski wrote: > Convert Generic Power Domain bindings to DT schema format using > json-schema. The consumer bindings are split to separate file. > > Signed-off-by: Krzysztof Kozlowski For the media bindings: Acked-by: Hans Verkuil Thanks! Hans > > --- > > Changes since v1: > 1. Select all nodes for consumers, > 2. Remove from consumers duplicated properties with dt-schema, > 3. Fix power domain pattern, > 4. Remove unneeded types. > --- > .../devicetree/bindings/arm/arm,scmi.txt | 2 +- > .../devicetree/bindings/arm/arm,scpi.txt | 2 +- > .../bindings/arm/freescale/fsl,scu.txt| 2 +- > .../bindings/clock/clk-exynos-audss.txt | 2 +- > .../bindings/clock/exynos5433-clock.txt | 4 +- > .../bindings/clock/renesas,cpg-mssr.txt | 2 +- > .../clock/renesas,r8a7778-cpg-clocks.txt | 2 +- > .../clock/renesas,r8a7779-cpg-clocks.txt | 2 +- > .../clock/renesas,rcar-gen2-cpg-clocks.txt| 2 +- > .../bindings/clock/renesas,rz-cpg-clocks.txt | 2 +- > .../bindings/clock/ti/davinci/psc.txt | 2 +- > .../bindings/display/etnaviv/etnaviv-drm.txt | 2 +- > .../devicetree/bindings/display/msm/dpu.txt | 2 +- > .../devicetree/bindings/display/msm/mdp5.txt | 2 +- > .../devicetree/bindings/dsp/fsl,dsp.yaml | 2 +- > .../firmware/nvidia,tegra186-bpmp.txt | 2 +- > .../bindings/media/imx7-mipi-csi2.txt | 3 +- > .../bindings/media/mediatek-jpeg-decoder.txt | 3 +- > .../bindings/media/mediatek-mdp.txt | 3 +- > .../bindings/opp/qcom-nvmem-cpufreq.txt | 2 +- > .../devicetree/bindings/pci/pci-keystone.txt | 2 +- > .../bindings/phy/ti,phy-am654-serdes.txt | 2 +- > .../bindings/power/amlogic,meson-gx-pwrc.txt | 2 +- > .../devicetree/bindings/power/fsl,imx-gpc.txt | 2 +- > .../bindings/power/fsl,imx-gpcv2.txt | 2 +- > .../power/power-domain-consumers.yaml | 105 + > .../bindings/power/power-domain.yaml | 134 > .../bindings/power/power_domain.txt | 205 -- > .../devicetree/bindings/power/qcom,rpmpd.txt | 2 +- > .../bindings/power/renesas,rcar-sysc.txt | 2 +- > .../bindings/power/renesas,sysc-rmobile.txt | 2 +- > .../bindings/power/xlnx,zynqmp-genpd.txt | 2 +- > .../bindings/soc/bcm/brcm,bcm2835-pm.txt | 2 +- > .../bindings/soc/mediatek/scpsys.txt | 2 +- > .../bindings/soc/ti/sci-pm-domain.txt | 2 +- > .../bindings/usb/nvidia,tegra124-xusb.txt | 4 +- > MAINTAINERS | 2 +- > 37 files changed, 278 insertions(+), 241 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/power/power-domain-consumers.yaml > create mode 100644 Documentation/devicetree/bindings/power/power-domain.yaml > delete mode 100644 Documentation/devicetree/bindings/power/power_domain.txt > > diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt > b/Documentation/devicetree/bindings/arm/arm,scmi.txt > index 083dbf96ee00..f493d69e6194 100644 > --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt > +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt > @@ -100,7 +100,7 @@ Required sub-node properties: > > [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html > [1] Documentation/devicetree/bindings/clock/clock-bindings.txt > -[2] Documentation/devicetree/bindings/power/power_domain.txt > +[2] Documentation/devicetree/bindings/power/power-domain.yaml > [3] Documentation/devicetree/bindings/thermal/thermal.txt > [4] Documentation/devicetree/bindings/sram/sram.txt > [5] Documentation/devicetree/bindings/reset/reset.txt > diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt > b/Documentation/devicetree/bindings/arm/arm,scpi.txt > index 401831973638..7b83ef43b418 100644 > --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt > +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt > @@ -110,7 +110,7 @@ Required properties: > [1] Documentation/devicetree/bindings/clock/clock-bindings.txt > [2] Documentation/devicetree/bindings/thermal/thermal.txt > [3] Documentation/devicetree/bindings/sram/sram.txt > -[4] Documentation/devicetree/bindings/power/power_domain.txt > +[4] Documentation/devicetree/bindings/power/power-domain.yaml > > Example: > > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > index c149fadc6f47..6c8a61b971f1 100644 > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > @@ -124,7 +124,7 @@ Required properties for Pinctrl sub nodes: > CONFIG settings. > > [1] Documentation/devicetree/bindings/clock/clock-bindings.txt > -[2] Documentation/devicetree/bindings/power/power_domain.txt > +[2] Documentatio
Re: [PATCH v2 13/18] media/v4l2-core: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion
On 11/3/19 10:18 PM, John Hubbard wrote:
> 1. Change v4l2 from get_user_pages(FOLL_LONGTERM), to
> pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
>
> 2. Because all FOLL_PIN-acquired pages must be released via
> put_user_page(), also convert the put_page() call over to
> put_user_pages_dirty_lock().
>
> Reviewed-by: Ira Weiny
> Cc: Mauro Carvalho Chehab
> Signed-off-by: John Hubbard
Acked-by: Hans Verkuil
Looks good, thanks!
Hans
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
> b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index 28262190c3ab..9b9c5b37bf59 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -183,12 +183,12 @@ static int videobuf_dma_init_user_locked(struct
> videobuf_dmabuf *dma,
> dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
> data, size, dma->nr_pages);
>
> - err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
> - flags | FOLL_LONGTERM, dma->pages, NULL);
> + err = pin_longterm_pages(data & PAGE_MASK, dma->nr_pages,
> + flags, dma->pages, NULL);
>
> if (err != dma->nr_pages) {
> dma->nr_pages = (err >= 0) ? err : 0;
> - dprintk(1, "get_user_pages: err=%d [%d]\n", err,
> + dprintk(1, "pin_longterm_pages: err=%d [%d]\n", err,
> dma->nr_pages);
> return err < 0 ? err : -EINVAL;
> }
> @@ -349,11 +349,8 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
> BUG_ON(dma->sglen);
>
> if (dma->pages) {
> - for (i = 0; i < dma->nr_pages; i++) {
> - if (dma->direction == DMA_FROM_DEVICE)
> - set_page_dirty_lock(dma->pages[i]);
> - put_page(dma->pages[i]);
> - }
> + put_user_pages_dirty_lock(dma->pages, dma->nr_pages,
> + dma->direction == DMA_FROM_DEVICE);
> kfree(dma->pages);
> dma->pages = NULL;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/18] media/v4l2-core: set pages dirty upon releasing DMA buffers
On 11/3/19 10:17 PM, John Hubbard wrote:
> After DMA is complete, and the device and CPU caches are synchronized,
> it's still required to mark the CPU pages as dirty, if the data was
> coming from the device. However, this driver was just issuing a
> bare put_page() call, without any set_page_dirty*() call.
>
> Fix the problem, by calling set_page_dirty_lock() if the CPU pages
> were potentially receiving data from the device.
>
> Cc: Mauro Carvalho Chehab
> Signed-off-by: John Hubbard
Acked-by: Hans Verkuil
Looks good, thanks!
Hans
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
> b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index 66a6c6c236a7..28262190c3ab 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -349,8 +349,11 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
> BUG_ON(dma->sglen);
>
> if (dma->pages) {
> - for (i = 0; i < dma->nr_pages; i++)
> + for (i = 0; i < dma->nr_pages; i++) {
> + if (dma->direction == DMA_FROM_DEVICE)
> + set_page_dirty_lock(dma->pages[i]);
> put_page(dma->pages[i]);
> + }
> kfree(dma->pages);
> dma->pages = NULL;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
