Re: [PATCH 7/8] drm/vmwgfx: add SPDX idenitifier and clarify license
Hi, Dirk, On 05/04/2018 12:15 AM, Dirk Hohndel (VMware) wrote: This is licensed under GPL-2.0. Signed-off-by: Dirk Hohndel (VMware) --- drivers/gpu/drm/vmwgfx/Kconfig| 1 + .../vmwgfx/device_include/vmware_pack_begin.h | 25 +-- .../vmwgfx/device_include/vmware_pack_end.h | 25 +-- drivers/gpu/drm/vmwgfx/vmwgfx_msg.h | 14 ++- 4 files changed, 5 insertions(+), 60 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig index 8c308dac99c5..6b28a326f8bb 100644 --- a/drivers/gpu/drm/vmwgfx/Kconfig +++ b/drivers/gpu/drm/vmwgfx/Kconfig @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 config DRM_VMWGFX tristate "DRM driver for VMware Virtual GPU" depends on DRM && PCI && X86 && MMU diff --git a/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_begin.h b/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_begin.h index 7e7b0ce34aa2..75308bd0d970 100644 --- a/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_begin.h +++ b/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_begin.h @@ -1,25 +1,2 @@ -/** - * Copyright 2015 VMware, Inc. All rights reserved. - * - * Permission is hereby granted, free of charge, to any person - * obtaining a copy of this software and associated documentation - * files (the "Software"), to deal in the Software without - * restriction, including without limitation the rights to use, copy, - * modify, merge, publish, distribute, sublicense, and/or sell copies - * of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be - * included in all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS - * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN - * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN - * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE - * SOFTWARE. - * - **/ +/* SPDX-License-Identifier: GPL-2.0 */ #include diff --git a/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_end.h b/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_end.h index e2e440ed3d44..e93d6f28b68c 100644 --- a/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_end.h +++ b/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_end.h @@ -1,25 +1,2 @@ -/** - * Copyright 2015 VMware, Inc. All rights reserved. - * - * Permission is hereby granted, free of charge, to any person - * obtaining a copy of this software and associated documentation - * files (the "Software"), to deal in the Software without - * restriction, including without limitation the rights to use, copy, - * modify, merge, publish, distribute, sublicense, and/or sell copies - * of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be - * included in all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS - * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN - * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN - * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE - * SOFTWARE. - * - **/ +/* SPDX-License-Identifier: GPL-2.0 */ __packed diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h index 557a033fb610..f1589964be65 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h @@ -1,16 +1,6 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright (C) 2016, VMware, Inc. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - * NON INFRINGEMENT. See the GNU General Public License for more - * details. + * Copyright 2016, VMwa
Re: [PATCH] drm/bridge: adv7511: fix spelling of driver name in Kconfig
On Friday 27 April 2018 03:11 AM, Laurent Pinchart wrote: Hi Peter, Thank you for the patch. On Friday, 27 April 2018 00:36:44 EEST Peter Rosin wrote: Could perhaps prevent some confusion. queued to drm-misc-next Thanks, Archit Signed-off-by: Peter Rosin Reviewed-by: Laurent Pinchart --- drivers/gpu/drm/bridge/adv7511/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig b/drivers/gpu/drm/bridge/adv7511/Kconfig index 592b9d2ec034..944e440c4fde 100644 --- a/drivers/gpu/drm/bridge/adv7511/Kconfig +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig @@ -1,5 +1,5 @@ config DRM_I2C_ADV7511 - tristate "AV7511 encoder" + tristate "ADV7511 encoder" depends on OF select DRM_KMS_HELPER select REGMAP_I2C ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: bridge: adv7511: Replace mdelay with usleep_range in adv7511_probe
On Friday 27 April 2018 03:46 AM, Laurent Pinchart wrote:
Hi Jia-Ju,
Thank you for the patch.
On Wednesday, 11 April 2018 11:33:42 EEST Jia-Ju Bai wrote:
adv7511_probe() is never called in atomic context.
This function is only set as ".probe" in struct i2c_driver.
Despite never getting called from atomic context, adv7511_probe()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Nice work ! Is the tool open-source ?
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index b2431ae..2cf7fa1
100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1054,7 +1054,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id) }
if (adv7511->gpio_pd) {
- mdelay(5);
+ usleep_range(5000, 6000);
gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
}
The patch looks good to me.
Reviewed-by: Laurent Pinchart
queued to drm-misc-next
Thanks,
Archit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106259] [bisected] UVD hangs system on Vega10 linux-4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106259 --- Comment #2 from James Harvey --- Hi Christian, thanks for taking the time to look at this. I'm seeing this issue on the mainline linux-4.17 release candidates. I skipped testing rc1, ran the bisect after seeing this on rc2, then tested http://cgit.freedesktop.org/~agd5f/linux/?h=drm-fixes-4.17 prior to the rc3 release, just in case it was already fixed. Still present on rc3. In order to bisect, I did need to cherrypick [fdb401d03d311399d844b9f23ec5ab98a2811f58] drm/amd/display: Fix multiple definitions of handle_crc_irq, otherwise I would get linker errors. I'm using the firmware from git.kernel.org dated 2018-04-16. -- 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 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #189 from tkdestroyer2+bugs-freedesk...@gmail.com --- I tried what chris suggested, and it worked up until the point at which some X session closes (right after login or after exiting basic xterm test session), where the system locks up. They seem to have patched 4.16.*, which was totally broken before for me on 4.16.2. I guess I'll keep doing my dpm=0 thing for 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
Re: [PULL] drm-intel-next
On 4 May 2018 at 10:29, Dave Airlie wrote: > On 4 May 2018 at 10:19, Dave Airlie wrote: >> On 2 May 2018 at 17:03, Jani Nikula wrote: >>> >>> Hi Dave - >>> >>> drm-intel-next-2018-04-13: >>> First drm/i915 feature batch heading for v4.18: >>> >>> - drm-next backmerge to fix build (Rodrigo) >>> - GPU documentation improvements (Kevin) >>> - GuC and HuC refactoring, host/GuC communication, logging, fixes, and more >>> (mostly Michal and Michał, also Jackie, Michel and Piotr) >>> - PSR and PSR2 enabling and fixes (DK, José, Rodrigo and Chris) >>> - Selftest updates (Chris, Daniele) >>> - DPLL management refactoring (Lucas) >>> - DP MST fixes (Lyude and DK) >>> - Watermark refactoring and changes to support NV12 (Mahesh) >>> - NV12 prep work (Chandra) >>> - Icelake Combo PHY enablers (Manasi) >>> - Perf OA refactoring and ICL enabling (Lionel) >>> - ICL enabling (Oscar, Paulo, Nabendu, Mika, Kelvin, Michel) >>> - Workarounds refactoring (Oscar) >>> - HDCP fixes and improvements (Ramalingam, Radhakrishna) >>> - Power management fixes (Imre) >>> - Various display fixes (Maarten, Ville, Vidya, Jani, Gaurav) >>> - debugfs for FIFO underrun clearing (Maarten) >>> - Execlist improvements (Chris) >>> - Reset improvements (Chris) >>> - Plenty of things here and there I overlooked and/or didn't understand... >>> (Everyone) >>> >> >> Just FYI I've started using dim for managing the drm-next tree (step >> one to a possible group), >> >> This pull gets rejected by dim apply-pull for two reasons, >> >> One the driver date bump isn't reviewed, and one patch in here the SOB >> line is different >> name than the committer, even though they appear to be same person. >> >> I've pulled it anyways, but just logging the dim issues for prosperity. > > Actually I haven't pulled it, but I think dim just doesn't handle my > use case very well. > I do > dim -f apply-pull < pullreq > > It gets merge conflicts and ask me to solve them, but there doesn't seem > to be a dim apply-pull --resolved type of interface to say, keep going > and finish the > dim stuff you were doing before we hit conflicts. > I manually did git commit --amend -s --no-edit dim add-link drm-next < pullreq but it would be nice to have a continue or resolved. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-next
On 4 May 2018 at 10:19, Dave Airlie wrote: > On 2 May 2018 at 17:03, Jani Nikula wrote: >> >> Hi Dave - >> >> drm-intel-next-2018-04-13: >> First drm/i915 feature batch heading for v4.18: >> >> - drm-next backmerge to fix build (Rodrigo) >> - GPU documentation improvements (Kevin) >> - GuC and HuC refactoring, host/GuC communication, logging, fixes, and more >> (mostly Michal and Michał, also Jackie, Michel and Piotr) >> - PSR and PSR2 enabling and fixes (DK, José, Rodrigo and Chris) >> - Selftest updates (Chris, Daniele) >> - DPLL management refactoring (Lucas) >> - DP MST fixes (Lyude and DK) >> - Watermark refactoring and changes to support NV12 (Mahesh) >> - NV12 prep work (Chandra) >> - Icelake Combo PHY enablers (Manasi) >> - Perf OA refactoring and ICL enabling (Lionel) >> - ICL enabling (Oscar, Paulo, Nabendu, Mika, Kelvin, Michel) >> - Workarounds refactoring (Oscar) >> - HDCP fixes and improvements (Ramalingam, Radhakrishna) >> - Power management fixes (Imre) >> - Various display fixes (Maarten, Ville, Vidya, Jani, Gaurav) >> - debugfs for FIFO underrun clearing (Maarten) >> - Execlist improvements (Chris) >> - Reset improvements (Chris) >> - Plenty of things here and there I overlooked and/or didn't understand... >> (Everyone) >> > > Just FYI I've started using dim for managing the drm-next tree (step > one to a possible group), > > This pull gets rejected by dim apply-pull for two reasons, > > One the driver date bump isn't reviewed, and one patch in here the SOB > line is different > name than the committer, even though they appear to be same person. > > I've pulled it anyways, but just logging the dim issues for prosperity. Actually I haven't pulled it, but I think dim just doesn't handle my use case very well. I do dim -f apply-pull < pullreq It gets merge conflicts and ask me to solve them, but there doesn't seem to be a dim apply-pull --resolved type of interface to say, keep going and finish the dim stuff you were doing before we hit conflicts. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-next
On 2 May 2018 at 17:03, Jani Nikula wrote: > > Hi Dave - > > drm-intel-next-2018-04-13: > First drm/i915 feature batch heading for v4.18: > > - drm-next backmerge to fix build (Rodrigo) > - GPU documentation improvements (Kevin) > - GuC and HuC refactoring, host/GuC communication, logging, fixes, and more > (mostly Michal and Michał, also Jackie, Michel and Piotr) > - PSR and PSR2 enabling and fixes (DK, José, Rodrigo and Chris) > - Selftest updates (Chris, Daniele) > - DPLL management refactoring (Lucas) > - DP MST fixes (Lyude and DK) > - Watermark refactoring and changes to support NV12 (Mahesh) > - NV12 prep work (Chandra) > - Icelake Combo PHY enablers (Manasi) > - Perf OA refactoring and ICL enabling (Lionel) > - ICL enabling (Oscar, Paulo, Nabendu, Mika, Kelvin, Michel) > - Workarounds refactoring (Oscar) > - HDCP fixes and improvements (Ramalingam, Radhakrishna) > - Power management fixes (Imre) > - Various display fixes (Maarten, Ville, Vidya, Jani, Gaurav) > - debugfs for FIFO underrun clearing (Maarten) > - Execlist improvements (Chris) > - Reset improvements (Chris) > - Plenty of things here and there I overlooked and/or didn't understand... > (Everyone) > Just FYI I've started using dim for managing the drm-next tree (step one to a possible group), This pull gets rejected by dim apply-pull for two reasons, One the driver date bump isn't reviewed, and one patch in here the SOB line is different name than the committer, even though they appear to be same person. I've pulled it anyways, but just logging the dim issues for prosperity. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/8] R-Car DU: Support CRC calculation
On 3 May 2018 at 23:45, Daniel Vetter wrote: > On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart > wrote: >> Hi Dave, >> >> Ping ? > > Not aware of any crc core work going on in drm, so has my ack. Worst > case we do a topic branch or something like that (since I guess you'll > do a pull request anyway on the v4l side). Acked-by: me. Oops, Acked-by: Dave Airlie Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106177] overclocking doesn't work with 4.17-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=106177 --- Comment #3 from gr...@sub.red --- At least I had the same behaviour, value not "sticky" and no impact on actual clock. I noticed it when I tested 4.17-rc2, actually wanted to test the "wattman" functionality. Then noticed, it doesn't work on the 4.16.6 either. Will have to test older kernels, maybe this weekend. -- 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 106177] overclocking doesn't work with 4.17-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=106177 --- Comment #2 from Christoph Haag --- I just tried 4.16.7 and overclocking still works on the 4.16 version. And I think on 4.17rc3 it still doesn't work. Do you mean on 4.16.6 overclocking does not work for you? Then it's probably not the same as my issue. -- 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 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 chrisg_...@hotmail.com changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REOPENED|RESOLVED --- Comment #188 from chrisg_...@hotmail.com --- I suffered pretty much all of the issue listed in this thread for many weeks since upgrading to 3 1440p monitors. I have an Club 3D R9 390 Royal Queen. Comment #182 best describes the problem I faced and what I had to do to work around it. I am happy to announce that kernel 4.16.7 has solved this issue for me. My system has no more issues booting. KDE is stable. No flickering at all. Even when forcing power_dpm_force_performance_level to 'low'. I'm running Gentoo with: mesa-18.1.0 libdrm-2.4.91 xf86-video-amdgpu-18.0.1 xorg-drivers-1.19 kernel params include: radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.modeset=1 amdgpu.dc=1 amdgpu.dpm=1 If anyone needs more info please ask. -- 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 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g
https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #25 from Francisco Pina Martins --- I have submitted the bug to kernel bugzilla as you have suggested: https://bugzilla.kernel.org/show_bug.cgi?id=199613 Is there anything else I can do here to help track the eventual problem with AMDGPU? Or do you think the AMDGPU memory problem is being caused by `rcu_cpu_kthread`? Is there anything else you can recommend me to do in order to figure out to disentangle eventual multiple issues? -- 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 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off
https://bugs.freedesktop.org/show_bug.cgi?id=98324 --- Comment #11 from Darren Salt --- Created attachment 139326 --> https://bugs.freedesktop.org/attachment.cgi?id=139326&action=edit Bad EDID output (4.17-rc3 + DC) Once this happens (after VESA blanking long enough for the problem monitor to fully go to sleep), it persists until reboot. -- 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 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off
https://bugs.freedesktop.org/show_bug.cgi?id=98324 --- Comment #10 from Darren Salt --- Created attachment 139325 --> https://bugs.freedesktop.org/attachment.cgi?id=139325&action=edit Good EDID output (4.17-rc3 + DC) -- 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/msm: Don't setup control node debugfs files
On Thu, May 03, 2018 at 11:16:55AM -0400, Sean Paul wrote:
> On Thu, May 03, 2018 at 11:31:07AM +0200, Daniel Vetter wrote:
> > It's going away.
> >
> > v2: Try harder to find them all.
> >
> > Signed-off-by: Daniel Vetter
>
> Still
> Reviewed-by: Sean Paul
Ok, this compiled better, both remaining patches pushed.
-Daniel
>
> > Cc: Rob Clark
> > Cc: Jordan Crouse
> > Cc: Nicolas Dechesne
> > Cc: Archit Taneja
> > Cc: Bjorn Andersson
> > Cc: Arnd Bergmann
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/msm/adreno/adreno_device.c | 1 -
> > drivers/gpu/drm/msm/msm_debugfs.c | 3 ---
> > 2 files changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > index 8e0cb161754b..0ae5ace65462 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > @@ -168,7 +168,6 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> > if (gpu->funcs->debugfs_init) {
> > gpu->funcs->debugfs_init(gpu, dev->primary);
> > gpu->funcs->debugfs_init(gpu, dev->render);
> > - gpu->funcs->debugfs_init(gpu, dev->control);
> > }
> > #endif
> >
> > diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
> > b/drivers/gpu/drm/msm/msm_debugfs.c
> > index ba74cb4f94df..1ff3fda245d1 100644
> > --- a/drivers/gpu/drm/msm/msm_debugfs.c
> > +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> > @@ -140,9 +140,6 @@ int msm_debugfs_late_init(struct drm_device *dev)
> > if (ret)
> > return ret;
> > ret = late_init_minor(dev->render);
> > - if (ret)
> > - return ret;
> > - ret = late_init_minor(dev->control);
> > return ret;
> > }
> >
> > --
> > 2.17.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm_hwc] PSA: drm_hwc submissions via gitlab
On Thu, May 03, 2018 at 03:12:55PM -0400, Sean Paul wrote: > On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote: > > On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote: > > > Hey all, > > > Apologies for the direct ping. I've harvested your emails from drm_hwc > > > git logs, > > > and didn't want to leave anyone out. The good news is that your email > > > address > > > will forever be remembered in the annals of drm_hwcomposer! > > > > > > Anyways, back to the point. > > > > > > Now that we have our shiny freedesktop gitlab instance [1], we should > > > really > > > start using it to its fullest extent. This means 2 things: > > > > > > 1- When you send patches, please consider using gitlab merge requests > > > instead of > > >git send-email. This is not mandatory, but dri-devel is so busy, I > > > want to > > >make sure things aren't lost. Further, there might be some who are not > > >interested in reading dri-devel *gasp*, but who are interested in > > > drm_hwc. > > > 2- If you're interested in being notified of merge requests (since > > > dri-devel can > > >not be cc'd), please consider clicking "Watch" on the project and > > > choose your > > >desired notification level. > > > > > > If you're still reading, I'll point out a couple other things: > > > - There is a bug tracker on the gitlab instance, feel free to add > > > bugs/features/etc to it. > > > - I've added a TODO list to the wiki, but in typing this, realized it's > > > probably > > > better to file bugs for each item. So please ignore the TODO wiki entry. > > > > Any plans to wire up autobuilder or maybe even functional CI to the > > gitlab instance? That's where stuff gets really cool (and I think a > > lot of people will see the value of abandoning dri-devel much more, > > beyond the better S/N ratio). > > Not as far as I know. A fun afternoon project might be to hook up clang-format > verification as a merge request hook. Aside from that, I think proper (or even > improper/simple) CI would require more effort than we have resources. > A couple additional thoughts, We have seen a good uptick in drm_hwc activity in the last month or so, so maybe there is someone with time to do this. The other (imo significant) benefit gitlab has in addition to S/N is that it's not an email-based workflow. I'm particularly looking forward to reviewing patches side-by-side instead of in a mutt window :-). Sean > Sean > > > > > > Cheers, Daniel > > > > > > Thanks for reading, > > > > > > Sean > > > > > > [1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer > > > > > > -- > > > Sean Paul, Software Engineer, Google / Chromium OS > > > ___ > > > 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 > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- 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: [PATCH v1] drm: panel-orientation-quirks: Convert to use match_string() helper
On Thu, May 03, 2018 at 09:41:19PM +0300, Andy Shevchenko wrote:
> The new helper returns index of the matching string in an array.
> We are going to use it here.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index caebddda8bce..fe9c6c731e87 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -172,10 +172,9 @@ int drm_get_panel_orientation_quirk(int width, int
> height)
> if (!bios_date)
> continue;
>
> - for (i = 0; data->bios_dates[i]; i++) {
> - if (!strcmp(data->bios_dates[i], bios_date))
> - return data->orientation;
> - }
> + i = match_string(data->bios_dates, -1, bios_date);
> + if (i >= 0)
> + return data->orientation;
> }
>
> return DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> --
> 2.17.0
>
--
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: [drm_hwc] PSA: drm_hwc submissions via gitlab
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote: > On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote: > > Hey all, > > Apologies for the direct ping. I've harvested your emails from drm_hwc git > > logs, > > and didn't want to leave anyone out. The good news is that your email > > address > > will forever be remembered in the annals of drm_hwcomposer! > > > > Anyways, back to the point. > > > > Now that we have our shiny freedesktop gitlab instance [1], we should really > > start using it to its fullest extent. This means 2 things: > > > > 1- When you send patches, please consider using gitlab merge requests > > instead of > >git send-email. This is not mandatory, but dri-devel is so busy, I want > > to > >make sure things aren't lost. Further, there might be some who are not > >interested in reading dri-devel *gasp*, but who are interested in > > drm_hwc. > > 2- If you're interested in being notified of merge requests (since > > dri-devel can > >not be cc'd), please consider clicking "Watch" on the project and choose > > your > >desired notification level. > > > > If you're still reading, I'll point out a couple other things: > > - There is a bug tracker on the gitlab instance, feel free to add > > bugs/features/etc to it. > > - I've added a TODO list to the wiki, but in typing this, realized it's > > probably > > better to file bugs for each item. So please ignore the TODO wiki entry. > > Any plans to wire up autobuilder or maybe even functional CI to the > gitlab instance? That's where stuff gets really cool (and I think a > lot of people will see the value of abandoning dri-devel much more, > beyond the better S/N ratio). Not as far as I know. A fun afternoon project might be to hook up clang-format verification as a merge request hook. Aside from that, I think proper (or even improper/simple) CI would require more effort than we have resources. Sean > > Cheers, Daniel > > > > Thanks for reading, > > > > Sean > > > > [1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer > > > > -- > > Sean Paul, Software Engineer, Google / Chromium OS > > ___ > > 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 -- 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: [drm_hwc] PSA: drm_hwc submissions via gitlab
On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote: > Hey all, > Apologies for the direct ping. I've harvested your emails from drm_hwc git > logs, > and didn't want to leave anyone out. The good news is that your email address > will forever be remembered in the annals of drm_hwcomposer! > > Anyways, back to the point. > > Now that we have our shiny freedesktop gitlab instance [1], we should really > start using it to its fullest extent. This means 2 things: > > 1- When you send patches, please consider using gitlab merge requests instead > of >git send-email. This is not mandatory, but dri-devel is so busy, I want to >make sure things aren't lost. Further, there might be some who are not >interested in reading dri-devel *gasp*, but who are interested in drm_hwc. > 2- If you're interested in being notified of merge requests (since dri-devel > can >not be cc'd), please consider clicking "Watch" on the project and choose > your >desired notification level. > > If you're still reading, I'll point out a couple other things: > - There is a bug tracker on the gitlab instance, feel free to add > bugs/features/etc to it. > - I've added a TODO list to the wiki, but in typing this, realized it's > probably > better to file bugs for each item. So please ignore the TODO wiki entry. Any plans to wire up autobuilder or maybe even functional CI to the gitlab instance? That's where stuff gets really cool (and I think a lot of people will see the value of abandoning dri-devel much more, beyond the better S/N ratio). Cheers, Daniel > > Thanks for reading, > > Sean > > [1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer > > -- > Sean Paul, Software Engineer, Google / Chromium OS > ___ > 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
[Bug 106177] overclocking doesn't work with 4.17-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=106177 gr...@sub.red changed: What|Removed |Added CC||gr...@sub.red --- Comment #1 from gr...@sub.red --- I have the same issue on 4.16.6 and 4.17-rc2 and CIK hardware (Hawaii/R9 290X) -- 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 106306] amdgpu CIK power management issues (overdrive and wattman)
https://bugs.freedesktop.org/show_bug.cgi?id=106306 --- Comment #1 from gr...@sub.red --- Overdrive doesn't work either with current stable kernel (4.16.6). Clock remains stable (as seen in amdgpu_pm_info) and reading the value gives 0: > echo 5 | sudo tee /sys/class/drm/card0/device/pp_sclk_od 5 > cat /sys/class/drm/card0/device/pp_sclk_od 0 I can't currently tell when this issue appeared or if the feature even ever worked with this hardware, as I've never been using it. -- 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 106306] amdgpu CIK power management issues (overdrive and wattman)
https://bugs.freedesktop.org/show_bug.cgi?id=106306 gr...@sub.red changed: What|Removed |Added Summary|amdgpu CIK power management |amdgpu CIK power management |issues (wattman)|issues (overdrive and ||wattman) -- 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 106245] Raven ridge (2400g) fails to start (swiotlb buffer is full) with IOMMU disabled
https://bugs.freedesktop.org/show_bug.cgi?id=106245 --- Comment #2 from ojab --- Yep, works fine with `mem_encrypt=off amd_iommu=off` -- 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 106259] [bisected] UVD hangs system on Vega10 linux-4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106259 Christian König changed: What|Removed |Added CC||ckoenig.leichtzumerken@gmai ||l.com Status|NEW |ASSIGNED --- Comment #1 from Christian König --- Which branch are you testing this with? -- 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 6/6] drm/panel: rpi-touchscreen: Set status to "fail" when ->probe() fails
On Thu, May 3, 2018 at 11:40 AM, Boris Brezillon
wrote:
> The device might be described in the device tree but not connected to
> the I2C bus. Update the status property so that the DRM panel logic
> returns -ENODEV when someone tries to get the panel attached to this
> DT node.
>
> Signed-off-by: Boris Brezillon
> ---
> .../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 35
> ++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> index 2c9c9722734f..b8fcb1acef75 100644
> --- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> +++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> @@ -358,6 +358,39 @@ static const struct drm_panel_funcs
> rpi_touchscreen_funcs = {
> .get_modes = rpi_touchscreen_get_modes,
> };
>
> +static void rpi_touchscreen_set_status_fail(struct i2c_client *i2c)
> +{
> + struct property *newprop;
> +
> + newprop = kzalloc(sizeof(*newprop), GFP_KERNEL);
> + if (!newprop)
> + return;
> +
> + newprop->name = kstrdup("status", GFP_KERNEL);
> + if (!newprop->name)
> + goto err;
> +
> + newprop->value = kstrdup("fail", GFP_KERNEL);
> + if (!newprop->value)
> + goto err;
> +
> + newprop->length = sizeof("fail");
> +
> + if (of_update_property(i2c->dev.of_node, newprop))
> + goto err;
> +
As I mentioned on irc, can you make this a common DT function.
I'm not sure if it matters that we set status to fail vs. disabled. I
somewhat prefer the latter as we already have other cases and I'd
rather the api not pass a string in. I can't think of any reason to
distinguish the difference between fail and disabled.
> + /* We intentionally leak the memory we allocate here, because the new
> +* OF property might live longer than the underlying dev, so no way
> +* we can use devm_kzalloc() here.
> +*/
> + return;
> +
> +err:
> + kfree(newprop->value);
> + kfree(newprop->name);
> + kfree(newprop);
> +}
> +
> static int rpi_touchscreen_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> @@ -382,6 +415,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
>
> ver = rpi_touchscreen_i2c_read(ts, REG_ID);
> if (ver < 0) {
> + rpi_touchscreen_set_status_fail(i2c);
I've thought some more about this and I still think this should be
handled in the driver core or i2c core.
The reason is simple. I think the state of the system should be the
same after this as if you booted with 'status = "disabled"' for this
node. And that means the device should be removed completely because
we don't create struct device's for disabled nodes.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-next 01/21] drm/i915: Move u64-to-ptr helpers to general header
Quoting Leon Romanovsky (2018-05-03 16:36:55)
> From: Leon Romanovsky
>
> The macro u64_to_ptr() and function ptr_to_u64() are useful enough
> to be part of general header, so move them there and allow RDMA
> subsystem reuse them.
>
> Signed-off-by: Leon Romanovsky
Feel free to merge this through an appropriate tree, I guess you could
get some acks from LKML.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> ---
> drivers/gpu/drm/i915/i915_utils.h | 12 ++--
> include/linux/kernel.h| 12
> 2 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index 51dbfe5bb418..de3bfda7bf96 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -25,6 +25,8 @@
> #ifndef __I915_UTILS_H
> #define __I915_UTILS_H
>
> +#include
> +
> #undef WARN_ON
> /* Many gcc seem to no see through this and fall over :( */
> #if 0
> @@ -102,16 +104,6 @@
> __T;\
> })
>
> -static inline u64 ptr_to_u64(const void *ptr)
> -{
> - return (uintptr_t)ptr;
> -}
> -
> -#define u64_to_ptr(T, x) ({\
> - typecheck(u64, x); \
> - (T *)(uintptr_t)(x);\
> -})
> -
> #define __mask_next_bit(mask) ({ \
> int __idx = ffs(mask) - 1; \
> mask &= ~BIT(__idx);\
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 6a1eb0b0aad9..a738393c9694 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -70,6 +70,18 @@
> */
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr))
>
> +static inline u64 ptr_to_u64(const void *ptr)
> +{
> + return (uintptr_t)ptr;
> +}
> +
> +#define u64_to_ptr(T, x) ( \
> +{ \
> + typecheck(u64, x); \
> + (T *)(uintptr_t)(x);\
> +} \
> +)
> +
> #define u64_to_user_ptr(x) ( \
> { \
> typecheck(u64, x); \
> --
> 2.14.3
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/panel: Let of_drm_find_panel() return -ENODEV when the panel is disabled
DT nodes might be present in the DT but with a status property set to
"disabled" or "fail". In this case, we should not return -EPROBE_DEFER
when the caller ask for a drm_panel instance. Return -ENODEV instead.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_panel.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2d9e2684c6c8..15df28d20194 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -136,13 +136,18 @@ EXPORT_SYMBOL(drm_panel_detach);
*
* Return: A pointer to the panel registered for the specified device tree
* node or an ERR_PTR() if no panel matching the device tree node can be found.
- * The only error that can be reported is -EPROBE_DEFER, meaning that the panel
- * device has not been probed yet, and the caller should re-retry later.
+ * Possible error codes returned by this function:
+ * - EPROBE_DEFER: the panel device has not been probed yet, and the caller
+ * should re-retry later
+ * - ENODEV: the device is not available (status != "okay" or "ok")
*/
struct drm_panel *of_drm_find_panel(const struct device_node *np)
{
struct drm_panel *panel;
+ if (!of_device_is_available(np))
+ return ERR_PTR(-ENODEV);
+
mutex_lock(&panel_lock);
list_for_each_entry(panel, &panel_list, list) {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/panel: rpi-touchscreen: Set status to "fail" when ->probe() fails
The device might be described in the device tree but not connected to
the I2C bus. Update the status property so that the DRM panel logic
returns -ENODEV when someone tries to get the panel attached to this
DT node.
Signed-off-by: Boris Brezillon
---
.../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 35 ++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 2c9c9722734f..b8fcb1acef75 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -358,6 +358,39 @@ static const struct drm_panel_funcs rpi_touchscreen_funcs
= {
.get_modes = rpi_touchscreen_get_modes,
};
+static void rpi_touchscreen_set_status_fail(struct i2c_client *i2c)
+{
+ struct property *newprop;
+
+ newprop = kzalloc(sizeof(*newprop), GFP_KERNEL);
+ if (!newprop)
+ return;
+
+ newprop->name = kstrdup("status", GFP_KERNEL);
+ if (!newprop->name)
+ goto err;
+
+ newprop->value = kstrdup("fail", GFP_KERNEL);
+ if (!newprop->value)
+ goto err;
+
+ newprop->length = sizeof("fail");
+
+ if (of_update_property(i2c->dev.of_node, newprop))
+ goto err;
+
+ /* We intentionally leak the memory we allocate here, because the new
+* OF property might live longer than the underlying dev, so no way
+* we can use devm_kzalloc() here.
+*/
+ return;
+
+err:
+ kfree(newprop->value);
+ kfree(newprop->name);
+ kfree(newprop);
+}
+
static int rpi_touchscreen_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -382,6 +415,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
ver = rpi_touchscreen_i2c_read(ts, REG_ID);
if (ver < 0) {
+ rpi_touchscreen_set_status_fail(i2c);
dev_err(dev, "Atmel I2C read failed: %d\n", ver);
return -ENODEV;
}
@@ -391,6 +425,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
case 0xc3: /* ver 2 */
break;
default:
+ rpi_touchscreen_set_status_fail(i2c);
dev_err(dev, "Unknown Atmel firmware revision: 0x%02x\n", ver);
return -ENODEV;
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/of: Make drm_of_find_panel_or_bridge() fail when the device is disabled
There's no point searching for a drm_bridge or drm_panel if the OF node
we're pointing has a status property that is not "okay" or "ok". Just
return -ENODEV in this case.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_of.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index f413fae6f6dc..f8c1da95c63f 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -238,6 +238,11 @@ int drm_of_find_panel_or_bridge(const struct device_node
*np,
if (!remote)
return -ENODEV;
+ if (!of_device_is_available(remote)) {
+ of_node_put(remote);
+ return -ENODEV;
+ }
+
if (panel) {
struct drm_panel *tmp_panel;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] drm/vc4: Support the case where the DSI device is disabled
Having a device with a status property != "okay" in the DT is a valid
use case, and we should not prevent the registration of the DRM device
when the DSI device connected to the DSI controller is disabled.
Consider the ENODEV return code as a valid result and do not expose the
DSI encoder/connector when it happens.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_dsi.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 8aa897835118..db2f137f8b7b 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1606,8 +1606,18 @@ static int vc4_dsi_bind(struct device *dev, struct
device *master, void *data)
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
&panel, &dsi->bridge);
- if (ret)
+ if (ret) {
+ /* If the bridge or panel pointed by dev->of_node is not
+* enabled, just return 0 here so that we don't prevent the DRM
+* dev from being registered. Of course that means the DSI
+* encoder won't be exposed, but that's not a problem since
+* nothing is connected to it.
+*/
+ if (ret == -ENODEV)
+ return 0;
+
return ret;
+ }
if (panel) {
dsi->bridge = devm_drm_panel_bridge_add(dev, panel,
@@ -1652,7 +1662,8 @@ static void vc4_dsi_unbind(struct device *dev, struct
device *master,
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_dsi *dsi = dev_get_drvdata(dev);
- pm_runtime_disable(dev);
+ if (dsi->bridge)
+ pm_runtime_disable(dev);
vc4_dsi_encoder_destroy(dsi->encoder);
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of NULL
Right now, the DRM panel logic returns NULL when a panel pointing to
the passed OF node is not present in the list of registered panels.
Most drivers interpret this NULL value as -EPROBE_DEFER, but we are
about to modify the semantic of of_drm_find_panel() and let the
framework return -ENODEV when the device node we're pointing to has
a status property that is not equal to "okay" or "ok".
Let's first patch the of_drm_find_panel() implementation to return
ERR_PTR(-EPROBE_DEFER) instead of NULL and patch all callers to replace
the '!panel' check by an 'IS_ERR(panel)' one.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/bridge/cdns-dsi.c | 2 +-
drivers/gpu/drm/bridge/lvds-encoder.c | 4 ++--
drivers/gpu/drm/drm_of.c| 8 ++--
drivers/gpu/drm/drm_panel.c | 6 --
drivers/gpu/drm/exynos/exynos_dp.c | 9 ++---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 --
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 8 +---
drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 10 +++---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_lvds.c | 9 ++---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +-
drivers/gpu/drm/sti/sti_dvo.c | 7 +--
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
drivers/gpu/drm/tegra/dsi.c | 6 --
drivers/gpu/drm/tegra/output.c | 18 +++---
include/drm/drm_panel.h | 2 +-
18 files changed, 74 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cdns-dsi.c
index c255fc3e1be5..2c5991cf5397 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -1152,7 +1152,7 @@ static int cdns_dsi_attach(struct mipi_dsi_host *host,
np = of_node_get(dev->dev.of_node);
panel = of_drm_find_panel(np);
- if (panel) {
+ if (!IS_ERR(panel)) {
bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DSI);
} else {
bridge = of_drm_find_bridge(dev->dev.of_node);
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..f56c92f7af7c 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -68,9 +68,9 @@ static int lvds_encoder_probe(struct platform_device *pdev)
panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
- if (!panel) {
+ if (IS_ERR(panel)) {
dev_dbg(&pdev->dev, "panel not found, deferring probe\n");
- return -EPROBE_DEFER;
+ return PTR_ERR(panel);
}
lvds_encoder->panel_bridge =
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 1fe122461298..f413fae6f6dc 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -239,9 +239,13 @@ int drm_of_find_panel_or_bridge(const struct device_node
*np,
return -ENODEV;
if (panel) {
- *panel = of_drm_find_panel(remote);
- if (*panel)
+ struct drm_panel *tmp_panel;
+
+ tmp_panel = of_drm_find_panel(remote);
+ if (!IS_ERR(tmp_panel)) {
+ *panel = tmp_panel;
ret = 0;
+ }
}
/* No panel found yet, check for a bridge next. */
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 308d442a531b..2d9e2684c6c8 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -135,7 +135,9 @@ EXPORT_SYMBOL(drm_panel_detach);
* tree node. If a matching panel is found, return a pointer to it.
*
* Return: A pointer to the panel registered for the specified device tree
- * node or NULL if no panel matching the device tree node can be found.
+ * node or an ERR_PTR() if no panel matching the device tree node can be found.
+ * The only error that can be reported is -EPROBE_DEFER, meaning that the panel
+ * device has not been probed yet, and the caller should re-retry later.
*/
struct drm_panel *of_drm_find_panel(const struct device_node *np)
{
@@ -151,7 +153,7 @@ struct drm_panel *of_drm_find_panel(const struct
device_node *np)
}
mutex_unlock(&panel_lock);
- return NULL;
+ return ERR_PTR(-EPROBE_DEFER);
}
EXPORT_SYMBOL(of_drm_find_panel);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index 86330f396784..962cad0276e5 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -231,10 +231,13 @@ stati
[PATCH v2 0/6] drm/panel: Handle the "panel is missing" case properly
Hello, This is a new attempt at fixing the "panel is missing" issue (described in this thread [1]). I lost track of Eric's proposal, but I recently proposed to address this problem through a new ->detect() hook in the panel_funcs interface [2], which was rejected. So here is a new version based on the feedback I had from Daniel, Thierry and Rob. The idea is to allow of_drm_find_panel() to return -ENODEV and let the DRM driver decide what to do with that (silently ignore the missing component and register the DRM device, or fail to register the DRM device). Patch 1 is just a fix for an OF node ref leak I found in the tegra driver while working on this patch series. It can be applied independently but I send it here since patch 2 depends on it. Patch 2 changes the semantic of of_drm_find_panel() so that it returns an ERR_PTR() instead of NULL when the panel is not found. This way we'll be able to differentiate the "panel is missing" from "panel has not been probed yet" errors. Patch 3 and 4 are adding new tests in of_drm_find_panel() and drm_of_find_panel_or_bridge() to return -ENODEV when the status property of the DT node is not set to "okay". Patch 5 is patching the VC4 DSI encoder driver to gracefully handle the -ENODEV case and allow the registration of the DRM device when the DSI device is disabled. And finally, patch 6 is modifying the rpi-touchscreen panel driver to update the status property of the DT node when the device is not reachable on the I2C bus. This way, the DSI encoder driver will get an -ENODEV and the DRM device will be registered even if the DSI panel is not connected. Note that the status prop update is currently done in the I2C driver instead of the I2C or device-model core because I think modifying the behavior for all I2C devices (or all devices) is too risky. Feel free to comment on this implementation Thanks, Boris Changes since v1: - Everything :-) [1]https://lists.freedesktop.org/archives/dri-devel/2017-November/157688.html [2]https://www.spinics.net/lists/dri-devel/msg174808.html Boris Brezillon (6): drm/tegra: Fix a device_node leak when the DRM panel is not found drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of NULL drm/panel: Let of_drm_find_panel() return -ENODEV when the panel is disabled drm/of: Make drm_of_find_panel_or_bridge() fail when the device is disabled drm/vc4: Support the case where the DSI device is disabled drm/panel: rpi-touchscreen: Set status to "fail" when ->probe() fails drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/lvds-encoder.c | 4 +-- drivers/gpu/drm/drm_of.c | 13 ++-- drivers/gpu/drm/drm_panel.c| 11 +-- drivers/gpu/drm/exynos/exynos_dp.c | 9 -- drivers/gpu/drm/exynos/exynos_drm_dpi.c| 9 -- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 ++-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 8 +++-- drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 4 +-- .../gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c| 10 +-- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- .../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 35 ++ drivers/gpu/drm/rcar-du/rcar_lvds.c| 9 -- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/sti/sti_dvo.c | 7 +++-- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 +-- drivers/gpu/drm/tegra/dsi.c| 6 ++-- drivers/gpu/drm/tegra/output.c | 17 ++- drivers/gpu/drm/vc4/vc4_dsi.c | 15 -- include/drm/drm_panel.h| 2 +- 20 files changed, 131 insertions(+), 44 deletions(-) -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/tegra: Fix a device_node leak when the DRM panel is not found
of_node_put(panel) is not called when of_drm_find_panel(panel) returns
NULL, thus leaking the reference we hold on panel.
Fixes: 9be7d864cf07 ("drm/tegra: Implement panel support")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/tegra/output.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index ffe34bd0bb9d..676fd394836f 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -110,10 +110,9 @@ int tegra_output_probe(struct tegra_output *output)
panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
if (panel) {
output->panel = of_drm_find_panel(panel);
+ of_node_put(panel);
if (!output->panel)
return -EPROBE_DEFER;
-
- of_node_put(panel);
}
output->edid = of_get_property(output->of_node, "nvidia,edid", &size);
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drivers: remove force dma flag from buses
On Sat, Apr 28, 2018 at 08:21:59AM +0530, Nipun Gupta wrote: > With each bus implementing its own DMA configuration callback, > there is no need for bus to explicitly have force_dma in its > global structure. This patch modifies of_dma_configure API to > accept an input parameter which specifies if implicit DMA > configuration is required even when it is not described by the > firmware. > > Signed-off-by: Nipun Gupta > Acked-by: Bjorn Helgaas # PCI parts > --- > Changes in v2: > - This is a new change suggested by Robin and Christoph > and is added to the series. > > Changes in v3: > - Rebase and changes corresponding to the changes in patch 1/2 > > Changes in v4: > - Rebased on top of 4.17-rc2 > > drivers/amba/bus.c| 1 - > drivers/base/platform.c | 3 +-- > drivers/bcma/main.c | 2 +- > drivers/dma/qcom/hidma_mgmt.c | 2 +- This one: Acked-by: Vinod Koul -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add SPDX idenitifier and clarify license
On Thu, May 3, 2018 at 12:48 PM, Dirk Hohndel wrote: > But if you do the same analysis for header files... > > hohndel@rrmbpvm:~/src/linux[VMware-license-cleanup] > $ git grep SPDX | grep \.h: | cut -d: -f2 | sort | grep ^// | wc > 5491098 14823 > hohndel@rrmbpvm:~/src/linux[VMware-license-cleanup] > $ git grep SPDX | grep \.h: | cut -d: -f2 | sort | grep ^/\* | wc >7981 15962 215364 Right, Documentation/process/license-rules.rst says /* style should be used for .h files. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/15] dma-fence: Make ->enable_signaling optional
Quoting Daniel Vetter (2018-05-03 15:25:50)
> @@ -560,7 +567,7 @@ dma_fence_init(struct dma_fence *fence, const struct
> dma_fence_ops *ops,
>spinlock_t *lock, u64 context, unsigned seqno)
> {
> BUG_ON(!lock);
> - BUG_ON(!ops || !ops->wait || !ops->enable_signaling ||
> + BUG_ON(!ops || !ops->wait ||
>!ops->get_driver_name || !ops->get_timeline_name);
One thing I was wondering about (following the discussion of rhashtable
on lwn) was inlining this function and passing dma_fence_ops by value.
And seeing if that eliminates the branch and makes smaller code
(probably not, mostly idling wondering about that technique) and kills
off the BUGs (can then be BUILD_BUG_ON).
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/selftests: fix spelling mistake: "parmaters" -> "parameters"
Quoting Colin King (2018-05-03 16:45:10) > From: Colin Ian King > > Trivial fix to spelling mistake in pr_err error message > > Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/selftests: fix spelling mistake: "parmaters" -> "parameters"
From: Colin Ian King
Trivial fix to spelling mistake in pr_err error message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
b/drivers/gpu/drm/i915/selftests/i915_vma.c
index eb89e301b602..e90f97236e50 100644
--- a/drivers/gpu/drm/i915/selftests/i915_vma.c
+++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
@@ -81,7 +81,7 @@ checked_vma_instance(struct drm_i915_gem_object *obj,
}
if (i915_vma_compare(vma, vm, view)) {
- pr_err("i915_vma_compare failed with create parmaters!\n");
+ pr_err("i915_vma_compare failed with create parameters!\n");
return ERR_PTR(-EINVAL);
}
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm_hwcomposer: Stop using libsync to provide sw_sync wrappers
On Thu, May 03, 2018 at 10:30:35AM -0500, Rob Herring wrote: > On Thu, May 3, 2018 at 9:45 AM, Sean Paul wrote: > > On Thu, May 03, 2018 at 09:39:31AM -0500, Rob Herring wrote: > >> On Thu, May 3, 2018 at 9:32 AM, Sean Paul wrote: > >> > On Thu, May 03, 2018 at 09:14:41AM -0500, Rob Herring wrote: > >> >> On Thu, May 3, 2018 at 8:47 AM, Sean Paul wrote: > >> >> > On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan wrote: > >> >> >> Use of the sw_sync API is not allowed any more. Until drm_hwcomposer > >> >> >> is > >> >> >> weaned off of sw_sync, build our own copy. > >> >> > > >> >> > I don't think it is used any longer. AFAICT, with 2 seconds of grep, > >> >> > it's > >> >> > referenced in drmcompositorworker.cpp, virtualcompositorworker.cpp, > >> >> > and > >> >> > hwcomposer.cpp > >> >> > > >> >> > I think these are all HWC1 legacy files, so they can probably just > >> >> > get cleaned > >> >> > up. > >> >> > >> >> Are you sure? Doesn't the GL compositor have to wait on the fences of > >> >> the input buffers and create new fences for the GL compositing output > >> >> buffer(s) to pass into the kernel? It looked to me like sw_sync fences > >> >> are used in the latter case and that needs to be converted to use > >> >> eglCreateSyncKHR. > >> > > >> > Hmmm, yeah thanks for pointing that out. It does look like > >> > drmdisplaycomposition > >> > is using sw_sync to handle the GL compositor release fences. > >> > > >> > I'm pretty confident that despite the known issues causing GLC to not > >> > work on > >> > open stacks, there are probably a bunch of unknown issues that have been > >> > introduced while we try to tiptoe around it. > >> > > >> > If anyone wants to remove it, I'd certainly be interested in reviewing > >> > that > >> > patch :-). I'd do it myself, but unfortunately the amount of time I have > >> > to dedicate to drm_hwc at this point is just enough to perform > >> > [incorrect] > >> > reviews. > >> > >> Removing GL compositor or sw_sync? I've already written a patch to do > >> the former. > > > > Removing GL compositor. Is your patch on the list? > > No, I never got around to discussing it. I somewhat figured you would > not be in favor of that. > The writeback series definitely helped sway my opinion. I would really like to have our own super-spiffy GL compositor, since it was a net gain for us. However, in its current state, it's just bringing us down. > I'll need to rebase it as it's about 3 months old now. Cool! I'm relieved I didn't miss it :-) Sean > > Rob -- 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: [PATCH] drm/msm: Don't setup control node debugfs files
On Thu, May 03, 2018 at 11:31:07AM +0200, Daniel Vetter wrote:
> It's going away.
>
> v2: Try harder to find them all.
>
> Signed-off-by: Daniel Vetter
Still
Reviewed-by: Sean Paul
> Cc: Rob Clark
> Cc: Jordan Crouse
> Cc: Nicolas Dechesne
> Cc: Archit Taneja
> Cc: Bjorn Andersson
> Cc: Arnd Bergmann
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 1 -
> drivers/gpu/drm/msm/msm_debugfs.c | 3 ---
> 2 files changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 8e0cb161754b..0ae5ace65462 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -168,7 +168,6 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> if (gpu->funcs->debugfs_init) {
> gpu->funcs->debugfs_init(gpu, dev->primary);
> gpu->funcs->debugfs_init(gpu, dev->render);
> - gpu->funcs->debugfs_init(gpu, dev->control);
> }
> #endif
>
> diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
> b/drivers/gpu/drm/msm/msm_debugfs.c
> index ba74cb4f94df..1ff3fda245d1 100644
> --- a/drivers/gpu/drm/msm/msm_debugfs.c
> +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> @@ -140,9 +140,6 @@ int msm_debugfs_late_init(struct drm_device *dev)
> if (ret)
> return ret;
> ret = late_init_minor(dev->render);
> - if (ret)
> - return ret;
> - ret = late_init_minor(dev->control);
> return ret;
> }
>
> --
> 2.17.0
>
> ___
> 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
[drm_hwc] PSA: drm_hwc submissions via gitlab
Hey all, Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer! Anyways, back to the point. Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things: 1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level. If you're still reading, I'll point out a couple other things: - There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it. - I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry. Thanks for reading, Sean [1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer -- 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: [Intel-gfx] [PATCH] drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear()
On Thu, May 03, 2018 at 01:41:52PM +0300, Ville Syrjälä wrote:
> On Thu, May 03, 2018 at 08:35:30AM +0200, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 09:32:47PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Clear the old_state and new_state pointers for every object in
> > > drm_atomic_state_default_clear(). Otherwise
> > > drm_atomic_get_{new,old}_*_state() will hand out stale pointers to
> > > anyone who hasn't first confirmed that the object is in fact part of
> > > the current atomic transcation, if they are called after we've done
> > > the ww backoff dance while hanging on to the same drm_atomic_state.
> > >
> > > For example, handle_conflicting_encoders() looks like it could hit
> > > this since it iterates the full connector list and just calls
> > > drm_atomic_get_new_connector_state() for each.
> > >
> > > And I believe we have now witnessed this happening at least once in
> > > i915 check_digital_port_conflicts(). Commit 8b69449d2663 ("drm/i915:
> > > Remove last references to drm_atomic_get_existing* macros") changed
> > > the safe drm_atomic_get_existing_connector_state() to the unsafe
> > > drm_atomic_get_new_connector_state(), which opened the doors for
> > > this particular bug there as well.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Cc: Maarten Lankhorst
> > > Cc: Laurent Pinchart
> > > Cc: Abhay Kumar
> > > Fixes: 581e49fe6b41 ("drm/atomic: Add new iterators over all state, v3.")
> > > Signed-off-by: Ville Syrjälä
> >
> > Uh ... that's some bad oversight :-/
> >
> > Reviewed-by: Daniel Vetter
> >
> > btw for stable we might want to split this into 1 patch for core objects
> > and 1 patch for driver private stuff.
>
> Good point. I forgot we did that after the new iterators were
> introduced. I'll do the split.
Pushed the split version for drm-misc-fixes.
As mentioned on irc we don't have any get_{new,old}_private_state()
functions, so the private objs part is pretty theoretical. However
splitting does have the benefit of (hopefully) not requiring manual
intervention when someone tries to cherry-pick this to 4.12/4.13.
Thanks for the reviews.
>
> > Feel free to do so while applying
> > and keep my r-b. The fixes line for the 2nd patch would be:
> >
> > Fixes: a4370c777406 ("drm/atomic: Make private objs proper objects")
> > Cc: # v4.14+
>
> Ta.
>
> >
> > Cheers, Daniel
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 7d25c42f22db..c825c76edc1d 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -155,6 +155,8 @@ void drm_atomic_state_default_clear(struct
> > > drm_atomic_state *state)
> > >
> > > state->connectors[i].state);
> > > state->connectors[i].ptr = NULL;
> > > state->connectors[i].state = NULL;
> > > + state->connectors[i].old_state = NULL;
> > > + state->connectors[i].new_state = NULL;
> > > drm_connector_put(connector);
> > > }
> > >
> > > @@ -169,6 +171,8 @@ void drm_atomic_state_default_clear(struct
> > > drm_atomic_state *state)
> > >
> > > state->crtcs[i].ptr = NULL;
> > > state->crtcs[i].state = NULL;
> > > + state->crtcs[i].old_state = NULL;
> > > + state->crtcs[i].new_state = NULL;
> > > }
> > >
> > > for (i = 0; i < config->num_total_plane; i++) {
> > > @@ -181,6 +185,8 @@ void drm_atomic_state_default_clear(struct
> > > drm_atomic_state *state)
> > > state->planes[i].state);
> > > state->planes[i].ptr = NULL;
> > > state->planes[i].state = NULL;
> > > + state->planes[i].old_state = NULL;
> > > + state->planes[i].new_state = NULL;
> > > }
> > >
> > > for (i = 0; i < state->num_private_objs; i++) {
> > > @@ -190,6 +196,8 @@ void drm_atomic_state_default_clear(struct
> > > drm_atomic_state *state)
> > >state->private_objs[i].state);
> > > state->private_objs[i].ptr = NULL;
> > > state->private_objs[i].state = NULL;
> > > + state->private_objs[i].old_state = NULL;
> > > + state->private_objs[i].new_state = NULL;
> > > }
> > > state->num_private_objs = 0;
> > >
> > > --
> > > 2.16.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
Re: [PATCH 2/3] drm_hwcomposer: Stop using libsync to provide sw_sync wrappers
On Thu, May 03, 2018 at 09:39:31AM -0500, Rob Herring wrote: > On Thu, May 3, 2018 at 9:32 AM, Sean Paul wrote: > > On Thu, May 03, 2018 at 09:14:41AM -0500, Rob Herring wrote: > >> On Thu, May 3, 2018 at 8:47 AM, Sean Paul wrote: > >> > On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan wrote: > >> >> Use of the sw_sync API is not allowed any more. Until drm_hwcomposer is > >> >> weaned off of sw_sync, build our own copy. > >> > > >> > I don't think it is used any longer. AFAICT, with 2 seconds of grep, it's > >> > referenced in drmcompositorworker.cpp, virtualcompositorworker.cpp, and > >> > hwcomposer.cpp > >> > > >> > I think these are all HWC1 legacy files, so they can probably just get > >> > cleaned > >> > up. > >> > >> Are you sure? Doesn't the GL compositor have to wait on the fences of > >> the input buffers and create new fences for the GL compositing output > >> buffer(s) to pass into the kernel? It looked to me like sw_sync fences > >> are used in the latter case and that needs to be converted to use > >> eglCreateSyncKHR. > > > > Hmmm, yeah thanks for pointing that out. It does look like > > drmdisplaycomposition > > is using sw_sync to handle the GL compositor release fences. > > > > I'm pretty confident that despite the known issues causing GLC to not work > > on > > open stacks, there are probably a bunch of unknown issues that have been > > introduced while we try to tiptoe around it. > > > > If anyone wants to remove it, I'd certainly be interested in reviewing that > > patch :-). I'd do it myself, but unfortunately the amount of time I have > > to dedicate to drm_hwc at this point is just enough to perform [incorrect] > > reviews. > > Removing GL compositor or sw_sync? I've already written a patch to do > the former. Removing GL compositor. Is your patch on the list? Sean > > Rob -- 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: [PATCH v2] drm/pl111: Fix module probe bug
On Thu, May 03, 2018 at 04:04:31PM +0200, Linus Walleij wrote:
> Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
> Added a second module using the builtin_platform_driver() call,
> which works fine as long as you do not try to build the PL111
> driver as a module, because a module can only have one initcall
> and cause the following build bug:
>
> (...) multiple definition of `init_module' (...)
>
> Reported-by: Daniel Vetter
> Cc: Liviu Dudau
> Cc: Pawel Moll
> Cc: Eric Anholt
> Cc: Robin Murphy
> Fixes: a30933c27602 ("drm/pl111: Support the Versatile Express")
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - In my stress I missed that if there are several CLCD instances
> on the board the platform_driver_register() call will return
> -EBUSY so we need to ignore that explicitly, all we want is to
> register the driver at least once.
> ---
> drivers/gpu/drm/pl111/pl111_versatile.c | 7 +++
> drivers/gpu/drm/pl111/pl111_vexpress.c | 12 ++--
> drivers/gpu/drm/pl111/pl111_vexpress.h | 7 +++
> 3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
> b/drivers/gpu/drm/pl111/pl111_versatile.c
> index 78ddf8534fd2..ad769e3e9fd3 100644
> --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> @@ -326,6 +326,13 @@ int pl111_versatile_init(struct device *dev, struct
> pl111_drm_dev_private *priv)
> if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
> struct platform_device *pdev;
>
> + /* Registers a driver for the muxfpga */
> + ret = vexpress_muxfpga_init();
> + if (ret) {
> + dev_err(dev, "unable to intialize muxfpga driver\n");
> + return ret;
> + }
> +
> /* Call into deep Vexpress configuration API */
> pdev = of_find_device_by_node(np);
> if (!pdev) {
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c
> b/drivers/gpu/drm/pl111/pl111_vexpress.c
> index c9fee625faf1..c30f63cd66a8 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.c
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
> @@ -106,7 +106,6 @@ static int vexpress_muxfpga_probe(struct platform_device
> *pdev)
> if (IS_ERR(map))
> return PTR_ERR(map);
> dev_set_drvdata(dev, map);
> -
nit: unrelated whitespace change
> return 0;
> }
>
> @@ -122,4 +121,13 @@ static struct platform_driver vexpress_muxfpga_driver = {
> .probe = vexpress_muxfpga_probe,
> };
>
> -builtin_platform_driver(vexpress_muxfpga_driver);
> +int vexpress_muxfpga_init(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&vexpress_muxfpga_driver);
> + /* -EBUSY just means this driver is already registered */
> + if (ret && ret != -EBUSY)
> + return ret;
> + return 0;
fwiw, i think it'd be cleaner to do:
/* -EBUSY just means this driver is already registered */
if (ret == -EBUSY)
ret = 0;
return ret;
or if you're one of those people who doesn't mind inline conditionals:
/* -EBUSY just means this driver is already registered */
return ret == -EBUSY ? 0 : ret;
Anyways, just verbalizing my personal code style. With the whitespace fix,
Reviewed-by: Sean Paul
> +}
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.h
> b/drivers/gpu/drm/pl111/pl111_vexpress.h
> index 49876417f7b6..40fbe42369dc 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.h
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.h
> @@ -10,6 +10,8 @@ int pl111_vexpress_clcd_init(struct device *dev,
>struct pl111_drm_dev_private *priv,
>struct regmap *map);
>
> +int vexpress_muxfpga_init(void);
> +
> #else
>
> static int inline pl111_vexpress_clcd_init(struct device *dev,
> @@ -19,4 +21,9 @@ static int inline pl111_vexpress_clcd_init(struct device
> *dev,
> return -ENODEV;
> }
>
> +static inline int vexpress_muxfpga_init(void)
> +{
> + return 0;
> +}
> +
> #endif
> --
> 2.17.0
>
--
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: [PATCH 2/3] drm_hwcomposer: Stop using libsync to provide sw_sync wrappers
On Thu, May 03, 2018 at 09:14:41AM -0500, Rob Herring wrote: > On Thu, May 3, 2018 at 8:47 AM, Sean Paul wrote: > > On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan wrote: > >> Use of the sw_sync API is not allowed any more. Until drm_hwcomposer is > >> weaned off of sw_sync, build our own copy. > > > > I don't think it is used any longer. AFAICT, with 2 seconds of grep, it's > > referenced in drmcompositorworker.cpp, virtualcompositorworker.cpp, and > > hwcomposer.cpp > > > > I think these are all HWC1 legacy files, so they can probably just get > > cleaned > > up. > > Are you sure? Doesn't the GL compositor have to wait on the fences of > the input buffers and create new fences for the GL compositing output > buffer(s) to pass into the kernel? It looked to me like sw_sync fences > are used in the latter case and that needs to be converted to use > eglCreateSyncKHR. Hmmm, yeah thanks for pointing that out. It does look like drmdisplaycomposition is using sw_sync to handle the GL compositor release fences. I'm pretty confident that despite the known issues causing GLC to not work on open stacks, there are probably a bunch of unknown issues that have been introduced while we try to tiptoe around it. If anyone wants to remove it, I'd certainly be interested in reviewing that patch :-). I'd do it myself, but unfortunately the amount of time I have to dedicate to drm_hwc at this point is just enough to perform [incorrect] reviews. Sean > > Rob -- 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: [PATCH] backlight: remove obsolete comment for ->state
On Thu, May 03, 2018 at 04:15:17PM +0200, Daniel Vetter wrote:
> Jani spotted this when reviewing my earlier patch to remove the driver
> internal usage of this field in
>
> commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
> Author: Daniel Vetter
> Date: Wed Apr 25 19:42:52 2018 +0200
>
> backlight: Nuke BL_CORE_DRIVER1
>
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
Acked-by: Daniel Thompson
> ---
> include/linux/backlight.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 7fbf0539e14a..0b5897446dca 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -79,7 +79,6 @@ struct backlight_properties {
> /* Backlight type */
> enum backlight_type type;
> /* Flags used to signal drivers of state changes */
> - /* Upper 4 bits are reserved for driver internal use */
> unsigned int state;
>
> #define BL_CORE_SUSPENDED(1 << 0)/* backlight is suspended */
> --
> 2.17.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/15] drm/virtio: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 23353521f903..00c742a441bf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -36,11 +36,6 @@ static const char *virtio_get_timeline_name(struct dma_fence
*f)
return "controlq";
}
-static bool virtio_enable_signaling(struct dma_fence *f)
-{
- return true;
-}
-
static bool virtio_signaled(struct dma_fence *f)
{
struct virtio_gpu_fence *fence = to_virtio_fence(f);
@@ -67,9 +62,7 @@ static void virtio_timeline_value_str(struct dma_fence *f,
char *str, int size)
static const struct dma_fence_ops virtio_fence_ops = {
.get_driver_name = virtio_get_driver_name,
.get_timeline_name = virtio_get_timeline_name,
- .enable_signaling= virtio_enable_signaling,
.signaled= virtio_signaled,
- .wait= dma_fence_default_wait,
.fence_value_str = virtio_fence_value_str,
.timeline_value_str = virtio_timeline_value_str,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/15] dma-fence: Polish kernel-doc for dma-fence.c
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
Documentation/driver-api/dma-buf.rst | 6 ++
drivers/dma-buf/dma-fence.c | 140 ++-
2 files changed, 102 insertions(+), 44 deletions(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index dc384f2f7f34..b541e97c7ab1 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -130,6 +130,12 @@ Reservation Objects
DMA Fences
--
+.. kernel-doc:: drivers/dma-buf/dma-fence.c
+ :doc: DMA fences overview
+
+DMA Fences Functions Reference
+~~
+
.. kernel-doc:: drivers/dma-buf/dma-fence.c
:export:
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 41ec19c9efc7..0387c6a59055 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -38,12 +38,43 @@ EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
*/
static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
+/**
+ * DOC: DMA fences overview
+ *
+ * DMA fences, represented by &struct dma_fence, are the kernel internal
+ * synchronization primitive for DMA operations like GPU rendering, video
+ * encoding/decoding, or displaying buffers on a screen.
+ *
+ * A fence is initialized using dma_fence_init() and completed using
+ * dma_fence_signal(). Fences are associated with a context, allocated through
+ * dma_fence_context_alloc(), and all fences on the same context are
+ * fully ordered.
+ *
+ * Since the purposes of fences is to facilitate cross-device and
+ * cross-application synchronization, there's multiple ways to use one:
+ *
+ * - Individual fences can be exposed as a &sync_file, accessed as a file
+ * descriptor from userspace, created by calling sync_file_create(). This is
+ * called explicit fencing, since userspace passes around explicit
+ * synchronization points.
+ *
+ * - Some subsystems also have their own explicit fencing primitives, like
+ * &drm_syncobj. Compared to &sync_file, a &drm_syncobj allows the underlying
+ * fence to be updated.
+ *
+ * - Then there's also implicit fencing, where the synchronization points are
+ * implicitly passed around as part of shared &dma_buf instances. Such
+ * implicit fences are stored in &struct reservation_object through the
+ * &dma_buf.resv pointer.
+ */
+
/**
* dma_fence_context_alloc - allocate an array of fence contexts
- * @num: [in]amount of contexts to allocate
+ * @num: amount of contexts to allocate
*
- * This function will return the first index of the number of fences allocated.
- * The fence context is used for setting fence->context to a unique number.
+ * This function will return the first index of the number of fence contexts
+ * allocated. The fence context is used for setting &dma_fence.context to a
+ * unique number by passing the context to dma_fence_init().
*/
u64 dma_fence_context_alloc(unsigned num)
{
@@ -59,10 +90,14 @@ EXPORT_SYMBOL(dma_fence_context_alloc);
* Signal completion for software callbacks on a fence, this will unblock
* dma_fence_wait() calls and run all the callbacks added with
* dma_fence_add_callback(). Can be called multiple times, but since a fence
- * can only go from unsignaled to signaled state, it will only be effective
- * the first time.
+ * can only go from the unsignaled to the signaled state and not back, it will
+ * only be effective the first time.
*
- * Unlike dma_fence_signal, this function must be called with fence->lock held.
+ * Unlike dma_fence_signal(), this function must be called with &dma_fence.lock
+ * held.
+ *
+ * Returns 0 on success and a negative error value when @fence has been
+ * signalled already.
*/
int dma_fence_signal_locked(struct dma_fence *fence)
{
@@ -102,8 +137,11 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
* Signal completion for software callbacks on a fence, this will unblock
* dma_fence_wait() calls and run all the callbacks added with
* dma_fence_add_callback(). Can be called multiple times, but since a fence
- * can only go from unsignaled to signaled state, it will only be effective
- * the first time.
+ * can only go from the unsignaled to the signaled state and not back, it will
+ * only be effective the first time.
+ *
+ * Returns 0 on success and a negative error value when @fence has been
+ * signalled already.
*/
int dma_fence_signal(struct dma_fence *fence)
{
@@ -136,9 +174,9 @@ EXPORT_SYMBOL(dma_fence_signal);
/**
* dma_fence_wait_timeout - sleep until the fence gets signaled
* or until timeout elapses
- * @fence: [in]the fence to wait on
- * @intr: [in]if true, do an interruptible wait
- * @timeout: [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEO
[PATCH 08/15] drm/i915: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Colin Ian King
Cc: Daniel Vetter
Cc: Mika Kuoppala
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_gem_clflush.c| 7 ---
drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 7 ---
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c
b/drivers/gpu/drm/i915/i915_gem_clflush.c
index f5c570d35b2a..8e74c23cbd91 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
@@ -45,11 +45,6 @@ static const char *i915_clflush_get_timeline_name(struct
dma_fence *fence)
return "clflush";
}
-static bool i915_clflush_enable_signaling(struct dma_fence *fence)
-{
- return true;
-}
-
static void i915_clflush_release(struct dma_fence *fence)
{
struct clflush *clflush = container_of(fence, typeof(*clflush), dma);
@@ -63,8 +58,6 @@ static void i915_clflush_release(struct dma_fence *fence)
static const struct dma_fence_ops i915_clflush_ops = {
.get_driver_name = i915_clflush_get_driver_name,
.get_timeline_name = i915_clflush_get_timeline_name,
- .enable_signaling = i915_clflush_enable_signaling,
- .wait = dma_fence_default_wait,
.release = i915_clflush_release,
};
diff --git a/drivers/gpu/drm/i915/selftests/i915_sw_fence.c
b/drivers/gpu/drm/i915/selftests/i915_sw_fence.c
index 570e325af93e..0c02446f613d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/selftests/i915_sw_fence.c
@@ -611,16 +611,9 @@ static const char *mock_name(struct dma_fence *fence)
return "mock";
}
-static bool mock_enable_signaling(struct dma_fence *fence)
-{
- return true;
-}
-
static const struct dma_fence_ops mock_fence_ops = {
.get_driver_name = mock_name,
.get_timeline_name = mock_name,
- .enable_signaling = mock_enable_signaling,
- .wait = dma_fence_default_wait,
.release = dma_fence_free,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/15] drm/vgem: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Also remove the ->signaled callback, vgem can't peek ahead with a
fastpath, returning false is the default implementation.
Signed-off-by: Daniel Vetter
Cc: Kees Cook
Cc: Cihangir Akturk
Cc: Sean Paul
Cc: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_fence.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c
b/drivers/gpu/drm/vgem/vgem_fence.c
index b28876c222b4..75adedeaa384 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -43,16 +43,6 @@ static const char *vgem_fence_get_timeline_name(struct
dma_fence *fence)
return "unbound";
}
-static bool vgem_fence_signaled(struct dma_fence *fence)
-{
- return false;
-}
-
-static bool vgem_fence_enable_signaling(struct dma_fence *fence)
-{
- return true;
-}
-
static void vgem_fence_release(struct dma_fence *base)
{
struct vgem_fence *fence = container_of(base, typeof(*fence), base);
@@ -76,11 +66,7 @@ static void vgem_fence_timeline_value_str(struct dma_fence
*fence, char *str,
static const struct dma_fence_ops vgem_fence_ops = {
.get_driver_name = vgem_fence_get_driver_name,
.get_timeline_name = vgem_fence_get_timeline_name,
- .enable_signaling = vgem_fence_enable_signaling,
- .signaled = vgem_fence_signaled,
- .wait = dma_fence_default_wait,
.release = vgem_fence_release,
-
.fence_value_str = vgem_fence_value_str,
.timeline_value_str = vgem_fence_timeline_value_str,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/15] drm/nouveau: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now.
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 503fa94dc06d..444bbde65344 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -527,6 +527,5 @@ static const struct dma_fence_ops nouveau_fence_ops_uevent
= {
.get_timeline_name = nouveau_fence_get_timeline_name,
.enable_signaling = nouveau_fence_enable_signaling,
.signaled = nouveau_fence_is_signaled,
- .wait = dma_fence_default_wait,
.release = nouveau_fence_release
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/15] drm/vc4: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_fence.c b/drivers/gpu/drm/vc4/vc4_fence.c
index dbf5a5a5d5f5..9f40c0ddadc4 100644
--- a/drivers/gpu/drm/vc4/vc4_fence.c
+++ b/drivers/gpu/drm/vc4/vc4_fence.c
@@ -33,11 +33,6 @@ static const char *vc4_fence_get_timeline_name(struct
dma_fence *fence)
return "vc4-v3d";
}
-static bool vc4_fence_enable_signaling(struct dma_fence *fence)
-{
- return true;
-}
-
static bool vc4_fence_signaled(struct dma_fence *fence)
{
struct vc4_fence *f = to_vc4_fence(fence);
@@ -49,8 +44,6 @@ static bool vc4_fence_signaled(struct dma_fence *fence)
const struct dma_fence_ops vc4_fence_ops = {
.get_driver_name = vc4_fence_get_driver_name,
.get_timeline_name = vc4_fence_get_timeline_name,
- .enable_signaling = vc4_fence_enable_signaling,
.signaled = vc4_fence_signaled,
- .wait = dma_fence_default_wait,
.release = dma_fence_free,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/15] drm/qxl: Remove unecessary dma_fence_ops
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 7cb214577275..e37f0097f744 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -50,12 +50,6 @@ static const char *qxl_get_timeline_name(struct dma_fence
*fence)
return "release";
}
-static bool qxl_nop_signaling(struct dma_fence *fence)
-{
- /* fences are always automatically signaled, so just pretend we did
this.. */
- return true;
-}
-
static long qxl_fence_wait(struct dma_fence *fence, bool intr,
signed long timeout)
{
@@ -119,7 +113,6 @@ static long qxl_fence_wait(struct dma_fence *fence, bool
intr,
static const struct dma_fence_ops qxl_fence_ops = {
.get_driver_name = qxl_get_driver_name,
.get_timeline_name = qxl_get_timeline_name,
- .enable_signaling = qxl_nop_signaling,
.wait = qxl_fence_wait,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/15] drm/msm: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/msm_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
index 349c12f670eb..6076f55a603c 100644
--- a/drivers/gpu/drm/msm/msm_fence.c
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -119,11 +119,6 @@ static const char *msm_fence_get_timeline_name(struct
dma_fence *fence)
return f->fctx->name;
}
-static bool msm_fence_enable_signaling(struct dma_fence *fence)
-{
- return true;
-}
-
static bool msm_fence_signaled(struct dma_fence *fence)
{
struct msm_fence *f = to_msm_fence(fence);
@@ -133,9 +128,7 @@ static bool msm_fence_signaled(struct dma_fence *fence)
static const struct dma_fence_ops msm_fence_ops = {
.get_driver_name = msm_fence_get_driver_name,
.get_timeline_name = msm_fence_get_timeline_name,
- .enable_signaling = msm_fence_enable_signaling,
.signaled = msm_fence_signaled,
- .wait = dma_fence_default_wait,
.release = dma_fence_free,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/15] drm/etnaviv: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Acked-by: Lucas Stach
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 8a88799bf79b..b78d9f49aa23 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1038,11 +1038,6 @@ static const char
*etnaviv_fence_get_timeline_name(struct dma_fence *fence)
return dev_name(f->gpu->dev);
}
-static bool etnaviv_fence_enable_signaling(struct dma_fence *fence)
-{
- return true;
-}
-
static bool etnaviv_fence_signaled(struct dma_fence *fence)
{
struct etnaviv_fence *f = to_etnaviv_fence(fence);
@@ -1060,9 +1055,7 @@ static void etnaviv_fence_release(struct dma_fence *fence)
static const struct dma_fence_ops etnaviv_fence_ops = {
.get_driver_name = etnaviv_fence_get_driver_name,
.get_timeline_name = etnaviv_fence_get_timeline_name,
- .enable_signaling = etnaviv_fence_enable_signaling,
.signaled = etnaviv_fence_signaled,
- .wait = dma_fence_default_wait,
.release = etnaviv_fence_release,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/15] dma-fence: remove fill_driver_data callback
Noticed while I was typing docs. Entirely unused.
v2: Remove reference in @timeline_value_str too. While at it clarify
why timeline_value_str has a fence parameter - we don't have an
explicit timeline structure unfortunately.
Cc: Eric Anholt
Reviewed-by: Eric Anholt
Reviewed-by: Christian König (v1)
Cc: Christian König (v1)
Signed-off-by: Daniel Vetter
---
include/linux/dma-fence.h | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index eb9b05aa5aea..111aefe1c956 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -217,17 +217,6 @@ struct dma_fence_ops {
*/
void (*release)(struct dma_fence *fence);
- /**
-* @fill_driver_data:
-*
-* Callback to fill in free-form debug info.
-*
-* Returns amount of bytes filled, or negative error on failure.
-*
-* This callback is optional.
-*/
- int (*fill_driver_data)(struct dma_fence *fence, void *data, int size);
-
/**
* @fence_value_str:
*
@@ -242,8 +231,9 @@ struct dma_fence_ops {
* @timeline_value_str:
*
* Fills in the current value of the timeline as a string, like the
-* sequence number. This should match what @fill_driver_data prints for
-* the most recently signalled fence (assuming no delayed signalling).
+* sequence number. Note that the specific fence passed to this function
+* should not matter, drivers should only use it to look up the
+* corresponding timeline structures.
*/
void (*timeline_value_str)(struct dma_fence *fence,
char *str, int size);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/15] drm: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 7 ---
drivers/gpu/drm/drm_syncobj.c | 1 -
drivers/gpu/drm/scheduler/sched_fence.c | 11 ---
3 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a231dd5dce16..e4d3285f4191 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -225,16 +225,9 @@ static const char *drm_crtc_fence_get_timeline_name(struct
dma_fence *fence)
return crtc->timeline_name;
}
-static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
-{
- return true;
-}
-
static const struct dma_fence_ops drm_crtc_fence_ops = {
.get_driver_name = drm_crtc_fence_get_driver_name,
.get_timeline_name = drm_crtc_fence_get_timeline_name,
- .enable_signaling = drm_crtc_fence_enable_signaling,
- .wait = dma_fence_default_wait,
};
struct dma_fence *drm_crtc_create_fence(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index d4f4ce484529..adb3cb27d31e 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -207,7 +207,6 @@ static const struct dma_fence_ops
drm_syncobj_null_fence_ops = {
.get_driver_name = drm_syncobj_null_fence_get_name,
.get_timeline_name = drm_syncobj_null_fence_get_name,
.enable_signaling = drm_syncobj_null_fence_enable_signaling,
- .wait = dma_fence_default_wait,
.release = NULL,
};
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
b/drivers/gpu/drm/scheduler/sched_fence.c
index 69aab086b913..4843289cc8f0 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -81,11 +81,6 @@ static const char *drm_sched_fence_get_timeline_name(struct
dma_fence *f)
return (const char *)fence->sched->name;
}
-static bool drm_sched_fence_enable_signaling(struct dma_fence *f)
-{
- return true;
-}
-
/**
* amd_sched_fence_free - free up the fence memory
*
@@ -134,18 +129,12 @@ static void drm_sched_fence_release_finished(struct
dma_fence *f)
const struct dma_fence_ops drm_sched_fence_ops_scheduled = {
.get_driver_name = drm_sched_fence_get_driver_name,
.get_timeline_name = drm_sched_fence_get_timeline_name,
- .enable_signaling = drm_sched_fence_enable_signaling,
- .signaled = NULL,
- .wait = dma_fence_default_wait,
.release = drm_sched_fence_release_scheduled,
};
const struct dma_fence_ops drm_sched_fence_ops_finished = {
.get_driver_name = drm_sched_fence_get_driver_name,
.get_timeline_name = drm_sched_fence_get_timeline_name,
- .enable_signaling = drm_sched_fence_enable_signaling,
- .signaled = NULL,
- .wait = dma_fence_default_wait,
.release = drm_sched_fence_release_finished,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/15] dma-fence cleanup v2
Hi all, Resending the entire pile because I shrugged of some CI noise which wasn't noise. Silly me :-/ Besides the BUG_ON that also Chris spotted just minor changes, which I did send out individually already. As always, feedback very much welcome. Thanks, Daniel Daniel Vetter (15): dma-fence: remove fill_driver_data callback dma-fence: Make ->enable_signaling optional dma-fence: Allow wait_any_timeout for all fences dma-fence: Make ->wait callback optional drm/amdgpu: Remove unecessary dma_fence_ops drm: Remove unecessary dma_fence_ops drm/etnaviv: Remove unecessary dma_fence_ops drm/i915: Remove unecessary dma_fence_ops drm/msm: Remove unecessary dma_fence_ops drm/nouveau: Remove unecessary dma_fence_ops drm/qxl: Remove unecessary dma_fence_ops drm/vc4: Remove unecessary dma_fence_ops drm/vgem: Remove unecessary dma_fence_ops drm/virtio: Remove unecessary dma_fence_ops dma-fence: Polish kernel-doc for dma-fence.c Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-fence-array.c | 1 - drivers/dma-buf/dma-fence.c | 164 -- drivers/dma-buf/sw_sync.c | 1 - .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 1 - drivers/gpu/drm/drm_crtc.c| 7 - drivers/gpu/drm/drm_syncobj.c | 1 - drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 - drivers/gpu/drm/i915/i915_gem_clflush.c | 7 - .../gpu/drm/i915/selftests/i915_sw_fence.c| 7 - drivers/gpu/drm/msm/msm_fence.c | 7 - drivers/gpu/drm/nouveau/nouveau_fence.c | 1 - drivers/gpu/drm/qxl/qxl_release.c | 7 - drivers/gpu/drm/scheduler/sched_fence.c | 11 -- drivers/gpu/drm/vc4/vc4_fence.c | 7 - drivers/gpu/drm/vgem/vgem_fence.c | 14 -- drivers/gpu/drm/virtio/virtgpu_fence.c| 7 - include/linux/dma-fence.h | 32 ++-- 19 files changed, 131 insertions(+), 159 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/15] dma-fence: Allow wait_any_timeout for all fences
When this was introduced in
commit a519435a96597d8cd96123246fea4ae5a6c90b02
Author: Christian König
Date: Tue Oct 20 16:34:16 2015 +0200
dma-buf/fence: add fence_wait_any_timeout function v2
there was a restriction added that this only works if the dma-fence
uses the dma_fence_default_wait hook. Which works for amdgpu, which is
the only caller. Well, until you share some buffers with e.g. i915,
then you get an -EINVAL.
But there's really no reason for this, because all drivers must
support callbacks. The special ->wait hook is only as an optimization;
if the driver needs to create a worker thread for an active callback,
then it can avoid to do that if it knows that there's a process
context available already. So ->wait is just an optimization, just
using the logic in dma_fence_default_wait() should work for all
drivers.
Let's remove this restriction.
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Christian König
Cc: Alex Deucher
---
drivers/dma-buf/dma-fence.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 7b5b40d6b70e..59049375bd19 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -503,11 +503,6 @@ dma_fence_wait_any_timeout(struct dma_fence **fences,
uint32_t count,
for (i = 0; i < count; ++i) {
struct dma_fence *fence = fences[i];
- if (fence->ops->wait != dma_fence_default_wait) {
- ret = -EINVAL;
- goto fence_rm_cb;
- }
-
cb[i].task = current;
if (dma_fence_add_callback(fence, &cb[i].base,
dma_fence_default_wait_cb)) {
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/15] drm/amdgpu: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now.
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: Monk Liu
Cc: pding
Cc: Andrey Grodzovsky
Cc: Evan Quan
Cc: Daniel Vetter
Cc: Kees Cook
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c| 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
index 2c14025e5e76..574c1181ae9a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
@@ -173,7 +173,5 @@ static const struct dma_fence_ops amdkfd_fence_ops = {
.get_driver_name = amdkfd_fence_get_driver_name,
.get_timeline_name = amdkfd_fence_get_timeline_name,
.enable_signaling = amdkfd_fence_enable_signaling,
- .signaled = NULL,
- .wait = dma_fence_default_wait,
.release = amdkfd_fence_release,
};
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 97449e06a242..9dbbd69dd2b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -645,7 +645,6 @@ static const struct dma_fence_ops amdgpu_fence_ops = {
.get_driver_name = amdgpu_fence_get_driver_name,
.get_timeline_name = amdgpu_fence_get_timeline_name,
.enable_signaling = amdgpu_fence_enable_signaling,
- .wait = dma_fence_default_wait,
.release = amdgpu_fence_release,
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/15] dma-fence: Make ->wait callback optional
Almost everyone uses dma_fence_default_wait.
v2: Also remove the BUG_ON(!ops->wait) (Chris).
Reviewed-by: Christian König (v1)
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-fence-array.c | 1 -
drivers/dma-buf/dma-fence.c | 8 +---
drivers/dma-buf/sw_sync.c | 1 -
include/linux/dma-fence.h | 13 -
4 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index dd1edfb27b61..a8c254497251 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -104,7 +104,6 @@ const struct dma_fence_ops dma_fence_array_ops = {
.get_timeline_name = dma_fence_array_get_timeline_name,
.enable_signaling = dma_fence_array_enable_signaling,
.signaled = dma_fence_array_signaled,
- .wait = dma_fence_default_wait,
.release = dma_fence_array_release,
};
EXPORT_SYMBOL(dma_fence_array_ops);
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 59049375bd19..41ec19c9efc7 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -158,7 +158,10 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr,
signed long timeout)
return -EINVAL;
trace_dma_fence_wait_start(fence);
- ret = fence->ops->wait(fence, intr, timeout);
+ if (fence->ops->wait)
+ ret = fence->ops->wait(fence, intr, timeout);
+ else
+ ret = dma_fence_default_wait(fence, intr, timeout);
trace_dma_fence_wait_end(fence);
return ret;
}
@@ -562,8 +565,7 @@ dma_fence_init(struct dma_fence *fence, const struct
dma_fence_ops *ops,
spinlock_t *lock, u64 context, unsigned seqno)
{
BUG_ON(!lock);
- BUG_ON(!ops || !ops->wait ||
- !ops->get_driver_name || !ops->get_timeline_name);
+ BUG_ON(!ops || !ops->get_driver_name || !ops->get_timeline_name);
kref_init(&fence->refcount);
fence->ops = ops;
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 3d78ca89a605..53c1d6d36a64 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -188,7 +188,6 @@ static const struct dma_fence_ops timeline_fence_ops = {
.get_timeline_name = timeline_fence_get_timeline_name,
.enable_signaling = timeline_fence_enable_signaling,
.signaled = timeline_fence_signaled,
- .wait = dma_fence_default_wait,
.release = timeline_fence_release,
.fence_value_str = timeline_fence_value_str,
.timeline_value_str = timeline_fence_timeline_value_str,
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index c053d19e1e24..02dba8cd033d 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -191,11 +191,14 @@ struct dma_fence_ops {
/**
* @wait:
*
-* Custom wait implementation, or dma_fence_default_wait.
+* Custom wait implementation, defaults to dma_fence_default_wait() if
+* not set.
*
-* Must not be NULL, set to dma_fence_default_wait for default
implementation.
-* the dma_fence_default_wait implementation should work for any fence,
as long
-* as enable_signaling works correctly.
+* The dma_fence_default_wait implementation should work for any fence,
as long
+* as @enable_signaling works correctly. This hook allows drivers to
+* have an optimized version for the case where a process context is
+* already available, e.g. if @enable_signaling for the general case
+* needs to set up a worker thread.
*
* Must return -ERESTARTSYS if the wait is intr = true and the wait was
* interrupted, and remaining jiffies if fence has signaled, or 0 if
wait
@@ -203,7 +206,7 @@ struct dma_fence_ops {
* which should be treated as if the fence is signaled. For example a
hardware
* lockup could be reported like that.
*
-* This callback is mandatory.
+* This callback is optional.
*/
signed long (*wait)(struct dma_fence *fence,
bool intr, signed long timeout);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/15] dma-fence: Make ->enable_signaling optional
Many drivers have a trivial implementation for ->enable_signaling.
Let's make it optional by assuming that signalling is already
available when the callback isn't present.
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-fence.c | 13 -
include/linux/dma-fence.h | 3 ++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 4edb9fd3cf47..7b5b40d6b70e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -181,6 +181,13 @@ void dma_fence_release(struct kref *kref)
}
EXPORT_SYMBOL(dma_fence_release);
+/**
+ * dma_fence_free - default release function for &dma_fence.
+ * @fence: fence to release
+ *
+ * This is the default implementation for &dma_fence_ops.release. It calls
+ * kfree_rcu() on @fence.
+ */
void dma_fence_free(struct dma_fence *fence)
{
kfree_rcu(fence, rcu);
@@ -560,7 +567,7 @@ dma_fence_init(struct dma_fence *fence, const struct
dma_fence_ops *ops,
spinlock_t *lock, u64 context, unsigned seqno)
{
BUG_ON(!lock);
- BUG_ON(!ops || !ops->wait || !ops->enable_signaling ||
+ BUG_ON(!ops || !ops->wait ||
!ops->get_driver_name || !ops->get_timeline_name);
kref_init(&fence->refcount);
@@ -572,6 +579,10 @@ dma_fence_init(struct dma_fence *fence, const struct
dma_fence_ops *ops,
fence->flags = 0UL;
fence->error = 0;
+ if (!ops->enable_signaling)
+ set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+ &fence->flags);
+
trace_dma_fence_init(fence);
}
EXPORT_SYMBOL(dma_fence_init);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 111aefe1c956..c053d19e1e24 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -166,7 +166,8 @@ struct dma_fence_ops {
* released when the fence is signalled (through e.g. the interrupt
* handler).
*
-* This callback is mandatory.
+* This callback is optional. If this callback is not present, then the
+* driver must always have signaling enabled.
*/
bool (*enable_signaling)(struct dma_fence *fence);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight: remove obsolete comment for ->state
Jani spotted this when reviewing my earlier patch to remove the driver
internal usage of this field in
commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
Author: Daniel Vetter
Date: Wed Apr 25 19:42:52 2018 +0200
backlight: Nuke BL_CORE_DRIVER1
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
include/linux/backlight.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 7fbf0539e14a..0b5897446dca 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -79,7 +79,6 @@ struct backlight_properties {
/* Backlight type */
enum backlight_type type;
/* Flags used to signal drivers of state changes */
- /* Upper 4 bits are reserved for driver internal use */
unsigned int state;
#define BL_CORE_SUSPENDED (1 << 0)/* backlight is suspended */
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pl111: Fix module probe bug
On Thu, May 3, 2018 at 3:43 PM, Daniel Vetter wrote:
> On Thu, May 03, 2018 at 03:40:53PM +0200, Linus Walleij wrote:
>> Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
>> Added a second module using the builtin_platform_driver() call,
>> which works fine as long as you do not try to build the PL111
>> driver as a module, because a module can only have one initcall
>> and cause the following build bug:
>>
>> (...) multiple definition of `init_module' (...)
>>
>> Reported-by: Daniel Vetter
>> Cc: Liviu Dudau
>> Cc: Pawel Moll
>> Cc: Eric Anholt
>> Cc: Robin Murphy
>> Fixes: a30933c27602 ("drm/pl111: Support the Versatile Express")
>> Signed-off-by: Linus Walleij
>
> lgtm. Please also reenable the pl111 driver in the drm-rerere branch, you
> can simple revert 17c11b73c2ea6a21eaad5c1f5d358054c9e2c2f6.
>
> Reviewed-by: Daniel Vetter
Thanks Daniel, hope I can count that Review tag for v2 as well.
Will apply and push later tonight unless I have done more mistakes.
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/pl111: Fix module probe bug
Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
Added a second module using the builtin_platform_driver() call,
which works fine as long as you do not try to build the PL111
driver as a module, because a module can only have one initcall
and cause the following build bug:
(...) multiple definition of `init_module' (...)
Reported-by: Daniel Vetter
Cc: Liviu Dudau
Cc: Pawel Moll
Cc: Eric Anholt
Cc: Robin Murphy
Fixes: a30933c27602 ("drm/pl111: Support the Versatile Express")
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- In my stress I missed that if there are several CLCD instances
on the board the platform_driver_register() call will return
-EBUSY so we need to ignore that explicitly, all we want is to
register the driver at least once.
---
drivers/gpu/drm/pl111/pl111_versatile.c | 7 +++
drivers/gpu/drm/pl111/pl111_vexpress.c | 12 ++--
drivers/gpu/drm/pl111/pl111_vexpress.h | 7 +++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
b/drivers/gpu/drm/pl111/pl111_versatile.c
index 78ddf8534fd2..ad769e3e9fd3 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -326,6 +326,13 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
struct platform_device *pdev;
+ /* Registers a driver for the muxfpga */
+ ret = vexpress_muxfpga_init();
+ if (ret) {
+ dev_err(dev, "unable to intialize muxfpga driver\n");
+ return ret;
+ }
+
/* Call into deep Vexpress configuration API */
pdev = of_find_device_by_node(np);
if (!pdev) {
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c
b/drivers/gpu/drm/pl111/pl111_vexpress.c
index c9fee625faf1..c30f63cd66a8 100644
--- a/drivers/gpu/drm/pl111/pl111_vexpress.c
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
@@ -106,7 +106,6 @@ static int vexpress_muxfpga_probe(struct platform_device
*pdev)
if (IS_ERR(map))
return PTR_ERR(map);
dev_set_drvdata(dev, map);
-
return 0;
}
@@ -122,4 +121,13 @@ static struct platform_driver vexpress_muxfpga_driver = {
.probe = vexpress_muxfpga_probe,
};
-builtin_platform_driver(vexpress_muxfpga_driver);
+int vexpress_muxfpga_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&vexpress_muxfpga_driver);
+ /* -EBUSY just means this driver is already registered */
+ if (ret && ret != -EBUSY)
+ return ret;
+ return 0;
+}
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.h
b/drivers/gpu/drm/pl111/pl111_vexpress.h
index 49876417f7b6..40fbe42369dc 100644
--- a/drivers/gpu/drm/pl111/pl111_vexpress.h
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.h
@@ -10,6 +10,8 @@ int pl111_vexpress_clcd_init(struct device *dev,
struct pl111_drm_dev_private *priv,
struct regmap *map);
+int vexpress_muxfpga_init(void);
+
#else
static int inline pl111_vexpress_clcd_init(struct device *dev,
@@ -19,4 +21,9 @@ static int inline pl111_vexpress_clcd_init(struct device *dev,
return -ENODEV;
}
+static inline int vexpress_muxfpga_init(void)
+{
+ return 0;
+}
+
#endif
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/omap: minor fixes
For the series, Reviewed-by: Benoit Parrot Tomi Valkeinen wrote on Wed [2018-May-02 12:11:55 +0300]: > Hi, > > This series has some minor fixes found by a static analysis tool, and one for > missing linefeeds. As far as I know, we have never hit any of those errors. > > Tomi > > Tomi Valkeinen (4): > drm/omap: check return value from soc_device_match > drm/omap: handle error if scale coefs are not found > drm/omap: add missing linefeeds to prints > drm/omap: handle alloc failures in omap_connector > > drivers/gpu/drm/omapdrm/dss/dispc.c | 20 +--- > drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 7 ++- > drivers/gpu/drm/omapdrm/omap_connector.c | 10 ++ > 3 files changed, 29 insertions(+), 8 deletions(-) > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > ___ > 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: [PATCH v4 6/8] drm/panel: Add Ilitek ILI9881c panel driver
Hi Thierry,
Thanks for your review, I'll fix the other things you pointed out.
On Thu, Apr 26, 2018 at 05:07:12PM +0200, Thierry Reding wrote:
> > +static int ili9881c_send_cmd_data(struct ili9881c *ctx, u8 cmd, u8 data)
> > +{
> > + u8 buf[2] = { cmd, data };
> > + int ret;
> > +
> > + ret = mipi_dsi_dcs_write_buffer(ctx->dsi, buf, sizeof(buf));
> > + if (ret < 0)
> > + return ret;
> > +
> > + return 0;
> > +}
>
> According to this you're sending DCS commands, but none of the above
> look like valid DCS commands. Do you know what's going on here?
It looks to me that they are custom DCS commands.
> Also, can you include a reference to a datasheet where these
> instructions come from?
I'm not sure an Excel spreadsheet coming from the panel supplier would
be a good thing to include in a driver :)
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm_hwcomposer: Stop using libsync to provide sw_sync wrappers
On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan wrote: > Use of the sw_sync API is not allowed any more. Until drm_hwcomposer is > weaned off of sw_sync, build our own copy. I don't think it is used any longer. AFAICT, with 2 seconds of grep, it's referenced in drmcompositorworker.cpp, virtualcompositorworker.cpp, and hwcomposer.cpp I think these are all HWC1 legacy files, so they can probably just get cleaned up. Sean > > Cc: John Stultz > Cc: Rob Herring > Cc: Sean Paul > Signed-off-by: Alistair Strachan > --- > Android.mk | 37 + > 1 file changed, 29 insertions(+), 8 deletions(-) > > diff --git a/Android.mk b/Android.mk > index 573c5aa..747bf27 100644 > --- a/Android.mk > +++ b/Android.mk > @@ -14,15 +14,38 @@ > > ifeq ($(strip $(BOARD_USES_DRM_HWCOMPOSER)),true) > > -LOCAL_PATH := $(call my-dir) > +__this_dir := $(call my-dir) > + > +# = > +# libdrmhwc_sync.a > +# = > +include $(CLEAR_VARS) > + > +LOCAL_PATH := system/core/libsync > + > +LOCAL_SRC_FILES := sync.c > + > +LOCAL_CFLAGS := -Wno-unused-variable > + > +LOCAL_MODULE := libdrmhwc_sync > + > +LOCAL_VENDOR_MODULE := true > + > +LOCAL_C_INCLUDES := $(LOCAL_PATH)/include > + > +LOCAL_EXPORT_C_INCLUDE_DIRS := \ > + $(LOCAL_PATH) $(LOCAL_PATH)/include > + > +include $(BUILD_STATIC_LIBRARY) > > # = > # libdrmhwc_utils.a > # = > include $(CLEAR_VARS) > > -LOCAL_SRC_FILES := \ > - worker.cpp > +LOCAL_PATH := $(__this_dir) > + > +LOCAL_SRC_FILES := worker.cpp > > LOCAL_MODULE := libdrmhwc_utils > LOCAL_VENDOR_MODULE := true > @@ -34,6 +57,8 @@ include $(BUILD_STATIC_LIBRARY) > # = > include $(CLEAR_VARS) > > +LOCAL_PATH := $(__this_dir) > + > LOCAL_SHARED_LIBRARIES := \ > libcutils \ > libdrm \ > @@ -41,14 +66,10 @@ LOCAL_SHARED_LIBRARIES := \ > libGLESv2 \ > libhardware \ > liblog \ > - libsync \ > libui \ > libutils > > -LOCAL_STATIC_LIBRARIES := libdrmhwc_utils > - > -LOCAL_C_INCLUDES := \ > - system/core/libsync > +LOCAL_STATIC_LIBRARIES := libdrmhwc_utils libdrmhwc_sync > > LOCAL_SRC_FILES := \ > autolock.cpp \ > -- > 2.17.0.441.gb46fe60e1d-goog > -- 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: [PATCH v3 0/8] R-Car DU: Support CRC calculation
On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart wrote: > Hi Dave, > > Ping ? Not aware of any crc core work going on in drm, so has my ack. Worst case we do a topic branch or something like that (since I guess you'll do a pull request anyway on the v4l side). Acked-by: me. -Daniel > > On Saturday, 28 April 2018 23:50:19 EEST Laurent Pinchart wrote: >> Hello, >> >> (Dave, there's a request for you below) >> >> This patch series adds support for CRC calculation to the rcar-du-drm >> driver. >> >> CRC calculation is supported starting at the Renesas R-Car Gen3 SoCs, as >> earlier versions don't have the necessary hardware. On Gen3 SoCs, the CRC is >> computed by the DISCOM module part of the VSP-D and VSP-DL. >> >> The DISCOM is interfaced to the VSP through the UIF glue and appears as a >> VSP entity with a sink pad and a source pad. >> >> The series starts with a switch to SPDX license headers in patch 1/8, >> prompted by a checkpatch.pl warning for a later patch that complained about >> missing SPDX license headers. It then continues with cleanup and >> refactoring. Patches 2/8 and 3/8 prepare for DISCOM and UIF support by >> extending generic code to make it usable for the UIF. Patch 4/8 documents a >> structure that will receive new fields. >> >> Patch 5/8 then extends the API exposed by the VSP driver to the DU driver to >> support CRC computation configuration and reporting. The patch >> unfortunately needs to touch both the VSP and DU drivers, so the whole >> series will need to be merged through a single tree. >> >> Patch 5/8 adds support for the DISCOM and UIF in the VSP driver, patch 7/8 >> integrates it in the DRM pipeline, and patch 8/8 finally implements the CRC >> API in the DU driver to expose CRC computation to userspace. >> >> The hardware supports computing the CRC at any arbitrary point in the >> pipeline on a configurable window of the frame. This patch series supports >> CRC computation on input planes or pipeline output, but on the full frame >> only. Support for CRC window configuration can be added later if needed but >> will require extending the userspace API, as the DRM/KMS CRC API doesn't >> support this feature. >> >> Compared to v1, the CRC source names for plane inputs are now constructed >> from plane IDs instead of plane indices. This allows userspace to match CRC >> sources with planes. >> >> Compared to v2, various small issues reported by reviewers have been fixed. >> I believe the series to now be ready for upstream merge. >> >> Note that exposing the DISCOM and UIF though the V4L2 API isn't supported as >> the module is only found in VSP-D and VSP-DL instances that are not exposed >> through V4L2. It is possible to expose those instances through V4L2 with a >> small modification to the driver for testing purpose. If the need arises to >> test DISCOM and UIF with such an out-of-tree patch, support for CRC >> reporting through a V4L2 control can be added later without affecting how >> CRC is exposed through the DRM/KMS API. >> >> The patches are based on top of the "[PATCH v2 00/15] R-Car VSP1: >> Dynamically assign blend units to display pipelines" patch series, itself >> based on top of the Linux media master branch and scheduled for merge in >> v4.18. The new base caused heavy conflicts, requiring this series to be >> merged through the V4L2 tree. >> >> Dave, I have verified that this series merges cleanly with your drm-next and >> drm-fixes branches, with the drm-misc-next and drm-misc-fixes branches, and >> with the R-Car DU patches I would like to get merged in v4.18 through your >> tree. Could I get your ack to merge this through the V4L2 tree ? >> >> For convenience the patches are available at >> >> git://linuxtv.org/pinchartl/media.git vsp1-discom-v3-20180428 >> >> The code has been tested through the kms-test-crc.py script part of the DU >> test suite available at >> >> git://git.ideasonboard.com/renesas/kms-tests.git discom >> >> Laurent Pinchart (8): >> v4l: vsp1: Use SPDX license headers >> v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code >> v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper >> v4l: vsp1: Document the vsp1_du_atomic_config structure >> v4l: vsp1: Extend the DU API to support CRC computation >> v4l: vsp1: Add support for the DISCOM entity >> v4l: vsp1: Integrate DISCOM in display pipeline >> drm: rcar-du: Add support for CRC computation >> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 156 - >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 15 ++ >> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12 +- >> drivers/media/platform/vsp1/Makefile | 2 +- >> drivers/media/platform/vsp1/vsp1.h| 10 +- >> drivers/media/platform/vsp1/vsp1_brx.c| 6 +- >> drivers/media/platform/vsp1/vsp1_brx.h| 6 +- >> drivers/media/platform/vsp1/vsp1_clu.c| 71 ++-- >> drivers/media/platform/vsp1/vsp1_clu.h| 6 +- >> drivers/media/platform/
Re: [PATCH v3 10/11] media: vsp1: Support Interlaced display pipelines
Hi Laurent,
On 03/05/18 12:13, Laurent Pinchart wrote:
> Hi Kieran,
>>> + } else {
>>> + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_Y, mem.addr[0]);
>>> + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C0, mem.addr[1]);
>>> + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C1, mem.addr[2]);
>>> + }
>>> }
>>> +
>>> static void rpf_partition(struct vsp1_entity *entity,
>>> struct vsp1_pipeline *pipe,
>>> struct vsp1_partition *partition,
>>> diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h
>>> b/drivers/media/platform/vsp1/vsp1_rwpf.h index
>>> 70742ecf766f..8d6e42f27908 100644
>>> --- a/drivers/media/platform/vsp1/vsp1_rwpf.h
>>> +++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
>>> @@ -42,6 +42,7 @@ struct vsp1_rwpf {
>>> struct v4l2_pix_format_mplane format;
>>> const struct vsp1_format_info *fmtinfo;
>>> unsigned int brx_input;
>>> + bool interlaced;
>
> kerneldoc might be nice :-)
There's no existing kerneldoc on struct vsp1_rwpf ?
>>>
>>> unsigned int alpha;
>>>
>
> [snip]
>
>>> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
>>> index 678c24de1ac6..c10883f30980 100644
>>> --- a/include/media/vsp1.h
>>> +++ b/include/media/vsp1.h
>>> @@ -50,6 +50,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
>>> pipe_index,>
>>> * @dst: destination rectangle on the display (integer coordinates)
>>> * @alpha: alpha value (0: fully transparent, 255: fully opaque)
>>> * @zpos: Z position of the plane (from 0 to number of planes minus 1)
>>> + * @interlaced: true for interlaced pipelines
>
> Maybe "true if the pipeline outputs an interlaced stream" ?
That's fine - but I've neglected to incorporate this into my v4 repost :-(
If by any magic - v4 is suitable for integration already, and you're happy to
take it into your tree - please feel free to update this comment.
Otherwise it will be in any next update.
--
KB
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/17] drm/etnaviv: Remove unecessary dma_fence_ops
Am Freitag, den 27.04.2018, 08:17 +0200 schrieb Daniel Vetter:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> > Signed-off-by: Daniel Vetter
> > Cc: Lucas Stach
> > Cc: Russell King
> > Cc: Christian Gmeiner
> Cc: etna...@lists.freedesktop.org
I guess you are going to take the whole series through drm-misc, right?
If so:
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 8a88799bf79b..b78d9f49aa23 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1038,11 +1038,6 @@ static const char
> *etnaviv_fence_get_timeline_name(struct dma_fence *fence)
> > return dev_name(f->gpu->dev);
> }
>
> -static bool etnaviv_fence_enable_signaling(struct dma_fence *fence)
> -{
> > - return true;
> -}
> -
> static bool etnaviv_fence_signaled(struct dma_fence *fence)
> {
> > struct etnaviv_fence *f = to_etnaviv_fence(fence);
> @@ -1060,9 +1055,7 @@ static void etnaviv_fence_release(struct dma_fence
> *fence)
> static const struct dma_fence_ops etnaviv_fence_ops = {
> > .get_driver_name = etnaviv_fence_get_driver_name,
> > .get_timeline_name = etnaviv_fence_get_timeline_name,
> > - .enable_signaling = etnaviv_fence_enable_signaling,
> > .signaled = etnaviv_fence_signaled,
> > - .wait = dma_fence_default_wait,
> > .release = etnaviv_fence_release,
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pl111: Fix module probe bug
On Thu, May 03, 2018 at 03:40:53PM +0200, Linus Walleij wrote:
> Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
> Added a second module using the builtin_platform_driver() call,
> which works fine as long as you do not try to build the PL111
> driver as a module, because a module can only have one initcall
> and cause the following build bug:
>
> (...) multiple definition of `init_module' (...)
>
> Reported-by: Daniel Vetter
> Cc: Liviu Dudau
> Cc: Pawel Moll
> Cc: Eric Anholt
> Cc: Robin Murphy
> Fixes: a30933c27602 ("drm/pl111: Support the Versatile Express")
> Signed-off-by: Linus Walleij
lgtm. Please also reenable the pl111 driver in the drm-rerere branch, you
can simple revert 17c11b73c2ea6a21eaad5c1f5d358054c9e2c2f6.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/pl111/pl111_versatile.c | 7 +++
> drivers/gpu/drm/pl111/pl111_vexpress.c | 5 -
> drivers/gpu/drm/pl111/pl111_vexpress.h | 7 +++
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
> b/drivers/gpu/drm/pl111/pl111_versatile.c
> index 78ddf8534fd2..2f0daab30973 100644
> --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> @@ -326,6 +326,13 @@ int pl111_versatile_init(struct device *dev, struct
> pl111_drm_dev_private *priv)
> if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
> struct platform_device *pdev;
>
> + /* Registers a driver for the muxfpga */
> + ret = vexpress_muxfpga_init();
> + if (ret) {
> + dev_err(dev, "unable to intialized muxfpga driver\n");
> + return ret;
> + }
> +
> /* Call into deep Vexpress configuration API */
> pdev = of_find_device_by_node(np);
> if (!pdev) {
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c
> b/drivers/gpu/drm/pl111/pl111_vexpress.c
> index c9fee625faf1..508878c9bd52 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.c
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
> @@ -122,4 +122,7 @@ static struct platform_driver vexpress_muxfpga_driver = {
> .probe = vexpress_muxfpga_probe,
> };
>
> -builtin_platform_driver(vexpress_muxfpga_driver);
> +int vexpress_muxfpga_init(void)
> +{
> + return platform_driver_register(&vexpress_muxfpga_driver);
> +}
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.h
> b/drivers/gpu/drm/pl111/pl111_vexpress.h
> index 49876417f7b6..40fbe42369dc 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.h
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.h
> @@ -10,6 +10,8 @@ int pl111_vexpress_clcd_init(struct device *dev,
>struct pl111_drm_dev_private *priv,
>struct regmap *map);
>
> +int vexpress_muxfpga_init(void);
> +
> #else
>
> static int inline pl111_vexpress_clcd_init(struct device *dev,
> @@ -19,4 +21,9 @@ static int inline pl111_vexpress_clcd_init(struct device
> *dev,
> return -ENODEV;
> }
>
> +static inline int vexpress_muxfpga_init(void)
> +{
> + return 0;
> +}
> +
> #endif
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/pl111: Fix module probe bug
Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
Added a second module using the builtin_platform_driver() call,
which works fine as long as you do not try to build the PL111
driver as a module, because a module can only have one initcall
and cause the following build bug:
(...) multiple definition of `init_module' (...)
Reported-by: Daniel Vetter
Cc: Liviu Dudau
Cc: Pawel Moll
Cc: Eric Anholt
Cc: Robin Murphy
Fixes: a30933c27602 ("drm/pl111: Support the Versatile Express")
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_versatile.c | 7 +++
drivers/gpu/drm/pl111/pl111_vexpress.c | 5 -
drivers/gpu/drm/pl111/pl111_vexpress.h | 7 +++
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
b/drivers/gpu/drm/pl111/pl111_versatile.c
index 78ddf8534fd2..2f0daab30973 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -326,6 +326,13 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
struct platform_device *pdev;
+ /* Registers a driver for the muxfpga */
+ ret = vexpress_muxfpga_init();
+ if (ret) {
+ dev_err(dev, "unable to intialized muxfpga driver\n");
+ return ret;
+ }
+
/* Call into deep Vexpress configuration API */
pdev = of_find_device_by_node(np);
if (!pdev) {
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c
b/drivers/gpu/drm/pl111/pl111_vexpress.c
index c9fee625faf1..508878c9bd52 100644
--- a/drivers/gpu/drm/pl111/pl111_vexpress.c
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
@@ -122,4 +122,7 @@ static struct platform_driver vexpress_muxfpga_driver = {
.probe = vexpress_muxfpga_probe,
};
-builtin_platform_driver(vexpress_muxfpga_driver);
+int vexpress_muxfpga_init(void)
+{
+ return platform_driver_register(&vexpress_muxfpga_driver);
+}
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.h
b/drivers/gpu/drm/pl111/pl111_vexpress.h
index 49876417f7b6..40fbe42369dc 100644
--- a/drivers/gpu/drm/pl111/pl111_vexpress.h
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.h
@@ -10,6 +10,8 @@ int pl111_vexpress_clcd_init(struct device *dev,
struct pl111_drm_dev_private *priv,
struct regmap *map);
+int vexpress_muxfpga_init(void);
+
#else
static int inline pl111_vexpress_clcd_init(struct device *dev,
@@ -19,4 +21,9 @@ static int inline pl111_vexpress_clcd_init(struct device *dev,
return -ENODEV;
}
+static inline int vexpress_muxfpga_init(void)
+{
+ return 0;
+}
+
#endif
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/selftests: Rename the Kconfig option to CONFIG_DRM_DEBUG_SELFTEST
On Thu, May 03, 2018 at 01:22:16PM +0200, Maarten Lankhorst wrote: > We want to add more DRM selftests, and there's not much point in > having a Kconfig option for every single one of them, so make > a generic one. > > Signed-off-by: Maarten Lankhorst Seems like a reasonable idea. Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/Kconfig| 8 > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/selftests/Makefile | 2 +- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 757825ac60df..d684855b95c2 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -49,16 +49,16 @@ config DRM_DEBUG_MM > > If in doubt, say "N". > > -config DRM_DEBUG_MM_SELFTEST > - tristate "kselftests for DRM range manager (struct drm_mm)" > +config DRM_DEBUG_SELFTEST > + tristate "kselftests for DRM" > depends on DRM > depends on DEBUG_KERNEL > select PRIME_NUMBERS > select DRM_LIB_RANDOM > default n > help > - This option provides a kernel module that can be used to test > - the DRM range manager (drm_mm) and its API. This option is not > + This option provides kernel modules that can be used to run > + various selftests on parts of the DRM api. This option is not > useful for distributions or general kernels, but only for kernel > developers working on DRM and associated drivers. > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 9d66657ea117..4becc245e359 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -43,7 +43,7 @@ drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += > drm_fb_cma_helper.o > drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o > > obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o > -obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/ > +obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/ > > obj-$(CONFIG_DRM)+= drm.o > obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o > diff --git a/drivers/gpu/drm/selftests/Makefile > b/drivers/gpu/drm/selftests/Makefile > index 4aebfc7f27d4..f7dd66e859a9 100644 > --- a/drivers/gpu/drm/selftests/Makefile > +++ b/drivers/gpu/drm/selftests/Makefile > @@ -1 +1 @@ > -obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += test-drm_mm.o > +obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o > -- > 2.17.0 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-next 01/21] drm/i915: Move u64-to-ptr helpers to general header
From: Leon Romanovsky
The macro u64_to_ptr() and function ptr_to_u64() are useful enough
to be part of general header, so move them there and allow RDMA
subsystem reuse them.
Signed-off-by: Leon Romanovsky
---
drivers/gpu/drm/i915/i915_utils.h | 12 ++--
include/linux/kernel.h| 12
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 51dbfe5bb418..de3bfda7bf96 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -25,6 +25,8 @@
#ifndef __I915_UTILS_H
#define __I915_UTILS_H
+#include
+
#undef WARN_ON
/* Many gcc seem to no see through this and fall over :( */
#if 0
@@ -102,16 +104,6 @@
__T;\
})
-static inline u64 ptr_to_u64(const void *ptr)
-{
- return (uintptr_t)ptr;
-}
-
-#define u64_to_ptr(T, x) ({\
- typecheck(u64, x); \
- (T *)(uintptr_t)(x);\
-})
-
#define __mask_next_bit(mask) ({ \
int __idx = ffs(mask) - 1; \
mask &= ~BIT(__idx);\
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 6a1eb0b0aad9..a738393c9694 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -70,6 +70,18 @@
*/
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
+static inline u64 ptr_to_u64(const void *ptr)
+{
+ return (uintptr_t)ptr;
+}
+
+#define u64_to_ptr(T, x) ( \
+{ \
+ typecheck(u64, x); \
+ (T *)(uintptr_t)(x);\
+} \
+)
+
#define u64_to_user_ptr(x) ( \
{ \
typecheck(u64, x); \
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 06/11] media: vsp1: Provide VSP1 feature helper macro
The VSP1 devices define their specific capabilities through features
marked in their device info structure. Various parts of the code read
this info structure to infer if the features are available.
Wrap this into a more readable vsp1_feature(vsp1, f) macro to ensure
that usage is consistent throughout the driver.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1.h | 2 ++
drivers/media/platform/vsp1/vsp1_drv.c | 16
drivers/media/platform/vsp1/vsp1_wpf.c | 6 +++---
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1.h
b/drivers/media/platform/vsp1/vsp1.h
index 33f632331474..f0d21cc8e9ab 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -68,6 +68,8 @@ struct vsp1_device_info {
bool uapi;
};
+#define vsp1_feature(vsp1, f) ((vsp1)->info->features & (f))
+
struct vsp1_device {
struct device *dev;
const struct vsp1_device_info *info;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index d29f9c4baebe..0fc388bf5a33 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -265,7 +265,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
/* Instantiate all the entities. */
- if (vsp1->info->features & VSP1_HAS_BRS) {
+ if (vsp1_feature(vsp1, VSP1_HAS_BRS)) {
vsp1->brs = vsp1_brx_create(vsp1, VSP1_ENTITY_BRS);
if (IS_ERR(vsp1->brs)) {
ret = PTR_ERR(vsp1->brs);
@@ -275,7 +275,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(&vsp1->brs->entity.list_dev, &vsp1->entities);
}
- if (vsp1->info->features & VSP1_HAS_BRU) {
+ if (vsp1_feature(vsp1, VSP1_HAS_BRU)) {
vsp1->bru = vsp1_brx_create(vsp1, VSP1_ENTITY_BRU);
if (IS_ERR(vsp1->bru)) {
ret = PTR_ERR(vsp1->bru);
@@ -285,7 +285,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(&vsp1->bru->entity.list_dev, &vsp1->entities);
}
- if (vsp1->info->features & VSP1_HAS_CLU) {
+ if (vsp1_feature(vsp1, VSP1_HAS_CLU)) {
vsp1->clu = vsp1_clu_create(vsp1);
if (IS_ERR(vsp1->clu)) {
ret = PTR_ERR(vsp1->clu);
@@ -311,7 +311,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(&vsp1->hst->entity.list_dev, &vsp1->entities);
- if (vsp1->info->features & VSP1_HAS_HGO && vsp1->info->uapi) {
+ if (vsp1_feature(vsp1, VSP1_HAS_HGO) && vsp1->info->uapi) {
vsp1->hgo = vsp1_hgo_create(vsp1);
if (IS_ERR(vsp1->hgo)) {
ret = PTR_ERR(vsp1->hgo);
@@ -322,7 +322,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
&vsp1->entities);
}
- if (vsp1->info->features & VSP1_HAS_HGT && vsp1->info->uapi) {
+ if (vsp1_feature(vsp1, VSP1_HAS_HGT) && vsp1->info->uapi) {
vsp1->hgt = vsp1_hgt_create(vsp1);
if (IS_ERR(vsp1->hgt)) {
ret = PTR_ERR(vsp1->hgt);
@@ -353,7 +353,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
}
- if (vsp1->info->features & VSP1_HAS_LUT) {
+ if (vsp1_feature(vsp1, VSP1_HAS_LUT)) {
vsp1->lut = vsp1_lut_create(vsp1);
if (IS_ERR(vsp1->lut)) {
ret = PTR_ERR(vsp1->lut);
@@ -387,7 +387,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
}
- if (vsp1->info->features & VSP1_HAS_SRU) {
+ if (vsp1_feature(vsp1, VSP1_HAS_SRU)) {
vsp1->sru = vsp1_sru_create(vsp1);
if (IS_ERR(vsp1->sru)) {
ret = PTR_ERR(vsp1->sru);
@@ -537,7 +537,7 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
vsp1_write(vsp1, VI6_DPR_HSI_ROUTE, VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_BRU_ROUTE, VI6_DPR_NODE_UNUSED);
- if (vsp1->info->features & VSP1_HAS_BRS)
+ if (vsp1_feature(vsp1, VSP1_HAS_BRS))
vsp1_write(vsp1, VI6_DPR_ILV_BRS_ROUTE, VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_HGO_SMPPT, (7 << VI6_DPR_SMPPT_TGW_SHIFT) |
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 2edea361eee4..ea1d226371b2 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -141,13 +141,13 @@ static int wpf_init_controls(struct vsp1_rwpf *wpf)
if (wpf->entity.index != 0) {
/* Only WPF0 supports flipping. */
num_flip_ctrls = 0;
- } else if (vsp1->info->features & VSP1_HAS_WPF_HFLIP) {
+ } else if (vsp1_feature(vsp1, VSP1_HAS_WPF
[PATCH v4 11/11] drm: rcar-du: Support interlaced video output through vsp1
Use the newly exposed VSP1 interface to enable interlaced frame support through the VSP1 lif pipelines. Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index d71d709fe3d9..206532959ec9 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -289,6 +289,7 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) /* Signal polarities */ value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0) | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0) + | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0) | DSMR_DIPM_DISP | DSMR_CSPM; rcar_du_crtc_write(rcrtc, DSMR, value); diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index af7822a66dee..c7b37232ee91 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -186,6 +186,9 @@ static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) }; unsigned int i; + cfg.interlaced = !!(plane->plane.state->crtc->mode.flags + & DRM_MODE_FLAG_INTERLACE); + cfg.src.left = state->state.src.x1 >> 16; cfg.src.top = state->state.src.y1 >> 16; cfg.src.width = drm_rect_width(&state->state.src) >> 16; -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/11] media: vsp1: Support Interlaced display pipelines
Calculate the top and bottom fields for the interlaced frames and
utilise the extended display list command feature to implement the
auto-field operations. This allows the DU to update the VSP2 registers
dynamically based upon the currently processing field.
Signed-off-by: Kieran Bingham
---
v3:
- Pass DL through partition calls to allow autocmd's to be retrieved
- Document interlaced field in struct vsp1_du_atomic_config
v2:
- fix erroneous BIT value which enabled interlaced
- fix field handling at frame_end interrupt
---
drivers/media/platform/vsp1/vsp1_dl.c | 10 -
drivers/media/platform/vsp1/vsp1_drm.c | 11 -
drivers/media/platform/vsp1/vsp1_regs.h | 1 +-
drivers/media/platform/vsp1/vsp1_rpf.c | 71 --
drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +-
include/media/vsp1.h| 2 +-
6 files changed, 93 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index d33ae5f125bd..bbe9f3006f71 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -906,6 +906,8 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool
internal)
*/
unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
{
+ struct vsp1_device *vsp1 = dlm->vsp1;
+ u32 status = vsp1_read(vsp1, VI6_STATUS);
unsigned int flags = 0;
spin_lock(&dlm->lock);
@@ -931,6 +933,14 @@ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager
*dlm)
goto done;
/*
+* Progressive streams report only TOP fields. If we have a BOTTOM
+* field, we are interlaced, and expect the frame to complete on the
+* next frame end interrupt.
+*/
+ if (status & VI6_STATUS_FLD_STD(dlm->index))
+ goto done;
+
+ /*
* The device starts processing the queued display list right after the
* frame end interrupt. The display list thus becomes active.
*/
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 2c3db8b8adce..cc29c9d96bb7 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -811,6 +811,17 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int
pipe_index,
return -EINVAL;
}
+ if (!(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)) && cfg->interlaced) {
+ /*
+* Interlaced support requires extended display lists to
+* provide the auto-fld feature with the DU.
+*/
+ dev_dbg(vsp1->dev, "Interlaced unsupported on this output\n");
+ return -EINVAL;
+ }
+
+ rpf->interlaced = cfg->interlaced;
+
rpf->fmtinfo = fmtinfo;
rpf->format.num_planes = fmtinfo->planes;
rpf->format.plane_fmt[0].bytesperline = cfg->pitch;
diff --git a/drivers/media/platform/vsp1/vsp1_regs.h
b/drivers/media/platform/vsp1/vsp1_regs.h
index d054767570c1..a2ac65cc5155 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -28,6 +28,7 @@
#define VI6_SRESET_SRTS(n) (1 << (n))
#define VI6_STATUS 0x0038
+#define VI6_STATUS_FLD_STD(n) (1 << ((n) + 28))
#define VI6_STATUS_SYS_ACT(n) (1 << ((n) + 8))
#define VI6_WPF_IRQ_ENB(n) (0x0048 + (n) * 12)
diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c
b/drivers/media/platform/vsp1/vsp1_rpf.c
index 8fae7c485642..511b2e127820 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -20,6 +20,20 @@
#define RPF_MAX_WIDTH 8190
#define RPF_MAX_HEIGHT 8190
+/* Pre extended display list command data structure */
+struct vsp1_extcmd_auto_fld_body {
+ u32 top_y0;
+ u32 bottom_y0;
+ u32 top_c0;
+ u32 bottom_c0;
+ u32 top_c1;
+ u32 bottom_c1;
+ u32 reserved0;
+ u32 reserved1;
+} __packed;
+
+#define VSP1_DL_EXT_AUTOFLD_INTBIT(0)
+
/*
-
* Device Access
*/
@@ -64,6 +78,14 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
pstride |= format->plane_fmt[1].bytesperline
<< VI6_RPF_SRCM_PSTRIDE_C_SHIFT;
+ /*
+* pstride has both STRIDE_Y and STRIDE_C, but multiplying the whole
+* of pstride by 2 is conveniently OK here as we are multiplying both
+* values.
+*/
+ if (rpf->interlaced)
+ pstride *= 2;
+
vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_PSTRIDE, pstride);
/* Format */
@@ -100,6 +122,9 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
top = compose->top;
}
+ if (rpf->interlaced)
+ top /=
[PATCH v4 09/11] media: vsp1: Provide support for extended command pools
VSPD and VSP-DL devices can provide extended display lists supporting
extended command display list objects.
These extended commands require their own dma memory areas for a header
and body specific to the command type.
Implement a command pool to allocate all necessary memory in a single
DMA allocation to reduce pressure on the TLB, and provide convenient
re-usable command objects for the entities to utilise.
Signed-off-by: Kieran Bingham
---
v2:
- Fix spelling typo in commit message
- constify, and staticify the instantiation of vsp1_extended_commands
- s/autfld_cmds/autofld_cmds/
- staticify cmd pool functions (Thanks kbuild-bot)
---
drivers/media/platform/vsp1/vsp1_dl.c | 191 +++-
drivers/media/platform/vsp1/vsp1_dl.h | 3 +-
2 files changed, 194 insertions(+)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index b64d32535edc..d33ae5f125bd 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -117,6 +117,30 @@ struct vsp1_dl_body_pool {
};
/**
+ * struct vsp1_cmd_pool - display list body pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the pool and free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_cmd_pool {
+ /* DMA allocation */
+ dma_addr_t dma;
+ size_t size;
+ void *mem;
+
+ struct vsp1_dl_ext_cmd *cmds;
+ struct list_head free;
+
+ spinlock_t lock;
+
+ struct vsp1_device *vsp1;
+};
+
+/**
* struct vsp1_dl_list - Display list
* @list: entry in the display list manager lists
* @dlm: the display list manager
@@ -162,6 +186,7 @@ struct vsp1_dl_list {
* @queued: list queued to the hardware (written to the DL registers)
* @pending: list waiting to be queued to the hardware
* @pool: body pool for the display list bodies
+ * @autofld_cmds: command pool to support auto-fld interlaced mode
*/
struct vsp1_dl_manager {
unsigned int index;
@@ -175,6 +200,7 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
struct vsp1_dl_body_pool *pool;
+ struct vsp1_dl_cmd_pool *autofld_cmds;
};
/*
-
@@ -338,6 +364,140 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32
reg, u32 data)
}
/*
-
+ * Display List Extended Command Management
+ */
+
+enum vsp1_extcmd_type {
+ VSP1_EXTCMD_AUTODISP,
+ VSP1_EXTCMD_AUTOFLD,
+};
+
+struct vsp1_extended_command_info {
+ u16 opcode;
+ size_t body_size;
+} static const vsp1_extended_commands[] = {
+ [VSP1_EXTCMD_AUTODISP] = { 0x02, 96 },
+ [VSP1_EXTCMD_AUTOFLD] = { 0x03, 160 },
+};
+
+/**
+ * vsp1_dl_cmd_pool_create - Create a pool of commands from a single allocation
+ * @vsp1: The VSP1 device
+ * @type: The command pool type
+ * @num_commands: The quantity of commands to allocate
+ *
+ * Allocate a pool of commands each with enough memory to contain the private
+ * data of each command. The allocation sizes are dependent upon the command
+ * type.
+ *
+ * Return a pointer to a pool on success or NULL if memory can't be allocated.
+ */
+static struct vsp1_dl_cmd_pool *
+vsp1_dl_cmd_pool_create(struct vsp1_device *vsp1, enum vsp1_extcmd_type type,
+ unsigned int num_cmds)
+{
+ struct vsp1_dl_cmd_pool *pool;
+ unsigned int i;
+ size_t cmd_size;
+
+ pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+ if (!pool)
+ return NULL;
+
+ pool->cmds = kcalloc(num_cmds, sizeof(*pool->cmds), GFP_KERNEL);
+ if (!pool->cmds) {
+ kfree(pool);
+ return NULL;
+ }
+
+ cmd_size = sizeof(struct vsp1_dl_ext_cmd_header) +
+ vsp1_extended_commands[type].body_size;
+ cmd_size = ALIGN(cmd_size, 16);
+
+ pool->size = cmd_size * num_cmds;
+ pool->mem = dma_alloc_wc(vsp1->bus_master, pool->size, &pool->dma,
+GFP_KERNEL);
+ if (!pool->mem) {
+ kfree(pool->cmds);
+ kfree(pool);
+ return NULL;
+ }
+
+ spin_lock_init(&pool->lock);
+ INIT_LIST_HEAD(&pool->free);
+
+ for (i = 0; i < num_cmds; ++i) {
+ struct vsp1_dl_ext_cmd *cmd = &pool->cmds[i];
+ size_t cmd_offset = i * cmd_size;
+ size_t data_offset = sizeof(struct vsp1_dl_ext_cmd_header) +
+cmd_offset;
+
+ cmd->pool = pool;
+ cmd->cmd_opcode = vsp1_extended_commands[type].opcode;
+
+ /* TODO: Auto-disp can utilise more than one command per cmd */
+ cmd->num_cmds =
[PATCH v4 07/11] media: vsp1: Use header display lists for all WPF outputs linked to the DU
Header mode display lists are now supported on all WPF outputs. To
support extended headers and auto-fld capabilities for interlaced mode
handling only header mode display lists can be used.
Disable the headerless display list configuration, and remove the dead
code.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 107 ++-
1 file changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index fbffbd407b29..56514cd51c51 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -94,7 +94,7 @@ struct vsp1_dl_body_pool {
* struct vsp1_dl_list - Display list
* @list: entry in the display list manager lists
* @dlm: the display list manager
- * @header: display list header, NULL for headerless lists
+ * @header: display list header
* @dma: DMA address for the header
* @body0: first display list body
* @bodies: list of extra display list bodies
@@ -118,15 +118,9 @@ struct vsp1_dl_list {
bool internal;
};
-enum vsp1_dl_mode {
- VSP1_DL_MODE_HEADER,
- VSP1_DL_MODE_HEADERLESS,
-};
-
/**
* struct vsp1_dl_manager - Display List manager
* @index: index of the related WPF
- * @mode: display list operation mode (header or headerless)
* @singleshot: execute the display list in single-shot mode
* @vsp1: the VSP1 device
* @lock: protects the free, active, queued, and pending lists
@@ -138,7 +132,6 @@ enum vsp1_dl_mode {
*/
struct vsp1_dl_manager {
unsigned int index;
- enum vsp1_dl_mode mode;
bool singleshot;
struct vsp1_device *vsp1;
@@ -318,6 +311,7 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg,
u32 data)
static struct vsp1_dl_list *vsp1_dl_list_alloc(struct vsp1_dl_manager *dlm)
{
struct vsp1_dl_list *dl;
+ size_t header_offset;
dl = kzalloc(sizeof(*dl), GFP_KERNEL);
if (!dl)
@@ -330,16 +324,15 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct
vsp1_dl_manager *dlm)
dl->body0 = vsp1_dl_body_get(dlm->pool);
if (!dl->body0)
return NULL;
- if (dlm->mode == VSP1_DL_MODE_HEADER) {
- size_t header_offset = dl->body0->max_entries
-* sizeof(*dl->body0->entries);
- dl->header = ((void *)dl->body0->entries) + header_offset;
- dl->dma = dl->body0->dma + header_offset;
+ header_offset = dl->body0->max_entries
+* sizeof(*dl->body0->entries);
- memset(dl->header, 0, sizeof(*dl->header));
- dl->header->lists[0].addr = dl->body0->dma;
- }
+ dl->header = ((void *)dl->body0->entries) + header_offset;
+ dl->dma = dl->body0->dma + header_offset;
+
+ memset(dl->header, 0, sizeof(*dl->header));
+ dl->header->lists[0].addr = dl->body0->dma;
return dl;
}
@@ -471,16 +464,9 @@ struct vsp1_dl_body *vsp1_dl_list_get_body0(struct
vsp1_dl_list *dl)
*
* The reference must be explicitly released by a call to vsp1_dl_body_put()
* when the body isn't needed anymore.
- *
- * Additional bodies are only usable for display lists in header mode.
- * Attempting to add a body to a header-less display list will return an error.
*/
int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct vsp1_dl_body *dlb)
{
- /* Multi-body lists are only available in header mode. */
- if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
- return -EINVAL;
-
refcount_inc(&dlb->refcnt);
list_add_tail(&dlb->list, &dl->bodies);
@@ -501,17 +487,10 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct
vsp1_dl_body *dlb)
* Adding a display list to a chain passes ownership of the display list to
* the head display list item. The chain is released when the head dl item is
* put back with __vsp1_dl_list_put().
- *
- * Chained display lists are only usable in header mode. Attempts to add a
- * display list to a chain in header-less mode will return an error.
*/
int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
struct vsp1_dl_list *dl)
{
- /* Chained lists are only available in header mode. */
- if (head->dlm->mode != VSP1_DL_MODE_HEADER)
- return -EINVAL;
-
head->has_chain = true;
list_add_tail(&dl->chain, &head->chain);
return 0;
@@ -579,17 +558,10 @@ static bool vsp1_dl_list_hw_update_pending(struct
vsp1_dl_manager *dlm)
return false;
/*
-* Check whether the VSP1 has taken the update. In headerless mode the
-* hardware indicates this by clearing the UPD bit in the DL_BODY_SIZE
-* register, and in header mode by clearing the UPDHDR bit in the CMD
-* register.
+* Check whether the VSP1 has taken the update. In header mode by
+* clearing the UPDHDR bit in
[PATCH v4 08/11] media: vsp1: Add support for extended display list headers
Extended display list headers allow pre and post command lists to be
executed by the VSP pipeline. This provides the base support for
features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for
supporting continuous camera preview pipelines.
Signed-off-by: Kieran Bingham
---
v2:
- remove __packed attributes
---
drivers/media/platform/vsp1/vsp1.h | 1 +-
drivers/media/platform/vsp1/vsp1_dl.c | 83 +-
drivers/media/platform/vsp1/vsp1_dl.h | 29 -
drivers/media/platform/vsp1/vsp1_drv.c | 7 +-
drivers/media/platform/vsp1/vsp1_regs.h | 5 +-
5 files changed, 116 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1.h
b/drivers/media/platform/vsp1/vsp1.h
index f0d21cc8e9ab..56c62122a81a 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -53,6 +53,7 @@ struct vsp1_uif;
#define VSP1_HAS_HGO (1 << 7)
#define VSP1_HAS_HGT (1 << 8)
#define VSP1_HAS_BRS (1 << 9)
+#define VSP1_HAS_EXT_DL(1 << 10)
struct vsp1_device_info {
u32 version;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 56514cd51c51..b64d32535edc 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -22,6 +22,9 @@
#define VSP1_DLH_INT_ENABLE(1 << 1)
#define VSP1_DLH_AUTO_START(1 << 0)
+#define VSP1_DLH_EXT_PRE_CMD_EXEC (1 << 9)
+#define VSP1_DLH_EXT_POST_CMD_EXEC (1 << 8)
+
struct vsp1_dl_header_list {
u32 num_bytes;
u32 addr;
@@ -34,11 +37,34 @@ struct vsp1_dl_header {
u32 flags;
};
+struct vsp1_dl_ext_header {
+ u32 reserved0; /* alignment padding */
+
+ u16 pre_ext_cmd_qty;
+ u16 flags;
+ u32 pre_ext_cmd_plist;
+
+ u32 post_ext_cmd_qty;
+ u32 post_ext_cmd_plist;
+};
+
+struct vsp1_dl_header_extended {
+ struct vsp1_dl_header header;
+ struct vsp1_dl_ext_header ext;
+};
+
struct vsp1_dl_entry {
u32 addr;
u32 data;
};
+struct vsp1_dl_ext_cmd_header {
+ u32 cmd;
+ u32 flags;
+ u32 data;
+ u32 reserved;
+};
+
/**
* struct vsp1_dl_body - Display list body
* @list: entry in the display list list of bodies
@@ -95,9 +121,12 @@ struct vsp1_dl_body_pool {
* @list: entry in the display list manager lists
* @dlm: the display list manager
* @header: display list header
+ * @extended: extended display list header. NULL for normal lists
* @dma: DMA address for the header
* @body0: first display list body
* @bodies: list of extra display list bodies
+ * @pre_cmd: pre cmd to be issued through extended dl header
+ * @post_cmd: post cmd to be issued through extended dl header
* @has_chain: if true, indicates that there's a partition chain
* @chain: entry in the display list partition chain
* @internal: whether the display list is used for internal purpose
@@ -107,11 +136,15 @@ struct vsp1_dl_list {
struct vsp1_dl_manager *dlm;
struct vsp1_dl_header *header;
+ struct vsp1_dl_ext_header *extended;
dma_addr_t dma;
struct vsp1_dl_body *body0;
struct list_head bodies;
+ struct vsp1_dl_ext_cmd *pre_cmd;
+ struct vsp1_dl_ext_cmd *post_cmd;
+
bool has_chain;
struct list_head chain;
@@ -496,6 +529,14 @@ int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
return 0;
}
+static void vsp1_dl_ext_cmd_fill_header(struct vsp1_dl_ext_cmd *cmd)
+{
+ cmd->cmds[0].cmd = cmd->cmd_opcode;
+ cmd->cmds[0].flags = cmd->flags;
+ cmd->cmds[0].data = cmd->data_dma;
+ cmd->cmds[0].reserved = 0;
+}
+
static void vsp1_dl_list_fill_header(struct vsp1_dl_list *dl, bool is_last)
{
struct vsp1_dl_manager *dlm = dl->dlm;
@@ -548,6 +589,27 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list
*dl, bool is_last)
*/
dl->header->flags = VSP1_DLH_INT_ENABLE;
}
+
+ if (!dl->extended)
+ return;
+
+ dl->extended->flags = 0;
+
+ if (dl->pre_cmd) {
+ dl->extended->pre_ext_cmd_plist = dl->pre_cmd->cmd_dma;
+ dl->extended->pre_ext_cmd_qty = dl->pre_cmd->num_cmds;
+ dl->extended->flags |= VSP1_DLH_EXT_PRE_CMD_EXEC;
+
+ vsp1_dl_ext_cmd_fill_header(dl->pre_cmd);
+ }
+
+ if (dl->post_cmd) {
+ dl->extended->pre_ext_cmd_plist = dl->post_cmd->cmd_dma;
+ dl->extended->pre_ext_cmd_qty = dl->post_cmd->num_cmds;
+ dl->extended->flags |= VSP1_DLH_EXT_POST_CMD_EXEC;
+
+ vsp1_dl_ext_cmd_fill_header(dl->pre_cmd);
+ }
}
static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm)
@@ -735,14 +797,20 @@ unsigned int vsp1_dlm_irq_frame_end(struct
vsp1_dl_manager *dlm)
}
/* Hardware Setup */
-void vsp1_dlm_setup(struct vsp1_dev
[PATCH v4 04/11] media: vsp1: Remove unused display list structure field
The vsp1 reference in the vsp1_dl_body structure is not used.
Remove it.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index ec6fc21fabe0..b23e88cda49f 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -44,7 +44,6 @@ struct vsp1_dl_entry {
* @list: entry in the display list list of bodies
* @free: entry in the pool free body list
* @pool: pool to which this body belongs
- * @vsp1: the VSP1 device
* @entries: array of entries
* @dma: DMA address of the entries
* @size: size of the DMA memory in bytes
@@ -58,7 +57,6 @@ struct vsp1_dl_body {
refcount_t refcnt;
struct vsp1_dl_body_pool *pool;
- struct vsp1_device *vsp1;
struct vsp1_dl_entry *entries;
dma_addr_t dma;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/11] media: vsp1: Remove packed attributes from aligned structures
The use of the packed attribute can cause a performance penalty for
all accesses to the struct members, as the compiler will assume that the
structure has the potential to have an unaligned base.
These structures are all correctly aligned and contain no holes, thus
the attribute is redundant and negatively impacts performance, so we
remove the attributes entirely.
Signed-off-by: Kieran Bingham
---
v2
- Remove attributes entirely
---
drivers/media/platform/vsp1/vsp1_dl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index c7fa1cb088cd..f4cede9b9b43 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -25,19 +25,19 @@
struct vsp1_dl_header_list {
u32 num_bytes;
u32 addr;
-} __attribute__((__packed__));
+};
struct vsp1_dl_header {
u32 num_lists;
struct vsp1_dl_header_list lists[8];
u32 next_header;
u32 flags;
-} __attribute__((__packed__));
+};
struct vsp1_dl_entry {
u32 addr;
u32 data;
-} __attribute__((__packed__));
+};
/**
* struct vsp1_dl_body - Display list body
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/11] media: vsp1: Clean up DLM objects on error
If there is an error allocating a display list within a DLM object
the existing display lists are not free'd, and neither is the DL body
pool.
Use the existing vsp1_dlm_destroy() function to clean up on error.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index b23e88cda49f..fbffbd407b29 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -851,8 +851,10 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device
*vsp1,
struct vsp1_dl_list *dl;
dl = vsp1_dl_list_alloc(dlm);
- if (!dl)
+ if (!dl) {
+ vsp1_dlm_destroy(dlm);
return NULL;
+ }
list_add_tail(&dl->list, &dlm->free);
}
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/11] R-Car DU Interlaced support through VSP1
The Gen3 R-Car DU devices make use of the VSP to handle frame processing. In this series we implement support for handling interlaced pipelines by using the auto-fld feature of the VSP hardware. The implementation is preceded by some cleanup work and refactoring, through patches 1 to 6. These are trivial and could be collected earlier and independently if this series requires further revisions. Patch 7 makes a key distinctive change to remove all existing support for headerless display lists throughout the VSP1 driver, and ensures that all pipelines use the same code path. This simplifies the code and reduces opportunity for untested code paths to exist. Patches 8, 9 and 10 implement the relevant support in the VSP1 driver, before patch 11 finally enables the feature through the drm R-Car DU driver. This series is based upon my previous TLB optimise and body rework (v9), and is available from the following URL: git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git tags/vsp1/du/interlaced/v4 ChangeLog: v4: - Move configure_partition() call changes into tlb-optimise-v9 v3: - Rebased on top of TLB Optimise rework v8 - Added the DL parameter back into the configure_partition() calls. - This change could be moved into the TLB-Optimise series. - Document interlaced field in struct vsp1_du_atomic_config v2: - media: vsp1: use kernel __packed for structures became: media: vsp1: Remove packed attributes from aligned structures - media: vsp1: Add support for extended display list headers - No longer declares structs __packed - media: vsp1: Provide support for extended command pools - Fix spelling typo in commit message - constify, and staticify the instantiation of vsp1_extended_commands - s/autfld_cmds/autofld_cmds/ - staticify cmd pool functions (Thanks kbuild-bot) - media: vsp1: Support Interlaced display pipelines - fix erroneous BIT value which enabled interlaced - fix field handling at frame_end interrupt Kieran Bingham (11): media: vsp1: drm: Fix minor grammar error media: vsp1: Remove packed attributes from aligned structures media: vsp1: Rename dl_child to dl_next media: vsp1: Remove unused display list structure field media: vsp1: Clean up DLM objects on error media: vsp1: Provide VSP1 feature helper macro media: vsp1: Use header display lists for all WPF outputs linked to the DU media: vsp1: Add support for extended display list headers media: vsp1: Provide support for extended command pools media: vsp1: Support Interlaced display pipelines drm: rcar-du: Support interlaced video output through vsp1 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +- drivers/media/platform/vsp1/vsp1.h | 3 +- drivers/media/platform/vsp1/vsp1_dl.c | 407 +++-- drivers/media/platform/vsp1/vsp1_dl.h | 32 +- drivers/media/platform/vsp1/vsp1_drm.c | 13 +- drivers/media/platform/vsp1/vsp1_drv.c | 23 +- drivers/media/platform/vsp1/vsp1_regs.h | 6 +- drivers/media/platform/vsp1/vsp1_rpf.c | 71 +++- drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +- drivers/media/platform/vsp1/vsp1_wpf.c | 6 +- include/media/vsp1.h| 2 +- 12 files changed, 456 insertions(+), 112 deletions(-) base-commit: de53826416ea9c22ee985d1f0291aab7d7ea94ce -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/selftests: Add drm helper selftest
On Thu, May 03, 2018 at 01:22:17PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/selftests/Makefile| 2 +-
> .../gpu/drm/selftests/drm_helper_selftests.h | 9 +
> drivers/gpu/drm/selftests/test-drm-helper.c | 247 ++
> 4 files changed, 258 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/selftests/drm_helper_selftests.h
> create mode 100644 drivers/gpu/drm/selftests/test-drm-helper.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index d684855b95c2..28d059007ac2 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -55,6 +55,7 @@ config DRM_DEBUG_SELFTEST
> depends on DEBUG_KERNEL
> select PRIME_NUMBERS
> select DRM_LIB_RANDOM
> + select DRM_KMS_HELPER
> default n
> help
> This option provides kernel modules that can be used to run
> diff --git a/drivers/gpu/drm/selftests/Makefile
> b/drivers/gpu/drm/selftests/Makefile
> index f7dd66e859a9..9fc349fa18e9 100644
> --- a/drivers/gpu/drm/selftests/Makefile
> +++ b/drivers/gpu/drm/selftests/Makefile
> @@ -1 +1 @@
> -obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o
> +obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm-helper.o
> diff --git a/drivers/gpu/drm/selftests/drm_helper_selftests.h
> b/drivers/gpu/drm/selftests/drm_helper_selftests.h
> new file mode 100644
> index ..9771290ed228
> --- /dev/null
> +++ b/drivers/gpu/drm/selftests/drm_helper_selftests.h
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* List each unit test as selftest(name, function)
> + *
> + * The name is used as both an enum and expanded as igt__name to create
> + * a module parameter. It must be unique and legal for a C identifier.
> + *
> + * Tests are executed in order by igt/drm_selftests_helper
> + */
> +selftest(check_plane_state, igt_check_plane_state)
> diff --git a/drivers/gpu/drm/selftests/test-drm-helper.c
> b/drivers/gpu/drm/selftests/test-drm-helper.c
> new file mode 100644
> index ..a015712b43e8
> --- /dev/null
> +++ b/drivers/gpu/drm/selftests/test-drm-helper.c
> @@ -0,0 +1,247 @@
> +/*
> + * Test cases for the drm_kms_helper functions
> + */
> +
> +#define pr_fmt(fmt) "drm_kms_helper: " fmt
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define TESTS "drm_helper_selftests.h"
> +#include "drm_selftest.h"
> +
> +#define FAIL(test, msg, ...) \
> + do { \
> + if (test) { \
> + pr_err("%s/%u: " msg, __FUNCTION__, __LINE__,
> ##__VA_ARGS__); \
> + return -EINVAL; \
> + } \
> + } while (0)
> +
> +#define FAIL_ON(x) FAIL((x), "%s", "FAIL_ON(" __stringify(x) ")\n")
> +
> +static void set_src(struct drm_plane_state *plane_state,
> + unsigned src_x, unsigned src_y,
> + unsigned src_w, unsigned src_h)
> +{
> + plane_state->src_x = src_x;
> + plane_state->src_y = src_y;
> + plane_state->src_w = src_w;
> + plane_state->src_h = src_h;
> +}
> +
> +static bool check_src_eq(struct drm_plane_state *plane_state,
> + unsigned src_x, unsigned src_y,
> + unsigned src_w, unsigned src_h)
> +{
> + if (plane_state->src.x1 < 0) {
> + pr_err("src x coordinate %x should never be below 0.\n",
> plane_state->src.x1);
> + drm_rect_debug_print("src: ", &plane_state->src, true);
> + return false;
> + }
> + if (plane_state->src.y1 < 0) {
> + pr_err("src y coordinate %x should never be below 0.\n",
> plane_state->src.y1);
> + drm_rect_debug_print("src: ", &plane_state->src, true);
> + return false;
> + }
> +
> + if (plane_state->src.x1 != src_x ||
> + plane_state->src.y1 != src_y ||
> + drm_rect_width(&plane_state->src) != src_w ||
> + drm_rect_height(&plane_state->src) != src_h) {
> + drm_rect_debug_print("src: ", &plane_state->src, true);
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static void set_crtc(struct drm_plane_state *plane_state,
> + int crtc_x, int crtc_y,
> + unsigned crtc_w, unsigned crtc_h)
> +{
> + plane_state->crtc_x = crtc_x;
> + plane_state->crtc_y = crtc_y;
> + plane_state->crtc_w = crtc_w;
> + plane_state->crtc_h = crtc_h;
> +}
> +
> +static bool check_crtc_eq(struct drm_plane_state *plane_state,
> + int crtc_x, int crtc_y,
> + unsigned crtc_w, unsigned crtc_h)
> +{
> + if (plane_state->dst.x1 != crtc_x ||
> + plane_state->dst.y1 != crtc_y ||
> + drm_rect_width(&plane_state->dst) != crtc_w ||
> + drm_rect_height(&plane_state->dst) != crtc_h) {
> + drm_rect_debug_print("dst: ", &plane_state->dst, false);
> +
> + ret
[PATCH v4 01/11] media: vsp1: drm: Fix minor grammar error
The pixel format is 'unsupported'. Fix the small debug message which
incorrectly declares this.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index ef0148082bf7..2c3db8b8adce 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -806,7 +806,7 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int
pipe_index,
*/
fmtinfo = vsp1_get_format_info(vsp1, cfg->pixelformat);
if (!fmtinfo) {
- dev_dbg(vsp1->dev, "Unsupport pixel format %08x for RPF\n",
+ dev_dbg(vsp1->dev, "Unsupported pixel format %08x for RPF\n",
cfg->pixelformat);
return -EINVAL;
}
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/11] media: vsp1: Rename dl_child to dl_next
Both vsp1_dl_list_commit() and __vsp1_dl_list_put() walk the display
list chain referencing the nodes as children, when in reality they are
siblings.
Update the terminology to 'dl_next' to be consistent with the
vsp1_video_pipeline_run() usage.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index f4cede9b9b43..ec6fc21fabe0 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -398,7 +398,7 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct
vsp1_dl_manager *dlm)
/* This function must be called with the display list manager lock held.*/
static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
{
- struct vsp1_dl_list *dl_child;
+ struct vsp1_dl_list *dl_next;
if (!dl)
return;
@@ -408,8 +408,8 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
* hardware operation.
*/
if (dl->has_chain) {
- list_for_each_entry(dl_child, &dl->chain, chain)
- __vsp1_dl_list_put(dl_child);
+ list_for_each_entry(dl_next, &dl->chain, chain)
+ __vsp1_dl_list_put(dl_next);
}
dl->has_chain = false;
@@ -673,17 +673,17 @@ static void vsp1_dl_list_commit_singleshot(struct
vsp1_dl_list *dl)
void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool internal)
{
struct vsp1_dl_manager *dlm = dl->dlm;
- struct vsp1_dl_list *dl_child;
+ struct vsp1_dl_list *dl_next;
unsigned long flags;
if (dlm->mode == VSP1_DL_MODE_HEADER) {
/* Fill the header for the head and chained display lists. */
vsp1_dl_list_fill_header(dl, list_empty(&dl->chain));
- list_for_each_entry(dl_child, &dl->chain, chain) {
- bool last = list_is_last(&dl_child->chain, &dl->chain);
+ list_for_each_entry(dl_next, &dl->chain, chain) {
+ bool last = list_is_last(&dl_next->chain, &dl->chain);
- vsp1_dl_list_fill_header(dl_child, last);
+ vsp1_dl_list_fill_header(dl_next, last);
}
}
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/i915: Do not adjust scale when out of bounds, v2.
On Thu, May 03, 2018 at 01:22:15PM +0200, Maarten Lankhorst wrote:
> With the previous patch drm_atomic_helper_check_plane_state correctly
> calculates clipping and the xf86-video-intel ddx is fixed to fall back
> to GPU correctly when SetPlane fails, we can remove the hack where
> we try to pan/zoom when out of min/max scaling range. This was already
> poor behavior where the screen didn't show what was requested, and now
> instead we reject it outright. This simplifies check_sprite_plane a lot.
>
> Changes since v1:
> - Set crtc_h to the height correctly.
> - Reject < 3x3 rectangles instead of making them invisible forFor gen9+ skl_update_scaler_plane will reject them.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 144 +++-
> 1 file changed, 35 insertions(+), 109 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 44d7aca222b0..970015dcc6f1 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -936,22 +936,12 @@ intel_check_sprite_plane(struct intel_plane *plane,
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> struct drm_framebuffer *fb = state->base.fb;
> - int crtc_x, crtc_y;
> - unsigned int crtc_w, crtc_h;
> - uint32_t src_x, src_y, src_w, src_h;
> - struct drm_rect *src = &state->base.src;
> - struct drm_rect *dst = &state->base.dst;
> - struct drm_rect clip = {};
> int max_stride = INTEL_GEN(dev_priv) >= 9 ? 32768 : 16384;
> - int hscale, vscale;
> int max_scale, min_scale;
> bool can_scale;
> int ret;
> uint32_t pixel_format = 0;
>
> - *src = drm_plane_state_src(&state->base);
> - *dst = drm_plane_state_dest(&state->base);
> -
> if (!fb) {
> state->base.visible = false;
> return 0;
> @@ -990,64 +980,19 @@ intel_check_sprite_plane(struct intel_plane *plane,
> min_scale = plane->can_scale ? 1 : (1 << 16);
> }
>
> - /*
> - * FIXME the following code does a bunch of fuzzy adjustments to the
> - * coordinates and sizes. We probably need some way to decide whether
> - * more strict checking should be done instead.
> - */
> - drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> - state->base.rotation);
> -
> - hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
> - BUG_ON(hscale < 0);
> -
> - vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
> - BUG_ON(vscale < 0);
> -
> - if (crtc_state->base.enable)
> - drm_mode_get_hv_timing(&crtc_state->base.mode,
> -&clip.x2, &clip.y2);
> -
> - state->base.visible = drm_rect_clip_scaled(src, dst, &clip);
> -
> - crtc_x = dst->x1;
> - crtc_y = dst->y1;
> - crtc_w = drm_rect_width(dst);
> - crtc_h = drm_rect_height(dst);
> + ret = drm_atomic_helper_check_plane_state(&state->base,
> + &crtc_state->base,
> + min_scale, max_scale,
> + true, true);
> + if (ret)
> + return ret;
>
> if (state->base.visible) {
> - /* check again in case clipping clamped the results */
> - hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> - if (hscale < 0) {
> - DRM_DEBUG_KMS("Horizontal scaling factor out of
> limits\n");
> - drm_rect_debug_print("src: ", src, true);
> - drm_rect_debug_print("dst: ", dst, false);
> -
> - return hscale;
> - }
> -
> - vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> - if (vscale < 0) {
> - DRM_DEBUG_KMS("Vertical scaling factor out of
> limits\n");
> - drm_rect_debug_print("src: ", src, true);
> - drm_rect_debug_print("dst: ", dst, false);
> -
> - return vscale;
> - }
> -
> - /* Make the source viewport size an exact multiple of the
> scaling factors. */
> - drm_rect_adjust_size(src,
> - drm_rect_width(dst) * hscale -
> drm_rect_width(src),
> - drm_rect_height(dst) * vscale -
> drm_rect_height(src));
> -
> - drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
> - state->base.rotation);
> -
> - /* sanity check to make sure the src viewport wasn't enlarged */
> - WARN_ON(src->x1 < (int) state->base.src_x ||
> - src->y1 < (int) state->base.src_y ||
> -
Re: [PATCH] drm/atomic: Handling the case when setting old crtc for plane
On Thu, May 03, 2018 at 01:55:03PM +0300, Ville Syrjälä wrote:
> On Thu, May 03, 2018 at 11:24:59AM +0200, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 11:19:32AM +0530, Satendra Singh Thakur wrote:
> > > In the func drm_atomic_set_crtc_for_plane, with the current code,
> > > if crtc of the plane_state and crtc passed as argument to the func
> > > are same, entire func will executed in vein.
> > > It will get state of crtc and clear and set the bits in plane_mask.
> > > All these steps are not required for same old crtc.
> > > Ideally, we should do nothing in this case, this patch handles the same,
> > > and causes the program to return without doing anything in such scenario.
> > >
> > > Signed-off-by: Satendra Singh Thakur
> > > Cc: Madhur Verma
> > > Cc: Hemanshu Srivastava
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 7d25c42..5bd3365 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1421,7 +1421,9 @@ drm_atomic_set_crtc_for_plane(struct
> > > drm_plane_state *plane_state,
> > > {
> > > struct drm_plane *plane = plane_state->plane;
> > > struct drm_crtc_state *crtc_state;
> > > -
> > > + /* Nothing to do for same crtc*/
> > > + if (plane_state->crtc == crtc)
> > > + return 0;
> >
> > I didn't do this (both here and in the set_crtc_for_connector functions)
> > because the overhead is probably way down in the noise compared to the
> > overall atomic commit machinery. Do you really see this as a hotpath?
>
> drm_atomic_set_crtc_for_connector() actually has this since commit
> e2d800a3ce1b ("drm: Avoid connector reference imbalance on error path")
Ok, applied for consistency. Thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/omap: minor fixes
On 2018-05-02 12:11, Tomi Valkeinen wrote: > Hi, > > This series has some minor fixes found by a static analysis tool, and one for > missing linefeeds. As far as I know, we have never hit any of those errors. To all: Reviewed-by: Peter Ujfalusi > > Tomi > > Tomi Valkeinen (4): > drm/omap: check return value from soc_device_match > drm/omap: handle error if scale coefs are not found > drm/omap: add missing linefeeds to prints > drm/omap: handle alloc failures in omap_connector > > drivers/gpu/drm/omapdrm/dss/dispc.c | 20 +--- > drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 7 ++- > drivers/gpu/drm/omapdrm/omap_connector.c | 10 ++ > 3 files changed, 29 insertions(+), 8 deletions(-) > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/rect: Handle rounding errors in drm_rect_clip_scaled, v3.
On Thu, May 03, 2018 at 01:22:14PM +0200, Maarten Lankhorst wrote:
> Instead of relying on a scale which may increase rounding errors,
> clip src by doing: src * (dst - clip) / dst and rounding the result
> away from 1, so the new coordinates get closer to 1. We won't need
> to fix up with a magic macro afterwards, because our scaling factor
> will never go to the other side of 1.
>
> Changes since v1:
> - Adjust dst immediately, else drm_rect_width/height on dst gives bogus
> results.
> Change since v2:
> - Get rid of macros and use 64-bits math.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/gpu/drm/drm_rect.c | 45 -
> drivers/gpu/drm/i915/intel_sprite.c | 2 +-
> include/drm/drm_rect.h | 3 +-
> 4 files changed, 35 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9cb2209f6fc8..130da5195f3b 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -766,7 +766,7 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state,
> if (crtc_state->enable)
> drm_mode_get_hv_timing(&crtc_state->mode, &clip.x2, &clip.y2);
>
> - plane_state->visible = drm_rect_clip_scaled(src, dst, &clip, hscale,
> vscale);
> + plane_state->visible = drm_rect_clip_scaled(src, dst, &clip);
>
> drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
>
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index 4735526297aa..f477063f18ea 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -50,13 +50,21 @@ bool drm_rect_intersect(struct drm_rect *r1, const struct
> drm_rect *r2)
> }
> EXPORT_SYMBOL(drm_rect_intersect);
>
> +static u32 clip_scaled(u32 src, u32 dst, u32 clip)
> +{
> + u64 newsrc = mul_u32_u32(src, dst - clip);
'newsrc' feels slightly misleading. It would be a decent name for
the final return value of the function, but for this intermediate
value 'tmp' or something equally non specific might be better.
> +
> + if (src < (dst << 16))
> + return DIV_ROUND_UP_ULL(newsrc, dst);
> + else
> + return DIV_ROUND_DOWN_ULL(newsrc, dst);
I think we could use a comment here to explain the choice of
rounding direction. Eg.
/*
* Round toward 1.0 when clipping so that we don't accidentally
* change upscaling to downscaling or vice versa.
*/
?
> +}
> +
> /**
> * drm_rect_clip_scaled - perform a scaled clip operation
> * @src: source window rectangle
> * @dst: destination window rectangle
> * @clip: clip rectangle
> - * @hscale: horizontal scaling factor
> - * @vscale: vertical scaling factor
> *
> * Clip rectangle @dst by rectangle @clip. Clip rectangle @src by the
> * same amounts multiplied by @hscale and @vscale.
> @@ -66,33 +74,44 @@ EXPORT_SYMBOL(drm_rect_intersect);
> * %false otherwise
> */
> bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
> - const struct drm_rect *clip,
> - int hscale, int vscale)
> + const struct drm_rect *clip)
> {
> int diff;
>
> diff = clip->x1 - dst->x1;
> if (diff > 0) {
> - int64_t tmp = src->x1 + (int64_t) diff * hscale;
> - src->x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + u32 new_src_w = clip_scaled(drm_rect_width(src),
> + drm_rect_width(dst), diff);
Could have precomputed the src/dst width/height upfront maybe.
Oh, I guess you can't since your clip_scaled() uses the dst width/height
for more than the scaling factor. If it just computed diff*src/dst
like the original code does then precomputing would work just fine.
Your way feels a bit more complicated to me, but looks like it should
work.
Reviewed-by: Ville Syrjälä
> +
> + src->x1 = clamp_t(int64_t, src->x2 - new_src_w, INT_MIN,
> INT_MAX);
> + dst->x1 = clip->x1;
> }
> diff = clip->y1 - dst->y1;
> if (diff > 0) {
> - int64_t tmp = src->y1 + (int64_t) diff * vscale;
> - src->y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + u32 new_src_h = clip_scaled(drm_rect_height(src),
> + drm_rect_height(dst), diff);
> +
> + src->y1 = clamp_t(int64_t, src->y2 - new_src_h, INT_MIN,
> INT_MAX);
> + dst->y1 = clip->y1;
> }
> diff = dst->x2 - clip->x2;
> if (diff > 0) {
> - int64_t tmp = src->x2 - (int64_t) diff * hscale;
> - src->x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + u32 new_src_w = clip_scaled(drm_rect_width(src),
> + drm_rect_width(dst), diff);
> +
> + src->x2 = clamp_t(int64_t, src->x1 +
Re: [PATCH 1/5] drm/rect: Round above 1 << 16 upwards to correct scale calculation functions.
On Thu, May 03, 2018 at 01:22:13PM +0200, Maarten Lankhorst wrote: > When calculating limits we want to be as pessimistic as possible, > so we have to explicitly say whether we want to round up or down > to accurately calculate whether we are below min_scale or above > max_scale. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/drm_rect.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c > index a3783ecea297..4735526297aa 100644 > --- a/drivers/gpu/drm/drm_rect.c > +++ b/drivers/gpu/drm/drm_rect.c > @@ -106,7 +106,10 @@ static int drm_calc_scale(int src, int dst) > if (dst == 0) > return 0; > > - scale = src / dst; > + if (src > (dst << 16)) > + return DIV_ROUND_UP(src, dst); > + else > + scale = src / dst; > > return scale; > } > @@ -121,6 +124,9 @@ static int drm_calc_scale(int src, int dst) > * Calculate the horizontal scaling factor as > * (@src width) / (@dst width). > * > + * If the scale is below 1 << 16, round down, if above up. This will The "if above up" part doesn't read all that well to me. Maybe write it out fully "If the scale is above 1 << 16, round up"? Reviewed-by: Ville Syrjälä > + * calculate the scale with the most pessimistic limit calculation. > + * > * RETURNS: > * The horizontal scaling factor, or errno of out of limits. > */ > @@ -152,6 +158,9 @@ EXPORT_SYMBOL(drm_rect_calc_hscale); > * Calculate the vertical scaling factor as > * (@src height) / (@dst height). > * > + * If the scale is below 1 << 16, round down, if above up. This will > + * calculate the scale with the most pessimistic limit calculation. > + * > * RETURNS: > * The vertical scaling factor, or errno of out of limits. > */ > @@ -189,6 +198,9 @@ EXPORT_SYMBOL(drm_rect_calc_vscale); > * If the calculated scaling factor is above @max_vscale, > * decrease the height of rectangle @src to compensate. > * > + * If the scale is below 1 << 16, round down, if above up. This will > + * calculate the scale with the most pessimistic limit calculation. > + * > * RETURNS: > * The horizontal scaling factor. > */ > @@ -239,6 +251,9 @@ EXPORT_SYMBOL(drm_rect_calc_hscale_relaxed); > * If the calculated scaling factor is above @max_vscale, > * decrease the height of rectangle @src to compensate. > * > + * If the scale is below 1 << 16, round down, if above up. This will > + * calculate the scale with the most pessimistic limit calculation. > + * > * RETURNS: > * The vertical scaling factor. > */ > -- > 2.17.0 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add SPDX idenitifier and clarify license
Am 03.05.2018 um 15:03 schrieb Fabio Estevam: On Wed, May 2, 2018 at 10:46 AM, Thomas Hellstrom wrote: diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c b/drivers/gpu/drm/ttm/ttm_agp_backend.c index 7c2485fe88d8..ea4d59eb8966 100644 --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ According to Documentation/process/license-rules.rst the SPDX tag should start with // in .c files. Interesting, wasn't the long term coding style rule to not use C++ style comment in Linux C files? How does it come to abandon that now? Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/9] drm/panel: Add Netron DY E231732
Hi, On Wed, May 02, 2018 at 09:20:30AM +0200, Paul Kocialkowski wrote: > Le vendredi 09 septembre 2016 à 16:35 +0200, Maxime Ripard a écrit : > > On Wed, Sep 07, 2016 at 12:01:56AM +0800, Chen-Yu Tsai wrote: > > > Hi, > > > > > > On Tue, Sep 6, 2016 at 10:46 PM, Maxime Ripard > > > wrote: > > > > The E231732 is a 7" panel with a resolution of 800x480. > > > > > > From what I could make out of an archived version of Netron's > > > website > > > (it's unreachable from my place), they are a manufacturer of printed > > > ribbon cables, not LCD panels. This is probably a no-go. > > > > I don't know. I haven't been able to find any website for Netron DY, > > however, googling the part number I used find numerous matches on ebay > > and alibaba. > > While starting a port for the A13-based TZX-Q8-713B7 tablet, it appears > that my LCD cable also has the Netron-DY E231732 marking, but is > definitely different from the one on the SinA33. So I think Chen-Yu's > comment was founded and "Netron DY E231732" does not reflect the panel > name. > > Here are some details regarding the LCD cable on both devices: > > The SinA33 has a 1024x600 panel with the following markings: > 7300101463 > E231732 > NETRON-DY <> 1 > 94V-0\1310 > > The TZX-Q8-713B7 has a 800x480 panel with the following markings: > 7300101448 > E231732 > NETRON-DY <> 2 > 94V-0\1249 > > So it seems that the distinctive part of the name is > 7300101463/7300101448. > > Also, it seems that various online shops list the panels with a name > like "E231732 7300101463". So maybe we could change the bindings to > have: > > - netron-dy,e231732-7300101463 > - netron-dy,e231732-7300101448 > > What do you think? Does that make sense? > > We should probably also fallback netron-dy,e231732 to the sina33's panel > in order to avoid breaking the ABI. That's kind of unfortunate, and maybe the netron part is just the vendor of the flex cable. In your case, I guess the best work around this would be to call it TZX-Q8-713B7-panel, if it's shipped with a single resolution. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add SPDX idenitifier and clarify license
On Wed, May 2, 2018 at 10:46 AM, Thomas Hellstrom wrote: > diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c > b/drivers/gpu/drm/ttm/ttm_agp_backend.c > index 7c2485fe88d8..ea4d59eb8966 100644 > --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c > +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c > @@ -1,3 +1,4 @@ > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ According to Documentation/process/license-rules.rst the SPDX tag should start with // in .c files. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add SPDX idenitifier and clarify license
On Wed, May 02, 2018 at 11:25:35PM +0200, Dirk Hohndel wrote: > On Wed, May 02, 2018 at 04:33:30PM -0400, Sean Paul wrote: > > > > diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c > > > > b/drivers/gpu/drm/ttm/ttm_agp_backend.c > > > > index 7c2485fe88d8..ea4d59eb8966 100644 > > > > --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c > > > > +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c > > > > @@ -1,3 +1,4 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ > > > > > > > > /** > > > > * > > > > * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA > > > > > > Probably a stupid question, but can't you remove the boilerplate license > > > now? > > > > > > > Answering my own question, there are differences between the license in the > > files > > and the SPDX license [1]. They are: > > - the license in the files adds "(including the next paragraph)" in the > > second > > paragraph > > - the files have "AND/OR ITS SUPPLIERS" in the third paragraph > > - a couple of list items are transposed and changed, but should be fine > > according to [2] > > > > So IANAL, but it seems like you should either add the SPDX and remove the > > boilerplate, or keep the boilerplate and skip the SPDX. > > I am not a lawyer, either, so I asked a couple before starting this little > project... > > GPL and similar license boilerplate can be replaced (and I removed it from > some files in other commits that I'm working on to clean up the files > which originated from VMware), but the MIT license is a template license > and because of that the Copyright notice is actually part of the license > and in order for people to be able to reproduce that, you aren't supposed > to remove the boilerplate. > > There are a number of variations of the MIT license, a bit of googling > seems to indicate that the text that already existed in those files is the > MIT/X-Consortium flavor of the license - that's where the "including the > next paragraph" can be found, see here > https://www.x.org/releases/X11R7.7/doc/xorg-docs/License.html > > SPDX appears to consider those licenses equivalent (they have a different, > older flavor of the X11 license as "X11". > > Similarly, the "and/or its suppliers" language seems to have been added by > some > project around X (but I wasn't able to pin down where exactly it came from), > but > once again the lawyers don't appear to see an issue. > > So in summary > - we need to keep the boilerplate for MIT (but not GPL) > - the text modifications should be OK (and the scanners appear to > recognize the existing text as MIT) > > Not sure this answers your question. Thank you for the awesome summary, it is very helpful! So since the boilerplate has to stay, is there a benefit to adding the SPDX header? Is it just to make scripting/scraping easier? Sean > > /D -- 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: [Intel-gfx] [PATCH v8 1/2] drm: content-type property for HDMI connector
On Thu, 2018-05-03 at 10:46 +, Lisovskiy, Stanislav wrote:
> On Thu, 2018-05-03 at 13:18 +0300, Jani Nikula wrote:
> > On Wed, 02 May 2018, StanLis wrote:
> > > From: Stanislav Lisovskiy
> > >
> > >
> > > diff --git a/Documentation/gpu/kms-properties.csv
> > > b/Documentation/gpu/kms-properties.csv
> > > index 07ed22ea3bd6..bfde04eddd14 100644
> > > --- a/Documentation/gpu/kms-properties.csv
> > > +++ b/Documentation/gpu/kms-properties.csv
> > > @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property
> > > Name,Type,Property Values,Object attached,De
> > > ,Virtual GPU,“suggested X”,RANGE,"Min=0,
> > > Max=0x",Connector,property to suggest an X offset for a
> > > connector
> > > ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property
> > > to suggest an Y offset for a connector
> > > ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> > > }",Connector,TDB
> > > +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"",
> > > ""Photo"", ""Cinema"", ""Game"" }",Connector,TBD
> > > i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"",
> > > ""Full"",
> > > ""Limited 16:235"" }",Connector,"When this property is set to
> > > Limited 16:235 and CTM is set, the hardware will be programmed
> > > with
> > > the result of the multiplication of CTM by the limited range
> > > matrix
> > > to ensure the pixels normaly in the range 0..1.0 are remapped to
> > > the range 16/255..235/255."
> > > ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on""
> > > }",Connector,TBD
> > > ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"",
> > > ""PAL_B"" } etc.",Connector,TBD
> > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > b/drivers/gpu/drm/drm_atomic.c
> > > index 3d9ae057a6cd..046fc5249859 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1270,6 +1270,15 @@ static int
> > > drm_atomic_connector_set_property(struct drm_connector
> > > *connector,
> > > state->link_status = val;
> > > } else if (property == config->aspect_ratio_property) {
> > > state->picture_aspect_ratio = val;
> > > + } else if (property == config->content_type_property) {
> > > + /*
> > > + * Lowest two bits of content_type property
> > > control
> > > + * content_type, bit 2 controls itc bit.
> > > + * It was decided to have a single property
> > > called
> > > + * content_type, instead of content_type and
> > > itc.
> >
> > Who decided? I was trying to look through the history, but couldn't
> > find
> > the review discussion on this part.
> >
> > This approach encodes meaning to bits in the property value, while
> > no
> > such promise is actually made in the property interface. Do you
> > expect
> > to support graphics, photo, cinema, game with and without itc?
> >
> > Is the intention to be able to extend this later on? If yes, why is
> > itc
> > in bit 2 instead of e.g. bit 0, so the content-type could actually
> > grow?
>
> There was a discussion here with Hans Verkuil, somewhat 2-3 weeks
> ago,
> he indicated that HDMI 1.4 spec was wrong in assuming that itc and
> content-type bits can be used separately. Then it was decided offline
> with Ville Sirjala that we're not going to create a separate property
> for itc bit for a sake of simplicity.
> In short, the content type bits CN1..CN0 are not valid without itc
> bit.
>
> >
> > > + */
> > > + state->content_type = val & 3;
> > > + state->it_content = val >> 2;
> >
> > I'm mostly asking because this is really confusing considering the
> > property value definitions, and should IMO be written in terms of
> > the
> > macros, respecting SPOT, instead of adding magic numbers here.
> >
> > Also, later on you set frame->content_type =
> > HDMI_CONTENT_TYPE_GRAPHICS,
> > which is inconsistent with the masking above.
>
> If you mean those lines, where it initializes the avi infoframe
> structure, it sets itc bit at the same time with content_type and
> from
> the frame
> encoding point of view those are still separate, so there is no
> violation:
>
> + frame->content_type = HDMI_CONTENT_TYPE_GRAPHICS;
> + frame->itc = 0;
>
> So we have a single property setting both at the same time, as
> there is no point to have content-type without itc bit set.
> Everytime property is set, those state bits are changed and then
> encoded into frame.
>
> + frame.avi.content_type = connector->state->content_type;
> + frame.avi.itc = connector->state->it_content;
>
> > BR,
> > Jani.
> >
> >
> > PS. Please wait for the discussion to settle on this before sending
> > another version. Accumulating tons of revisions of the patch does
> > not
> > make it move any faster.
>
> Well, there was plenty of discussion already, Ville, Hans and Daniel
> gave recommendations and acknowleged those changes earlier, so I
> thought that everything is clear here at least. Any comments are
> stil
Re: [PATCH RESEND 1/2] drm/msm: remove unbalanced mutex unlock
On Thu, May 3, 2018 at 8:00 AM, Daniel Mack wrote:
> This regression stems from 0e08270a1f01 ("drm/msm: Separate locking of
> buffer resources from struct_mutex").
>
> Signed-off-by: Daniel Mack
> Cc: Sushmita Susheelendra
> Cc: Rob Clark
> Fixes: 0e08270a1f01 ("drm/msm: Separate locking of buffer resources from
> struct_mutex")
> ---
> I'm resending these two patches as I got no reply last time.
I've applied these two to msm-next. Sorry I missed them before...
for some reason they don't seem to show up in the dri-devel
patchworks[1]
BR,
-R
[1] https://patchwork.freedesktop.org/project/dri-devel/series/
>
> drivers/gpu/drm/msm/dsi/dsi_host.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 0f7324a686ca..27637d8a99ff 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -994,7 +994,6 @@ static int dsi_tx_buf_alloc(struct msm_dsi_host
> *msm_host, int size)
>
> ret = msm_gem_get_iova(msm_host->tx_gem_obj,
> priv->kms->aspace, &iova);
> - mutex_unlock(&dev->struct_mutex);
> if (ret) {
> pr_err("%s: failed to get iova, %d\n", __func__, ret);
> return ret;
> --
> 2.14.3
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
