Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Thu, Jun 04, 2020 at 09:37:45AM +0300, Mike Rapoport wrote: > On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote: > > On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > > > > With linux-next on sparc I too see the spinlock issue; something like: > > > > ... > > Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139 > > lock: 0xf53ef350, .magic: dead4ead, .owner: S01syslogd/139, .owner_cpu: 0 > > CPU: 0 PID: 139 Comm: S01syslogd Not tainted 5.7.0-next-20200603 #1 > > [f0067d00 : > > do_raw_spin_lock+0xa8/0xd8 ] > > [f00d598c : > > copy_page_range+0x328/0x804 ] > > [f0025c34 : > > dup_mm+0x334/0x434 ] > > [f0027198 : > > copy_process+0x1248/0x12d4 ] > > [f00273b8 : > > _do_fork+0x54/0x30c ] > > [f00276e4 : > > do_fork+0x5c/0x6c ] > > [f000de44 : > > sparc_do_fork+0x18/0x38 ] > > [f000b7f4 : > > do_syscall+0x34/0x40 ] > > [5010cd4c : > > 0x5010cd4c ] > > > > > > I'm going to bisect between there and HEAD. > > The sparc issue should be fixed by > > https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org Saw your other email. And yes they are! Thanks! Ira > > > Ira > > -- > Sincerely yours, > Mike. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Thu, Jun 04, 2020 at 09:18:05AM +0300, Mike Rapoport wrote: > On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > > On 6/3/20 2:14 PM, Ira Weiny wrote: > > > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote: > > >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > > >> > > >>>>> > > >>>>> Actually it occurs to me that the patch consolidating kmap_prot is > > >>>>> odd for > > >>>>> sparc 32 bit... > > >>>>> > > >>>>> Its a long shot but could you try reverting this patch? > > >>>>> > > >>>>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions > > >>>>> > > >>>> > > >>>> That is not easy to revert, unfortunately, due to several follow-up > > >>>> patches. > > >>> > > >>> I have gotten your sparc tests to run and they all pass... > > >>> > > >>> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh > > >>> Build reference: v5.7-rc4-17-g852b6f2edc0f > > >>> > > >>> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed > > >>> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed > > >>> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed > > >>> Building sparc32:SS-4:nosmp:initrd ... running . passed > > >>> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed > > >>> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed > > >>> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed > > >>> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed > > >>> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . > > >>> passed > > >>> Building sparc32:SS-4:smp:scsi:hd ... running . passed > > >>> Building sparc32:SS-5:smp:scsi:cd ... running . passed > > >>> Building sparc32:SS-10:smp:scsi:hd ... running . passed > > >>> Building sparc32:SS-20:smp:scsi:hd ... running . passed > > >>> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed > > >>> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed > > >>> > > >>> Is there another test I need to run? > > >> > > >> This all petered out, but as I understand it, this patchset still might > > >> have issues on various architectures. > > >> > > >> Can folks please provide an update on the testing status? > > > > > > I believe the tests were failing for Guenter due to another patch > > > set...[1] > > > > > > My tests with just this series are working. > > > > > >>From my understanding the other failures were unrelated.[2] > > > > > > > > > I've checked the patch above on top of the mmots which already has > > > Ira's patches and it booted fine. I've used sparc32_defconfig to build > > > the kernel and qemu-system-sparc with default machine and CPU. > > > > > > > > > Mike, am I wrong? Do you think the kmap() patches are still causing > > > issues? > > sparc32 UP and microblaze work for me with next-20200603, but I didn't > test other architectures. > > > For my part, all I can say is that -next is in pretty bad shape right now. > > The summary of my tests says: > > > > Build results: > > total: 151 pass: 130 fail: 21 > > Qemu test results: > > total: 430 pass: 375 fail: 55 > > > > sparc32 smp images in next-20200603 still crash for me with a spinlock > > recursion. > > I think this is because Will's fixes [1] are not yet in -next. > > > s390 images hang early in boot. Several others (alpha, arm64, > > various ppc) don't even compile. I can run some more bisects over time, > > but this is becoming a full-time job :-(. > > > > Guenter > > [1] https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org I abandoned the bisect and tested with this fix.[1] It passes. Guenter, on the original thread we had microblaze and ppc working with my fix. https://lore.kernel.org/lkml/20200519194215.ga71...@roeck-us.net/ Sounds like the current failures above are from something much newer in the tree. Ira [1] 23:26:24 >
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote: > On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > > With linux-next on sparc I too see the spinlock issue; something like: > > ... > Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139 > lock: 0xf53ef350, .magic: dead4ead, .owner: S01syslogd/139, .owner_cpu: 0 > CPU: 0 PID: 139 Comm: S01syslogd Not tainted 5.7.0-next-20200603 #1 > [f0067d00 : > do_raw_spin_lock+0xa8/0xd8 ] > [f00d598c : > copy_page_range+0x328/0x804 ] > [f0025c34 : > dup_mm+0x334/0x434 ] > [f0027198 : > copy_process+0x1248/0x12d4 ] > [f00273b8 : > _do_fork+0x54/0x30c ] > [f00276e4 : > do_fork+0x5c/0x6c ] > [f000de44 : > sparc_do_fork+0x18/0x38 ] > [f000b7f4 : > do_syscall+0x34/0x40 ] > [5010cd4c : > 0x5010cd4c ] > > > I'm going to bisect between there and HEAD. The sparc issue should be fixed by https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org > Ira -- Sincerely yours, Mike. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > On 6/3/20 2:14 PM, Ira Weiny wrote: > > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote: > >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > >> ... > >> > >> This all petered out, but as I understand it, this patchset still might > >> have issues on various architectures. > >> > >> Can folks please provide an update on the testing status? > > > > I believe the tests were failing for Guenter due to another patch set...[1] > > > > My tests with just this series are working. > > > >>From my understanding the other failures were unrelated.[2] > > > > > > I've checked the patch above on top of the mmots which already has > > Ira's patches and it booted fine. I've used sparc32_defconfig to build > > the kernel and qemu-system-sparc with default machine and CPU. > > > > > > Mike, am I wrong? Do you think the kmap() patches are still causing issues? > > > > For my part, all I can say is that -next is in pretty bad shape right now. > The summary of my tests says: > > Build results: > total: 151 pass: 130 fail: 21 > Qemu test results: > total: 430 pass: 375 fail: 55 > > sparc32 smp images in next-20200603 still crash for me with a spinlock > recursion. s390 images hang early in boot. Several others (alpha, arm64, > various ppc) don't even compile. I can run some more bisects over time, > but this is becoming a full-time job :-(. > I'm not sure what the process here is. I just applied my series[1] on Linus' Master branch[2] and ran sparc32 and s290 from your tests. sparc32: (passes) 21:43:49 > /home/iweiny/dev/linux-build-test/rootfs/sparc/run-qemu-sparc.sh Build reference: v5.7-7188-g67a7a97e8a0f Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed Building sparc32:SS-4:nosmp:initrd ... running . passed Building sparc32:SS-5:nosmp:scsi:hd ... running . passed Building sparc32:SS-10:nosmp:scsi:cd ... running . passed Building sparc32:SS-20:nosmp:scsi:hd ... running . passed Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running .. passed Building sparc32:SS-4:smp:scsi:hd ... running . passed Building sparc32:SS-5:smp:scsi:cd ... running . passed Building sparc32:SS-10:smp:scsi:hd ... running . passed Building sparc32:SS-20:smp:scsi:hd ... running . passed Building sparc32:SS-600MP:smp:scsi:hd ... running . passed Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed s390: (does not compile) :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp] In file included from ./arch/sparc/include/asm/bug.h:6:0, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/mm.h:9, from mm/huge_memory.c:8: mm/huge_memory.c: In function 'hugepage_init': ./include/linux/compiler.h:403:38: error: call to '__compiletime_assert_127' declared with attribute error: BUILD_BUG_ON failed: ((13 + (13-3))-13) >= 9 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ./include/linux/compiler.h:384:4: note: in definition of macro '__compiletime_assert' prefix ## suffix();\ ^~ ./include/linux/compiler.h:403:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) ^~~~ ./include/linux/bug.h:24:4: note: in expansion of macro 'BUILD_BUG_ON' BUILD_BUG_ON(cond); \ ^~~~ mm/huge_memory.c:403:2: note: in expansion of macro 'MAYBE_BUILD_BUG_ON' MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER); ^~ make[1]: *** [scripts/Makefile.build:267: mm/huge_memory.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1735: mm] Error 2 make: *** Waiting for unfinished jobs The s390 error is the same on Linus' master and linux-next. So wha
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > On 6/3/20 2:14 PM, Ira Weiny wrote: > > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote: > >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > >> > >>>>> > >>>>> Actually it occurs to me that the patch consolidating kmap_prot is odd > >>>>> for > >>>>> sparc 32 bit... > >>>>> > >>>>> Its a long shot but could you try reverting this patch? > >>>>> > >>>>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions > >>>>> > >>>> > >>>> That is not easy to revert, unfortunately, due to several follow-up > >>>> patches. > >>> > >>> I have gotten your sparc tests to run and they all pass... > >>> > >>> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh > >>> Build reference: v5.7-rc4-17-g852b6f2edc0f > >>> > >>> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed > >>> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed > >>> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed > >>> Building sparc32:SS-4:nosmp:initrd ... running . passed > >>> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed > >>> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed > >>> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed > >>> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed > >>> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed > >>> Building sparc32:SS-4:smp:scsi:hd ... running . passed > >>> Building sparc32:SS-5:smp:scsi:cd ... running . passed > >>> Building sparc32:SS-10:smp:scsi:hd ... running . passed > >>> Building sparc32:SS-20:smp:scsi:hd ... running . passed > >>> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed > >>> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed > >>> > >>> Is there another test I need to run? > >> > >> This all petered out, but as I understand it, this patchset still might > >> have issues on various architectures. > >> > >> Can folks please provide an update on the testing status? > > > > I believe the tests were failing for Guenter due to another patch set...[1] > > > > My tests with just this series are working. > > > >>From my understanding the other failures were unrelated.[2] > > > > > > I've checked the patch above on top of the mmots which already has > > Ira's patches and it booted fine. I've used sparc32_defconfig to build > > the kernel and qemu-system-sparc with default machine and CPU. > > > > > > Mike, am I wrong? Do you think the kmap() patches are still causing issues? sparc32 UP and microblaze work for me with next-20200603, but I didn't test other architectures. > For my part, all I can say is that -next is in pretty bad shape right now. > The summary of my tests says: > > Build results: > total: 151 pass: 130 fail: 21 > Qemu test results: > total: 430 pass: 375 fail: 55 > > sparc32 smp images in next-20200603 still crash for me with a spinlock > recursion. I think this is because Will's fixes [1] are not yet in -next. > s390 images hang early in boot. Several others (alpha, arm64, > various ppc) don't even compile. I can run some more bisects over time, > but this is becoming a full-time job :-(. > > Guenter [1] https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org -- Sincerely yours, Mike. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/23] drm/hisilicon/kirin: Use GEM CMA object functions
On Wed, Jun 3, 2020 at 1:31 AM Thomas Zimmermann wrote: > > The kirin driver uses the default implementation for CMA functions. The > DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver. > > Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now > sets .gem_create_object to drm_cma_gem_create_object_default_funcs(), > which sets CMA GEM object functions. GEM object functions implement the > rsp operations where possible. Corresponding interfaces in struct drm_driver > are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(), > which maps the imported buffer upon import. Mmap operations are performed > by drm_gem_prime_mmap(), which goes through GEM file operations. These > changes have been part of the aspeed driver for some time. > > v2: > * use DRM_GEM_CMA_DRIVER_OPS > > Signed-off-by: Thomas Zimmermann > Acked-by: Emil Velikov > Cc: Xu YiPing > Cc: Rongrong Zou > Cc: Xinliang Liu Thanks for sending this out! Works fine on my HiKey board. Tested-by: John Stultz thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/23] drm/hisilicon/kirin: Set .dumb_create to drm_gem_cma_dumb_create()
On Wed, Jun 3, 2020 at 1:31 AM Thomas Zimmermann wrote: > > The kirin drivers uses drm_gem_cma_dumb_create_internal() for its > .dumb_create implementation. The function is meant for internal use > only by drivers that require additional buffer setup. > > Kirin does not do an additional setup, so convert it over to > drm_gem_cma_dumb_create(). > > Signed-off-by: Thomas Zimmermann > Acked-by: Emil Velikov > Cc: Xu YiPing > Cc: Rongrong Zou > Cc: Xinliang Liu Thanks for sending this out! Works fine on my HiKey board. Tested-by: John Stultz thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: hdmi ddc clk: Fix size of m divider
On Wed, Apr 22, 2020 at 5:23 PM Maxime Ripard wrote:
>
> Hi,
>
> On Wed, Apr 15, 2020 at 07:52:28PM +0200, Jernej Škrabec wrote:
> > Dne sreda, 15. april 2020 ob 12:42:14 CEST je Maxime Ripard napisal(a):
> > > On Mon, Apr 13, 2020 at 06:09:08PM +0200, Jernej Škrabec wrote:
> > > > Dne ponedeljek, 13. april 2020 ob 16:12:39 CEST je Chen-Yu Tsai
> > napisal(a):
> > > > > On Mon, Apr 13, 2020 at 6:11 PM Chen-Yu Tsai wrote:
> > > > > > On Mon, Apr 13, 2020 at 5:55 PM Jernej Skrabec
> > > > > >
> > > >
> > > > wrote:
> > > > > > > m divider in DDC clock register is 4 bits wide. Fix that.
> > > > > > >
> > > > > > > Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> > > > > > > Signed-off-by: Jernej Skrabec
> > > > > >
> > > > > > Reviewed-by: Chen-Yu Tsai
> > > > >
> > > > > Cc stable?
> > > >
> > > > I don't think it's necessary:
> > > > 1. It doesn't change much (anything?) for me when reading EDID. I don't
> > > > think it's super important to have precise DDC clock in order to
> > > > properly
> > > > read EDID. 2. No matter if it has "Cc stable" tag or not, it will be
> > > > eventually picked for stable due to fixes tag.
> > > >
> > > > This was only small observation when I was researching EDID readout
> > > > issue
> > > > on A20 board, but sadly, I wasn't able to figure out why reading it
> > > > sometimes fails. I noticed similar issue on SoCs with DE2 (most
> > > > prominently on OrangePi PC2 - H5), but there was easy workaround - I
> > > > just
> > > > disabled video driver in U- Boot. However, if A20 display driver gets
> > > > disabled in U-Boot, it totally breaks video output on my TV when Linux
> > > > boots (no output). I guess there is more fundamental problem with clocks
> > > > than just field size. I think we should add more constraints in clock
> > > > driver, like preset some clock parents and not allow to change parents
> > > > when setting rate, but carefully, so simplefb doesn't break. Such
> > > > constraints should also solve problems with dual head setups.
> > > I disagree here. Doing all sorts of special case just doesn't scale,
> > > and we'll never have the special cases sorted out on all the boards
> > > (and it's a nightmare to maintain).
> > >
> > > Especially since it's basically putting a blanket over the actual
> > > issue and looking the other way. If there's something wrong with how
> > > we deal with (re)parenting, we should fix that. It impacts more than
> > > just DRM, and all the SoCs.
> >
> > I agree with you that automatic solution would be best, but I just don't see
> > it how it would be done.
>
> > Dual head display pipeline is pretty complex for clock driver to get it
> > right
> > on it's own. There are different possible setups and some of them are hot
> > pluggable, like HDMI.
>
> Do you have an actual scenario that is broken right now?
>
> > And there are also SoC specific quirks, like A64, where for some reason,
> > MIPI
> > DPHY and HDMI PHY share same clock parent - PLL_VIDEO0. Technically, MIPI
> > DPHY
> > can be clocked from PLL_PERIPH0 (fixed to 600 MHz), but that's not really
> > helpful. I'm not even sure if there is any good solution to this - certainly
> > HDMI and MIPI can't claim exclusivity and somehow best common rate must be
> > found for PLL_VIDEO0, if that's even possible.
>
> IIRC the DSI DPHY needs a clock running at 297MHz, which is pretty much what
> the
> HDMI PHY should need too (or 148.5, but that's pretty easy to generate from
> 297). So which problem do we have there?
>
> > I was sure that HDMI PHY on A64 can be clocked from PLL_VIDEO1, which would
> > solve main issue, but to date, I didn't find any way to do that.
> >
> > That's pretty off topic, so I hope original patch can be merged as-is.
>
> It does, sorry
>
> Acked-by: Maxime Ripard
Looks like this hasn't landed yet.
ChenYu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/dp: DP PHY compliance for JSL
Signed-off-by: Khaled Almahallawy
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/display/intel_dp.c | 40 ++---
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7223367171d1..44663e8ac9a1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5470,22 +5470,32 @@ intel_dp_autotest_phy_ddi_disable(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
- u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
+ u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value,
trans_ddi_port_mask;
+ enum port port = intel_dig_port->base.port;
+ i915_reg_t dp_tp_reg;
+
+ if (IS_ELKHARTLAKE(dev_priv)) {
+ dp_tp_reg = DP_TP_CTL(port);
+ trans_ddi_port_mask = TRANS_DDI_PORT_MASK;
+ } else if (IS_TIGERLAKE(dev_priv)) {
+ dp_tp_reg = TGL_DP_TP_CTL(pipe);
+ trans_ddi_port_mask = TGL_TRANS_DDI_PORT_MASK;
+ }
trans_ddi_func_ctl_value = intel_de_read(dev_priv,
TRANS_DDI_FUNC_CTL(pipe));
trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
- dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
+ dp_tp_ctl_value = intel_de_read(dev_priv, dp_tp_reg);
trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
- TGL_TRANS_DDI_PORT_MASK);
+ trans_ddi_port_mask);
trans_conf_value &= ~PIPECONF_ENABLE;
dp_tp_ctl_value &= ~DP_TP_CTL_ENABLE;
intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
trans_ddi_func_ctl_value);
- intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
+ intel_de_write(dev_priv, dp_tp_reg, dp_tp_ctl_value);
}
static void
@@ -5497,20 +5507,28 @@ intel_dp_autotest_phy_ddi_enable(struct intel_dp
*intel_dp, uint8_t lane_cnt)
enum port port = intel_dig_port->base.port;
struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
- u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
+ u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value,
trans_ddi_sel_port;
+ i915_reg_t dp_tp_reg;
+
+ if (IS_ELKHARTLAKE(dev_priv)) {
+ dp_tp_reg = DP_TP_CTL(port);
+ trans_ddi_sel_port = TRANS_DDI_SELECT_PORT(port);
+ } else if (IS_TIGERLAKE(dev_priv)) {
+ dp_tp_reg = TGL_DP_TP_CTL(pipe);
+ trans_ddi_sel_port = TGL_TRANS_DDI_SELECT_PORT(port);
+ }
trans_ddi_func_ctl_value = intel_de_read(dev_priv,
TRANS_DDI_FUNC_CTL(pipe));
trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
-
trans_ddi_func_ctl_value |= TRANS_DDI_FUNC_ENABLE |
- TGL_TRANS_DDI_SELECT_PORT(port);
+ trans_ddi_sel_port;
trans_conf_value |= PIPECONF_ENABLE;
dp_tp_ctl_value |= DP_TP_CTL_ENABLE;
intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
- intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
+ intel_de_write(dev_priv, dp_tp_reg, dp_tp_ctl_value);
intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
trans_ddi_func_ctl_value);
}
@@ -5557,6 +5575,7 @@ static u8 intel_dp_autotest_phy_pattern(struct intel_dp
*intel_dp)
static void intel_dp_handle_test_request(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct drm_i915_private *dev_priv = i915;
u8 response = DP_TEST_NAK;
u8 request = 0;
int status;
@@ -5582,6 +5601,11 @@ static void intel_dp_handle_test_request(struct intel_dp
*intel_dp)
response = intel_dp_autotest_edid(intel_dp);
break;
case DP_TEST_LINK_PHY_TEST_PATTERN:
+ if (!IS_ELKHARTLAKE(dev_priv) || !IS_TIGERLAKE(dev_priv)) {
+ drm_dbg_kms(&i915->drm,
+ "PHY compliance for platform not supported\n");
+ return;
+ }
drm_dbg_kms(&i915->drm, "PHY_PATTERN test requested\n");
response = intel_dp_autotest_phy_pattern(intel_dp);
break;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedes
nouveau-fixes 5.8
Hey Dave, Daniel, Another -fixes pull for nouveau, mostly more HDA fixes, but also a fix for display hangs on Volta/Turing, and a GK20A regression fix. Thanks, Ben. The following changes since commit 0ad679d157aa69ddf0ee46b564c9fbb646cf6d4e: drm/nouveau/kms/gt215-: fix race with audio driver runpm (2020-06-01 17:28:42 +1000) are available in the Git repository at: git://github.com/skeggsb/linux linux-5.8 for you to fetch changes up to dd67cab5db7e940dad66653a04d780d53bd380d5: drm/nouveau/kms/nv50-: clear SW state of disabled windows harder (2020-06-04 14:23:22 +1000) Ben Skeggs (6): drm/nouveau/disp: provide hint to OR allocation about HDA requirements drm/nouveau/disp: split part of OR allocation logic into a function drm/nouveau/disp: modify OR allocation policy to account for HDA requirements drm/nouveau/disp/gp100: split SOR implementation from gm200 drm/nouveau/disp/gm200-: detect and potentially disable HDA support on some SORs drm/nouveau/kms/nv50-: clear SW state of disabled windows harder Thierry Reding (1): drm/nouveau: gr/gk20a: Use firmware version 0 drivers/gpu/drm/nouveau/dispnv50/disp.c| 17 ++-- drivers/gpu/drm/nouveau/dispnv50/wndw.c| 5 +- drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 3 +- drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 + drivers/gpu/drm/nouveau/nvkm/engine/disp/gp100.c | 2 +- drivers/gpu/drm/nouveau/nvkm/engine/disp/gp102.c | 2 +- drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c| 73 - drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h| 2 +- .../gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c| 4 +- .../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 36 - .../gpu/drm/nouveau/nvkm/engine/disp/sorgp100.c| 93 ++ .../gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c| 35 +++- .../gpu/drm/nouveau/nvkm/engine/disp/sortu102.c| 32 +++- drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 2 +- 15 files changed, 270 insertions(+), 38 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgp100.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 16/23] drm/rcar-du: Use GEM CMA object functions
Hi Thomas,
Thank you for the patch.
On Wed, Jun 03, 2020 at 10:31:25AM +0200, Thomas Zimmermann wrote:
> The rcar-du driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
> macro now sets these defaults and .dumb_create in struct drm_driver.
>
> By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
> sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
> which sets CMA GEM object functions. GEM object functions implement the
> rsp operations where possible. Corresponding interfaces in struct drm_driver
> are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
> which maps the imported buffer upon import. Mmap operations are performed
> by drm_gem_prime_mmap(), which goes through GEM file operations. These
> changes have been part of the aspeed driver for some time.
How is the aspeed driver related to this patch ?
>
> v2:
> * update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
As explained in the review of v1, this combines multiple changes in a
single patch. Some of those changes are not straightforward to review.
It would be easier if they were split in separate patches.
> Signed-off-by: Thomas Zimmermann
> Tested-by: Kieran Bingham
> Acked-by: Emil Velikov
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 3e67cf70f0402..f53b0ec710850 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -476,16 +476,7 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
>
> static struct drm_driver rcar_du_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .dumb_create= rcar_du_dumb_create,
> + DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(rcar_du_dumb_create),
> .fops = &rcar_du_fops,
> .name = "rcar-du",
> .desc = "Renesas R-Car Display Unit",
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/15] PCI: Add shorthand define for message signalled interrupt types
That's a sensible change. In your title you can use "macro" or "definition" or "macro definition". "Define" is a verb. "PCI: Add a macro for message-signalled interrupt types" On 2020-06-03 7:45 a.m., Piotr Stankiewicz wrote: > There are several places in the kernel which check/ask for MSI or MSI-X > interrupts. It would make sense to have a shorthand constant, similar to "a shorthand constant" --> "a macro which defines all MSI-type of interrupt." Regards, Luben > PCI_IRQ_ALL_TYPES, to use in these situations. So add PCI_IRQ_MSI_TYPES, > for this purpose. > > Signed-off-by: Piotr Stankiewicz > Suggested-by: Andy Shevchenko > Reviewed-by: Andy Shevchenko > --- > Documentation/PCI/msi-howto.rst | 5 +++-- > include/linux/pci.h | 4 ++-- > 2 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/Documentation/PCI/msi-howto.rst b/Documentation/PCI/msi-howto.rst > index aa2046af69f7..2800ff5aa395 100644 > --- a/Documentation/PCI/msi-howto.rst > +++ b/Documentation/PCI/msi-howto.rst > @@ -105,7 +105,8 @@ if it can't meet the minimum number of vectors. > The flags argument is used to specify which type of interrupt can be used > by the device and the driver (PCI_IRQ_LEGACY, PCI_IRQ_MSI, PCI_IRQ_MSIX). > A convenient short-hand (PCI_IRQ_ALL_TYPES) is also available to ask for > -any possible kind of interrupt. If the PCI_IRQ_AFFINITY flag is set, > +any possible kind of interrupt, and (PCI_IRQ_MSI_TYPES) to ask for message > +signalled interrupts (MSI or MSI-X). If the PCI_IRQ_AFFINITY flag is set, > pci_alloc_irq_vectors() will spread the interrupts around the available CPUs. > > To get the Linux IRQ numbers passed to request_irq() and free_irq() and the > @@ -160,7 +161,7 @@ the single MSI mode for a device. It could be done by > passing two 1s as > Some devices might not support using legacy line interrupts, in which case > the driver can specify that only MSI or MSI-X is acceptable:: > > - nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_MSI | PCI_IRQ_MSIX); > + nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_MSI_TYPES); > if (nvec < 0) > goto out_err; > > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 83ce1cdf5676..b6c9bf70363e 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -1422,8 +1422,8 @@ int pci_set_vga_state(struct pci_dev *pdev, bool decode, > */ > #define PCI_IRQ_VIRTUAL (1 << 4) > > -#define PCI_IRQ_ALL_TYPES \ > - (PCI_IRQ_LEGACY | PCI_IRQ_MSI | PCI_IRQ_MSIX) > +#define PCI_IRQ_MSI_TYPES(PCI_IRQ_MSI | PCI_IRQ_MSIX) > +#define PCI_IRQ_ALL_TYPES(PCI_IRQ_LEGACY | PCI_IRQ_MSI_TYPES) > > /* kmem_cache style wrapper around pci_alloc_consistent() */ > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings
On Tue, May 19, 2020 at 11:37:01AM +0530, Krishna Manikandan wrote: > MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks > like DPU display controller, DSI etc. Add YAML schema > for the device tree bindings for the same. > > Signed-off-by: Krishna Manikandan > > Changes in v2: > - Changed dpu to DPU (Sam Ravnborg) > - Fixed indentation issues (Sam Ravnborg) > - Added empty line between different properties (Sam Ravnborg) > - Replaced reference txt files with their corresponding > yaml files (Sam Ravnborg) > - Modified the file to use "|" only when it is > necessary (Sam Ravnborg) > > Changes in v3: > - Corrected the license used (Rob Herring) > - Added maxItems for properties (Rob Herring) > - Dropped generic descriptions (Rob Herring) > - Added ranges property (Rob Herring) > - Corrected the indendation (Rob Herring) > - Added additionalProperties (Rob Herring) > - Split dsi file into two, one for dsi controller > and another one for dsi phy per target (Rob Herring) > - Corrected description for pinctrl-names (Rob Herring) > - Corrected the examples used in yaml file (Rob Herring) > - Delete dsi.txt and dpu.txt (Rob Herring) > > Changes in v4: > - Move schema up by one level (Rob Herring) > - Add patternProperties for mdp node (Rob Herring) > - Corrected description of some properties (Rob Herring) > --- > .../bindings/display/msm/dpu-sc7180.yaml | 243 > .../bindings/display/msm/dpu-sdm845.yaml | 220 ++ > .../devicetree/bindings/display/msm/dpu.txt| 141 > .../display/msm/dsi-controller-sc7180.yaml | 123 +++ > .../display/msm/dsi-controller-sdm845.yaml | 120 ++ > .../bindings/display/msm/dsi-controller.yaml | 151 + > .../bindings/display/msm/dsi-phy-sc7180.yaml | 75 +++ > .../bindings/display/msm/dsi-phy-sdm845.yaml | 76 +++ > .../devicetree/bindings/display/msm/dsi-phy.yaml | 82 +++ > .../devicetree/bindings/display/msm/dsi.txt| 246 > - > 10 files changed, 1090 insertions(+), 387 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml > delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-controller.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml > create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy.yaml > delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > new file mode 100644 > index 000..b5607f9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > @@ -0,0 +1,243 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Description of Qualcomm Display DPU dt properties. > + > +maintainers: > + - Krishna Manikandan > + > +description: | > + Device tree bindings for MSM Mobile Display Subsytem(MDSS) that > encapsulates > + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device > tree > + bindings of MDSS and DPU are mentioned for SC7180 target. > + > +properties: > + compatible: > +items: > + - const: qcom,sc7180-mdss blank line between properties. > + reg: > +maxItems: 1 > + > + reg-names: > +const: mdss > + > + power-domains: > +maxItems: 1 > + > + clocks: > +maxItems: 3 > + > + clock-names: > +description: | > + Device clock names in the same order as mentioned in clocks property. > + The required clocks are mentioned below. Not a useful description. Unless you have something specific about *this* device, drop it. > +items: > + - const: iface > + - const: ahb > + - const: core > + > + interrupts: > +maxItems: 1 > + > + interrupt-controller: true > + > + "#interrupt-cells": > +const: 1 > + > + iommus: > +maxItems: 1 > + > + "#address-cells": > +const: 2 > + > + "#size-cells": > +const: 2 > + > + ranges: true > + > + interconnects: > +description: | > + Interconnect path specifier for MDSS according
[PATCH v2 3/3] drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulses
Some TypeC -> native DP adapters, at least the Club CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than ~540
usec, leading to MST probe failures.
According to the DP alt mode specification adapters should forward short
pulses with a duration greater than 250 usec. According to the DP
specificatin DP sources should detect short pulses in the
500 usec -> 2 ms range. Based on this filtering out short pulses with a
duration less than 540 usec is incorrect.
To make such adapters work add support for a driver polling on MST
inerrupt flags, and wire this up in the i915 driver. The sink can clear
an interrupt it raised after 110 ms if the source doesn't respond, so
use a 50 ms poll period to avoid missing an interrupt. Polling of the
MST interrupt flags is explicitly allowed by the DP specification.
This fixes MST probe failures I saw using this adapter and a DELL U2515H
monitor.
v2:
- Fix the wait event timeout for the no-poll case.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 19 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 +++
include/drm/drm_dp_mst_helper.h | 1 +
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5bc72e800b85..4e987a513df8 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1178,11 +1178,24 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
struct drm_dp_sideband_msg_tx *txmsg)
{
struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
+ unsigned long wait_timeout = msecs_to_jiffies(4000);
+ unsigned long wait_expires = jiffies + wait_timeout;
int ret;
- ret = wait_event_timeout(mgr->tx_waitq,
-check_txmsg_state(mgr, txmsg),
-(4 * HZ));
+ for (;;) {
+ ret = wait_event_timeout(mgr->tx_waitq,
+check_txmsg_state(mgr, txmsg),
+mgr->cbs->update_hpd_irq_state ?
+ msecs_to_jiffies(50) :
+ wait_timeout);
+
+ if (ret || !mgr->cbs->update_hpd_irq_state ||
+ time_after(jiffies, wait_expires))
+ break;
+
+ mgr->cbs->update_hpd_irq_state(mgr);
+ }
+
mutex_lock(&mgr->qlock);
if (ret > 0) {
if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d18b406f2a7d..1ff7d0096262 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -765,8 +765,23 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return NULL;
}
+static void
+intel_dp_mst_update_hpd_irq_state(struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+
+ spin_lock_irq(&i915->irq_lock);
+ i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
+ spin_unlock_irq(&i915->irq_lock);
+
+ queue_work(i915->hotplug.dp_wq, &i915->hotplug.dig_port_work);
+}
+
static const struct drm_dp_mst_topology_cbs mst_cbs = {
.add_connector = intel_dp_add_mst_connector,
+ .update_hpd_irq_state = intel_dp_mst_update_hpd_irq_state,
};
static struct intel_dp_mst_encoder *
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 9e1ffcd7cb68..c902f4380200 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -475,6 +475,7 @@ struct drm_dp_mst_topology_mgr;
struct drm_dp_mst_topology_cbs {
/* create a connector for a port */
struct drm_connector *(*add_connector)(struct drm_dp_mst_topology_mgr
*mgr, struct drm_dp_mst_port *port, const char *path);
+ void (*update_hpd_irq_state)(struct drm_dp_mst_topology_mgr *mgr);
};
#define DP_MAX_PAYLOAD (sizeof(unsigned long) * 8)
--
2.23.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm/dp_mst: Sanitize mgr->qlock locking in drm_dp_mst_wait_tx_reply()
On Thu, 2020-06-04 at 00:10 +0300, Imre Deak wrote:
> Make the locking look symmetric with the unlocking.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 1bdf3cfeeebb..5bc72e800b85 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1183,7 +1183,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> ret = wait_event_timeout(mgr->tx_waitq,
>check_txmsg_state(mgr, txmsg),
>(4 * HZ));
> - mutex_lock(&mstb->mgr->qlock);
> + mutex_lock(&mgr->qlock);
> if (ret > 0) {
> if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
> ret = -EIO;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp_mst: Fix disabling MST on a port
On Thu, 2020-06-04 at 00:10 +0300, Imre Deak wrote:
> Currently MST on a port can get enabled/disabled from the hotplug work
> and get disabled from the short pulse work in a racy way. Fix this by
> relying on the MST state checking in the hotplug work and just schedule
> a hotplug work from the short pulse handler if some problem happened
> during the MST interrupt handling.
Nice
>
> This removes the explicit MST disabling in case of an AUX failure, but
> if AUX fails, then probably the detection will also fail during the
> scheduled hotplug work and it's not guaranteed that we'll see
> intermittent errors anyway.
>
> While at it also simplify the error checking of the MST interrupt
> handler.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 33 +++--
> 1 file changed, 4 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 55fda074c0ad..befbcacddaa1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5604,7 +5604,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> }
> }
>
> - return need_retrain;
> + return need_retrain ? -EINVAL : 0;
> }
>
> static bool
> @@ -7255,35 +7255,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> }
>
> if (intel_dp->is_mst) {
> - switch (intel_dp_check_mst_status(intel_dp)) {
> - case -EINVAL:
> - /*
> - * If we were in MST mode, and device is not
> - * there, get out of MST mode
> - */
> - drm_dbg_kms(&i915->drm,
> - "MST device may have disappeared %d vs
> %d\n",
> - intel_dp->is_mst,
> - intel_dp->mst_mgr.mst_state);
> - intel_dp->is_mst = false;
> - drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
> - intel_dp->is_mst);
> -
> - return IRQ_NONE;
> - case 1:
> - return IRQ_NONE;
> - default:
> - break;
> - }
> - }
> -
> - if (!intel_dp->is_mst) {
> - bool handled;
> -
> - handled = intel_dp_short_pulse(intel_dp);
> -
> - if (!handled)
> + if (intel_dp_check_mst_status(intel_dp) < 0)
> return IRQ_NONE;
> + } else if (!intel_dp_short_pulse(intel_dp)) {
> + return IRQ_NONE;
> }
>
> return IRQ_HANDLED;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote: > On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > > > > > > > > > Actually it occurs to me that the patch consolidating kmap_prot is odd > > > > for > > > > sparc 32 bit... > > > > > > > > Its a long shot but could you try reverting this patch? > > > > > > > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions > > > > > > > > > > That is not easy to revert, unfortunately, due to several follow-up > > > patches. > > > > I have gotten your sparc tests to run and they all pass... > > > > 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh > > Build reference: v5.7-rc4-17-g852b6f2edc0f > > > > Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed > > Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed > > Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed > > Building sparc32:SS-4:nosmp:initrd ... running . passed > > Building sparc32:SS-5:nosmp:scsi:hd ... running . passed > > Building sparc32:SS-10:nosmp:scsi:cd ... running . passed > > Building sparc32:SS-20:nosmp:scsi:hd ... running . passed > > Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed > > Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed > > Building sparc32:SS-4:smp:scsi:hd ... running . passed > > Building sparc32:SS-5:smp:scsi:cd ... running . passed > > Building sparc32:SS-10:smp:scsi:hd ... running . passed > > Building sparc32:SS-20:smp:scsi:hd ... running . passed > > Building sparc32:SS-600MP:smp:scsi:hd ... running . passed > > Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed > > > > Is there another test I need to run? > > This all petered out, but as I understand it, this patchset still might > have issues on various architectures. > > Can folks please provide an update on the testing status? I believe the tests were failing for Guenter due to another patch set...[1] My tests with just this series are working. >From my understanding the other failures were unrelated.[2] I've checked the patch above on top of the mmots which already has Ira's patches and it booted fine. I've used sparc32_defconfig to build the kernel and qemu-system-sparc with default machine and CPU. Mike, am I wrong? Do you think the kmap() patches are still causing issues? Ira [1] https://lore.kernel.org/lkml/2807e5fd2f6fda4886f6618eac48510e92eab...@crsmsx101.amr.corp.intel.com/ [2] https://lore.kernel.org/lkml/20200520195110.gh1118...@kernel.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulses
Some TypeC -> native DP adapters, at least the Club CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than ~540
usec, leading to MST probe failures.
According to the DP alt mode specification adapters should forward short
pulses with a duration greater than 250 usec. According to the DP
specificatin DP sources should detect short pulses in the
500 usec -> 2 ms range. Based on this filtering out short pulses with a
duration less than 540 usec is incorrect.
To make such adapters work add support for a driver polling on MST
inerrupt flags, and wire this up in the i915 driver. The sink can clear
an interrupt it raised after 110 ms if the source doesn't respond, so
use a 50 ms poll period to avoid missing an interrupt. Polling of the
MST interrupt flags is explicitly allowed by the DP specification.
This fixes MST probe failures I saw using this adapter and a DELL U2515H
monitor.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 +++
include/drm/drm_dp_mst_helper.h | 1 +
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5bc72e800b85..d1bf340a95a8 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1178,11 +1178,23 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
struct drm_dp_sideband_msg_tx *txmsg)
{
struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
+ unsigned long wait_expires = jiffies + msecs_to_jiffies(4000);
int ret;
- ret = wait_event_timeout(mgr->tx_waitq,
-check_txmsg_state(mgr, txmsg),
-(4 * HZ));
+ for (;;) {
+ ret = wait_event_timeout(mgr->tx_waitq,
+check_txmsg_state(mgr, txmsg),
+mgr->cbs->update_hpd_irq_state ?
+ msecs_to_jiffies(50) :
+ wait_expires);
+
+ if (ret || !mgr->cbs->update_hpd_irq_state ||
+ time_after(jiffies, wait_expires))
+ break;
+
+ mgr->cbs->update_hpd_irq_state(mgr);
+ }
+
mutex_lock(&mgr->qlock);
if (ret > 0) {
if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d18b406f2a7d..1ff7d0096262 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -765,8 +765,23 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return NULL;
}
+static void
+intel_dp_mst_update_hpd_irq_state(struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+
+ spin_lock_irq(&i915->irq_lock);
+ i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
+ spin_unlock_irq(&i915->irq_lock);
+
+ queue_work(i915->hotplug.dp_wq, &i915->hotplug.dig_port_work);
+}
+
static const struct drm_dp_mst_topology_cbs mst_cbs = {
.add_connector = intel_dp_add_mst_connector,
+ .update_hpd_irq_state = intel_dp_mst_update_hpd_irq_state,
};
static struct intel_dp_mst_encoder *
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 9e1ffcd7cb68..c902f4380200 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -475,6 +475,7 @@ struct drm_dp_mst_topology_mgr;
struct drm_dp_mst_topology_cbs {
/* create a connector for a port */
struct drm_connector *(*add_connector)(struct drm_dp_mst_topology_mgr
*mgr, struct drm_dp_mst_port *port, const char *path);
+ void (*update_hpd_irq_state)(struct drm_dp_mst_topology_mgr *mgr);
};
#define DP_MAX_PAYLOAD (sizeof(unsigned long) * 8)
--
2.23.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/i915/dp_mst: Fix disabling MST on a port
Currently MST on a port can get enabled/disabled from the hotplug work
and get disabled from the short pulse work in a racy way. Fix this by
relying on the MST state checking in the hotplug work and just schedule
a hotplug work from the short pulse handler if some problem happened
during the MST interrupt handling.
This removes the explicit MST disabling in case of an AUX failure, but
if AUX fails, then probably the detection will also fail during the
scheduled hotplug work and it's not guaranteed that we'll see
intermittent errors anyway.
While at it also simplify the error checking of the MST interrupt
handler.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 33 +++--
1 file changed, 4 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 55fda074c0ad..befbcacddaa1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5604,7 +5604,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
}
}
- return need_retrain;
+ return need_retrain ? -EINVAL : 0;
}
static bool
@@ -7255,35 +7255,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
}
if (intel_dp->is_mst) {
- switch (intel_dp_check_mst_status(intel_dp)) {
- case -EINVAL:
- /*
-* If we were in MST mode, and device is not
-* there, get out of MST mode
-*/
- drm_dbg_kms(&i915->drm,
- "MST device may have disappeared %d vs
%d\n",
- intel_dp->is_mst,
- intel_dp->mst_mgr.mst_state);
- intel_dp->is_mst = false;
- drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
- intel_dp->is_mst);
-
- return IRQ_NONE;
- case 1:
- return IRQ_NONE;
- default:
- break;
- }
- }
-
- if (!intel_dp->is_mst) {
- bool handled;
-
- handled = intel_dp_short_pulse(intel_dp);
-
- if (!handled)
+ if (intel_dp_check_mst_status(intel_dp) < 0)
return IRQ_NONE;
+ } else if (!intel_dp_short_pulse(intel_dp)) {
+ return IRQ_NONE;
}
return IRQ_HANDLED;
--
2.23.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/dp_mst: Sanitize mgr->qlock locking in drm_dp_mst_wait_tx_reply()
Make the locking look symmetric with the unlocking.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 1bdf3cfeeebb..5bc72e800b85 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1183,7 +1183,7 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
ret = wait_event_timeout(mgr->tx_waitq,
check_txmsg_state(mgr, txmsg),
(4 * HZ));
- mutex_lock(&mstb->mgr->qlock);
+ mutex_lock(&mgr->qlock);
if (ret > 0) {
if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
ret = -EIO;
--
2.23.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > > > > > > Actually it occurs to me that the patch consolidating kmap_prot is odd for > > > sparc 32 bit... > > > > > > Its a long shot but could you try reverting this patch? > > > > > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions > > > > > > > That is not easy to revert, unfortunately, due to several follow-up patches. > > I have gotten your sparc tests to run and they all pass... > > 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh > Build reference: v5.7-rc4-17-g852b6f2edc0f > > Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed > Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed > Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed > Building sparc32:SS-4:nosmp:initrd ... running . passed > Building sparc32:SS-5:nosmp:scsi:hd ... running . passed > Building sparc32:SS-10:nosmp:scsi:cd ... running . passed > Building sparc32:SS-20:nosmp:scsi:hd ... running . passed > Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed > Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed > Building sparc32:SS-4:smp:scsi:hd ... running . passed > Building sparc32:SS-5:smp:scsi:cd ... running . passed > Building sparc32:SS-10:smp:scsi:hd ... running . passed > Building sparc32:SS-20:smp:scsi:hd ... running . passed > Building sparc32:SS-600MP:smp:scsi:hd ... running . passed > Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed > > Is there another test I need to run? This all petered out, but as I understand it, this patchset still might have issues on various architectures. Can folks please provide an update on the testing status? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: MIPI DSI, DBI, and tinydrm drivers
Hi Noralf, On Wed, 3 Jun 2020 at 13:15, Noralf Trønnes wrote: > > Den 28.05.2020 17.27, skrev Emil Velikov: > > On Sun, 24 May 2020 at 19:35, Daniel Vetter wrote: > >> > >> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes wrote: > >>> > >>> > >>> > >>> Den 24.05.2020 18.13, skrev Paul Cercueil: > Hi list, > > I'd like to open a discussion about the current support of MIPI DSI and > DBI panels. > > Both are standards from the MIPI alliance, both are communication > protocols between a LCD controller and a LCD panel, they generally both > use the same commands (DCS), the main difference is that DSI is serial > and DBI is generally parallel. > > In the kernel right now, DSI is pretty well implemented. All the > infrastucture to register a DSI host, DSI device etc. is there. DSI > panels are implemented as regular drm_panel instances, and their drivers > go through the DSI API to communicate with the panel, which makes them > independent of the DSI host driver. > > DBI, on the other hand, does not have any of this. All (?) DBI panels > are implemented as tinydrm drivers, which make them impossible to use > with regular DRM drivers. Writing a standard drm_panel driver is > impossible, as there is no concept of host and device. All these tinydrm > drivers register their own DBI host as they all do DBI over SPI. > > I think this needs a good cleanup. Given that DSI and DBI are so > similar, it would probably make sense to fuse DBI support into the > current DSI code, as trying to update DBI would result in a lot of code > being duplicated. With the proper host/device registration mechanism > from DSI code, it would be possible to turn most of the tinydrm drivers > into regular drm_panel drivers. > >> > >> Do we have drivers with dbi support that actually want to reuse the > >> tinydrm drivers? Good clean is all good, but we need a solid reason > >> for changing stuff. Plus we need to make sure we're not just > >> rediscovering all the old reasons for why we ended up where we are > >> right now in the first place. > >> > The problem then is that these should still be available as tinydrm > drivers. If the DSI/DBI panels can somehow register a .update_fb() > callback, it would make it possible to have a panel-agnostic tinydrm > driver, which would then probably open a lot of doors, and help a lot to > clean the mess. > > I think I can help with that, I just need some guidance - I am fishing > in exotic seas here. > > Thoughts, comments, are very welcome. > >>> > >>> I did look at this a few months back: > >>> > >>> drm/mipi-dbi: Support panel drivers > >>> https://lists.freedesktop.org/archives/dri-devel/2019-August/228966.html > >>> > > Coming late to the party - the series looks like a great step forward. > > > >>> The problem with DBI is that it has reused other busses which means we > >>> don't have DBI drivers, we have SPI drivers instead (6800/8080 is not > >>> avail. as busses in Linux yet). DSI and DPI on the other hand has > >>> dedicated hw controller drivers not shared with other subsystems. > >>> > >>> My initial tinydrm work used drm_panel, but I was not allowed to use it > >>> (at least not the way I had done it). > >> > >> Hm, do we have a summary of all the discussions/reasons from back > >> then? All I remember is that it's all that simple, you've done a lot > >> of work exploring all the options, I'm fairly sure I suggested > >> drm_panel even back then but somehow it didn't really work. Would be > >> good if we make sure we don't at least repeat history too much :-) > >> > > This pretty much ^^. Does anyone have a link/summary of the concerns? > > > > I found the thread where you Emil suggested I look at drm_panel: > > https://lists.freedesktop.org/archives/dri-devel/2015-September/091215.html > Guilty as charged ;-) Guess I should ask some silly questions first: Was tinydrm modelled as a drm driver itself, because the idea of drm_panel::update() callback seemed dirty? That's the only concern raised that I can find on the list... It's effectively in the link you provided. As far as I can tell, first RFC was already using the tiny drm driver model. https://patchwork.freedesktop.org/patch/77161/ Yet again, do we actually need the callback? The mipi-dbi(?) spi panels in panel/ get away w/o one, while pushing far more pixels onto the screen (tiny has resolutions up-to 320x480, panel up-to 480x800). That said, I'm a fan of lifting the tiny (panel) drivers into drm-panel and exposing them via dbi-bus sounds reasonable IMHO. Seems like Paul has the DT dbi/spi bus questions covered as well. Patches illustrating his ideas would be more than welcome. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-de
Re: Dynamically change enumeration list of DRM enumeration property
Hi, On 2020-06-03 11:12, Pekka Paalanen wrote: > On Wed, 3 Jun 2020 10:50:28 +0530 > Yogish Kulkarni wrote: > >> Inline.. >> >> On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote: >> >>> On Mon, 1 Jun 2020 09:22:27 +0530 >>> Yogish Kulkarni wrote: >>> Hi, For letting DRM clients to select output encoding: Sink can support certain display timings with high output bit-depths >>> using multiple output encodings, e.g. sink can support a particular timing with RGB 10-bit, YCbCr422 10-bit and YCbCr420 10-bit. So DRM client may want >>> to select YCbCr422 10-bit over RBG 10-bit output to reduce the link >>> bandwidth (and in turn reduce power/voltage). If DRM driver automatically selects output encoding then we are restricting DRM clients from making >>> appropriate choice. >>> >>> Hi, >>> >>> right, that seems to be another reason. >>> For selectable output color range: Certain applications (typically graphics) usually rendered in full range while some applications (typically video) have limited range content. >>> Since content can change dynamically, DRM driver does not have enough >>> information to choose correct quantization. Only DRM client can correctly select >>> which quantization to set (to preserve artist's intent). >>> >>> Now this is an interesting topic for me. As far as I know, there is no >>> window system protocol to tell the display server whether the >>> application provided content is using full or limited range. This means >>> that the display server cannot tell DRM about full vs. limited range >>> either. It also means that when not fullscreen, the display server >>> cannot show the limited range video content correctly, because it would >>> have to be converted to full-range (or vice versa). >>> >> Right, but there could be DRM client which doesn't use window system (e.g. >> Gstreamer video sink) and wants to select between full/limited color range. >> I agree that there is no window system protocol yet but maybe Wayland >> protocol could be added/extended for this purpose once we finalize things >> that needs to be done in DRM. > > Hi, > > right. If you have that use case and a userspace project welcomes such > feature, you're good. Kodi is a userspace application that is very interested in being able to control or set preferred HDMI output format (rgb444/yuv444/422/420) and quantization range (full/limited). Main reason is to allow end-users to make overrides when sink EDID don't fully match the TV/AVR features or when drm driver makes a bad automatic choice. Hans Verkuil's conclusion in HDMI RGB Quantization Range Lessons at [1] hold ture, it is total chaos. Right now, Kodi set the COLOR_ENCODING and COLOR_RANGE plane properties to let kernel know color encoding and color range of a YUV framebuffer. A single active plane showing a YUV framebuffer with limited range could hint a drm driver that end-user might want to use YUV and limited range output to prevent any banding effect when watching a movie. But in the case of when there is a second overlay plane for OSD or subtitles it may become very hard to guess what configuration works best for end-user. I have piggybacked on the "content type" connector property in [2] for my personal use to signal my drm driver if YUV (Movie) or RGB (Graphics) output is preferred this far but proper drm properties would really help :-) [1] https://elinux.org/images/5/53/Elce2017_0-hdmi.pdf [2] https://github.com/xbmc/xbmc/pull/14358 > > If you propose a KMS property for this, I would hope the patches > document or have links pointing to answers to all my questions here. > That would help both driver and userspace implementations to get into > the same mindset. > >>> But why would an application produce limited range pixels anyway? Is it >>> common that hardware video decoders are unable to produce full-range >>> pixels? >>> >> >> The primary reason for why content producer masters video/gfx content as >> limited range is for compatibility with sinks which only support limited >> range, and not because video decoders are not capable of decoding >> full-range content. > > What I was asking is, even if the video content is limited range, why > would one not decode it into full-range pixels always and if the sink > need limited range, then convert again in hardware? When done right, it > makes no difference in output compared to using limited range > through-out if both content and sink use limited range. For the Allwinner/Amlogic/Rockchip arm devices I mainly play with the video decoder does not support range conversion (to my knowledge) and will produce NV12/YU12 framebuffers in the range the video was encoded in. These devices typically lack a high-performance GPU/3D-accelerator and may have limited CSC capabilities in the display controller. The HDMI block can usually do simple RGB/YUV and full/limited conversions, bu
Re: [PATCH v3 105/105] ARM: dts: bcm2711: Enable the display pipeline
Hi Maxime,
Am 27.05.20 um 17:49 schrieb Maxime Ripard:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 46 +++-
> arch/arm/boot/dts/bcm2711.dtsi| 115 ++-
> 2 files changed, 160 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index 222d7825e1ab..c4a650ea4e21 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -231,3 +231,49 @@
> &vchiq {
> interrupts = ;
> };
> +
> +&vc4 {
> + status = "okay";
> +};
> +
> +&pixelvalve0 {
> + status = "okay";
> +};
> +
> +&pixelvalve1 {
> + status = "okay";
> +};
> +
> +&pixelvalve2 {
> + status = "okay";
> +};
> +
> +&pixelvalve4 {
> + status = "okay";
> +};
> +
> +&vec {
> + status = "disabled";
> +};
> +
> +&hdmi0 {
> + clocks = <&firmware_clocks 13>, <&dvp 0>;
> + status = "okay";
> +};
> +
> +&ddc0 {
> + status = "okay";
> +};
> +
> +&hdmi1 {
> + clocks = <&firmware_clocks 13>, <&dvp 1>;
> + status = "okay";
> +};
> +
> +&ddc1 {
> + status = "okay";
> +};
> +
> +&hvs {
> + clocks = <&firmware_clocks 4>;
> +};
it would be nice to have these references in alphabetical order.
Regards
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: simple: Add support for KOE TX26D202VM0BWA panel
Hi Emil. > > > > I expect to have some hours for linux work friday or saturday, but no > > promises... > > > Don't worry - once the DT maintainers ack 1/2, I'll merge the series. If it is in alphabetical order then we are good to go. For such simple patches we do not need DT maintainer ack. You can add my: r-b then you are fully covered. Sam > > -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: gr/gk20a: Use firmware version 0
On Thu, 4 Jun 2020 at 01:43, Emil Velikov wrote:
>
> On Wed, 3 Jun 2020 at 15:20, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > Tegra firmware doesn't actually use any version numbers and passing -1
> > causes the existing firmware binaries not to be found. Use version 0 to
> > find the correct files.
> >
> > Signed-off-by: Thierry Reding
>
> Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation
> based on available FW")
> Reviewed-by: Emil Velikov
Oops, my bad. Merged.
Ben.
>
> -Emil
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm: Add Generic USB Display driver
Den 02.06.2020 02.12, skrev Peter Stuge:
> Hi Noralf,
>
> Thanks a lot for going into more detail.
>
> Noralf Trønnes wrote:
>>> Several Linux/DRM internals have "leaked" into the USB protocol - this
>>> should be avoided if you want device implementations other than your
>>> gadget, because those internals can change within Linux in the future,
>>> while the protocol must not.
>>>
>>
>> That's intentional, I see no point in recreating uapi values that won't
>> change:
>>
>> Linux errno: /include/uapi/asm-generic/errno{-base,}.h
>> Pixel formats: include/uapi/drm/drm_fourcc.h
>> Connector types and status: include/uapi/drm/drm_mode.h
>
> I understand, and it's good that these are uapi values, but I will still
> disagree with using errno and DRM connector types in the USB protocol,
> which is a "namespace" of its own.
>
> That is an important point here; GUD is three things: a Linux DRM driver,
> a Linux gadget driver and a USB protocol. USB protocols (good ones) are
> OS-agnostic.
>
I need to be more clear here about the word 'Generic' that I've used.
This is not a OS-agnostic protocol. It's written for Linux. I have had
the BSD's in mind, hence the MIT license, FreeBSD for instance has a DRM
subsystem. Other OS'es might not support all DRM properties, but should
be able to use it as a basic display. They will ofc need to translate
the Linux DRM specifics into their own environment. But first and
foremost this is for Linux.
The host driver is written against the capabilities of the Linux gadget
framework and the DRM subsystem. This will add some peculiarities that a
microcontroller implementation won't face. The focal point of the
project is providing as good performance as possible for Full HD desktop
use.
The word 'Generic' means that it's (should be) possible to make a USB
display for use on Linux without having to write a graphics driver. This
includes all kinds of tiny/small displays that currently are SPI or I2C
interfaced. These will probably use a microcontroller instead of a Linux
SoC to keep cost low.
>
If the device transfer buffer can't fit an uncompressed framebuffer
update, the update is split up into parts that do fit.
>>>
>>> Does "device transfer buffer" refer to something like display RAM on
>>> the device side? If so, its size is a device implementation detail
>>> which shouldn't be exposed over USB.
>>
>> The reason for exposing this is that the Linux gadget driver needs to
>> decompress the transfer into a buffer and the host needs to know how big
>> this is (the host can choose to lower this if it can't allocate a
>> continuous buffer of this size).
>
> I understand; so it's only required for some compression types - then
> it should at least be completely optional, but in any case I find
> exposing/having to expose this to be awful USB protocol design and I
> hope we can find a better way.
>
> Maybe it's premature anyway? How would you feel about skipping compression
> to begin with?
>
Performance is not good without compression so I need to keep that.
>
>> lz4 (in the kernel) is block compression and can't be used for
>> decompressing just a stream of bytes. There is a lz4 frame protocol
>> which looks like it could be useful, but it's not available in the
>> kernel. I hardly know anything about compression so I'm in no position
>> to add that to the kernel. Maybe someone will add it at a later time if
>> it is useful.
>
> Why did you choose to use lz4?
>
The kernel supports it and in actually performs quite well.
Decompression is much faster than compression which fits nicely with not
so powerful USB devices. Low resolution displays might not need
compression at all.
> Whether compression comes now or later, maybe there is a more suitable
> algorithm?
>
Could be, it's possible to support other compression methods. I'll leave
that to the professionals that need it for their display.
>
>>> The R1 idea is great!
>>
>> My plan was to remove R1 support from this version of the patchset, but
>> I forgot. The reason is that it's cumbersome to test when the gadget
>> driver doesn't support it.
>
> Why not support R1 also in the gadget?
>
The DRM subsystem doesn't have support for it so the gadget wouldn't
know when to use it. Monochrome DRM drivers advertise a XRGB format
and converts this into monochrome. The reason for using this format is
because all userspace supports it. AFAIK no DRM userspace support
monochrome.
>
>> You mention further down that you have use cases for this, do you have a
>> timeplan for when you will make use of R1?
>
> No strict plan, but if it helps I could make a demo device and -firmware
> without much effort. You mentioned that you would like to have a
> microcontroller device for testing?
>
I have done a microcontroller implementation, so I have tried it. It's
quite a different environment to work in than Linux for sure :-) It
might have been a more pleasant experience if I'd spent money on a
professional compil
Re: [PATCH v3] drm/fourcc: document modifier uniqueness requirements
TMZ is more complicated. If there is a TMZ buffer used by a command buffer, then all other used buffers must also be TMZ or read only. If no TMZ buffers are used by a command buffer, then TMZ is disabled. If a context is not secure, TMZ is also disabled. A context can switch between secure and non-secure based on the buffers being used. So mixing secure and non-secure memory writes in one command buffer won't work. This is not fixable in the driver - apps must be aware of this. Marek On Wed, Jun 3, 2020 at 5:50 AM Daniel Stone wrote: > Hi Alex, > > On Mon, 1 Jun 2020 at 15:25, Alex Deucher wrote: > > On Fri, May 29, 2020 at 11:03 AM Daniel Stone > wrote: > > > What Weston _does_ know, however, is that display controller can work > > > with modifier set A, and the GPU can work with modifier set B, and if > > > the client can pick something from modifier set A, then there is a > > > much greater probability that Weston can leave the GPU alone so it can > > > be entirely used by the client. It also knows that if the surface > > > can't be directly scanned out for whatever reason, then there's no > > > point in the client optimising for direct scanout, and it can tell the > > > client to select based on optimality purely for the GPU. > > > > Just so I understand this correctly, the main reason for this is to > > deal with display hardware and render hardware from different vendors > > which may or may not support any common formats other than linear. > > It handles pretty much everything other than a single-context, > single-GPU, single-device, tunnel. > > When sharing between subsystems and device categories, it lets us talk > about capabilities in a more global way. For example, GBM lets you > talk about 'scanout' and 'texture' and 'render', but what about media > codecs? We could add the concept of decode/encode to something like > GBM, and all the protocols like Wayland/X11 as well, then hope it > actually works, but ... > > When sharing between heterogeneous vendors, it lets us talk about > capabilities in a neutral way. For example, if you look at most modern > Arm SoCs, your GPU, display controller, and media codec, will very > likely all be from three totally different vendors. A GPU like > Mali-T8xx can be shipped in tens of different vendor SoCs in several > different revisions each. Just saying 'scanout' is totally meaningless > for the Panfrost driver. Putting awareness for every different KMS > platform and every different codec down into the Mesa driver is a > synchronisation nightmare, and all those drivers would also need > specific awareness about the Mesa driver. So modifiers allow us to > explicitly describe that we want a particular revision of Arm > Framebuffer Compression, and all the components can understand that > without having to be specifically aware of 15 different KMS drivers. > But even if you have the same vendor ... > > When sharing between multiple devices of the same class from the same > vendor, it lets us surface and transit that information in a generic > way, without AMD having to figure out ways to tunnel back-channel > information between different instances of drivers potentially > targeting different revisions. The alternatives seem to be deeply > pessimal hacks, and we think we can do better. And when we get > pessimal ... > > In every case, modifiers are about surfacing and sharing information. > One of the reasons Collabora have been putting so much time and energy > into this work is exactly _because_ solving those problems on a > case-by-case basis was a pretty lucrative source of revenue for us. > Debugging these kinds of issues before has usually involved specific > driver knowledge, hacking into the driver to insert your own tracing, > etc. > > If you (as someone who's trying to use a device optimally) are > fortunate enough that you can get the attention of a vendor and have > them solve the problem for you, then that's lucky for everyone apart > from the AMD engineers who have to go solve it. If you're not, and you > can't figure it out yourself, then you have to go pay a consultancy. > On the face of it, that's good for us, except that we don't want to be > doing that kind of repetitive boring work. But it's bad for the > ecosystem that this knowledge is hidden away and that you have to pay > specialists to extract it. So we're really keen to surface as much > mechanism and information as possible, to give people the tools to > either solve their own problems or at least make well-informed > reports, burn down a toxic source of revenue, waste less engineering > time extracting hidden information, and empower users as much as > possible. > > > It > > provides a way to tunnel device capabilities between the different > > drivers. In the case of a device with display and rendering on the > > same device or multiple devices from the same vendor, it not really > > that useful. > > Oh no, it's still super useful. There are a ton of corner cases where > 'i
Re: [PATCH v2 1/2] drm: vmwgfx: remove drm_driver::master_set() return typ
Looks like a nice cleanup to me. (No idea if at some point there
actually was a reason for a return value...)
Reviewed-by: Roland Scheidegger
Am 30.05.20 um 14:46 schrieb Emil Velikov:
> The function always returns zero (success). Ideally we'll remove it all
> together - although that's requires a little more work.
>
> For now, we can drop the return type and simplify the drm core code
> surrounding it.
>
> v2: remove redundant assignment (Sam)
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: VMware Graphics
> Cc: Roland Scheidegger
> Signed-off-by: Emil Velikov
> Cc: Sam Ravnborg
> Reviewed-by: Sam Ravnborg
> ---
> VMWare team, I'm planning to push this via drm-misc. Review, ack and
> comments are appreciated.
> ---
> drivers/gpu/drm/drm_auth.c | 32 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 +++-
> include/drm/drm_drv.h | 4 ++--
> 3 files changed, 12 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index 74ce0c29c960..4c723e3a689c 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -122,27 +122,19 @@ struct drm_master *drm_master_create(struct drm_device
> *dev)
> return master;
> }
>
> -static int drm_set_master(struct drm_device *dev, struct drm_file *fpriv,
> - bool new_master)
> +static void drm_set_master(struct drm_device *dev, struct drm_file *fpriv,
> +bool new_master)
> {
> - int ret = 0;
> -
> dev->master = drm_master_get(fpriv->master);
> - if (dev->driver->master_set) {
> - ret = dev->driver->master_set(dev, fpriv, new_master);
> - if (unlikely(ret != 0)) {
> - drm_master_put(&dev->master);
> - }
> - }
> + if (dev->driver->master_set)
> + dev->driver->master_set(dev, fpriv, new_master);
>
> - fpriv->was_master = (ret == 0);
> - return ret;
> + fpriv->was_master = true;
> }
>
> static int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
> {
> struct drm_master *old_master;
> - int ret;
>
> lockdep_assert_held_once(&dev->master_mutex);
>
> @@ -157,22 +149,12 @@ static int drm_new_set_master(struct drm_device *dev,
> struct drm_file *fpriv)
> fpriv->is_master = 1;
> fpriv->authenticated = 1;
>
> - ret = drm_set_master(dev, fpriv, true);
> - if (ret)
> - goto out_err;
> + drm_set_master(dev, fpriv, true);
>
> if (old_master)
> drm_master_put(&old_master);
>
> return 0;
> -
> -out_err:
> - /* drop references and restore old master on failure */
> - drm_master_put(&fpriv->master);
> - fpriv->master = old_master;
> - fpriv->is_master = 0;
> -
> - return ret;
> }
>
> /*
> @@ -265,7 +247,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void
> *data,
> goto out_unlock;
> }
>
> - ret = drm_set_master(dev, file_priv, false);
> + drm_set_master(dev, file_priv, false);
> out_unlock:
> mutex_unlock(&dev->master_mutex);
> return ret;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index c2247a893ed4..470428387878 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1129,9 +1129,9 @@ static long vmw_compat_ioctl(struct file *filp,
> unsigned int cmd,
> }
> #endif
>
> -static int vmw_master_set(struct drm_device *dev,
> - struct drm_file *file_priv,
> - bool from_open)
> +static void vmw_master_set(struct drm_device *dev,
> +struct drm_file *file_priv,
> +bool from_open)
> {
> /*
>* Inform a new master that the layout may have changed while
> @@ -1139,8 +1139,6 @@ static int vmw_master_set(struct drm_device *dev,
>*/
> if (!from_open)
> drm_sysfs_hotplug_event(dev);
> -
> - return 0;
> }
>
> static void vmw_master_drop(struct drm_device *dev,
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index bb924cddc09c..835c38a76ef6 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -311,8 +311,8 @@ struct drm_driver {
>*
>* Called whenever the minor master is set. Only used by vmwgfx.
>*/
> - int (*master_set)(struct drm_device *dev, struct drm_file *file_priv,
> - bool from_open);
> + void (*master_set)(struct drm_device *dev, struct drm_file *file_priv,
> +bool from_open);
> /**
>* @master_drop:
>*
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders
Am 02.06.20 um 17:54 schrieb Maxime Ripard: > On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote: >> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard wrote: >>> the vc4_hdmi driver has some custom structures to hold the data it needs to >>> associate with the drm_encoder and drm_connector structures. >>> >>> However, it allocates them separately from the vc4_hdmi structure which >>> makes it more complicated than it needs to be. >>> >>> Move those structures to be contained by vc4_hdmi and update the code >>> accordingly. >> >>> @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, struct >>> device *master, void *data) >>> struct drm_device *drm = dev_get_drvdata(master); >>> struct vc4_dev *vc4 = drm->dev_private; >>> struct vc4_hdmi *hdmi; >>> - struct vc4_hdmi_encoder *vc4_hdmi_encoder; >>> + struct drm_encoder *encoder; >>> struct device_node *ddc_node; >>> u32 value; >>> int ret; >>> @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, struct >>> device *master, void *data) >>> if (!hdmi) >>> return -ENOMEM; >>> >>> - vc4_hdmi_encoder = devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder), >>> - GFP_KERNEL); >>> - if (!vc4_hdmi_encoder) >>> - return -ENOMEM; >>> - vc4_hdmi_encoder->base.type = VC4_ENCODER_TYPE_HDMI0; >>> - hdmi->encoder = &vc4_hdmi_encoder->base.base; >>> - >>> hdmi->pdev = pdev; >>> + encoder = &hdmi->encoder.base.base; >>> + encoder->base.type = VC4_ENCODER_TYPE_HDMI0; >> Wait, does this patch build? > All those patches were build tested, so yep > >> setting struct drm_encoder->base.type = VC4_* seems very wrong, when >> previously we were setting struct vc4_hdmi_encoder->base.type (struct >> vc4_encoder->type). > So the structure layout now is that vc4_hdmi embeds vc4_hdmi_encoder as > encoder. So &hdmi->encoder is a pointer to vc4_hdmi_encoder. > vc4_hdmi_encoder's base is since that patch a struct vc4_encoder. and > vc4_encoder's base is a drm_encoder. > > so encoder being a drm_encoder is correct there. > > However, drm_encoder's base is drm_mode_object that does have a type > field, which is an uint32_t, which will accept a VC4_ENCODER_TYPE_* just > fine... > > Now, drm_encoder_init will then kick in and call drm_mode_object_add > which will override it to a proper value and since the clock select bit > in the PV is the same for both HDMI0 and HDMI1, everything works just > fine... > > Good catch, I'll fix it. And I guess it's a good indication we don't > need a separate HDMI0 and HDMI1 encoder type. > FWIW this is the first patch which breaks X on my Raspberry Pi 3 B. Here are the bisect results: 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat) b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good 2c6a651cac6359cb0244a40d3b7a14e72918f169 good 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat) 601527fea6bb226abd088a864e74b25368218e87 good 2165607ede34d229d0cbce916c70c7fb6c0337be good f094f388fc2df848227e2ae648df2c97872df42b good 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat) 4c4da3823e4d1a8189e96a59a79451fff372f70b good 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit commit 020de18840a1075b2671736c6cc2e451030fad74 Author: Maxime Ripard Date: Mon Jan 6 17:17:29 2020 +0100 drm/vc4: hdmi: rework connectors and encoders the vc4_hdmi driver has some custom structures to hold the data it needs to associate with the drm_encoder and drm_connector structures. However, it allocates them separately from the vc4_hdmi structure which makes it more complicated than it needs to be. Move those structures to be contained by vc4_hdmi and update the code accordingly. Signed-off-by: Maxime Ripard ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: simple: Add support for KOE TX26D202VM0BWA panel
On Tue, 2 Jun 2020 at 21:57, Sam Ravnborg wrote:
>
> Hi Emil.
>
> On Tue, Jun 02, 2020 at 01:46:19PM +0100, Emil Velikov wrote:
> > On Tue, 2 Jun 2020 at 08:17, Liu Ying wrote:
> > >
> > > This patch adds support for Kaohsiung Opto-Electronics Inc.
> > > 10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT LCD panel with LVDS interface.
> > > The panel has dual LVDS channels.
> > >
> > > My panel is manufactured by US Micro Products(USMP). There is a tag at
> > > the back of the panel, which indicates the panel type is 'TX26D202VM0BWA'
> > > and it's made by KOE in Taiwan.
> > >
> > > The panel spec from USMP can be found at:
> > > https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-192120NDU-A0.pdf
> > >
> > > The below panel spec from KOE is basically the same to the one from USMP.
> > > However, the panel type 'TX26D202VM0BAA' is a little bit different.
> > > It looks that the two types of panel are compatible with each other.
> > > http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf
> > >
> > > Cc: Thierry Reding
> > > Cc: Sam Ravnborg
> > > Signed-off-by: Liu Ying
> > > ---
> > > drivers/gpu/drm/panel/panel-simple.c | 34
> > > ++
> > > 1 file changed, 34 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > b/drivers/gpu/drm/panel/panel-simple.c
> > > index b6ecd15..7c222ec 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -2200,6 +2200,37 @@ static const struct panel_desc koe_tx14d24vm1bpa =
> > > {
> > > },
> > > };
> > >
> > > +static const struct display_timing koe_tx26d202vm0bwa_timing = {
> > > + .pixelclock = { 15182, 15672, 15978 },
> > > + .hactive = { 1920, 1920, 1920 },
> > > + .hfront_porch = { 105, 130, 142 },
> > > + .hback_porch = { 45, 70, 82 },
> > > + .hsync_len = { 30, 30, 30 },
> > > + .vactive = { 1200, 1200, 1200},
> > > + .vfront_porch = { 3, 5, 10 },
> > > + .vback_porch = { 2, 5, 10 },
> > > + .vsync_len = { 5, 5, 5 },
> > > +};
> > > +
> > > +static const struct panel_desc koe_tx26d202vm0bwa = {
> > > + .timings = &koe_tx26d202vm0bwa_timing,
> > > + .num_timings = 1,
> > > + .bpc = 8,
> > > + .size = {
> > > + .width = 217,
> > > + .height = 136,
> > > + },
> > > + .delay = {
> > > + .prepare = 1000,
> > > + .enable = 1000,
> > > + .unprepare = 1000,
> > > + .disable = 1000,
> > Ouch 1s for each delay is huge. Nevertheless it matches the specs so,
> > the series is:
> > Reviewed-by: Emil Velikov
> >
> > Sam, Thierry I assume you'll merge the series. Let me know if I should
> > pick it up.
> I am quite busy with non-linux stuff these days so fine if you can pick
> them up. I like that simple panel patches are processed fast.
>
> I expect to have some hours for linux work friday or saturday, but no
> promises...
>
Don't worry - once the DT maintainers ack 1/2, I'll merge the series.
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically change enumeration list of DRM enumeration property
Hi all, On Wed, 3 Jun 2020 at 10:57, Ville Syrjälä wrote: > > On Wed, Jun 03, 2020 at 12:12:23PM +0300, Pekka Paalanen wrote: > > On Wed, 3 Jun 2020 10:50:28 +0530 > > Yogish Kulkarni wrote: > > > > > Inline.. > > > > > > On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote: > > > > > > > On Mon, 1 Jun 2020 09:22:27 +0530 > > > > Yogish Kulkarni wrote: > > > > > > > > > Hi, > > > > > > > > > > For letting DRM clients to select output encoding: > > > > > Sink can support certain display timings with high output bit-depths > > > > using > > > > > multiple output encodings, e.g. sink can support a particular timing > > > > > with > > > > > RGB 10-bit, YCbCr422 10-bit and YCbCr420 10-bit. So DRM client may > > > > > want > > > > to > > > > > select YCbCr422 10-bit over RBG 10-bit output to reduce the link > > > > bandwidth > > > > > (and in turn reduce power/voltage). If DRM driver automatically > > > > > selects > > > > > output encoding then we are restricting DRM clients from making > > > > appropriate > > > > > choice. > > > > > > > > Hi, > > > > > > > > right, that seems to be another reason. > > > > > > > > > For selectable output color range: > > > > > Certain applications (typically graphics) usually rendered in full > > > > > range > > > > > while some applications (typically video) have limited range content. > > > > Since > > > > > content can change dynamically, DRM driver does not have enough > > > > information > > > > > to choose correct quantization. Only DRM client can correctly select > > > > which > > > > > quantization to set (to preserve artist's intent). > > > > > > > > Now this is an interesting topic for me. As far as I know, there is no > > > > window system protocol to tell the display server whether the > > > > application provided content is using full or limited range. This means > > > > that the display server cannot tell DRM about full vs. limited range > > > > either. It also means that when not fullscreen, the display server > > > > cannot show the limited range video content correctly, because it would > > > > have to be converted to full-range (or vice versa). > > > > > > > Right, but there could be DRM client which doesn't use window system (e.g. > > > Gstreamer video sink) and wants to select between full/limited color > > > range. > > > I agree that there is no window system protocol yet but maybe Wayland > > > protocol could be added/extended for this purpose once we finalize things > > > that needs to be done in DRM. > > > > Hi, > > > > right. If you have that use case and a userspace project welcomes such > > feature, you're good. > > > > If you propose a KMS property for this, I would hope the patches > > document or have links pointing to answers to all my questions here. > > That would help both driver and userspace implementations to get into > > the same mindset. > > > > > > But why would an application produce limited range pixels anyway? Is it > > > > common that hardware video decoders are unable to produce full-range > > > > pixels? > > > > > > > > > > The primary reason for why content producer masters video/gfx content as > > > limited range is for compatibility with sinks which only support limited > > > range, and not because video decoders are not capable of decoding > > > full-range content. > > > > What I was asking is, even if the video content is limited range, why > > would one not decode it into full-range pixels always and if the sink > > need limited range, then convert again in hardware? When done right, it > > makes no difference in output compared to using limited range > > through-out if both content and sink use limited range. > > > > > Also, certain cinema-related content (e.g., movies) may > > > be better suited for limited range encoding due to the level of detail > > > that > > > they need to present/hide (see "Why does limited RGB even exist?" section > > > in > > > https://www.benq.com/en-us/knowledge-center/knowledge/full-rgb-vs-limited-rgb-is-there-a-difference.html#:~:text=Full%20RGB%20means%20the%20ability,less%20dark)%20than%20full%20RGB > > > ). > > > > That is a very nice link, thanks! > > > > But to me it seems the section "Why is this a problem?" gets "crushed > > blacks" backwards, so maybe I just don't get it. > > > > I would assume that if the source (computer) sends full-range pixel > > values on the wire and the sink (monitor) works in limited-range mode, > > then you would get crushed blacks and crushed whites. > > > > But if the source sends limited-range data and the sink works in > > full-range more, you'd get the "washed out" image. > > > > My thinking comes from the mapping of channel values: if 0-16 and > > 235-255 ranges show no difference within them, I'd call that "crushed". > > Similarly if one assumes 16 is darkest black and it's actually not, > > you'd get "washed out" (I might call it compressed instead, because it > > affects both black and white ends, unable to achieve both the darkest > > black an
[PATCH] drm/todo: Add item about modeset properties
Add some information about pre-atomic modeset properties alongside a list of suggestions how to handle the different instances. Signed-off-by: Emil Velikov --- Documentation/gpu/todo.rst | 32 1 file changed, 32 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 658b52f7ffc6..6648fd13cc1e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -392,6 +392,38 @@ Contact: Laurent Pinchart, respective driver maintainers Level: Intermediate +Consolidate custom driver modeset properties + + +Before atomic modeset took place, many drivers where creating their own +properties. Among other things, atomic brought the requirement that custom, +driver specific properties should not be used. + +In for this task, we aim to introduce core helper or reuse the existing ones +if available: + +A quick, unconfirmed, examples list. + +Introduce core helpers: +- audio (amdgpu, intel, gma500, radeon) +- brightness, contrast, etc (armada, nouveau) - overlay only (?) +- broadcast rgb (gma500, intel) +- colorkey (armada, nouveau, rcar) - overlay only (?) +- dither (amdgpu, nouveau, radeon) - varies across drivers +- underscan family (amdgpu, radeon, nouveau) + +Already in core: +- colorspace (sti) +- tv format names, enhancements (gma500, intel) +- tv overscan, margins, etc. (gma500, intel) +- zorder (omapdrm) - same as zpos (?) + + +Contact: Emil Velikov, respective driver maintainers + +Level: Intermediate + + Core refactorings = -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/omap: Fix suspend resume regression after platform data removal
Hi Tony, On 31/05/2020 22:39, Tony Lindgren wrote: When booting without legacy platform data, we no longer have omap_device calling PM runtime suspend for us on suspend. This causes the driver context not be saved as we have no suspend and resume functions defined. Let's fix the issue by switching over to use UNIVERSAL_DEV_PM_OPS as it will call the existing PM runtime suspend functions on suspend. I don't think we can use UNIVERSAL_DEV_PM_OPS, as we can't disable DSS modules in any order, but things have to be shut down in orderly manner. omapdrm hasn't relied on omap_device calling runtime suspend for us (I didn't know it does that). We have system suspend hooks in omap_drv.c: SIMPLE_DEV_PM_OPS(omapdrm_pm_ops, omap_drm_suspend, omap_drm_resume) omap_drm_suspend() is supposed to turn off the displays, which then cause dispc_runtime_put (and other runtime_puts) to be called, which result in dispc_runtime_suspend (and other runtime PM suspends). So... For some reason that's no longer happening? I need to try to find a board with which suspend/resume works (without DSS)... Tomi -- 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] drm/nouveau/dispnv50: fix runtime pm imbalance on error
Hi! Was going through my email and found this from last month, it's a bit late
and someone might have reviewed/pushed this already but just in case:
Reviewed-by: Lyude Paul
On Wed, 2020-05-20 at 18:47 +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 6be9df1820c5..e670756664ff 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1123,8 +1123,10 @@ nv50_mstc_detect(struct drm_connector *connector,
> return connector_status_disconnected;
>
> ret = pm_runtime_get_sync(connector->dev->dev);
> - if (ret < 0 && ret != -EACCES)
> + if (ret < 0 && ret != -EACCES) {
> + pm_runtime_put_autosuspend(connector->dev->dev);
> return connector_status_disconnected;
> + }
>
> ret = drm_dp_mst_detect_port(connector, ctx, mstc->port->mgr,
>mstc->port);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model
On Wed, Jun 3, 2020 at 6:12 PM Lukasz Luba wrote:
>
>
>
> On 6/3/20 4:40 PM, Rafael J. Wysocki wrote:
> > On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
> >>
> >>
> >>
> >> On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
> >>> On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
>
> Hi Daniel,
>
> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> > On 27/05/2020 11:58, Lukasz Luba wrote:
> >> Add support for other devices than CPUs. The registration function
> >> does not require a valid cpumask pointer and is ready to handle new
> >> devices. Some of the internal structures has been reorganized in order
> >> to
> >> keep consistent view (like removing per_cpu pd pointers).
> >>
> >> Signed-off-by: Lukasz Luba
> >> ---
> >
> > [ ... ]
> >
> >> }
> >> EXPORT_SYMBOL_GPL(em_register_perf_domain);
> >> +
> >> +/**
> >> + * em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for
> >> a device
> >> + * @dev : Device for which the EM is registered
> >> + *
> >> + * Try to unregister the EM for the specified device (but not a CPU).
> >> + */
> >> +void em_dev_unregister_perf_domain(struct device *dev)
> >> +{
> >> +if (IS_ERR_OR_NULL(dev) || !dev->em_pd)
> >> +return;
> >> +
> >> +if (_is_cpu_device(dev))
> >> +return;
> >> +
> >> +mutex_lock(&em_pd_mutex);
> >
> > Is the mutex really needed?
>
> I just wanted to align this unregister code with register. Since there
> is debugfs dir lookup and the device's EM existence checks I thought it
> wouldn't harm just to lock for a while and make sure the registration
> path is not used. These two paths shouldn't affect each other, but with
> modules loading/unloading I wanted to play safe.
>
> I can change it maybe to just dmb() and the end of the function if it's
> a big performance problem in this unloading path. What do you think?
> >>>
> >>> I would rather leave the mutex locking as is.
> >>>
> >>> However, the question to ask is what exactly may go wrong without that
> >>> locking in place? Is there any specific race condition that you are
> >>> concerned about?
> >>>
> >>
> >> I tried to test this with module loading & unloading with panfrost
> >> driver and CPU hotplug (which should bail out quickly) and was OK.
> >> I don't see any particular race. I don't too much about the
> >> debugfs code, though. That's why I tried to protect from some
> >> scripts/services which try to re-load the driver.
> >>
> >> Apart from that, maybe just this dev->em = NULL to be populated to all
> >> CPUs, which mutex_unlock synchronizes for free here.
> >
> > If it may run concurrently with the registration for the same device,
> > the locking is necessary, but in that case the !dev->em_pd check needs
> > to go under the mutex too IMO, or you may end up leaking the pd if the
> > registration can run between that check and the point at which the
> > mutex is taken.
>
> They don't run concurrently for the same device and users of that EM are
> already gone.
> I just wanted to be sure that everything is cleaned and synced properly.
> Here is some example of the directories under
> /sys/kernel/debug/energy_model
> cpu0, cpu4, gpu, dsp, etc
>
> The only worry that I had was the debugfs dir name, which is a
> string from dev_name() and will be the same for the next registration
> if module is re-loaded.
OK, so that needs to be explained in a comment.
> So the 'name' is reused and debugfs_create_dir()
> and debugfs_remove_recursive() uses this fsnotify, but they are
> operating under inode_lock/unlock() on the parent dir 'energy_model'.
> Then there is also this debugfs_lookup() which is slightly different.
>
> That's why I put a mutex to separate all registration and unregistration
> for all devices.
> It should work without the mutex in unregister path, but I think it does
> not harm to take
Well, fair enough, but I still think that the !dev->em_pd check should
be done under the mutex or it will be confusing.
> it just in case and also have the CPU variable sync for free.
I'm not sure what you mean by the last part here?
> >
> > Apart from this your kerneldoc comments might me improved IMO.
> >
> > First of all, you can use @dev inside of a kerneldoc (if @dev
> > represents an argument of the documented function) and that will
> > produce the right output automatically.
>
> OK
>
> >
> > Second, it is better to avoid saying things like "Try to unregister
> > ..." in kerneldoc comments (the "Try to" part is redundant). Simply
> > say "Unregister ..." instead.
>
> Good point, thanks, I will use "Unregister ..." then.
>
> >
> > Thanks!
> >
>
> Shell I send a 'resend patch' which changes these @dev and
> 'unregister' comments?
Yes, please, but see the comments above too.
> Or wait for you to finish reviewing the other patches and
Re: [Nouveau] [PATCH] drm/nouveau: gr/gk20a: Use firmware version 0
On Wed, 3 Jun 2020 at 15:20, Thierry Reding wrote:
>
> From: Thierry Reding
>
> Tegra firmware doesn't actually use any version numbers and passing -1
> causes the existing firmware binaries not to be found. Use version 0 to
> find the correct files.
>
> Signed-off-by: Thierry Reding
Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation
based on available FW")
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model
On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
>
>
>
> On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
> > On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
> >>
> >> Hi Daniel,
> >>
> >> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> >>> On 27/05/2020 11:58, Lukasz Luba wrote:
> Add support for other devices than CPUs. The registration function
> does not require a valid cpumask pointer and is ready to handle new
> devices. Some of the internal structures has been reorganized in order to
> keep consistent view (like removing per_cpu pd pointers).
>
> Signed-off-by: Lukasz Luba
> ---
> >>>
> >>> [ ... ]
> >>>
> }
> EXPORT_SYMBOL_GPL(em_register_perf_domain);
> +
> +/**
> + * em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for a
> device
> + * @dev : Device for which the EM is registered
> + *
> + * Try to unregister the EM for the specified device (but not a CPU).
> + */
> +void em_dev_unregister_perf_domain(struct device *dev)
> +{
> +if (IS_ERR_OR_NULL(dev) || !dev->em_pd)
> +return;
> +
> +if (_is_cpu_device(dev))
> +return;
> +
> +mutex_lock(&em_pd_mutex);
> >>>
> >>> Is the mutex really needed?
> >>
> >> I just wanted to align this unregister code with register. Since there
> >> is debugfs dir lookup and the device's EM existence checks I thought it
> >> wouldn't harm just to lock for a while and make sure the registration
> >> path is not used. These two paths shouldn't affect each other, but with
> >> modules loading/unloading I wanted to play safe.
> >>
> >> I can change it maybe to just dmb() and the end of the function if it's
> >> a big performance problem in this unloading path. What do you think?
> >
> > I would rather leave the mutex locking as is.
> >
> > However, the question to ask is what exactly may go wrong without that
> > locking in place? Is there any specific race condition that you are
> > concerned about?
> >
>
> I tried to test this with module loading & unloading with panfrost
> driver and CPU hotplug (which should bail out quickly) and was OK.
> I don't see any particular race. I don't too much about the
> debugfs code, though. That's why I tried to protect from some
> scripts/services which try to re-load the driver.
>
> Apart from that, maybe just this dev->em = NULL to be populated to all
> CPUs, which mutex_unlock synchronizes for free here.
If it may run concurrently with the registration for the same device,
the locking is necessary, but in that case the !dev->em_pd check needs
to go under the mutex too IMO, or you may end up leaking the pd if the
registration can run between that check and the point at which the
mutex is taken.
Apart from this your kerneldoc comments might me improved IMO.
First of all, you can use @dev inside of a kerneldoc (if @dev
represents an argument of the documented function) and that will
produce the right output automatically.
Second, it is better to avoid saying things like "Try to unregister
..." in kerneldoc comments (the "Try to" part is redundant). Simply
say "Unregister ..." instead.
Thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
Hi Maxime, Am 03.06.20 um 15:14 schrieb Maxime Ripard: > Hi Stefan, > > On Tue, Jun 02, 2020 at 10:03:13PM +0200, Stefan Wahren wrote: >> Am 02.06.20 um 21:31 schrieb Eric Anholt: >>> On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson >>> wrote: Hi Maxime and Eric On Tue, 2 Jun 2020 at 15:12, Maxime Ripard wrote: > Hi Eric > > On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote: >> On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote: >>> The VIDEN bit in the pixelvalve currently being used to enable or >>> disable >>> the pixelvalve seems to not be enough in some situations, which whill >>> end >>> up with the pixelvalve stalling. >>> >>> In such a case, even re-enabling VIDEN doesn't bring it back and we >>> need to >>> clear the FIFO. This can only be done if the pixelvalve is disabled >>> though. >>> >>> In order to overcome this, we can configure the pixelvalve during >>> mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO >>> there, and in atomic_disable disable the pixelvalve again. >> What displays has this been tested with? Getting this sequencing >> right is so painful, and things like DSI are tricky to get to light >> up. > That FIFO is between the HVS and the HDMI PVs, so this was obviously > tested against that. Dave also tested the DSI output IIRC, so we should > be covered here. DSI wasn't working on the first patch set that Maxime sent - I haven't tested this one as yet but will do so. DPI was working early on to both an Adafruit 800x480 DPI panel, and via a VGA666 as VGA. HDMI is obviously working. VEC is being ignored now. The clock structure is more restricted than earlier chips, so to get the required clocks for the VEC without using fractional divides it compromises the clock that other parts of the system can run at (IIRC including the ARM). That's why the VEC has to be explicitly enabled for the firmware to enable it as the only output. It's annoying, but that's just a restriction of the chip. >>> I'm more concerned with "make sure we don't regress pre-pi4 with this >>> series" than "pi4 displays all work from the beginning" >> unfortuntely i can confirm this. With this patch series (using Maxime's >> git repo with multi_v7_defconfig) my Raspberry Pi 3 B hangs up while >> starting X (screen stays black, heartbeat stops, no more output at the >> debug UART). AFAIR v2 didn't had this issue. > Did it happen with a DSI display or something else? with my HDMI display (HP ZR2440w). At first everything looks good (Raspbian splash screen is displayed), but before the real workspace is displayed this issue happens. > I've been trying to setup the DSI display on an RPi3 today, but noticed > that it looks like there's a regression in next that prevents the HDMI > driver to load entirely (without my patches). I took your rpi4-kms branch and switched before your series and everything works fine. I will try to bisect the offending commit. Stefan > > Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model
On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
>
> Hi Daniel,
>
> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> > On 27/05/2020 11:58, Lukasz Luba wrote:
> >> Add support for other devices than CPUs. The registration function
> >> does not require a valid cpumask pointer and is ready to handle new
> >> devices. Some of the internal structures has been reorganized in order to
> >> keep consistent view (like removing per_cpu pd pointers).
> >>
> >> Signed-off-by: Lukasz Luba
> >> ---
> >
> > [ ... ]
> >
> >> }
> >> EXPORT_SYMBOL_GPL(em_register_perf_domain);
> >> +
> >> +/**
> >> + * em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for a
> >> device
> >> + * @dev : Device for which the EM is registered
> >> + *
> >> + * Try to unregister the EM for the specified device (but not a CPU).
> >> + */
> >> +void em_dev_unregister_perf_domain(struct device *dev)
> >> +{
> >> +if (IS_ERR_OR_NULL(dev) || !dev->em_pd)
> >> +return;
> >> +
> >> +if (_is_cpu_device(dev))
> >> +return;
> >> +
> >> +mutex_lock(&em_pd_mutex);
> >
> > Is the mutex really needed?
>
> I just wanted to align this unregister code with register. Since there
> is debugfs dir lookup and the device's EM existence checks I thought it
> wouldn't harm just to lock for a while and make sure the registration
> path is not used. These two paths shouldn't affect each other, but with
> modules loading/unloading I wanted to play safe.
>
> I can change it maybe to just dmb() and the end of the function if it's
> a big performance problem in this unloading path. What do you think?
I would rather leave the mutex locking as is.
However, the question to ask is what exactly may go wrong without that
locking in place? Is there any specific race condition that you are
concerned about?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Set connector type for DSI panels
On Tue, Jun 02, 2020 at 08:12:40PM +0300, Laurent Pinchart wrote: > None of the DSI panels set the connector_type in their panel_desc > descriptor. As they are all guaranteed to be DSI panels, that's an easy > fix, set the connector type to DRM_MODE_CONNECTOR_DSI. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/panel/panel-simple.c | 7 +++ > 1 file changed, 7 insertions(+) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: gr/gk20a: Use firmware version 0
From: Thierry Reding
Tegra firmware doesn't actually use any version numbers and passing -1
causes the existing firmware binaries not to be found. Use version 0 to
find the correct files.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
index ec330d791d15..e56880f3e3bd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
@@ -352,7 +352,7 @@ gk20a_gr_load(struct gf100_gr *gr, int ver, const struct
gf100_gr_fwif *fwif)
static const struct gf100_gr_fwif
gk20a_gr_fwif[] = {
- { -1, gk20a_gr_load, &gk20a_gr },
+ { 0, gk20a_gr_load, &gk20a_gr },
{}
};
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/hdlcd: Don't call drm_crtc_vblank_off on unbind
On Tue, Jun 02, 2020 at 02:00:16PM +0100, Liviu Dudau wrote: > On Tue, Jun 02, 2020 at 11:51:40AM +0200, Daniel Vetter wrote: > > This is already taken care of by drm_atomic_helper_shutdown(), and > > in that case only for the CRTC which are actually on. > > > > Only tricky bit here is that we kill the interrupt handling before we > > shut down crtc, so need to reorder that. > > > > Signed-off-by: Daniel Vetter > > Cc: Liviu Dudau > > Acked-by: Liviu Dudau Ok I merged the two arm patches, thanks for taking a look. First patch needs more work ... -Daniel > > Best regards, > Liviu > > > Cc: Brian Starkey > > Cc: > > --- > > drivers/gpu/drm/arm/hdlcd_drv.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c > > b/drivers/gpu/drm/arm/hdlcd_drv.c > > index 194419f47c5e..26bc5d7766f5 100644 > > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > > @@ -347,9 +347,8 @@ static void hdlcd_drm_unbind(struct device *dev) > > of_node_put(hdlcd->crtc.port); > > hdlcd->crtc.port = NULL; > > pm_runtime_get_sync(dev); > > - drm_crtc_vblank_off(&hdlcd->crtc); > > - drm_irq_uninstall(drm); > > drm_atomic_helper_shutdown(drm); > > + drm_irq_uninstall(drm); > > pm_runtime_put(dev); > > if (pm_runtime_enabled(dev)) > > pm_runtime_disable(dev); > > -- > > 2.26.2 > > > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET
On Wed, Jun 03, 2020 at 01:17:14PM +, Simon Ser wrote: > On Wednesday, June 3, 2020 1:36 PM, Daniel Vetter wrote: > > > On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote: > > > > > On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote: > > > > > > > In update_output_state, the link-status property was reset to GOOD to > > > > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset > > > > is also performed on an atomic commit without ALLLOW_MODESET. If a > > > > > > I didn't think udate_output_state() was getting called for > > > non-legacy paths. Where is that coming from? > > > > Oops, I'm blind and you're right, there's no bug. We already only > > force-set this for legacy modeset (and fbcon). > > Indeed, good catch Ville. set_config is purely a legacy thing. > > > That also means that atomic userspace has to handle this, which is maybe > > not so awesome ... So maybe we need to duct-tape over this for atomic too, > > and in that case it should be only done when ALLOW_MODESET is set. > > > > But maybe all the compositors that care will handle this :-/ > > Not fond of this because we'll basically end up with some drivers > checking for link-status (none do that yet) and some user-space > resetting it to GOOD. It'll break only if user-space doesn't reset and > a driver which checks link-status is used. Driver-specific behaviour > isn't great. See my other reply, drivers don't need to check for GOOD, it's kinda magic. -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 v2] drm: document how user-space should use link-status
On Wed, Jun 03, 2020 at 01:27:55PM +, Simon Ser wrote: > > > + * When user-space performs an atomic commit on a connector with a > > > "BAD" > > > + * link-status without resetting the property to "GOOD", it gets > > > + * implicitly reset. This might make the atomic commit fail if the > > > modeset > > > + * is unsuccessful. > > > > I think this was what Daniel was saying that the kernel should require > > ALLOW_MODESET to be set for the automatic reset, right? > > Actually this paragraph isn't true. link-status is only reset to GOOD for > legacy modeset. > > But right now this doesn't matter since no driver reads the link-status > property value as far as I can tell. Note, only i915 sets link-status > to BAD. It's magic ... change in link status results in connectors_change (or something like that), which forces the modeset (and first recomputation of mode state) that fixes everything up. But yeah I entirely missed that the autoreset to GOOD only happens in legacy modeset. I guess we might have some atomic compositors with slightly suboptimal handling of link status failure :-/ > > I'm fine with how the doc is written now. But if ALLOW_MODESET becomes > > a requirement for the automatic reset, I suspect there is a risk to > > regress Weston, assuming the automatic reset used to be successful. > > Right now a commit without ALLOW_MODESET won't reset link-status to GOOD, > but also won't re-train the link on i915. So I think it's fine to require > ALLOW_MODESET. > > Should drivers read the value of the link-status property? Or should we > ignore user-space writes to the property and only require ALLOW_MODESET > to re-train the link? Well without allow_modeset it'll fail, that's the problem. But since we dont automatically restore, I think the only problem is that existing atomic userspace might be stuck on a bad link for a while ... -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 v2 07/15] drm/amdgpu: Use PCI_IRQ_MSI_TYPES where appropriate
On Wed, Jun 3, 2020 at 7:48 AM Piotr Stankiewicz
wrote:
>
> Seeing as there is shorthand available to use when asking for any type
> of interrupt, or any type of message signalled interrupt, leverage it.
>
> Signed-off-by: Piotr Stankiewicz
> Reviewed-by: Andy Shevchenko
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> index 5ed4227f304b..2588dd1015db 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> @@ -249,15 +249,10 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
>
> if (amdgpu_msi_ok(adev)) {
> int nvec = pci_msix_vec_count(adev->pdev);
I think you can drop pci_msix_vec_count() here. It's not used since
we always request 1 vector.
Alex
> - unsigned int flags;
>
> - if (nvec <= 0) {
> - flags = PCI_IRQ_MSI;
> - } else {
> - flags = PCI_IRQ_MSI | PCI_IRQ_MSIX;
> - }
> /* we only need one vector */
> - nvec = pci_alloc_irq_vectors(adev->pdev, 1, 1, flags);
> + nvec = pci_alloc_irq_vectors(adev->pdev, 1, 1,
> +PCI_IRQ_MSI_TYPES);
> if (nvec > 0) {
> adev->irq.msi_enabled = true;
> dev_dbg(adev->dev, "amdgpu: using MSI/MSI-X.\n");
> --
> 2.17.2
>
> ___
> 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 v2] drm: document how user-space should use link-status
> > + * When user-space performs an atomic commit on a connector with a > > "BAD" > > + * link-status without resetting the property to "GOOD", it gets > > + * implicitly reset. This might make the atomic commit fail if the > > modeset > > + * is unsuccessful. > > I think this was what Daniel was saying that the kernel should require > ALLOW_MODESET to be set for the automatic reset, right? Actually this paragraph isn't true. link-status is only reset to GOOD for legacy modeset. But right now this doesn't matter since no driver reads the link-status property value as far as I can tell. Note, only i915 sets link-status to BAD. > I'm fine with how the doc is written now. But if ALLOW_MODESET becomes > a requirement for the automatic reset, I suspect there is a risk to > regress Weston, assuming the automatic reset used to be successful. Right now a commit without ALLOW_MODESET won't reset link-status to GOOD, but also won't re-train the link on i915. So I think it's fine to require ALLOW_MODESET. Should drivers read the value of the link-status property? Or should we ignore user-space writes to the property and only require ALLOW_MODESET to re-train the link? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET
On Wednesday, June 3, 2020 1:36 PM, Daniel Vetter wrote: > On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote: > > > On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote: > > > > > In update_output_state, the link-status property was reset to GOOD to > > > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset > > > is also performed on an atomic commit without ALLLOW_MODESET. If a > > > > I didn't think udate_output_state() was getting called for > > non-legacy paths. Where is that coming from? > > Oops, I'm blind and you're right, there's no bug. We already only > force-set this for legacy modeset (and fbcon). Indeed, good catch Ville. set_config is purely a legacy thing. > That also means that atomic userspace has to handle this, which is maybe > not so awesome ... So maybe we need to duct-tape over this for atomic too, > and in that case it should be only done when ALLOW_MODESET is set. > > But maybe all the compositors that care will handle this :-/ Not fond of this because we'll basically end up with some drivers checking for link-status (none do that yet) and some user-space resetting it to GOOD. It'll break only if user-space doesn't reset and a driver which checks link-status is used. Driver-specific behaviour isn't great. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] drm/shmem-helpers: Ensure get_pages is not called on imported dma-buf
On Thu, May 14, 2020 at 09:30:04AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > Just a bit of light paranoia. Also sprinkle this check over
> > drm_gem_shmem_get_sg_table, which should only be called when
> > exporting, same for the pin/unpin functions, on which it relies to
> > work correctly.
> >
> > Cc: Gerd Hoffmann
> > Cc: Rob Herring
> > Cc: Noralf Trønnes
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_gem_shmem_helper.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index 117a7841e284..f7011338813e 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -170,6 +170,8 @@ int drm_gem_shmem_get_pages(struct drm_gem_shmem_object
> > *shmem)
> > {
> > int ret;
> >
> > + WARN_ON(shmem->base.import_attach);
> > +
> > ret = mutex_lock_interruptible(&shmem->pages_lock);
> > if (ret)
> > return ret;
> > @@ -225,6 +227,8 @@ int drm_gem_shmem_pin(struct drm_gem_object *obj)
> > {
> > struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >
> > + WARN_ON(shmem->base.import_attach);
> > +
>
> I don't understand this change. If a driver pins pages it now has to
> check that the pages are not imported?
Nope. There's two classes of functions in the helpers, and I'm trying to
unconfuse them:
- stuff used to implement gem_funcs. These are obviously only ever used on
native objects, never on imported ones (on imported ones we try to
forward through the dma-buf layer to the exporter). drm_gem_shmem_pin is
only used in that role to implement gem_funcs->pin. Calling it on an
imported buffer is indeed a bug.
- the other set of functions are for drivers to do their stuff. The
interface which (implicitly) pins stuff into places is various set of
get_pages, which do have different paths for native and imported
objects.
Apologies that I missed your question here, I merged all the patches
leading up to this one for now.
Thanks, Daniel
>
>
> > return drm_gem_shmem_get_pages(shmem);
> > }
> > EXPORT_SYMBOL(drm_gem_shmem_pin);
> > @@ -240,6 +244,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
> > {
> > struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >
> > + WARN_ON(shmem->base.import_attach);
> > +
> > drm_gem_shmem_put_pages(shmem);
> > }
> > EXPORT_SYMBOL(drm_gem_shmem_unpin);
> > @@ -510,6 +516,8 @@ static void drm_gem_shmem_vm_open(struct vm_area_struct
> > *vma)
> > struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> > int ret;
> >
> > + WARN_ON(shmem->base.import_attach);
> > +
> > ret = drm_gem_shmem_get_pages(shmem);
> > WARN_ON_ONCE(ret != 0);
> >
> > @@ -611,6 +619,8 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
> > drm_gem_object *obj)
> > {
> > struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >
> > + WARN_ON(shmem->base.import_attach);
> > +
> > return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT);
> > }
> > EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
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 5/9] drm/udl: Don't call get/put_pages on imported dma-buf
On Thu, May 14, 2020 at 02:47:57PM +0200, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 09:25:18AM +0200, Thomas Zimmermann wrote:
> > Hi,
> >
> > given the upcoming removal of this file, I don't know if you really want
> > to merge this patch. If so, please see my comment on patch 6 and
>
> Yeah I can wait for your patch to land, I just looked at that series. I'm
> kinda just keeping this around as a reminder locally.
Still applied cleanly to drm-misc-next, so I applied it.
-Daniel
> -Daniel
>
> >
> > Acked-by: Thomas Zimmermann
> >
> > Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > > There's no direct harm, because for the shmem helpers these are noops
> > > on imported buffers. The trouble is in the locks these take - I want
> > > to change dma_buf_vmap locking, and so need to make sure that we only
> > > ever take certain locks on one side of the dma-buf interface: Either
> > > for exporters, or for importers.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Dave Airlie
> > > Cc: Sean Paul
> > > Cc: Gerd Hoffmann
> > > Cc: Thomas Zimmermann
> > > Cc: Alex Deucher
> > > Cc: Daniel Vetter
> > > Cc: Thomas Gleixner
> > > Cc: Sam Ravnborg
> > > ---
> > > drivers/gpu/drm/udl/udl_gem.c | 22 --
> > > 1 file changed, 12 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
> > > index b6e26f98aa0a..c68d3e265329 100644
> > > --- a/drivers/gpu/drm/udl/udl_gem.c
> > > +++ b/drivers/gpu/drm/udl/udl_gem.c
> > > @@ -46,29 +46,31 @@ static void *udl_gem_object_vmap(struct
> > > drm_gem_object *obj)
> > > if (shmem->vmap_use_count++ > 0)
> > > goto out;
> > >
> > > - ret = drm_gem_shmem_get_pages(shmem);
> > > - if (ret)
> > > - goto err_zero_use;
> > > -
> > > - if (obj->import_attach)
> > > + if (obj->import_attach) {
> > > shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
> > > - else
> > > + } else {
> > > + ret = drm_gem_shmem_get_pages(shmem);
> > > + if (ret)
> > > + goto err;
> > > +
> > > shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
> > > VM_MAP, PAGE_KERNEL);
> > >
> > > + if (!shmem->vaddr)
> > > + drm_gem_shmem_put_pages(shmem);
> > > + }
> > > +
> > > if (!shmem->vaddr) {
> > > DRM_DEBUG_KMS("Failed to vmap pages\n");
> > > ret = -ENOMEM;
> > > - goto err_put_pages;
> > > + goto err;
> > > }
> > >
> > > out:
> > > mutex_unlock(&shmem->vmap_lock);
> > > return shmem->vaddr;
> > >
> > > -err_put_pages:
> > > - drm_gem_shmem_put_pages(shmem);
> > > -err_zero_use:
> > > +err:
> > > shmem->vmap_use_count = 0;
> > > mutex_unlock(&shmem->vmap_lock);
> > > return ERR_PTR(ret);
> > >
> >
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Geschäftsführer: Felix Imendörffer
> >
>
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Don't call dma_buf_vunmap without _vmap
On Sun, May 31, 2020 at 09:02:11AM -0700, Rob Clark wrote:
> On Thu, May 14, 2020 at 1:11 PM Daniel Vetter wrote:
> >
> > I honestly don't exactly understand what's going on here, but the
> > current code is wrong for sure: It calls dma_buf_vunmap without ever
> > calling dma_buf_vmap.
> >
> > What I'm not sure about is whether the WARN_ON is correct:
> > - msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
> > a pretty neat layering violation of how you shouldn't peek behind
> > the curtain of the dma-buf exporter, but par for course. Note that
> > all the nice new helpers don't (and we should probably have a bit a
> > warning about this in the kerneldoc).
> >
> > - but then in the get_vaddr() in msm_gem.c, we seems to happily wrap a
> > vmap() around any object with ->pages set (so including imported
> > dma-buf).
> >
> > - I'm not seeing any guarantees that userspace can't use an imported
> > dma-buf for e.g. MSM_SUBMIT_CMD_BUF in a5xx_submit_in_rb, so no
> > guarantees that an imported dma-buf won't end up with a ->vaddr set.
> >
> > But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by
> > calling dma_buf_vunmap is the wrong thing to do.
> >
> > v2: Rob said in review that we do indeed have a gap in get_vaddr() that
> > needs to be plugged. But the users I've found aren't legit users on
> > imported dma-buf, so we can just reject that.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Rob Clark
> > Cc: Sean Paul
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: freedr...@lists.freedesktop.org
>
> Reviewed-by: Rob Clark
Queued in drm-misc-next for 5.9, thanks for your review.
-Daniel
>
> > ---
> > drivers/gpu/drm/msm/msm_gem.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> > index 5a6a79fbc9d6..e70abd1cde43 100644
> > --- a/drivers/gpu/drm/msm/msm_gem.c
> > +++ b/drivers/gpu/drm/msm/msm_gem.c
> > @@ -554,6 +554,9 @@ static void *get_vaddr(struct drm_gem_object *obj,
> > unsigned madv)
> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
> > int ret = 0;
> >
> > + if (obj->import_attach)
> > + return ERR_PTR(-ENODEV);
> > +
> > mutex_lock(&msm_obj->lock);
> >
> > if (WARN_ON(msm_obj->madv > madv)) {
> > @@ -907,8 +910,7 @@ static void free_object(struct msm_gem_object *msm_obj)
> > put_iova(obj);
> >
> > if (obj->import_attach) {
> > - if (msm_obj->vaddr)
> > - dma_buf_vunmap(obj->import_attach->dmabuf,
> > msm_obj->vaddr);
> > + WARN_ON(msm_obj->vaddr);
> >
> > /* Don't drop the pages for imported dmabuf, as they are not
> > * ours, just free the array we allocated:
> > --
> > 2.26.2
> >
--
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 v2 03/10] drm/client: Add drm_client_framebuffer_flush()
Den 28.05.2020 15.48, skrev Emil Velikov:
> Hi all,
>
> I realise this has landed, so a small FYI comment.
>
> On Sat, 9 May 2020 at 15:16, Noralf Trønnes wrote:
>
>> +int drm_client_framebuffer_flush(struct drm_client_buffer *buffer, struct
>> drm_rect *rect)
>> +{
>> + if (!buffer || !buffer->fb || !buffer->fb->funcs->dirty)
>
> Hmm cannot think of a good reason why anyone would call this with
> !buffer || !buffer->fb?
> Might be a good idea to WARN in those cases - otherwise the user is
> given false sense to security.
>
I agree, I'll send a fixup when I get through my backlog.
Noralf.
> Looking at the upcoming user (drm/gud) it already has both - so it's
> perfectly safe.
>
> -Emil
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: MIPI DSI, DBI, and tinydrm drivers
Den 28.05.2020 17.27, skrev Emil Velikov: > On Sun, 24 May 2020 at 19:35, Daniel Vetter wrote: >> >> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes wrote: >>> >>> >>> >>> Den 24.05.2020 18.13, skrev Paul Cercueil: Hi list, I'd like to open a discussion about the current support of MIPI DSI and DBI panels. Both are standards from the MIPI alliance, both are communication protocols between a LCD controller and a LCD panel, they generally both use the same commands (DCS), the main difference is that DSI is serial and DBI is generally parallel. In the kernel right now, DSI is pretty well implemented. All the infrastucture to register a DSI host, DSI device etc. is there. DSI panels are implemented as regular drm_panel instances, and their drivers go through the DSI API to communicate with the panel, which makes them independent of the DSI host driver. DBI, on the other hand, does not have any of this. All (?) DBI panels are implemented as tinydrm drivers, which make them impossible to use with regular DRM drivers. Writing a standard drm_panel driver is impossible, as there is no concept of host and device. All these tinydrm drivers register their own DBI host as they all do DBI over SPI. I think this needs a good cleanup. Given that DSI and DBI are so similar, it would probably make sense to fuse DBI support into the current DSI code, as trying to update DBI would result in a lot of code being duplicated. With the proper host/device registration mechanism from DSI code, it would be possible to turn most of the tinydrm drivers into regular drm_panel drivers. >> >> Do we have drivers with dbi support that actually want to reuse the >> tinydrm drivers? Good clean is all good, but we need a solid reason >> for changing stuff. Plus we need to make sure we're not just >> rediscovering all the old reasons for why we ended up where we are >> right now in the first place. >> The problem then is that these should still be available as tinydrm drivers. If the DSI/DBI panels can somehow register a .update_fb() callback, it would make it possible to have a panel-agnostic tinydrm driver, which would then probably open a lot of doors, and help a lot to clean the mess. I think I can help with that, I just need some guidance - I am fishing in exotic seas here. Thoughts, comments, are very welcome. >>> >>> I did look at this a few months back: >>> >>> drm/mipi-dbi: Support panel drivers >>> https://lists.freedesktop.org/archives/dri-devel/2019-August/228966.html >>> > Coming late to the party - the series looks like a great step forward. > >>> The problem with DBI is that it has reused other busses which means we >>> don't have DBI drivers, we have SPI drivers instead (6800/8080 is not >>> avail. as busses in Linux yet). DSI and DPI on the other hand has >>> dedicated hw controller drivers not shared with other subsystems. >>> >>> My initial tinydrm work used drm_panel, but I was not allowed to use it >>> (at least not the way I had done it). >> >> Hm, do we have a summary of all the discussions/reasons from back >> then? All I remember is that it's all that simple, you've done a lot >> of work exploring all the options, I'm fairly sure I suggested >> drm_panel even back then but somehow it didn't really work. Would be >> good if we make sure we don't at least repeat history too much :-) >> > This pretty much ^^. Does anyone have a link/summary of the concerns? > I found the thread where you Emil suggested I look at drm_panel: https://lists.freedesktop.org/archives/dri-devel/2015-September/091215.html I used drm_panel in the tinydrm RFC's, but dropped it in version 1 according to the changelog. I think it was Thierry that didn't like how it was used, but I'm not entirely sure. Unfortunately I can't find the emails. There's nothing on the preceding RFC v2, so looks like it's gone somehow: https://patchwork.freedesktop.org/patch/80117/?series=4520&rev=2 Noralf. > From userspace POV - having these as panel makes sense. > Currently as new tiny drm _driver_ gets added, userspace has to be > updated to deal with it ... every so often. > > Additionally having both DPI and DBI code for the given panel > alongside one another makes the overall picture clearer. > > -Emil > Aside: mipi_dbi API should grow a drm_ prefix. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 04/10] drm: bridge: dw_mipi_dsi: allow bridge daisy chaining
On Wed, 03 Jun 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
Thank you for the patch.
On Mon, Apr 27, 2020 at 11:19:46AM +0300, Adrian Ratiu wrote:
Up until now the assumption was that the synopsis dsi bridge
will directly connect to an encoder provided by the platform
driver, but the current practice for drivers is to leave the
encoder empty via the simple encoder API and add their logic to
their own drm_bridge. Thus we need an ablility to connect the
DSI bridge to another bridge provided by the platform driver,
so we extend the dw_mipi_dsi bind() API with a new "previous
bridge" arg instead of just hardcoding NULL. Cc: Laurent
Pinchart Signed-off-by:
Adrian Ratiu --- New in v8. ---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 --
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +-
include/drm/bridge/dw_mipi_dsi.h| 5 - 3
files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
16fd87055e7b7..140ff40fa1b62 100644 ---
a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -1456,11
+1456,13 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
/*
* Bind/unbind API, used from platforms based on the component
framework. */
-int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct
drm_encoder *encoder) +int dw_mipi_dsi_bind(struct dw_mipi_dsi
*dsi, + struct drm_encoder *encoder, +
struct drm_bridge *prev_bridge)
{ int ret;
- ret = drm_bridge_attach(encoder, &dsi->bridge, NULL, 0); +
ret = drm_bridge_attach(encoder, &dsi->bridge, prev_bridge, 0);
Please note that chaining of bridges doesn't work well if
multiple bridges in the chain try to create a connector. This is
why a DRM_BRIDGE_ATTACH_NO_CONNECTOR flag has been added, with a
helper to create a connector for a chain of bridges
(drm_bridge_connector_init()). This won't play well with the
component framework. I would recommend using the
of_drm_find_bridge() instead in the rockchip driver, and
deprecating dw_mipi_dsi_bind().
Thank you for this insight, indeed the bridge dw_mipi_dsi_bind()
is clunky and we're making it even more so by possibly
re-inventing drm_bridge_connector_init() with it in a way which
can't work (well it does work but can lead to those nasty
multiple-encoder corner-cases you mention).
I'll address this before posting v9, to try to move to
of_drm_find_bridge() and remove dw_mipi_dsi_bind().
if (ret) {
DRM_ERROR("Failed to initialize bridge with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 3feff0c45b3f7..83ef43be78135 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -929,7 +929,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
return ret;
}
- ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder);
+ ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder, NULL);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
return ret;
diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
index b0e390b3288e8..699b3531f5b36 100644
--- a/include/drm/bridge/dw_mipi_dsi.h
+++ b/include/drm/bridge/dw_mipi_dsi.h
@@ -14,6 +14,7 @@
#include
struct drm_display_mode;
+struct drm_bridge;
struct drm_encoder;
struct dw_mipi_dsi;
struct mipi_dsi_device;
@@ -62,7 +63,9 @@ struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device
*pdev,
const struct dw_mipi_dsi_plat_data
*plat_data);
void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
-int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder);
+int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi,
+struct drm_encoder *encoder,
+struct drm_bridge *prev_bridge);
void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi);
void dw_mipi_dsi_set_slave(struct dw_mipi_dsi *dsi, struct dw_mipi_dsi *slave);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/15] drm/amdgpu: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 5ed4227f304b..2588dd1015db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -249,15 +249,10 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
if (amdgpu_msi_ok(adev)) {
int nvec = pci_msix_vec_count(adev->pdev);
- unsigned int flags;
- if (nvec <= 0) {
- flags = PCI_IRQ_MSI;
- } else {
- flags = PCI_IRQ_MSI | PCI_IRQ_MSIX;
- }
/* we only need one vector */
- nvec = pci_alloc_irq_vectors(adev->pdev, 1, 1, flags);
+ nvec = pci_alloc_irq_vectors(adev->pdev, 1, 1,
+PCI_IRQ_MSI_TYPES);
if (nvec > 0) {
adev->irq.msi_enabled = true;
dev_dbg(adev->dev, "amdgpu: using MSI/MSI-X.\n");
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/15] PCI: Add shorthand define for message signalled interrupt types
There are several places in the kernel which check/ask for MSI or MSI-X interrupts. It would make sense to have a shorthand constant, similar to PCI_IRQ_ALL_TYPES, to use in these situations. So add PCI_IRQ_MSI_TYPES, for this purpose. Signed-off-by: Piotr Stankiewicz Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko --- Documentation/PCI/msi-howto.rst | 5 +++-- include/linux/pci.h | 4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/PCI/msi-howto.rst b/Documentation/PCI/msi-howto.rst index aa2046af69f7..2800ff5aa395 100644 --- a/Documentation/PCI/msi-howto.rst +++ b/Documentation/PCI/msi-howto.rst @@ -105,7 +105,8 @@ if it can't meet the minimum number of vectors. The flags argument is used to specify which type of interrupt can be used by the device and the driver (PCI_IRQ_LEGACY, PCI_IRQ_MSI, PCI_IRQ_MSIX). A convenient short-hand (PCI_IRQ_ALL_TYPES) is also available to ask for -any possible kind of interrupt. If the PCI_IRQ_AFFINITY flag is set, +any possible kind of interrupt, and (PCI_IRQ_MSI_TYPES) to ask for message +signalled interrupts (MSI or MSI-X). If the PCI_IRQ_AFFINITY flag is set, pci_alloc_irq_vectors() will spread the interrupts around the available CPUs. To get the Linux IRQ numbers passed to request_irq() and free_irq() and the @@ -160,7 +161,7 @@ the single MSI mode for a device. It could be done by passing two 1s as Some devices might not support using legacy line interrupts, in which case the driver can specify that only MSI or MSI-X is acceptable:: - nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_MSI | PCI_IRQ_MSIX); + nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_MSI_TYPES); if (nvec < 0) goto out_err; diff --git a/include/linux/pci.h b/include/linux/pci.h index 83ce1cdf5676..b6c9bf70363e 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1422,8 +1422,8 @@ int pci_set_vga_state(struct pci_dev *pdev, bool decode, */ #define PCI_IRQ_VIRTUAL(1 << 4) -#define PCI_IRQ_ALL_TYPES \ - (PCI_IRQ_LEGACY | PCI_IRQ_MSI | PCI_IRQ_MSIX) +#define PCI_IRQ_MSI_TYPES (PCI_IRQ_MSI | PCI_IRQ_MSIX) +#define PCI_IRQ_ALL_TYPES (PCI_IRQ_LEGACY | PCI_IRQ_MSI_TYPES) /* kmem_cache style wrapper around pci_alloc_consistent() */ -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/15] Forward MSI-X vector enable error code in pci_alloc_irq_vectors_affinity()
The primary objective of this patch series is to change the behaviour of pci_alloc_irq_vectors_affinity() such that it forwards the MSI-X enable error code when appropriate. In the process, though, it was pointed out that there are multiple places in the kernel which check/ask for message signalled interrupts (MSI or MSI-X), which spawned the first patch adding PCI_IRQ_MSI_TYPES. Finally the rest of the chain converts all users to take advantage of PCI_IRQ_MSI_TYPES or PCI_IRQ_ALL_TYPES, as appropriate. Piotr Stankiewicz (15): PCI/MSI: Forward MSI-X vector enable error code in pci_alloc_irq_vectors_affinity() PCI: Add shorthand define for message signalled interrupt types PCI: Use PCI_IRQ_MSI_TYPES where appropriate ahci: Use PCI_IRQ_MSI_TYPES where appropriate crypto: inside-secure - Use PCI_IRQ_MSI_TYPES where appropriate dmaengine: dw-edma: Use PCI_IRQ_MSI_TYPES where appropriate drm/amdgpu: Use PCI_IRQ_MSI_TYPES where appropriate IB/qib: Use PCI_IRQ_MSI_TYPES where appropriate media: ddbridge: Use PCI_IRQ_MSI_TYPES where appropriate vmw_vmci: Use PCI_IRQ_ALL_TYPES where appropriate mmc: sdhci: Use PCI_IRQ_MSI_TYPES where appropriate amd-xgbe: Use PCI_IRQ_MSI_TYPES where appropriate aquantia: atlantic: Use PCI_IRQ_ALL_TYPES where appropriate net: hns3: Use PCI_IRQ_MSI_TYPES where appropriate scsi: Use PCI_IRQ_MSI_TYPES and PCI_IRQ_ALL_TYPES where appropriate Documentation/PCI/msi-howto.rst | 5 +++-- drivers/ata/ahci.c | 2 +- drivers/crypto/inside-secure/safexcel.c | 2 +- drivers/dma/dw-edma/dw-edma-pcie.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 9 ++--- drivers/infiniband/hw/qib/qib_pcie.c | 6 -- drivers/media/pci/ddbridge/ddbridge-main.c | 2 +- drivers/misc/vmw_vmci/vmci_guest.c | 3 +-- drivers/mmc/host/sdhci-pci-gli.c | 3 +-- drivers/mmc/host/sdhci-pci-o2micro.c | 3 +-- drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 2 +- drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 4 +--- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +-- .../net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c| 3 +-- drivers/pci/msi.c| 4 ++-- drivers/pci/pcie/portdrv_core.c | 4 ++-- drivers/pci/switch/switchtec.c | 3 +-- drivers/scsi/ipr.c | 5 +++-- drivers/scsi/vmw_pvscsi.c| 2 +- include/linux/pci.h | 4 ++-- 20 files changed, 31 insertions(+), 40 deletions(-) -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET
On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote: > On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote: > > In update_output_state, the link-status property was reset to GOOD to > > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset > > is also performed on an atomic commit without ALLLOW_MODESET. If a > > I didn't think udate_output_state() was getting called for > non-legacy paths. Where is that coming from? Oops, I'm blind and you're right, there's no bug. We already only force-set this for legacy modeset (and fbcon). That also means that atomic userspace has to handle this, which is maybe not so awesome ... So maybe we need to duct-tape over this for atomic too, and in that case it should be only done when ALLOW_MODESET is set. But maybe all the compositors that care will handle this :-/ -Daniel > > > driver reads link-status to figure out whether to re-train the link, > > this could cause an atomic commit failure. User-space doesn't expect > > such a failure, because commits without ALLOW_MODESET aren't supposed to > > fail because of link training issues. > > > > Change update_output_state to implicitly reset link-status to GOOD only > > if ALLOW_MODESET is set. This is the case for legacy drmModeSetCrtc > > because drm_atomic_state_init sets it (and is used in > > drm_atomic_helper_set_config, called from drm_mode_setcrtc). > > > > Drivers don't seem to read link-status at the moment -- they seem to > > rely on user-space performing a modeset instead. So this shouldn't > > result in any change in behaviour, this should only prevent future > > failures if drivers start reading link-status. > > > > Signed-off-by: Simon Ser > > Suggested-by: Pekka Paalanen > > Cc: Daniel Vetter > > Cc: Manasi Navare > > --- > > drivers/gpu/drm/drm_atomic.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > > index 965173fd0ac2..3d9d9e6f7397 100644 > > --- a/drivers/gpu/drm/drm_atomic.c > > +++ b/drivers/gpu/drm/drm_atomic.c > > @@ -1426,7 +1426,8 @@ static int update_output_state(struct > > drm_atomic_state *state, > > return ret; > > > > /* Make sure legacy setCrtc always re-trains */ > > - new_conn_state->link_status = DRM_LINK_STATUS_GOOD; > > + if (state->allow_modeset) > > + new_conn_state->link_status = > > DRM_LINK_STATUS_GOOD; > > } > > } > > > > -- > > 2.26.2 > > > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrjälä > Intel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET
On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote: > In update_output_state, the link-status property was reset to GOOD to > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset > is also performed on an atomic commit without ALLLOW_MODESET. If a I didn't think udate_output_state() was getting called for non-legacy paths. Where is that coming from? > driver reads link-status to figure out whether to re-train the link, > this could cause an atomic commit failure. User-space doesn't expect > such a failure, because commits without ALLOW_MODESET aren't supposed to > fail because of link training issues. > > Change update_output_state to implicitly reset link-status to GOOD only > if ALLOW_MODESET is set. This is the case for legacy drmModeSetCrtc > because drm_atomic_state_init sets it (and is used in > drm_atomic_helper_set_config, called from drm_mode_setcrtc). > > Drivers don't seem to read link-status at the moment -- they seem to > rely on user-space performing a modeset instead. So this shouldn't > result in any change in behaviour, this should only prevent future > failures if drivers start reading link-status. > > Signed-off-by: Simon Ser > Suggested-by: Pekka Paalanen > Cc: Daniel Vetter > Cc: Manasi Navare > --- > drivers/gpu/drm/drm_atomic.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 965173fd0ac2..3d9d9e6f7397 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -1426,7 +1426,8 @@ static int update_output_state(struct drm_atomic_state > *state, > return ret; > > /* Make sure legacy setCrtc always re-trains */ > - new_conn_state->link_status = DRM_LINK_STATUS_GOOD; > + if (state->allow_modeset) > + new_conn_state->link_status = > DRM_LINK_STATUS_GOOD; > } > } > > -- > 2.26.2 > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET
On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote: > In update_output_state, the link-status property was reset to GOOD to > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset > is also performed on an atomic commit without ALLLOW_MODESET. If a > driver reads link-status to figure out whether to re-train the link, > this could cause an atomic commit failure. User-space doesn't expect > such a failure, because commits without ALLOW_MODESET aren't supposed to > fail because of link training issues. > > Change update_output_state to implicitly reset link-status to GOOD only > if ALLOW_MODESET is set. This is the case for legacy drmModeSetCrtc > because drm_atomic_state_init sets it (and is used in > drm_atomic_helper_set_config, called from drm_mode_setcrtc). > > Drivers don't seem to read link-status at the moment -- they seem to > rely on user-space performing a modeset instead. So this shouldn't > result in any change in behaviour, this should only prevent future > failures if drivers start reading link-status. > > Signed-off-by: Simon Ser > Suggested-by: Pekka Paalanen I think we should have Cc: sta...@vger.kernel.org on this. Also I think would be really awesome if we can update/extend the igt, but I guess if you don't have a chamelium it's a bit hard to make that happen :-/ Also I guess you'll reflect this in your doc patch? With the cc: stable this has my Reviewed-by: Daniel Vetter Cheers, Daniel > Cc: Daniel Vetter > Cc: Manasi Navare > --- > drivers/gpu/drm/drm_atomic.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 965173fd0ac2..3d9d9e6f7397 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -1426,7 +1426,8 @@ static int update_output_state(struct drm_atomic_state > *state, > return ret; > > /* Make sure legacy setCrtc always re-trains */ > - new_conn_state->link_status = DRM_LINK_STATUS_GOOD; > + if (state->allow_modeset) > + new_conn_state->link_status = > DRM_LINK_STATUS_GOOD; > } > } > > -- > 2.26.2 > > -- 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
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #26 from Cyrax (ev...@hotmail.com) --- (In reply to Petteri Aimonen from comment #25) > Looks like there are two kinds of crash bugs here. Many of the amdgpu > crashes have been fixed in 5.7.0, but the specific one that gives "simd > exception" in dmesg is not. > > @Cyrax There is an experimental patch in > https://bugzilla.kernel.org/show_bug.cgi?id=207979 if you want to try. > > Out of interest, are you possibly running a 32-bit operating system under > virtualization on 64-bit host? That's what triggers the bug for me. I'm running one 32-bit LXC container (Arch Linux. https://archlinux32.org/>) and three 64-bit LXC containers (Arch Linux). Additionally I'm running three VirtualBox guests which are Windows, Arch Linux and old version LEDE (OpenWRT) router OS (All are running 64-bit OS). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET
In update_output_state, the link-status property was reset to GOOD to ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset is also performed on an atomic commit without ALLLOW_MODESET. If a driver reads link-status to figure out whether to re-train the link, this could cause an atomic commit failure. User-space doesn't expect such a failure, because commits without ALLOW_MODESET aren't supposed to fail because of link training issues. Change update_output_state to implicitly reset link-status to GOOD only if ALLOW_MODESET is set. This is the case for legacy drmModeSetCrtc because drm_atomic_state_init sets it (and is used in drm_atomic_helper_set_config, called from drm_mode_setcrtc). Drivers don't seem to read link-status at the moment -- they seem to rely on user-space performing a modeset instead. So this shouldn't result in any change in behaviour, this should only prevent future failures if drivers start reading link-status. Signed-off-by: Simon Ser Suggested-by: Pekka Paalanen Cc: Daniel Vetter Cc: Manasi Navare --- drivers/gpu/drm/drm_atomic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 965173fd0ac2..3d9d9e6f7397 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1426,7 +1426,8 @@ static int update_output_state(struct drm_atomic_state *state, return ret; /* Make sure legacy setCrtc always re-trains */ - new_conn_state->link_status = DRM_LINK_STATUS_GOOD; + if (state->allow_modeset) + new_conn_state->link_status = DRM_LINK_STATUS_GOOD; } } -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-stm32] [PATCH v8 08/10] drm: stm: dw-mipi-dsi: let the bridge handle the HW version check
On Tue, 02 Jun 2020, Emil Velikov wrote: Hi Adrian, Hi Email, On Mon, 1 Jun 2020 at 10:14, Adrian Ratiu wrote: On Fri, 29 May 2020, Philippe CORNU wrote: > Hi Adrian, and thank you very much for the patchset. Thank > you also for having tested it on STM32F769 and STM32MP1. > Sorry for the late response, Yannick and I will review it as > soon as possible and we will keep you posted. Note: Do not > hesitate to put us in copy for the next version > (philippe.co...@st.com, yannick.fer...@st.com) Regards, > Philippe :-) Hi Philippe, Thank you very much for your previous and future STM testing, really appreciate it! I've CC'd Yannick until now but I'll also CC you sure :) It's been over a month since I posted v8 and I was just gearing up to address all feedback, rebase & retest to prepare v9 but I'll wait a little longer, no problem, it's no rush. Small idea, pardon for joining so late: Might be a good idea to add inline comment, why the clocks are disabled so late. Effectively a 2 line version of the commit summary. Feel free to make that a separate/follow-up patch. Thanks, I'll add the comment to this patch in v9. -Emil ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 6/6] drm: exynos: mixer: Add interconnect support
Hi Chanwoo,
On 01.06.2020 09:58, Chanwoo Choi wrote:
> On 5/30/20 1:32 AM, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski
>>
>> This patch adds interconnect support to exynos-mixer. The mixer works
>> the same as before when CONFIG_INTERCONNECT is 'n'.
>>
>> For proper operation of the video mixer block we need to ensure the
>> interconnect busses like DMC or LEFTBUS provide enough bandwidth so
>> as to avoid DMA buffer underruns in the mixer block. i.e we need to
>> prevent those busses from operating in low perfomance OPPs when
>> the mixer is running.
>> In this patch the bus bandwidth request is done through the interconnect
>> API, the bandiwidth value is calculated from selected DRM mode, i.e.
>> video plane width, height, refresh rate and pixel format.
>>
>> Co-developed-by: Artur Świgoń
>> Signed-off-by: Marek Szyprowski
>> [s.nawrocki: renamed soc_path variable to icc_path, edited commit desc.]
>> Signed-off-by: Sylwester Nawrocki
>> drivers/gpu/drm/exynos/exynos_mixer.c | 73
>> ---
>> 1 file changed, 68 insertions(+), 5 deletions(-)
>> +static void mixer_set_memory_bandwidth(struct exynos_drm_crtc *crtc)
>> +{
>> +struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
>> +struct mixer_context *ctx = crtc->ctx;
>> +unsigned long bw, bandwidth = 0;
>> +u32 avg_bw, peak_bw;
>> +int i, j, sub;
>> +
>> +if (!ctx->icc_path)
>> +return;
>> +
>> +for (i = 0; i < MIXER_WIN_NR; i++) {
>> +struct drm_plane *plane = &ctx->planes[i].base;
>> +const struct drm_format_info *format;
>> +
>> +if (plane->state && plane->state->crtc && plane->state->fb) {
>> +format = plane->state->fb->format;
>> +bw = mode->hdisplay * mode->vdisplay *
>> +drm_mode_vrefresh(mode);
>> +if (mode->flags & DRM_MODE_FLAG_INTERLACE)
>> +bw /= 2;
>> +for (j = 0; j < format->num_planes; j++) {
>> +sub = j ? (format->vsub * format->hsub) : 1;
>> +bandwidth += format->cpp[j] * bw / sub;
>
> First of all, I agree this approach.
>
> Could you please add more detailed comments for understadning
> about this calculation? As you commented, it seems that
> the final bandwidth contains the width/height/refresh rate
> and pixel format. If you add one real example, it will be very helpful.
OK, I will improve the commit message and add a comment to the function.
As far as I understand this simply calculates amount of data in bytes that
needs to be read from the system memory per second for given video stream,
by summing values for each mixer window and for each color plane within
a window.
Anyway, the patch will to be changed as after some more tests it seems
the calculation works for LEFTBUS but DMC clock on Odroid U3 needs to
be set to 400 MHz, rather than to at least 160 MHz. With any lower value
the mixer underflow error interrupts are being triggered and eventually
the IOMMU page fault occurs.
--
Regards,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS documentation for userspace
On Thursday, June 27, 2019 4:59 PM, Jani Nikula wrote: > On Sat, 22 Jun 2019, Daniel Vetter dan...@ffwll.ch wrote: > > > On Wed, Jun 19, 2019 at 10:16 PM Jani Nikula > > jani.nik...@linux.intel.com wrote: > > > > > On Wed, 19 Jun 2019, Daniel Vetter dan...@ffwll.ch wrote: > > > > > > > - figure out what to do with the libdrm manpages. Some stuff we really > > > > want to also document there. But geez nroff. Maybe we need to stuff > > > > libdrm into the kernel, dunno. > > > > > > > > > > How would people feel about converting libdrm man pages to rst, and > > > using rst2man in the build? We did that for igt man pages [1]. Looking > > > at the diff, I think it's plain to see how that could lower the bar for > > > contributing. And perhaps it would be easier to refactor and move > > > documentation around too. > > > > I think that'd be very nice. > > > > > I forget, I probably used pandoc or something to do the bulk of the igt > > > conversion, and added some manual polish on top. I'm not volunteering > > > for the libdrm man page conversion though. ;) > > > > Hm, maybe dig out the old tools you used and point Simon at them? > > I could swear I did it with pandoc only, but the pandoc I have on my > distro right now does not support man input. Upstream documentation > claims it does, so I don't know what gives. > > If that fails, first man2html and then pandoc from html to rst works to > an extent. > > Regardless, I think the hardest part is deciding what style to use in > the rst files (all the headings and synopsis and references etc.) and > then tediously do the manual cleanup after the conversion. It's a > one-time effort, so there are limits to the ROI on polishing the > toolchain. After all these months, I've started converting the man pages to rst [1]. Better late than never! I've used this command to convert xml to rst: pandoc -s -f docbook -t rst -o man/drm.rst man/drm.xml This mostly works but needs some rework to fixup references and headings. You can see the final result in the MR. [1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/72 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically change enumeration list of DRM enumeration property
On Wed, Jun 03, 2020 at 12:12:23PM +0300, Pekka Paalanen wrote: > On Wed, 3 Jun 2020 10:50:28 +0530 > Yogish Kulkarni wrote: > > > Inline.. > > > > On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote: > > > > > On Mon, 1 Jun 2020 09:22:27 +0530 > > > Yogish Kulkarni wrote: > > > > > > > Hi, > > > > > > > > For letting DRM clients to select output encoding: > > > > Sink can support certain display timings with high output bit-depths > > > using > > > > multiple output encodings, e.g. sink can support a particular timing > > > > with > > > > RGB 10-bit, YCbCr422 10-bit and YCbCr420 10-bit. So DRM client may want > > > > > > > to > > > > select YCbCr422 10-bit over RBG 10-bit output to reduce the link > > > bandwidth > > > > (and in turn reduce power/voltage). If DRM driver automatically selects > > > > output encoding then we are restricting DRM clients from making > > > appropriate > > > > choice. > > > > > > Hi, > > > > > > right, that seems to be another reason. > > > > > > > For selectable output color range: > > > > Certain applications (typically graphics) usually rendered in full range > > > > while some applications (typically video) have limited range content. > > > Since > > > > content can change dynamically, DRM driver does not have enough > > > information > > > > to choose correct quantization. Only DRM client can correctly select > > > which > > > > quantization to set (to preserve artist's intent). > > > > > > Now this is an interesting topic for me. As far as I know, there is no > > > window system protocol to tell the display server whether the > > > application provided content is using full or limited range. This means > > > that the display server cannot tell DRM about full vs. limited range > > > either. It also means that when not fullscreen, the display server > > > cannot show the limited range video content correctly, because it would > > > have to be converted to full-range (or vice versa). > > > > > Right, but there could be DRM client which doesn't use window system (e.g. > > Gstreamer video sink) and wants to select between full/limited color range. > > I agree that there is no window system protocol yet but maybe Wayland > > protocol could be added/extended for this purpose once we finalize things > > that needs to be done in DRM. > > Hi, > > right. If you have that use case and a userspace project welcomes such > feature, you're good. > > If you propose a KMS property for this, I would hope the patches > document or have links pointing to answers to all my questions here. > That would help both driver and userspace implementations to get into > the same mindset. > > > > But why would an application produce limited range pixels anyway? Is it > > > common that hardware video decoders are unable to produce full-range > > > pixels? > > > > > > > The primary reason for why content producer masters video/gfx content as > > limited range is for compatibility with sinks which only support limited > > range, and not because video decoders are not capable of decoding > > full-range content. > > What I was asking is, even if the video content is limited range, why > would one not decode it into full-range pixels always and if the sink > need limited range, then convert again in hardware? When done right, it > makes no difference in output compared to using limited range > through-out if both content and sink use limited range. > > > Also, certain cinema-related content (e.g., movies) may > > be better suited for limited range encoding due to the level of detail that > > they need to present/hide (see "Why does limited RGB even exist?" section > > in > > https://www.benq.com/en-us/knowledge-center/knowledge/full-rgb-vs-limited-rgb-is-there-a-difference.html#:~:text=Full%20RGB%20means%20the%20ability,less%20dark)%20than%20full%20RGB > > ). > > That is a very nice link, thanks! > > But to me it seems the section "Why is this a problem?" gets "crushed > blacks" backwards, so maybe I just don't get it. > > I would assume that if the source (computer) sends full-range pixel > values on the wire and the sink (monitor) works in limited-range mode, > then you would get crushed blacks and crushed whites. > > But if the source sends limited-range data and the sink works in > full-range more, you'd get the "washed out" image. > > My thinking comes from the mapping of channel values: if 0-16 and > 235-255 ranges show no difference within them, I'd call that "crushed". > Similarly if one assumes 16 is darkest black and it's actually not, > you'd get "washed out" (I might call it compressed instead, because it > affects both black and white ends, unable to achieve both the darkest > black and the brightest white). > > Anyway, I believe I do understand that if you have content in one > range and the sink assumes a different range, the content will show > poorly. I don't doubt that. > > My question instead is: why would it be bad to always con
Re: [PATCH v3] drm/fourcc: document modifier uniqueness requirements
Hi Alex, On Mon, 1 Jun 2020 at 15:25, Alex Deucher wrote: > On Fri, May 29, 2020 at 11:03 AM Daniel Stone wrote: > > What Weston _does_ know, however, is that display controller can work > > with modifier set A, and the GPU can work with modifier set B, and if > > the client can pick something from modifier set A, then there is a > > much greater probability that Weston can leave the GPU alone so it can > > be entirely used by the client. It also knows that if the surface > > can't be directly scanned out for whatever reason, then there's no > > point in the client optimising for direct scanout, and it can tell the > > client to select based on optimality purely for the GPU. > > Just so I understand this correctly, the main reason for this is to > deal with display hardware and render hardware from different vendors > which may or may not support any common formats other than linear. It handles pretty much everything other than a single-context, single-GPU, single-device, tunnel. When sharing between subsystems and device categories, it lets us talk about capabilities in a more global way. For example, GBM lets you talk about 'scanout' and 'texture' and 'render', but what about media codecs? We could add the concept of decode/encode to something like GBM, and all the protocols like Wayland/X11 as well, then hope it actually works, but ... When sharing between heterogeneous vendors, it lets us talk about capabilities in a neutral way. For example, if you look at most modern Arm SoCs, your GPU, display controller, and media codec, will very likely all be from three totally different vendors. A GPU like Mali-T8xx can be shipped in tens of different vendor SoCs in several different revisions each. Just saying 'scanout' is totally meaningless for the Panfrost driver. Putting awareness for every different KMS platform and every different codec down into the Mesa driver is a synchronisation nightmare, and all those drivers would also need specific awareness about the Mesa driver. So modifiers allow us to explicitly describe that we want a particular revision of Arm Framebuffer Compression, and all the components can understand that without having to be specifically aware of 15 different KMS drivers. But even if you have the same vendor ... When sharing between multiple devices of the same class from the same vendor, it lets us surface and transit that information in a generic way, without AMD having to figure out ways to tunnel back-channel information between different instances of drivers potentially targeting different revisions. The alternatives seem to be deeply pessimal hacks, and we think we can do better. And when we get pessimal ... In every case, modifiers are about surfacing and sharing information. One of the reasons Collabora have been putting so much time and energy into this work is exactly _because_ solving those problems on a case-by-case basis was a pretty lucrative source of revenue for us. Debugging these kinds of issues before has usually involved specific driver knowledge, hacking into the driver to insert your own tracing, etc. If you (as someone who's trying to use a device optimally) are fortunate enough that you can get the attention of a vendor and have them solve the problem for you, then that's lucky for everyone apart from the AMD engineers who have to go solve it. If you're not, and you can't figure it out yourself, then you have to go pay a consultancy. On the face of it, that's good for us, except that we don't want to be doing that kind of repetitive boring work. But it's bad for the ecosystem that this knowledge is hidden away and that you have to pay specialists to extract it. So we're really keen to surface as much mechanism and information as possible, to give people the tools to either solve their own problems or at least make well-informed reports, burn down a toxic source of revenue, waste less engineering time extracting hidden information, and empower users as much as possible. > It > provides a way to tunnel device capabilities between the different > drivers. In the case of a device with display and rendering on the > same device or multiple devices from the same vendor, it not really > that useful. Oh no, it's still super useful. There are a ton of corner cases where 'if you're on same same-vendor same-gen same-silicon hardware' falls apart - in addition to the world just not being very much same-vendor/same-gen/same-silicon anymore. For some concrete examples: On NVIDIA Tegra hardware, planes within the display controller have heterogeneous capability. Some can decompress and detile, others can't. On Rockchip hardware, AFBC (DCC equivalent) is available for scanout on any plane, and can be produced by the GPU. Great! Except that 'any plane' isn't 'every plane' - there's a global decompression unit. On Intel hardware, they appear to have forked the media codec IP, shipping two different versions of the codec, one as 'low-power' and one as 'normal', obvi
Re: [PATCH v2] drm: document how user-space should use link-status
On Tue, 02 Jun 2020 19:18:15 +
Simon Ser wrote:
> Describe what a "BAD" link-status means for user-space and how it should
> handle it. The logic described has been implemented in igt [1].
>
> v2:
>
> - Change wording to avoid "enabled" (Daniel)
> - Add paragraph about multiple connectors sharing the same CRTC (Pekka)
> - Add paragraph about performing an atomic commit on a connector without
> updating the link-status property (Daniel)
>
> [1]:
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/fbe61f529737191d0920521946a575bd55f00fbe
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Manasi Navare
> Cc: Pekka Paalanen
> ---
> drivers/gpu/drm/drm_connector.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f2b20fd66319..829b21124048 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -994,6 +994,21 @@ static const struct drm_prop_enum_list dp_colorspaces[]
> = {
> * after modeset, the kernel driver may set this to "BAD" and issue a
> * hotplug uevent. Drivers should update this value using
> * drm_connector_set_link_status_property().
> + *
> + * When user-space receives the hotplug uevent and detects a "BAD"
> + * link-status, the sink doesn't receive pixels anymore. The list of
> + * available modes may have changed. User-space is expected to pick a
> new
> + * mode if the current one has disappeared and perform a new modeset
> with
> + * link-status set to "GOOD" to re-enable the connector.
> + *
> + * If multiple connectors share the same CRTC and one of them gets a
> "BAD"
> + * link-status, the other are unaffected (ie. the sinks still continue
> to
> + * receive pixels).
> + *
Hi,
looks good up to here.
> + * When user-space performs an atomic commit on a connector with a "BAD"
> + * link-status without resetting the property to "GOOD", it gets
> + * implicitly reset. This might make the atomic commit fail if the
> modeset
> + * is unsuccessful.
I think this was what Daniel was saying that the kernel should require
ALLOW_MODESET to be set for the automatic reset, right?
I'm fine with how the doc is written now. But if ALLOW_MODESET becomes
a requirement for the automatic reset, I suspect there is a risk to
regress Weston, assuming the automatic reset used to be successful.
I understand this doc describes the current situation and it answers my
questions, so:
Acked-by: Pekka Paalanen
Thanks,
pq
> * non_desktop:
> * Indicates the output should be ignored for purposes of displaying a
> * standard desktop environment or console. This is most likely because
pgpBr8L9n2zKV.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
On 02.06.2020 10:21, Krzysztof Kozlowski wrote:
>> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
>> +{
>> +struct of_phandle_args args;
>> +int num, ret;
>> +
>> +num = of_count_phandle_with_args(np, "samsung,interconnect-parent",
>> +"#interconnect-cells");
>> +if (num != 1)
>> +return NULL; /* parent nodes are optional */
>> +
>> +ret = of_parse_phandle_with_args(np, "samsung,interconnect-parent",
>> +"#interconnect-cells", 0, &args);
>> +if (ret < 0)
>> +return ERR_PTR(ret);
>> +
>> +of_node_put(args.np);
>> +
>> +return of_icc_get_from_provider(&args);
> I think of_node_put() should happen after of_icc_get_from_provider().
Indeed, thanks, I will amend that. It seems the node reference count
decrementing
is often not done properly after existing calls to of_parse_phandle_with_args().
--
Thanks,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically change enumeration list of DRM enumeration property
On Wed, 3 Jun 2020 10:50:28 +0530 Yogish Kulkarni wrote: > Inline.. > > On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote: > > > On Mon, 1 Jun 2020 09:22:27 +0530 > > Yogish Kulkarni wrote: > > > > > Hi, > > > > > > For letting DRM clients to select output encoding: > > > Sink can support certain display timings with high output bit-depths > > using > > > multiple output encodings, e.g. sink can support a particular timing with > > > RGB 10-bit, YCbCr422 10-bit and YCbCr420 10-bit. So DRM client may want > > to > > > select YCbCr422 10-bit over RBG 10-bit output to reduce the link > > bandwidth > > > (and in turn reduce power/voltage). If DRM driver automatically selects > > > output encoding then we are restricting DRM clients from making > > appropriate > > > choice. > > > > Hi, > > > > right, that seems to be another reason. > > > > > For selectable output color range: > > > Certain applications (typically graphics) usually rendered in full range > > > while some applications (typically video) have limited range content. > > Since > > > content can change dynamically, DRM driver does not have enough > > information > > > to choose correct quantization. Only DRM client can correctly select > > which > > > quantization to set (to preserve artist's intent). > > > > Now this is an interesting topic for me. As far as I know, there is no > > window system protocol to tell the display server whether the > > application provided content is using full or limited range. This means > > that the display server cannot tell DRM about full vs. limited range > > either. It also means that when not fullscreen, the display server > > cannot show the limited range video content correctly, because it would > > have to be converted to full-range (or vice versa). > > > Right, but there could be DRM client which doesn't use window system (e.g. > Gstreamer video sink) and wants to select between full/limited color range. > I agree that there is no window system protocol yet but maybe Wayland > protocol could be added/extended for this purpose once we finalize things > that needs to be done in DRM. Hi, right. If you have that use case and a userspace project welcomes such feature, you're good. If you propose a KMS property for this, I would hope the patches document or have links pointing to answers to all my questions here. That would help both driver and userspace implementations to get into the same mindset. > > But why would an application produce limited range pixels anyway? Is it > > common that hardware video decoders are unable to produce full-range > > pixels? > > > > The primary reason for why content producer masters video/gfx content as > limited range is for compatibility with sinks which only support limited > range, and not because video decoders are not capable of decoding > full-range content. What I was asking is, even if the video content is limited range, why would one not decode it into full-range pixels always and if the sink need limited range, then convert again in hardware? When done right, it makes no difference in output compared to using limited range through-out if both content and sink use limited range. > Also, certain cinema-related content (e.g., movies) may > be better suited for limited range encoding due to the level of detail that > they need to present/hide (see "Why does limited RGB even exist?" section > in > https://www.benq.com/en-us/knowledge-center/knowledge/full-rgb-vs-limited-rgb-is-there-a-difference.html#:~:text=Full%20RGB%20means%20the%20ability,less%20dark)%20than%20full%20RGB > ). That is a very nice link, thanks! But to me it seems the section "Why is this a problem?" gets "crushed blacks" backwards, so maybe I just don't get it. I would assume that if the source (computer) sends full-range pixel values on the wire and the sink (monitor) works in limited-range mode, then you would get crushed blacks and crushed whites. But if the source sends limited-range data and the sink works in full-range more, you'd get the "washed out" image. My thinking comes from the mapping of channel values: if 0-16 and 235-255 ranges show no difference within them, I'd call that "crushed". Similarly if one assumes 16 is darkest black and it's actually not, you'd get "washed out" (I might call it compressed instead, because it affects both black and white ends, unable to achieve both the darkest black and the brightest white). Anyway, I believe I do understand that if you have content in one range and the sink assumes a different range, the content will show poorly. I don't doubt that. My question instead is: why would it be bad to always convert everything to full-range inside the source (e.g. decoder -> app -> display server all in full-range), and then convert for the wire into what the sink expects? Because that is how Wayland color management is going to handle differing color spaces, more or less. (Actually, quite likely the compos
Re: [RFC PATCH 1/1] drm/mm: add ig_frag selftest
On 6/2/20 4:25 PM, Christian König wrote:
Am 02.06.20 um 16:13 schrieb Nirmoy:
Hi Christian,
On 6/2/20 2:47 PM, Christian König wrote:
Nirmoy please keep in mind that your current implementation doesn't
fully solve the issue the test case is exercising.
In other words what you have implement is fast skipping of
fragmented address space for bottom-up and top-down.
But what this test here exercises is the fast skipping of aligned
allocations. You should probably adjust the test case a bit.
Allocations with size=4k and aign = 8k is known to introduce
fragmentation,
Yes, but this fragmentation can't be avoided with what we already
implemented. For this we would need the extension with the alignment I
already explained.
do you mean I should only test bottom-up and top-down
for now ?
Yes and no.
What we need to test is the following:
1. Make tons of allocations with size=4k and align=0.
2. Free every other of those allocations.
3. Make tons of allocations with size=8k and align=0.
Previously bottom-up and top-down would have checked all the holes
created in step #2.
With your change they can immediately see that this doesn't make sense
and shortcut to the leftmost/rightmost leaf node in the tree with the
large free block.
That we can handle the alignment as well is the next step of that.
Thanks Christian for the detailed explanation. I have modified this as
you suggested, will send in few minutes.
Regards,
Nirmoy
Regards,
Christian.
Regards,
Nirmoy
Regards,
Christian.
Am 29.05.20 um 23:01 schrieb Nirmoy:
On 5/29/20 5:52 PM, Chris Wilson wrote:
Quoting Nirmoy (2020-05-29 16:40:53)
This works correctly most of the times but sometimes
I have to take my word back. In another machine, 20k insertions in
best mode takes 6-9 times more than 10k insertions, all most all
the time.
evict, bottom-up and top-down modes remains in 2-5 times range.
If I reduce the insertions to 1k and 2k then scaling factor for
best mode stays below 4 most of the time.
evict, bottom-up and top-down modes remains in 2-3 times range.
I wonder if it makes sense to test with only 1k and 2k insertions
and tolerate more than error if the mode == best.
Regards,
Nirmoy
20k insertions can take more than 8 times of 10k insertion time.
The pressure is on to improve then :)
Regards,
Nirmoy
On 5/29/20 6:33 PM, Nirmoy Das wrote:
This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if time taken by 20k insertions takes more than 4 times
of 10k insertions as we know that insertions scale quadratically.
Also tolerate 10% error because of kernel scheduler's jitters.
Output:
[ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm),
with random_seed=0x9bfb4117 max_iterations=8192 max_prime=128
[ 8092.653520] drm_mm: igt_sanitycheck - ok!
[ 8092.653525] igt_debug 0x-0x0200:
512: free
[ 8092.653526] igt_debug 0x0200-0x0600:
1024: used
[ 8092.653527] igt_debug 0x0600-0x0a00:
1024: free
[ 8092.653528] igt_debug 0x0a00-0x0e00:
1024: used
[ 8092.653529] igt_debug 0x0e00-0x1000:
512: free
[ 8092.653529] igt_debug total: 4096, used 2048 free 2048
[ 8112.569813] drm_mm: best fragmented insert of 1 and 2
insertions took 504 and 1996 msecs
[ 8112.723254] drm_mm: bottom-up fragmented insert of 1 and
2 insertions took 44 and 108 msecs
[ 8112.813212] drm_mm: top-down fragmented insert of 1 and
2 insertions took 40 and 44 msecs
[ 8112.847733] drm_mm: evict fragmented insert of 1 and
2 insertions took 8 and 20 msecs
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 73
2 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h
b/drivers/gpu/drm/selftests/drm_mm_selftests.h
index 6b943ea1c57d..8c87c964176b 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -14,6 +14,7 @@ selftest(insert, igt_insert)
selftest(replace, igt_replace)
selftest(insert_range, igt_insert_range)
selftest(align, igt_align)
+selftest(frag, igt_frag)
selftest(align32, igt_align32)
selftest(align64, igt_align64)
selftest(evict, igt_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 9aabe82dcd3a..05d8f3659b4d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
return 0;
}
+static int get_insert_time(unsigned int num_insert,
+ const struct insert_mode *mode)
+{
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigne
[PATCH v2 03/23] drm/arm: Use GEM CMA object functions
The arm driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Liviu Dudau
Acked-by: Emil Velikov
---
drivers/gpu/drm/arm/hdlcd_drv.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 194419f47c5e5..c83b81a3a582a 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -240,17 +240,7 @@ static struct drm_driver hdlcd_driver = {
.irq_preinstall = hdlcd_irq_preinstall,
.irq_postinstall = hdlcd_irq_postinstall,
.irq_uninstall = hdlcd_irq_uninstall,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_print_info = drm_gem_cma_print_info,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create = drm_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = hdlcd_debugfs_init,
#endif
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/23] drm/komeda: Use GEM CMA object functions
The komeda driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver. All
remaining operations are provided by CMA GEM object functions.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
v2:
* update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
Signed-off-by: Thomas Zimmermann
Acked-by: Liviu Dudau
Acked-by: Emil Velikov
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 6b85d5f4caa85..1f6682032ca49 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -61,16 +61,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void
*data)
static struct drm_driver komeda_kms_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.lastclose = drm_fb_helper_lastclose,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create= komeda_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(komeda_gem_cma_dumb_create),
.fops = &komeda_cma_fops,
.name = "komeda",
.desc = "Arm Komeda Display Processor driver",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/23] drm/atmel-hlcdc: Use GEM CMA object functions
The atmel-hlcdc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Acked-by: Emil Velikov
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 112aa5066ceed..871293d1aeeba 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -821,16 +821,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
.irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
.irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
.irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
- .dumb_create = drm_gem_cma_dumb_create,
+ DRM_GEM_CMA_DRIVER_OPS,
.fops = &fops,
.name = "atmel-hlcdc",
.desc = "Atmel HLCD Controller DRM",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/23] drm/hisilicon/kirin: Set .dumb_create to drm_gem_cma_dumb_create()
The kirin drivers uses drm_gem_cma_dumb_create_internal() for its
.dumb_create implementation. The function is meant for internal use
only by drivers that require additional buffer setup.
Kirin does not do an additional setup, so convert it over to
drm_gem_cma_dumb_create().
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
Cc: Xu YiPing
Cc: Rongrong Zou
Cc: Xinliang Liu
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index c339e632522a9..18e57e571e054 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -923,7 +923,7 @@ static struct drm_driver ade_driver = {
.fops = &ade_fops,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create = drm_gem_cma_dumb_create_internal,
+ .dumb_create = drm_gem_cma_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 18/23] drm/stm: Use GEM CMA object functions
The stm driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
v2:
* update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
Signed-off-by: Thomas Zimmermann
Reviewed-by: Philippe Cornu
Acked-by: Emil Velikov
---
drivers/gpu/drm/stm/drv.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 0f85dd86cafa7..411103f013e25 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -62,16 +62,7 @@ static struct drm_driver drv_driver = {
.minor = 0,
.patchlevel = 0,
.fops = &drv_driver_fops,
- .dumb_create = stm_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(stm_gem_cma_dumb_create),
};
static int drv_load(struct drm_device *ddev)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/23] drm/mcde: Use GEM CMA object functions
The mcde driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Linus Walleij
Acked-by: Emil Velikov
---
drivers/gpu/drm/mcde/mcde_drv.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 84f3e2dbd77bd..d300be5ee463d 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -228,17 +228,7 @@ static struct drm_driver mcde_drm_driver = {
.major = 1,
.minor = 0,
.patchlevel = 0,
- .dumb_create = drm_gem_cma_dumb_create,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
-
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
};
static int mcde_drm_bind(struct device *dev)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 15/23] drm/mxsfb: Use GEM CMA object functions
The mxsfb driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 497cf443a9afa..47c7dce03da4a 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -356,16 +356,7 @@ static struct drm_driver mxsfb_driver = {
.irq_handler= mxsfb_irq_handler,
.irq_preinstall = mxsfb_irq_preinstall,
.irq_uninstall = mxsfb_irq_preinstall,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create= drm_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
.fops = &fops,
.name = "mxsfb-drm",
.desc = "MXSFB Controller DRM",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/23] drm/malidp: Use GEM CMA object functions
The malidp driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
v2:
* update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
Signed-off-by: Thomas Zimmermann
Acked-by: Liviu Dudau
Acked-by: Emil Velikov
---
drivers/gpu/drm/arm/malidp_drv.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c2507b7d8512b..cbd35fd305803 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -563,16 +563,7 @@ static void malidp_debugfs_init(struct drm_minor *minor)
static struct drm_driver malidp_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create = malidp_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(malidp_dumb_create),
#ifdef CONFIG_DEBUG_FS
.debugfs_init = malidp_debugfs_init,
#endif
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/23] drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
to their defaults. No functional changes are made.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index 6b27242b9ee3c..1167ff78e24a3 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -188,12 +188,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
static struct drm_driver aspeed_gfx_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
- .gem_create_object = drm_cma_gem_create_object_default_funcs,
- .dumb_create= drm_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_mmap = drm_gem_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
.fops = &fops,
.name = "aspeed-gfx-drm",
.desc = "ASPEED GFX DRM",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/23] drm/hisilicon/kirin: Use GEM CMA object functions
The kirin driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
v2:
* use DRM_GEM_CMA_DRIVER_OPS
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
Cc: Xu YiPing
Cc: Rongrong Zou
Cc: Xinliang Liu
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 18e57e571e054..e1108c1735ad0 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -921,17 +921,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ade_fops);
static struct drm_driver ade_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = &ade_fops,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create = drm_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
-
+ DRM_GEM_CMA_DRIVER_OPS,
.name = "kirin",
.desc = "Hisilicon Kirin620 SoC DRM Driver",
.date = "20150718",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/23] drm: Convert most CMA-based drivers to GEM object functions
Most of the CMA-based drivers use the default implementation for the callbacks in struct drm_driver. With this patch, these interfaces are initialized with a common helper macro and GEM object functions replace several deprecated interfaces. The first patch updates the existing macro to similar naming as with SHMEM and adds a helper for drivers that override the default implementation for .dumb_create(). The remaining patches convert the drivers. The aspeed driver already uses GEM object functions and only changes to the initializer macro. The kirin driver also changes to the default dumb_create function. I don't have much of the hardware, so it's only compile-tested on aarch64, arm and x86-64 only. Several patches have Tested-by tags. The aspeed driver has used the implemented scheme for a while. v2: * add more detailed commit messages (Laurent, Sam) * use default .dumb_create implementation in kirin (Emil) * fix zte build error (Sam, Emil) * introduce DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (everyone) Thomas Zimmermann (23): drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro drm/arc: Use GEM CMA object functions drm/arm: Use GEM CMA object functions drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS drm/atmel-hlcdc: Use GEM CMA object functions drm/fsl-dcu: Use GEM CMA object functions drm/hisilicon/kirin: Set .dumb_create to drm_gem_cma_dumb_create() drm/hisilicon/kirin: Use GEM CMA object functions drm/imx: Use GEM CMA object functions drm/ingenic: Use GEM CMA object functions drm/komeda: Use GEM CMA object functions drm/malidp: Use GEM CMA object functions drm/mcde: Use GEM CMA object functions drm/meson: Use GEM CMA object functions drm/mxsfb: Use GEM CMA object functions drm/rcar-du: Use GEM CMA object functions drm/shmobile: Use GEM CMA object functions drm/stm: Use GEM CMA object functions drm/sti: Use GEM CMA object functions drm/tilcdc: Use GEM CMA object functions drm/tv200: Use GEM CMA object functions drm/zte: Use GEM CMA object functions drm: Remove struct drm_driver.gem_print_info drivers/gpu/drm/arc/arcpgu_drv.c | 12 +--- .../gpu/drm/arm/display/komeda/komeda_kms.c | 11 +-- drivers/gpu/drm/arm/hdlcd_drv.c | 12 +--- drivers/gpu/drm/arm/malidp_drv.c | 11 +-- drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 11 +-- drivers/gpu/drm/drm_gem.c | 2 -- drivers/gpu/drm/drm_gem_cma_helper.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 11 +-- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +--- drivers/gpu/drm/imx/imx-drm-core.c| 12 +--- drivers/gpu/drm/ingenic/ingenic-drm.c | 13 +--- drivers/gpu/drm/mcde/mcde_drv.c | 12 +--- drivers/gpu/drm/meson/meson_drv.c | 15 ++ drivers/gpu/drm/mxsfb/mxsfb_drv.c | 11 +-- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +-- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 11 +-- drivers/gpu/drm/sti/sti_drv.c | 12 +--- drivers/gpu/drm/stm/drv.c | 11 +-- drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +- drivers/gpu/drm/tidss/tidss_drv.c | 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 13 +--- drivers/gpu/drm/tiny/hx8357d.c| 2 +- drivers/gpu/drm/tiny/ili9225.c| 2 +- drivers/gpu/drm/tiny/ili9341.c| 2 +- drivers/gpu/drm/tiny/ili9486.c| 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c| 2 +- drivers/gpu/drm/tiny/st7586.c | 2 +- drivers/gpu/drm/tiny/st7735r.c| 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 12 +--- drivers/gpu/drm/zte/zx_drm_drv.c | 11 +-- include/drm/drm_drv.h | 17 --- include/drm/drm_gem_cma_helper.h | 30 --- 34 files changed, 58 insertions(+), 245 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 14/23] drm/meson: Use GEM CMA object functions
The meson driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
v2:
* update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/meson/meson_drv.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 4c5aafcec7991..8b9c8dd788c41 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -96,19 +96,8 @@ static struct drm_driver meson_driver = {
/* IRQ */
.irq_handler= meson_irq,
- /* PRIME Ops */
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
-
- /* GEM Ops */
- .dumb_create= meson_dumb_create,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
+ /* CMA Ops */
+ DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(meson_dumb_create),
/* Misc */
.fops = &fops,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 19/23] drm/sti: Use GEM CMA object functions
The sti driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/sti/sti_drv.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 3f9db3e3f3978..381804126e70d 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -132,19 +132,9 @@ DEFINE_DRM_GEM_CMA_FOPS(sti_driver_fops);
static struct drm_driver sti_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create = drm_gem_cma_dumb_create,
+ DRM_GEM_CMA_DRIVER_OPS,
.fops = &sti_driver_fops,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
-
.debugfs_init = sti_drm_dbg_init,
.name = DRIVER_NAME,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 20/23] drm/tilcdc: Use GEM CMA object functions
The tilcdc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index a5e9ee4c7fbf4..0d74a64432633 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -496,18 +496,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
static struct drm_driver tilcdc_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.irq_handler= tilcdc_irq,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_print_info = drm_gem_cma_print_info,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create= drm_gem_cma_dumb_create,
-
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = tilcdc_debugfs_init,
#endif
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/23] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro
Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
helpers. An internal version is provided for drivers that override
the default .dumb_create callback. Adapt drivers to the changes.
v2:
* provide DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Acked-by: Emil Velikov
---
drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_drv.c| 3 +--
drivers/gpu/drm/tidss/tidss_drv.c| 2 +-
drivers/gpu/drm/tiny/hx8357d.c | 2 +-
drivers/gpu/drm/tiny/ili9225.c | 2 +-
drivers/gpu/drm/tiny/ili9341.c | 2 +-
drivers/gpu/drm/tiny/ili9486.c | 2 +-
drivers/gpu/drm/tiny/mi0283qt.c | 2 +-
drivers/gpu/drm/tiny/repaper.c | 2 +-
drivers/gpu/drm/tiny/st7586.c| 2 +-
drivers/gpu/drm/tiny/st7735r.c | 2 +-
include/drm/drm_gem_cma_helper.h | 30
12 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index b3db3ca7bd7a7..322a695608607 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -620,7 +620,7 @@ EXPORT_SYMBOL(drm_cma_gem_create_object_default_funcs);
* address set. This address is released when the object is freed.
*
* This function can be used as the &drm_driver.gem_prime_import_sg_table
- * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut to set
+ * callback. The &DRM_GEM_CMA_DRIVER_OPS macro provides a shortcut to set
* the necessary DRM driver operations.
*
* Returns:
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 328272ff77d84..94a90961284ce 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -52,8 +52,7 @@ static struct drm_driver sun4i_drv_driver = {
.minor = 0,
/* GEM Operations */
- DRM_GEM_CMA_VMAP_DRIVER_OPS,
- .dumb_create= drm_sun4i_gem_dumb_create,
+ DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(drm_sun4i_gem_dumb_create),
};
static int sun4i_drv_bind(struct device *dev)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
b/drivers/gpu/drm/tidss/tidss_drv.c
index 99edc66ebdef2..1753cdc74ebda 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -112,7 +112,7 @@ static struct drm_driver tidss_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = &tidss_fops,
.release= tidss_release,
- DRM_GEM_CMA_VMAP_DRIVER_OPS,
+ DRM_GEM_CMA_DRIVER_OPS,
.name = "tidss",
.desc = "TI Keystone DSS",
.date = "20180215",
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index b4bc358a3269a..592da71d7ca70 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -196,7 +196,7 @@ DEFINE_DRM_GEM_CMA_FOPS(hx8357d_fops);
static struct drm_driver hx8357d_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = &hx8357d_fops,
- DRM_GEM_CMA_VMAP_DRIVER_OPS,
+ DRM_GEM_CMA_DRIVER_OPS,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "hx8357d",
.desc = "HX8357D",
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index d1a5ab6747d5c..368ff6c8a1efb 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -346,7 +346,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9225_fops);
static struct drm_driver ili9225_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = &ili9225_fops,
- DRM_GEM_CMA_VMAP_DRIVER_OPS,
+ DRM_GEM_CMA_DRIVER_OPS,
.name = "ili9225",
.desc = "Ilitek ILI9225",
.date = "20171106",
diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
index bb819f45a5d3b..e1b9043ef7a0a 100644
--- a/drivers/gpu/drm/tiny/ili9341.c
+++ b/drivers/gpu/drm/tiny/ili9341.c
@@ -152,7 +152,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9341_fops);
static struct drm_driver ili9341_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = &ili9341_fops,
- DRM_GEM_CMA_VMAP_DRIVER_OPS,
+ DRM_GEM_CMA_DRIVER_OPS,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "ili9341",
.desc = "Ilitek ILI9341",
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 2702ea557d297..90a17f40fdf0c 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9
[PATCH v2 22/23] drm/zte: Use GEM CMA object functions
The zte driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/zte/zx_drm_drv.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 1141c1ed1ed04..31014a451f8bd 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -36,16 +36,7 @@ DEFINE_DRM_GEM_CMA_FOPS(zx_drm_fops);
static struct drm_driver zx_drm_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create = drm_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
.fops = &zx_drm_fops,
.name = "zx-vou",
.desc = "ZTE VOU Controller DRM",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/23] drm/arc: Use GEM CMA object functions
The arc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/arc/arcpgu_drv.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index c05d001163e0e..f164818ec477a 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -154,17 +154,7 @@ static struct drm_driver arcpgu_drm_driver = {
.minor = 0,
.patchlevel = 0,
.fops = &arcpgu_drm_ops,
- .dumb_create = drm_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_print_info = drm_gem_cma_print_info,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = arcpgu_debugfs_init,
#endif
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 23/23] drm: Remove struct drm_driver.gem_print_info
The .gem_print_info callback in struct drm_driver is obsolete and has
no users left. Remove it.
Signed-off-by: Thomas Zimmermann
Suggested-by: Emil Velikov
---
drivers/gpu/drm/drm_gem.c | 2 --
include/drm/drm_drv.h | 17 -
2 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index efc0367841e2b..08b3fa27ec406 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1191,8 +1191,6 @@ void drm_gem_print_info(struct drm_printer *p, unsigned
int indent,
if (obj->funcs && obj->funcs->print_info)
obj->funcs->print_info(p, indent, obj);
- else if (obj->dev->driver->gem_print_info)
- obj->dev->driver->gem_print_info(p, indent, obj);
}
int drm_gem_pin(struct drm_gem_object *obj)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index bb924cddc09c1..8f110a28b6a23 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -353,23 +353,6 @@ struct drm_driver {
*/
void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);
- /**
-* @gem_print_info:
-*
-* This callback is deprecated in favour of
-* &drm_gem_object_funcs.print_info.
-*
-* If driver subclasses struct &drm_gem_object, it can implement this
-* optional hook for printing additional driver specific info.
-*
-* drm_printf_indent() should be used in the callback passing it the
-* indent argument.
-*
-* This callback is called from drm_gem_print_info().
-*/
- void (*gem_print_info)(struct drm_printer *p, unsigned int indent,
- const struct drm_gem_object *obj);
-
/**
* @gem_create_object: constructor for gem objects
*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 21/23] drm/tv200: Use GEM CMA object functions
The tve200 driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Linus Walleij
Acked-by: Emil Velikov
---
drivers/gpu/drm/tve200/tve200_drv.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tve200/tve200_drv.c
b/drivers/gpu/drm/tve200/tve200_drv.c
index 00ba9e5ce1307..c3aa39bd38ecd 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -147,17 +147,7 @@ static struct drm_driver tve200_drm_driver = {
.major = 1,
.minor = 0,
.patchlevel = 0,
- .dumb_create = drm_gem_cma_dumb_create,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
-
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
};
static int tve200_probe(struct platform_device *pdev)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/23] drm/fsl-dcu: Use GEM CMA object functions
The fsl-dcu driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index f15d2e7967a3e..abbc1ddbf27f0 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -141,16 +141,7 @@ static struct drm_driver fsl_dcu_drm_driver = {
.irq_handler= fsl_dcu_drm_irq,
.irq_preinstall = fsl_dcu_irq_uninstall,
.irq_uninstall = fsl_dcu_irq_uninstall,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
- .dumb_create= drm_gem_cma_dumb_create,
+ DRM_GEM_CMA_DRIVER_OPS,
.fops = &fsl_dcu_drm_fops,
.name = "fsl-dcu-drm",
.desc = "Freescale DCU DRM",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/23] drm/imx: Use GEM CMA object functions
The imx driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/imx/imx-drm-core.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 2e38f1a5cf8da..36037b2e65647 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -146,17 +146,7 @@ static const struct drm_ioctl_desc imx_drm_ioctls[] = {
static struct drm_driver imx_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create= drm_gem_cma_dumb_create,
-
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
.ioctls = imx_drm_ioctls,
.num_ioctls = ARRAY_SIZE(imx_drm_ioctls),
.fops = &imx_drm_driver_fops,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/23] drm/ingenic: Use GEM CMA object functions
The ingenic driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Tested-by: Paul Cercueil
Reviewed-by: Paul Cercueil
Acked-by: Emil Velikov
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 55b49a31729bf..16f0740df507c 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -519,18 +519,7 @@ static struct drm_driver ingenic_drm_driver_data = {
.patchlevel = 0,
.fops = &ingenic_drm_fops,
-
- .dumb_create= drm_gem_cma_dumb_create,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
-
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
.irq_handler= ingenic_drm_irq_handler,
};
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 17/23] drm/shmobile: Use GEM CMA object functions
The shmobile driver uses the default implementation for CMA functions.
The DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct
drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index ae9d6b8d3ca87..26a15c214bd3f 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -131,16 +131,7 @@ DEFINE_DRM_GEM_CMA_FOPS(shmob_drm_fops);
static struct drm_driver shmob_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET,
.irq_handler= shmob_drm_irq,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
- .dumb_create= drm_gem_cma_dumb_create,
+ DRM_GEM_CMA_DRIVER_OPS,
.fops = &shmob_drm_fops,
.name = "shmob-drm",
.desc = "Renesas SH Mobile DRM",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 16/23] drm/rcar-du: Use GEM CMA object functions
The rcar-du driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GEM object functions. GEM object functions implement the
rsp operations where possible. Corresponding interfaces in struct drm_driver
are cleared. Prime import now uses drm_gem_cma_prime_import_sg_table_vmap(),
which maps the imported buffer upon import. Mmap operations are performed
by drm_gem_prime_mmap(), which goes through GEM file operations. These
changes have been part of the aspeed driver for some time.
v2:
* update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
Signed-off-by: Thomas Zimmermann
Tested-by: Kieran Bingham
Acked-by: Emil Velikov
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 3e67cf70f0402..f53b0ec710850 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -476,16 +476,7 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
static struct drm_driver rcar_du_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
- .dumb_create= rcar_du_dumb_create,
+ DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(rcar_du_dumb_create),
.fops = &rcar_du_fops,
.name = "rcar-du",
.desc = "Renesas R-Car Display Unit",
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 v.j.du...@gmail.com changed: What|Removed |Added CC||v.j.du...@gmail.com --- Comment #55 from v.j.du...@gmail.com --- Tested on Ubuntu with kernel 5.6.15 - looks better now: amdgpu-pci-0100 Adapter: PCI adapter vddgfx: 1000.00 mV fan1:1200 RPM (min =0 RPM, max = 6000 RPM) edge: +72.0°C (crit = +104000.0°C, hyst = -273.1°C) power1: 117.00 W (cap = 216.00 W) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/connector: notify userspace on hotplug after register complete
On Tue, Jun 02, 2020 at 08:37:31PM -0700, Jeykumar Sankaran wrote: > drm connector notifies userspace on hotplug event prematurely before > late_register and mode_object register completes. This leads to a race > between userspace and kernel on updating the IDR list. So, move the > notification to end of connector register. > > Signed-off-by: Jeykumar Sankaran > Signed-off-by: Steve Cohen Hm on the unregister side we don't have the race, there we remove everything and then send out the uevent. But there the uevent is also generated in a separate step, so I wonder whether we shouldn't do the same for register for symmetry ... Anyway this looks good, nice catch, I'll add cc: stable and merge. -Daniel > --- > drivers/gpu/drm/drm_connector.c | 5 + > drivers/gpu/drm/drm_sysfs.c | 3 --- > 2 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index b1099e1..d877ddc 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > > #include > > @@ -523,6 +524,10 @@ int drm_connector_register(struct drm_connector > *connector) > drm_mode_object_register(connector->dev, &connector->base); > > connector->registration_state = DRM_CONNECTOR_REGISTERED; > + > + /* Let userspace know we have a new connector */ > + drm_sysfs_hotplug_event(connector->dev); > + > goto unlock; > > err_debugfs: > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c > index 939f003..f0336c8 100644 > --- a/drivers/gpu/drm/drm_sysfs.c > +++ b/drivers/gpu/drm/drm_sysfs.c > @@ -291,9 +291,6 @@ int drm_sysfs_connector_add(struct drm_connector > *connector) > return PTR_ERR(connector->kdev); > } > > - /* Let userspace know we have a new connector */ > - drm_sysfs_hotplug_event(dev); > - > if (connector->ddc) > return sysfs_create_link(&connector->kdev->kobj, >&connector->ddc->dev.kobj, "ddc"); > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Set connector type for DSI panels
On Tue, Jun 02, 2020 at 08:12:40PM +0300, Laurent Pinchart wrote:
> None of the DSI panels set the connector_type in their panel_desc
> descriptor. As they are all guaranteed to be DSI panels, that's an easy
> fix, set the connector type to DRM_MODE_CONNECTOR_DSI.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/panel/panel-simple.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index b6ecd1552132..b86b52bfece7 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -4082,6 +4082,7 @@ static const struct panel_desc_dsi auo_b080uan01 = {
> .width = 108,
> .height = 272,
> },
> + .connector_type = DRM_MODE_CONNECTOR_DSI,
> },
> .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_CLOCK_NON_CONTINUOUS,
> .format = MIPI_DSI_FMT_RGB888,
> @@ -4110,6 +4111,7 @@ static const struct panel_desc_dsi boe_tv080wum_nl0 = {
> .width = 107,
> .height = 172,
> },
> + .connector_type = DRM_MODE_CONNECTOR_DSI,
> },
> .flags = MIPI_DSI_MODE_VIDEO |
>MIPI_DSI_MODE_VIDEO_BURST |
> @@ -4140,6 +4142,7 @@ static const struct panel_desc_dsi lg_ld070wx3_sl01 = {
> .width = 94,
> .height = 151,
> },
> + .connector_type = DRM_MODE_CONNECTOR_DSI,
> },
> .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_CLOCK_NON_CONTINUOUS,
> .format = MIPI_DSI_FMT_RGB888,
> @@ -4168,6 +4171,7 @@ static const struct panel_desc_dsi lg_lh500wx1_sd03 = {
> .width = 62,
> .height = 110,
> },
> + .connector_type = DRM_MODE_CONNECTOR_DSI,
> },
> .flags = MIPI_DSI_MODE_VIDEO,
> .format = MIPI_DSI_FMT_RGB888,
> @@ -4196,6 +4200,7 @@ static const struct panel_desc_dsi
> panasonic_vvx10f004b00 = {
> .width = 217,
> .height = 136,
> },
> + .connector_type = DRM_MODE_CONNECTOR_DSI,
> },
> .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
>MIPI_DSI_CLOCK_NON_CONTINUOUS,
> @@ -4225,6 +4230,7 @@ static const struct panel_desc_dsi lg_acx467akm_7 = {
> .width = 62,
> .height = 110,
> },
> + .connector_type = DRM_MODE_CONNECTOR_DSI,
> },
> .flags = 0,
> .format = MIPI_DSI_FMT_RGB888,
> @@ -4254,6 +4260,7 @@ static const struct panel_desc_dsi osd101t2045_53ts = {
> .width = 217,
> .height = 136,
> },
> + .connector_type = DRM_MODE_CONNECTOR_DSI,
> },
> .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
>MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/doc: device hot-unplug for userspace
On Tue, Jun 02, 2020 at 10:00:10AM -0400, Andrey Grodzovsky wrote: > > On 6/1/20 10:32 AM, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > > Set up the expectations on how hot-unplugging a DRM device should look like > > to > > userspace. > > > > Written by Daniel Vetter's request and largely based on his comments in IRC > > and > > from > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&sdata=Mbsx6qBXN9MBnDDJi4shRZobf7tjcClvNUlUCPsiVtw%3D&reserved=0 > > . > > > > A related Wayland protocol change proposal is at > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fwayland%2Fwayland-protocols%2F-%2Fmerge_requests%2F35&data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&sdata=5j%2FNQFW0C1wvdnR%2BC0WgGU0JcNCb8fIYBPXFOmp36Ck%3D&reserved=0 > > > > Signed-off-by: Pekka Paalanen > > Cc: Daniel Vetter > > Cc: Andrey Grodzovsky > > Cc: Dave Airlie > > Cc: Sean Paul > > Cc: Simon Ser > > > > --- > > > > v3: > > - update ENODEV doc (Daniel) > > - clarify existing vs. new mmaps (Andrey) > > - split into KMS and render/cross sections (Andrey, Daniel) > > - open() returns ENXIO (open(2) man page) > > - ioctls may return ENODEV (Andrey, Daniel) > > - new wayland-protocols MR > > > > v2: > > - mmap reads/writes undefined (Daniel) > > - make render ioctl behaviour driver-specific (Daniel) > > - restructure the mmap paragraphs (Daniel) > > - chardev minor notes (Simon) > > - open behaviour (Daniel) > > - DRM leasing behaviour (Daniel) > > - added links > > > > Disclaimer: I am a userspace developer writing for other userspace > > developers. > > I took some liberties in defining what should happen without knowing what is > > actually possible or what existing drivers already implement. > > --- > > Documentation/gpu/drm-uapi.rst | 114 - > > 1 file changed, 113 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > > index 56fec6ed1ad8..db56c681b648 100644 > > --- a/Documentation/gpu/drm-uapi.rst > > +++ b/Documentation/gpu/drm-uapi.rst > > @@ -1,3 +1,5 @@ > > +.. Copyright 2020 DisplayLink (UK) Ltd. > > + > > === > > Userland interfaces > > === > > @@ -162,6 +164,116 @@ other hand, a driver requires shared state between > > clients which is > > visible to user-space and accessible beyond open-file boundaries, they > > cannot support render nodes. > > +Device Hot-Unplug > > += > > + > > +.. note:: > > + The following is the plan. Implementation is not there yet > > + (2020 May). > > + > > +Graphics devices (display and/or render) may be connected via USB (e.g. > > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end > > +user is able to hot-unplug this kind of devices while they are being > > +used, and expects that the very least the machine does not crash. Any > > +damage from hot-unplugging a DRM device needs to be limited as much as > > +possible and userspace must be given the chance to handle it if it wants > > +to. Ideally, unplugging a DRM device still lets a desktop to continue > > +running, but that is going to need explicit support throughout the whole > > +graphics stack: from kernel and userspace drivers, through display > > +servers, via window system protocols, and in applications and libraries. > > + > > +Other scenarios that should lead to the same are: unrecoverable GPU > > +crash, PCI device disappearing off the bus, or forced unbind of a driver > > +from the physical device. > > + > > +In other words, from userspace perspective everything needs to keep on > > +working more or less, until userspace stops using the disappeared DRM > > +device and closes it completely. Userspace will learn of the device > > +disappearance from the device removed uevent, ioctls returning ENODEV > > +(or driver-specific ioctls returning driver-specific things), or open() > > +returning ENXIO. > > + > > +Only after userspace has closed all relevant DRM device and dmabuf file > > +descriptors and removed all mmaps, the DRM driver can tear down its > > +instance for the device that no longer exists. If the same physical > > +device somehow comes back in the mean time, it shall be a new DRM > > +device. > > + > > +Similar to PIDs, chardev minor numbers are not recycled immediately. A > > +new DRM device always picks the next free minor number compared to the > > +previous one allocated, and wraps around when minor numbers are > > +exhausted. > > + > > +The goal raises at least the following requirements for the kernel and > > +drivers. > > + > > +Requirements for KMS UAPI
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
On Tue, Jun 02, 2020 at 08:13:17PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > On Tue, Jun 02, 2020 at 03:12:37PM +0200, Daniel Vetter wrote: > > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote: > > > On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: > > > > On 2020-03-09 20:51, Laurent Pinchart wrote: > > > > > Replace the manual connector implementation based on drm_panel with > > > > > the > > > > > drm_panel_bridge helper. This simplifies the mxsfb driver by removing > > > > > connector-related code, and standardizing all pipeline control > > > > > operations on bridges. > > > > > > > > > > A hack is needed to get hold of the connector, as that's our only > > > > > source > > > > > of bus flags and formats for now. As soon as the bridge API provides > > > > > us > > > > > with that information this can be fixed. > > > > > > > > This seems like a nice simplification. > > > > > > > > I gave this a go applied on today's drm-misc-next using a Colibri iMX7 > > > > (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of > > > > the simple panel driver. I get this when booting: > > > > > > > > [2.976698] [drm] Supports vblank timestamp caching Rev 2 > > > > (21.10.2013). > > > > [2.983526] [ cut here ] > > > > [2.988180] WARNING: CPU: 0 PID: 1 at > > > > drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 > > > > [2.998059] Modules linked in: > > > > [3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > > > 5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29 > > > > [3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree) > > > > [3.016281] [] (unwind_backtrace) from [] > > > > (show_stack+0xb/0xc) > > > > [3.023887] [] (show_stack) from [] > > > > (dump_stack+0x63/0x70) > > > > [3.031144] [] (dump_stack) from [] > > > > (__warn+0x9d/0xb0) > > > > [3.038047] [] (__warn) from [] > > > > (warn_slowpath_fmt+0x6b/0x70) > > > > [3.045564] [] (warn_slowpath_fmt) from [] > > > > (devm_drm_panel_bridge_add+0x25/0x28) > > > > [3.054736] [] (devm_drm_panel_bridge_add) from > > > > [] (mxsfb_probe+0x197/0x2e0) > > > > [3.063559] [] (mxsfb_probe) from [] > > > > (platform_drv_probe+0x2d/0x60) > > > > [3.071598] [] (platform_drv_probe) from [] > > > > (really_probe+0x1dd/0x330) > > > > [3.079897] [] (really_probe) from [] > > > > (driver_probe_device+0x4f/0x154) > > > > [3.088195] [] (driver_probe_device) from [] > > > > (device_driver_attach+0x37/0x44) > > > > [3.097101] [] (device_driver_attach) from [] > > > > (__driver_attach+0x7b/0xec) > > > > [3.105660] [] (__driver_attach) from [] > > > > (bus_for_each_dev+0x3d/0x64) > > > > [3.113870] [] (bus_for_each_dev) from [] > > > > (bus_add_driver+0xef/0x160) > > > > [3.122081] [] (bus_add_driver) from [] > > > > (driver_register+0x35/0x9c) > > > > [3.130119] [] (driver_register) from [] > > > > (do_one_initcall+0x3d/0x1e4) > > > > [3.138333] [] (do_one_initcall) from [] > > > > (kernel_init_freeable+0x1b3/0x1fc) > > > > [3.147069] [] (kernel_init_freeable) from [] > > > > (kernel_init+0x7/0xd0) > > > > [3.155194] [] (kernel_init) from [] > > > > (ret_from_fork+0x11/0x38) > > > > [3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8) > > > > [3.167862] 3fa0: > > > > > > > > [3.176071] 3fc0: > > > > > > > > [3.184278] 3fe0: 0013 > > > > > > > > [3.191029] ---[ end trace b69e1f44de470959 ]--- > > > > [3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19 > > > > > > > > Should we maybe use devm_drm_panel_bridge_add_typed? > > > > > > As Sam reported, this is caused by the panel not setting connector_type. > > > We could use devm_drm_panel_bridge_add_typed(), even if I like the > > > warning as it uncovers the problematic panels and gets them fixed. What > > > would be your preference ? > > > > Adding warnings everywhere is kinda uncool, at least my experience is that > > if there's too much you get warning overload and train people to ignore > > them. > > > > Imo either hide the wwarning for now, or if it's not too much work, review > > all the panel drivers and make sure they set the connector type somewhere. > > All panel drivers but panel-simple set the connector type. For > panel-simple, the type is stored in the panel_desc panel description, > and out of the 123 supported panels, only 48 have a connector type. I've > just sent a patch to fix this for the 7 DSI panels, so only 68 panels to > go :-) This will require trying to find the corresponding datasheets, so > that's a large effort for a single developer. That's why I was hoping a > WARN_ON() could help distributing the work :-) I hear your concern > though, and I'll set a default in this driver for t
