Re: [PATCH v4 1/3] drm/uapi: Add USB connector type
Am 22.01.21 um 08:54 schrieb Thomas Zimmermann: The more I look at it the more I think it should be 'Unknown' here. BTW, can I try this out somehow? I do have an RPi3. Do I need a special disk image? Oh, I saw that wiki url now. I'll check this out. Best regards Thomas break; }; Noralf. Best regards Thomas -Daniel Best regards Thomas Beware, new connector types have in the past resulted in userspace burning Maybe it's become better ... Acked-by: Daniel Vetter /** * struct drm_mode_get_connector - Get connector metadata. -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 ___ 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH 2/3] dma-buf: heaps: Add a WARN_ON should the vmap_cnt go negative
Hi John, Suren,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> We shouldn't vunmap more then we vmap, but if we do, make
> sure we complain loudly.
I was checking the general usage of vunmap in the kernel, and I
couldn't find many instances where we need to WARN_ON for the vunmap
count more than vmap count. Is there a specific need for this in the heaps?
Best,
Sumit.
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Suggested-by: Suren Baghdasaryan
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/cma_heap.c| 1 +
> drivers/dma-buf/heaps/system_heap.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 364fc2f3e499..0c76cbc3fb11 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -232,6 +232,7 @@ static void cma_heap_vunmap(struct dma_buf *dmabuf,
> struct dma_buf_map *map)
> struct cma_heap_buffer *buffer = dmabuf->priv;
>
> mutex_lock(>lock);
> + WARN_ON(buffer->vmap_cnt == 0);
> if (!--buffer->vmap_cnt) {
> vunmap(buffer->vaddr);
> buffer->vaddr = NULL;
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> index 405351aad2a8..2321c91891f6 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -273,6 +273,7 @@ static void system_heap_vunmap(struct dma_buf *dmabuf,
> struct dma_buf_map *map)
> struct system_heap_buffer *buffer = dmabuf->priv;
>
> mutex_lock(>lock);
> + WARN_ON(buffer->vmap_cnt == 0);
> if (!--buffer->vmap_cnt) {
> vunmap(buffer->vaddr);
> buffer->vaddr = NULL;
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] drm/uapi: Add USB connector type
Hi
Am 21.01.21 um 19:07 schrieb Noralf Trønnes:
Den 21.01.2021 11.01, skrev Thomas Zimmermann:
Hi
Am 21.01.21 um 09:27 schrieb Daniel Vetter:
On Thu, Jan 21, 2021 at 8:45 AM Thomas Zimmermann
wrote:
Hi Noralf,
glad to hear from you! Welcome back!
Thanks Thomas!
Am 20.01.21 um 18:42 schrieb Daniel Vetter:
On Wed, Jan 20, 2021 at 6:10 PM Noralf Trønnes
wrote:
Add a connector type for USB connected display panels.
Signed-off-by: Noralf Trønnes
---
I have forgotten to update drm_connector_enum_list which maps type to name.
include/uapi/drm/drm_mode.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fed66a03c7ae..33024cc5d26e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -367,6 +367,7 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_DPI 17
#define DRM_MODE_CONNECTOR_WRITEBACK 18
#define DRM_MODE_CONNECTOR_SPI 19
+#define DRM_MODE_CONNECTOR_USB 20
I would not call it USB. I could imagine that at some point a generic
USB protocol could serve simple displays (i.e. in the sense of USB HID
or data or imaging). (Maybe Thunderbold already counts.) Anyway, USB
should be reserved for this case.
We end up calling those DisplayPort, since that's what's being
transported over thunderbolt or usb-C. So the usb connector would be
called usb-C. I think the reason we don't do fancy connector names is
that adding them is a bit a pain. Plus drm/i915 specifically has some
very quirky connector enumerating that doesn't match much with reality
unfortunately anyway :-/
In the case of the other USB drivers, IIRC we use the connector type
that is at the output (i.e., HDMI in the case of udl). I think we should
do the same here. Or use 'Unknown'.
There are 2 DRM USB drivers and they use:
- udl: DRM_MODE_CONNECTOR_DVII
Mine has plain old VGA. Maybe we should change generally this to Unknown.
- gm12u320: DRM_MODE_CONNECTOR_VGA
gm12u320 is a mini projector so it doesn't actually have a VGA
connector. I have never seen a udl device but I assume it has a DVII
connector?
For display adapters it makes sense to use the connector on the adapter
as the reported connector, but for display panels that don't have any
connector except for the cable that is connected to the hosts USB
connector, why can't it be called a USB connector? That's the connector
the user sees.
It's not the relevant connector for the display output. USB is the bus
system. (Making your argument in terms of discrete GPUs, the connector
would always be PCI then.)
Ofc as Daniel mentions it's a downside that userspace doesn't know about
the connector type, and who knows when it will updated (if I don't do it).
Weston will name it: "UNNAMED-%d"
Mutter: "Unknown%d-%d"
X: "Unknown%d-%d"
Sam and Laurent has discussed adding a PANEL connector type instead of
adding more connector types for panel connectors. I think that would
have been a better choice instead of the SPI connector type that I added
in 2019. But I think PANEL was meant for panels connected to an internal
connector.
Here's my protocol connector types and how it's mapped to DRM:
#define GUD_CONNECTOR_TYPE_PANEL0
#define GUD_CONNECTOR_TYPE_VGA 1
#define GUD_CONNECTOR_TYPE_COMPOSITE2
#define GUD_CONNECTOR_TYPE_SVIDEO 3
#define GUD_CONNECTOR_TYPE_COMPONENT4
#define GUD_CONNECTOR_TYPE_DVI 5
#define GUD_CONNECTOR_TYPE_DISPLAYPORT 6
#define GUD_CONNECTOR_TYPE_HDMI 7
static int gud_gadget_ctrl_get_connector(struct gud_gadget *gdg,
unsigned int index,
struct gud_connector_descriptor_req
*desc)
{
...
gconn = >connectors[index];
switch (gconn->connector->connector_type) {
case DRM_MODE_CONNECTOR_VGA:
desc->connector_type = GUD_CONNECTOR_TYPE_VGA;
break;
case DRM_MODE_CONNECTOR_DVII:
fallthrough;
case DRM_MODE_CONNECTOR_DVID:
fallthrough;
case DRM_MODE_CONNECTOR_DVIA:
desc->connector_type = GUD_CONNECTOR_TYPE_DVI;
break;
case DRM_MODE_CONNECTOR_Composite:
desc->connector_type = GUD_CONNECTOR_TYPE_COMPOSITE;
break;
case DRM_MODE_CONNECTOR_SVIDEO:
desc->connector_type = GUD_CONNECTOR_TYPE_SVIDEO;
break;
case DRM_MODE_CONNECTOR_Component:
desc->connector_type = GUD_CONNECTOR_TYPE_COMPONENT;
break;
case DRM_MODE_CONNECTOR_DisplayPort:
desc->connector_type = GUD_CONNECTOR_TYPE_DISPLAYPORT;
break;
case DRM_MODE_CONNECTOR_HDMIA:
fallthrough;
case DRM_MODE_CONNECTOR_HDMIB:
desc->connector_type = GUD_CONNECTOR_TYPE_HDMI;
Re: linux-next: build warning after merge of the drm tree
Hi Daniel, On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter wrote: > > Hm that has been in drm-intel-gt-next for a few days, is that tree not > in linux-next? It is not. These are the drm branches currently in linux-next: drm-fixes git://git.freedesktop.org/git/drm/drm.git drm-fixes amdgpu-fixesgit://people.freedesktop.org/~agd5f/linux drm-fixes drm-intel-fixes git://anongit.freedesktop.org/drm-intel for-linux-next-fixes drm-misc-fixes git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes drm git://git.freedesktop.org/git/drm/drm.git drm-next amdgpu https://gitlab.freedesktop.org/agd5f/linux drm-next drm-intel git://anongit.freedesktop.org/drm-intel for-linux-next drm-tegra git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next drm-miscgit://anongit.freedesktop.org/drm/drm-misc for-linux-next drm-msm https://gitlab.freedesktop.org/drm/msm.git msm-next imx-drm https://git.pengutronix.de/git/pza/linuximx-drm/next etnaviv https://git.pengutronix.de/git/lst/linuxetnaviv/next -- Cheers, Stephen Rothwell pgpSXc7kK1r3v.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warning after merge of the drm tree
On Fri, Jan 22, 2021 at 1:59 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
> Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
> !COMPILE_TEST [=y]
> Selected by [m]:
> - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
> Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
> !COMPILE_TEST [=y]
> Selected by [m]:
> - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
> Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
> !COMPILE_TEST [=y]
> Selected by [m]:
> - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
>
> Maybe introduced by commit
>
> 4f86975f539d ("drm/i915: Add DEBUG_GEM to the recommended CI config")
Hm that has been in drm-intel-gt-next for a few days, is that tree not
in linux-next?
-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
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #3 from kolAflash (kolafl...@kolahilft.de) --- I searched through my journalctl log. I set up the whole system in May 2020 with Linux-5.6.7. (journalctl has everything back to that date) The bug appeared as following since October and Linux-5.8. So Linux-5.8 was also affected (contradicting my original post). I used the system nearly every day and always use s2ram (never shutting down, only rebooting when needed for updates). So this can be seen statistically. - 2020-10-21 with Linux-5.8.14 (Debian 5.8.0-3, installed after 2020-09-26) - 2020-12-11 with Linux-5.9.11 (Debian 5.9.0-4, installed 2020-12-04) - 2020-12-25 with Linux-5.9.11 - 2021-01-13 with Linux-5.10.4 (Debian 5.10.0-1, installed 2021-01-10) - 2021-01-16 with Linux-5.10.4 - 2021-01-19 with Linux-5.10.4 So the bug didn't appear with Linux <= 5.7. And the bugs frequency increased with Linux-5.10. In parallel I'm still trying to rule out other factors. (BIOS updates, other software changes, ...) Something significant might be, that Debian used GCC-9 for Linux-5.7. And starting with Linux-5.8 GCC-10 was used. -- You may reply to this email to add a comment. 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: [git pull] drm fixes for 5.11-rc5
The pull request you sent on Fri, 22 Jan 2021 10:00:50 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-22 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/36ada25026357c855d5839166f78017509824b77 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [m]:
- DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [m]:
- DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [m]:
- DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
Maybe introduced by commit
4f86975f539d ("drm/i915: Add DEBUG_GEM to the recommended CI config")
--
Cheers,
Stephen Rothwell
pgpEcuByYVK38.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.11-rc5
Hi Linus, Regular fixes pull, nothing too major in here, just some core fixes, one vc4, bunch of i915 and a bunch of amdgpu. Dave. drm-fixes-2021-01-22: drm fixes for 5.11-rc5 core: - atomic: Release state on error - syncobj: Fix use-after-free - ttm: Don't use GFP_TRANSHUGE_LIGTH - vram-helper: Fix memory leak in vmap vc4: - Unify driver naming for PCM i915: - HDCP fixes - PMU wakeref fix - Fix HWSP validity race - Fix DP protocol converter accidental 4:4:4->4:2:0 conversion for RGB amdgpu: - Green Sardine fixes - Vangogh fixes - Renoir fixes - Misc display fixes The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31: Linux 5.11-rc4 (2021-01-17 16:37:05 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-22 for you to fetch changes up to 06ee38dc2aab3b5a09feb74128cf7326a490b788: Merge tag 'amd-drm-fixes-5.11-2021-01-21' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-01-22 09:43:21 +1000) drm fixes for 5.11-rc5 core: - atomic: Release state on error - syncobj: Fix use-after-free - ttm: Don't use GFP_TRANSHUGE_LIGTH - vram-helper: Fix memory leak in vmap vc4: - Unify driver naming for PCM i915: - HDCP fixes - PMU wakeref fix - Fix HWSP validity race - Fix DP protocol converter accidental 4:4:4->4:2:0 conversion for RGB amdgpu: - Green Sardine fixes - Vangogh fixes - Renoir fixes - Misc display fixes Aaron Liu (1): drm/amdgpu: update mmhub mgcg for mmhub_v2_3 Anshuman Gupta (2): drm/i915/hdcp: Update CP property in update_pipe drm/i915/hdcp: Get conn while content_type changed Aric Cyr (1): drm/amd/display: Allow PSTATE chnage when no displays are enabled Bing Guo (1): drm/amd/display: Change function decide_dp_link_settings to avoid infinite looping Chris Wilson (2): drm/i915/gt: Prevent use of engine->wa_ctx after error drm/i915: Check for rq->hwsp validity after acquiring RCU lock Christian König (1): drm/ttm: stop using GFP_TRANSHUGE_LIGHT Daniel Vetter (1): drm/syncobj: Fix use-after-free Dave Airlie (3): Merge tag 'drm-misc-fixes-2021-01-20' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2021-01-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-5.11-2021-01-21' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Huang Rui (1): drm/amdgpu: remove gpu info firmware of green sardine Jake Wang (1): drm/amd/display: Update dram_clock_change_latency for DCN2.1 Jinzhou Su (1): drm/amdgpu: modify GCR_GENERAL_CNTL for Vangogh Nicholas Kazlauskas (1): drm/amd/display: Use hardware sequencer functions for PG control Nicolas Saenz Julienne (1): drm/vc4: Unify PCM card's driver_name Pan Bian (1): drm/atomic: put state on error path Prike Liang (1): drm/amdgpu/pm: no need GPU status set since mmnbif_gpu_BIF_DOORBELL_FENCE_CNTL added in FSDL Sung Lee (1): drm/amd/display: DCN2X Find Secondary Pipe properly in MPO + ODM Case Thomas Zimmermann (1): drm/vram-helper: Reuse existing page mappings in vmap Tvrtko Ursulin (1): drm/i915/pmu: Don't grab wakeref when enabling events Ville Syrjälä (1): drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4 Vladimir Stempen (1): drm/amd/display: Fixed corruptions on HPDRX link loss restore drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 - drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 4 +- drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c| 84 -- .../amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c | 6 +- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 7 +- .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 18 +++-- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 9 ++- .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 7 +- .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +- drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c| 2 +- drivers/gpu/drm/drm_atomic_helper.c| 2 +- drivers/gpu/drm/drm_gem_vram_helper.c | 14 +++- drivers/gpu/drm/drm_syncobj.c | 8 ++- drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- drivers/gpu/drm/i915/display/intel_dp.c| 9 +-- drivers/gpu/drm/i915/display/intel_dp.h| 3 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 9 +++ drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 9 +-- drivers/gpu/drm/i915/gt/intel_lrc.c| 3 + drivers/gpu/drm/i915/gt/intel_timeline.c | 10 ++- drivers/gpu/drm/i915/i915_pmu.c| 30 drivers/gpu/drm/i915/i915_request.h| 37 -- drivers/gpu/drm/ttm/ttm_pool.c
Re: [PATCH v2 3/5] drm/mediatek: Change disp/ddp term to mutex in mtk mutex driver
Matthias Brugger 於 2021年1月21日 週四 下午4:19寫道：
>
> On Thu, Jan 21, 2021 at 07:46:44AM +0800, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > Matthias Brugger 於 2021年1月21日 週四 上午2:27寫道：
> > >
> > > On Thu, Jan 07, 2021 at 07:17:27AM +0800, Chun-Kuang Hu wrote:
> > > > From: CK Hu
> > > >
> > > > mtk mutex is used by both drm and mdp driver, so change disp/ddp term to
> > > > mutex to show that it's a common driver for drm and mdp.
> > > >
> > > > Signed-off-by: CK Hu
> > > > Signed-off-by: Chun-Kuang Hu
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 30 +--
> > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> > > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
> > > > drivers/gpu/drm/mediatek/mtk_mutex.c| 305
> > > > drivers/gpu/drm/mediatek/mtk_mutex.h| 26 +-
> > > > 5 files changed, 182 insertions(+), 183 deletions(-)
> > > >
> > > [...]
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_mutex.c
> > > > b/drivers/gpu/drm/mediatek/mtk_mutex.c
> > > > index 1c8a253f4788..98a060bf225d 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_mutex.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_mutex.c
> > > [...]
> > > >
> > > > -static const struct of_device_id ddp_driver_dt_match[] = {
> > > > +static const struct of_device_id mutex_driver_dt_match[] = {
> > > > { .compatible = "mediatek,mt2701-disp-mutex",
> > > > - .data = _ddp_driver_data},
> > > > + .data = _mutex_driver_data},
> > > > { .compatible = "mediatek,mt2712-disp-mutex",
> > > > - .data = _ddp_driver_data},
> > > > + .data = _mutex_driver_data},
> > > > { .compatible = "mediatek,mt8167-disp-mutex",
> > > > - .data = _ddp_driver_data},
> > > > + .data = _mutex_driver_data},
> > > > { .compatible = "mediatek,mt8173-disp-mutex",
> > > > - .data = _ddp_driver_data},
> > > > + .data = _mutex_driver_data},
> > > > {},
> > > > };
> > > > -MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
> > > > +MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
> > >
> > > I think it would make sense in a follow-up patch to update the binding
> > > to use "mediatek,mt2701-mutex" to reflect that mutex is used for drm and
> > > mdp driver. Make sense?
> >
> > Yes, it make sense. I would try to update the binding, but I wonder
> > device tree should be backward compatible? Let's discuss in that
> > follow-up patches.
> >
>
> From my understanding, we will need to keep the of_device_id entries for
> the old binding in the driver (so that old DTs still work) while we
> should enforce the new binding. I'm not sure if the yaml has a option
> for out-of-date compatibles.
OK, I would do it so and remove out-f-date compatibles in yaml at
first to see any feedback.
Regards,
Chun-Kuang.
>
> Regards,
> Matthias
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/11] drm/atomic: Pass the full state to planes atomic disable and update
Hi Maxime,
Thank you for the patch.
On Thu, Jan 21, 2021 at 05:35:34PM +0100, Maxime Ripard wrote:
> The current atomic helpers have either their object state being passed as
> an argument or the full atomic state.
>
> The former is the pattern that was done at first, before switching to the
> latter for new hooks or when it was needed.
>
> Let's convert the remaining helpers to provide a consistent interface,
> this time with the planes atomic_update and atomic_disable.
>
> The conversion was done using the coccinelle script below, built tested on
> all the drivers.
>
> @@
> identifier plane, plane_state;
> symbol state;
> @@
>
> struct drm_plane_helper_funcs {
> ...
> void (*atomic_update)(struct drm_plane *plane,
> - struct drm_plane_state *plane_state);
> + struct drm_atomic_state *state);
> ...
> }
>
> @@
> identifier plane, plane_state;
> symbol state;
> @@
>
> struct drm_plane_helper_funcs {
> ...
> void (*atomic_disable)(struct drm_plane *plane,
> -struct drm_plane_state *plane_state);
> +struct drm_atomic_state *state);
> ...
> }
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> (
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_update = func,
> ...,
> };
> |
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_disable = func,
> ...,
> };
> )
>
> @@
> struct drm_plane_helper_funcs *FUNCS;
> identifier f;
> identifier crtc_state;
> identifier plane, plane_state, state;
> expression e;
> @@
>
> f(struct drm_crtc_state *crtc_state)
> {
> ...
> struct drm_atomic_state *state = e;
> <+...
> (
> - FUNCS->atomic_disable(plane, plane_state)
> + FUNCS->atomic_disable(plane, state)
> |
> - FUNCS->atomic_update(plane, plane_state)
> + FUNCS->atomic_update(plane, state)
> )
> ...+>
> }
>
> @@
> identifier plane_atomic_func.func;
> identifier plane;
> symbol state;
> @@
>
> func(struct drm_plane *plane,
> -struct drm_plane_state *state)
> +struct drm_plane_state *old_plane_state)
> {
> <...
> - state
> + old_plane_state
> ...>
> }
>
> @ ignores_old_state @
> identifier plane_atomic_func.func;
> identifier plane, old_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *old_state)
> {
> ... when != old_state
> }
>
> @ adds_old_state depends on plane_atomic_func && !ignores_old_state @
> identifier plane_atomic_func.func;
> identifier plane, plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_plane_state *plane_state)
> {
> + struct drm_plane_state *plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> ...
> }
>
> @ depends on plane_atomic_func @
> identifier plane_atomic_func.func;
> identifier plane, plane_state;
> @@
>
> func(struct drm_plane *plane,
> - struct drm_plane_state *plane_state
> + struct drm_atomic_state *state
> )
> { ... }
>
> @ include depends on adds_old_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_old_state @
> @@
>
> + #include
> #include
>
> @@
> identifier plane_atomic_func.func;
> identifier plane, state;
> identifier plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state) {
> ...
> struct drm_plane_state *plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> <+...
> - plane_state->state
> + state
> ...+>
> }
>
> Signed-off-by: Maxime Ripard
>
> ---
>
> Changes from v1:
> - Reintroduce the old_plane_state check in zynqmp_disp_crtc_atomic_disable
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 8
> drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 --
> drivers/gpu/drm/omapdrm/omap_plane.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +++-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +++-
> drivers/gpu/drm/tidss/tidss_plane.c | 4 ++--
> drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_disp.c| 15 ---
> include/drm/drm_modeset_helper_vtables.h | 4 ++--
For these,
Reviewed-by: Laurent Pinchart
> 58 files changed, 211 insertions(+), 123 deletions(-)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/13] livepatch: move klp_find_object_module to module.c
On Thu, Jan 21, 2021 at 08:49:50AM +0100, Christoph Hellwig wrote:
> @@ -820,14 +796,25 @@ static int klp_init_object(struct klp_patch *patch,
> struct klp_object *obj)
> const char *name;
>
> obj->patched = false;
> - obj->mod = NULL;
Why was this line removed?
> if (klp_is_module(obj)) {
> if (strlen(obj->name) >= MODULE_NAME_LEN)
> return -EINVAL;
> name = obj->name;
>
> - klp_find_object_module(obj);
> + /*
> + * We do not want to block removal of patched modules and
> + * therefore we do not take a reference here. The patches are
> + * removed by klp_module_going() instead.
> + *
> + * Do not mess work of klp_module_coming() and
> + * klp_module_going(). Note that the patch might still be
> + * needed before klp_module_going() is called. Module functions
> + * can be called even in the GOING state until mod->exit()
> + * finishes. This is especially important for patches that
> + * modify semantic of the functions.
> + */
> + obj->mod = find_klp_module(obj->name);
These comments don't make sense in this context, they should be kept
with the code in find_klp_module().
--
Josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] RFC: dma-fence: Document recoverable page fault implications
Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that. While the discussion is still fresh I figured good time to try and document the conclusions a bit. References: https://lore.kernel.org/dri-devel/20210107030127.20393-1-felix.kuehl...@amd.com/ Cc: Maarten Lankhorst Cc: Thomas Hellström Cc: "Christian König" Cc: Jerome Glisse Cc: Felix Kuehling Signed-off-by: Daniel Vetter Cc: Sumit Semwal Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org -- I'll be away next week, but figured I'll type this up quickly for some comments and to check whether I got this all roughly right. Critique very much wanted on this, so that we can make sure hw which can't preempt (with pagefaults pending) like gfx10 has a clear path to support page faults in upstream. So anything I missed, got wrong or like that would be good. -Daniel --- Documentation/driver-api/dma-buf.rst | 66 1 file changed, 66 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a2133d69872c..e924c1e4f7a3 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -257,3 +257,69 @@ fences in the kernel. This means: userspace is allowed to use userspace fencing or long running compute workloads. This also means no implicit fencing for shared buffers in these cases. + +Recoverable Hardware Page Faults Implications +~ + +Modern hardware supports recoverable page faults, which has a lot of +implications for DMA fences. + +First, a pending page fault obviously holds up the work that's running on the +accelerator and a memory allocation is usually required to resolve the fault. +But memory allocations are not allowed to gate completion of DMA fences, which +means any workload using recoverable page faults cannot use DMA fences for +synchronization. Synchronization fences controlled by userspace must be used +instead. + +On GPUs this poses a problem, because current desktop compositor protocols on +Linus rely on DMA fences, which means without an entirely new userspace stack +built on top of userspace fences, they cannot benefit from recoverable page +faults. The exception is when page faults are only used as migration hints and +never to on-demand fill a memory request. For now this means recoverable page +faults on GPUs are limited to pure compute workloads. + +Furthermore GPUs usually have shared resources between the 3D rendering and +compute side, like compute units or command submission engines. If both a 3D +job with a DMA fence and a compute workload using recoverable page faults are +pending they could deadlock: + +- The 3D workload might need to wait for the compute job to finish and release + hardware resources first. + +- The compute workload might be stuck in a page fault, because the memory + allocation is waiting for the DMA fence of the 3D workload to complete. + +There are a few ways to prevent this problem: + +- Compute workloads can always be preempted, even when a page fault is pending + and not yet repaired. Not all hardware supports this. + +- DMA fence workloads and workloads which need page fault handling have + independent hardware resources to guarantee forward progress. This could be + achieved through e.g. through dedicated engines and minimal compute unit + reservations for DMA fence workloads. + +- The reservation approach could be further refined by only reserving the + hardware resources for DMA fence workloads when they are in-flight. This must + cover the time from when the DMA fence is visible to other threads up to + moment when fence is completed through dma_fence_signal(). + +- As a last resort, if the hardware provides no useful reservation mechanics, + all workloads must be flushed from the GPU when switching between jobs + requiring DMA fences or jobs requiring page fault handling: This means all DMA + fences must complete before a compute job with page fault handling can be + inserted into the scheduler queue. And vice versa, before a DMA fence can be + made visible anywhere in the system, all compute workloads must be preempted + to guarantee all pending GPU page faults are flushed. + +Note that workloads that run on independent hardware like copy engines or other +GPUs do not have any impact. This allows us to keep using DMA fences internally +in the kernel even for resolving hardware page faults, e.g. by using copy +engines to clear or copy memory needed to resolve the page fault. + +In some ways this page fault problem is a special case of the `Infinite DMA +Fences` discussions: Infinite fences from compute workloads are allowed to +depend on DMA fences, but not the other way around. And not even the page fault +problem is new, because some other CPU thread in userspace might +hit a page fault which holds up a userspace fence -
Re: [PATCH v6 00/16] Fix several bad kernel-doc markups
On Thu, 14 Jan 2021 09:04:36 +0100 Mauro Carvalho Chehab wrote: > 1) 10 remaining fixup patches from the series I sent back on Dec, 1st: > >parport: fix a kernel-doc markup >rapidio: fix kernel-doc a markup >fs: fix kernel-doc markups >pstore/zone: fix a kernel-doc markup >firmware: stratix10-svc: fix kernel-doc markups >connector: fix a kernel-doc markup >lib/crc7: fix a kernel-doc markup >memblock: fix kernel-doc markups >w1: fix a kernel-doc markup >selftests: kselftest_harness.h: partially fix kernel-doc markups A week later none of these have shown up in linux-next, so I went ahead and applied the set. Thanks, jon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change
On 2021-01-19 10:50 a.m., Aurabindo Pillai wrote:
[Why]
A seamless transition between modes can be performed if the new incoming
mode has the same timing parameters as the optimized mode on a display with a
variable vtotal min/max.
Smooth video playback usecases can be enabled with this seamless transition by
switching to a new mode which has a refresh rate matching the video.
[How]
Skip full modeset if userspace requested a compatible freesync mode which only
differs in the front porch timing from the current mode.
Signed-off-by: Aurabindo Pillai
Acked-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 233 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
2 files changed, 198 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index aaef2fb528fd..d66494cdd8c8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -213,6 +213,9 @@ static bool amdgpu_dm_psr_disable_all(struct
amdgpu_display_manager *dm);
static const struct drm_format_info *
amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
+static bool
+is_timing_unchanged_for_freesync(struct drm_crtc_state *old_crtc_state,
+struct drm_crtc_state *new_crtc_state);
/*
* dm_vblank_get_counter
*
@@ -4940,7 +4943,8 @@ static void fill_stream_properties_from_drm_display_mode(
const struct drm_connector *connector,
const struct drm_connector_state *connector_state,
const struct dc_stream_state *old_stream,
- int requested_bpc)
+ int requested_bpc,
+ bool is_in_modeset)
{
struct dc_crtc_timing *timing_out = >timing;
const struct drm_display_info *info = >display_info;
@@ -4995,19 +4999,28 @@ static void
fill_stream_properties_from_drm_display_mode(
timing_out->hdmi_vic = hv_frame.vic;
}
- timing_out->h_addressable = mode_in->crtc_hdisplay;
- timing_out->h_total = mode_in->crtc_htotal;
- timing_out->h_sync_width =
- mode_in->crtc_hsync_end - mode_in->crtc_hsync_start;
- timing_out->h_front_porch =
- mode_in->crtc_hsync_start - mode_in->crtc_hdisplay;
- timing_out->v_total = mode_in->crtc_vtotal;
- timing_out->v_addressable = mode_in->crtc_vdisplay;
- timing_out->v_front_porch =
- mode_in->crtc_vsync_start - mode_in->crtc_vdisplay;
- timing_out->v_sync_width =
- mode_in->crtc_vsync_end - mode_in->crtc_vsync_start;
- timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+ if (is_in_modeset) {
+ timing_out->h_addressable = mode_in->hdisplay;
+ timing_out->h_total = mode_in->htotal;
+ timing_out->h_sync_width = mode_in->hsync_end -
mode_in->hsync_start;
+ timing_out->h_front_porch = mode_in->hsync_start -
mode_in->hdisplay;
+ timing_out->v_total = mode_in->vtotal;
+ timing_out->v_addressable = mode_in->vdisplay;
+ timing_out->v_front_porch = mode_in->vsync_start -
mode_in->vdisplay;
+ timing_out->v_sync_width = mode_in->vsync_end -
mode_in->vsync_start;
+ timing_out->pix_clk_100hz = mode_in->clock * 10;
+ } else {
+ timing_out->h_addressable = mode_in->crtc_hdisplay;
+ timing_out->h_total = mode_in->crtc_htotal;
+ timing_out->h_sync_width = mode_in->crtc_hsync_end -
mode_in->crtc_hsync_start;
+ timing_out->h_front_porch = mode_in->crtc_hsync_start -
mode_in->crtc_hdisplay;
+ timing_out->v_total = mode_in->crtc_vtotal;
+ timing_out->v_addressable = mode_in->crtc_vdisplay;
+ timing_out->v_front_porch = mode_in->crtc_vsync_start -
mode_in->crtc_vdisplay;
+ timing_out->v_sync_width = mode_in->crtc_vsync_end -
mode_in->crtc_vsync_start;
+ timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+ }
+
Not sure if I commented on this last time but I don't really understand
what this is_in_modeset logic is supposed to be doing here.
We should be modifying crtc_vsync_* for the generated modes, no? Not
just the vsync_* parameters.
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
stream->output_color_space = get_output_color_space(timing_out);
@@ -5227,6 +5240,33 @@ get_highest_refresh_rate_mode(struct amdgpu_dm_connector
*aconnector,
return m_pref;
}
+static bool is_freesync_video_mode(struct drm_display_mode *mode,
+ struct amdgpu_dm_connector *aconnector)
+{
+ struct drm_display_mode *high_mode;
+ int timing_diff;
+
+ high_mode = get_highest_refresh_rate_mode(aconnector, false);
+ if (!high_mode || !mode)
+ return false;
+
+
[PATCH] drm/i915/dp: Don't use DPCD backlights that need PWM enable/disable
We haven't yet implemented support for backlights that need to be
enabled/disabled via PWM instead of AUX, which means we'll break things if
we enable DPCD backlight control on these machines. Luckily though since
most of these machines work fine just using the plain PWM backlight
controls anyway, there shouldn't be any issue with just leaving DPCD
backlight controls disabled in such situations.
This should fix the issues with PWM being left on that were being observed
on fi-bdw-samus.
Signed-off-by: Lyude Paul
Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only
SDR for now)")
Testcase: igt/gem_exec_suspend/basic-s0 # fi-bdw-samus
Cc: Lyude Paul
Cc: Jani Nikula
Cc: "Ville Syrjälä"
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 31a478f63d52..651884390137 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -586,9 +586,14 @@ intel_dp_aux_supports_vesa_backlight(struct
intel_connector *connector)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
/* Check the eDP Display control capabilities registers to determine if
-* the panel can support backlight control over the aux channel
+* the panel can support backlight control over the aux channel.
+*
+* TODO: We currently only support AUX only backlight configurations,
not backlights which
+* require a mix of PWM and AUX controls to work. In the mean time,
these machines typically
+* work just fine using normal PWM controls anyway.
*/
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
+ (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
return true;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/11] drm/todo: Remove the drm_atomic_state todo item
On Thu, Jan 21, 2021 at 5:36 PM Maxime Ripard wrote: > > Only planes' prepare_fb and cleanup_fb, and encoders' atomic_check and > atomic_mode_set hooks remain with an object state and not the global > drm_atomic_state. > > prepare_fb and cleanup_fb operate by design on a given state and > depending on the calling site can operate on either the old or new > state, so it doesn't really make much sense to convert them. > > The encoders' atomic_check and atomic_mode_set operate on the CRTC and > connector state connected to them since encoders don't have a state of > their own. Without those state pointers, we would need to get the CRTC > through the drm_connector_state crtc pointer. > > However, in order to get the drm_connector_state pointer, we would need > to get the connector itself and while usually we have a single connector > connected to the encoder, we can't really get it from the encoder at > the moment since it could be behind any number of bridges. > > While this could be addressed by (for example) listing all the > connectors and finding the one that has the encoder as its source, it > feels like an unnecessary rework for something that is slowly getting > replaced by bridges. > > Since all the users that matter have been converted, let's remove the > TODO item. > > Signed-off-by: Maxime Ripard Acked-by: Daniel Vetter > > --- > > Changes from v1: > - New patch > --- > Documentation/gpu/todo.rst | 46 -- > 1 file changed, 46 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 009d8e6c7e3c..609794108f5a 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -440,52 +440,6 @@ Contact: Emil Velikov, respective driver maintainers > > Level: Intermediate > > -Plumb drm_atomic_state all over > > - > -Currently various atomic functions take just a single or a handful of > -object states (eg. plane state). While that single object state can > -suffice for some simple cases, we often have to dig out additional > -object states for dealing with various dependencies between the individual > -objects or the hardware they represent. The process of digging out the > -additional states is rather non-intuitive and error prone. > - > -To fix that most functions should rather take the overall > -drm_atomic_state as one of their parameters. The other parameters > -would generally be the object(s) we mainly want to interact with. > - > -For example, instead of > - > -.. code-block:: c > - > - int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state > *state); > - > -we would have something like > - > -.. code-block:: c > - > - int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state > *state); > - > -The implementation can then trivially gain access to any required object > -state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(), > -drm_atomic_get_old_plane_state(), and their equivalents for > -other object types. > - > -Additionally many drivers currently access the object->state pointer > -directly in their commit functions. That is not going to work if we > -eg. want to allow deeper commit pipelines as those pointers could > -then point to the states corresponding to a future commit instead of > -the current commit we're trying to process. Also non-blocking commits > -execute locklessly so there are serious concerns with dereferencing > -the object->state pointers without holding the locks that protect them. > -Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(), > -etc. avoids these problems as well since they relate to a specific > -commit via the passed in drm_atomic_state. > - > -Contact: Ville Syrjälä, Daniel Vetter > - > -Level: Intermediate > - > Use struct dma_buf_map throughout codebase > -- > > -- > 2.29.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 v4 1/3] drm/uapi: Add USB connector type
Den 21.01.2021 11.01, skrev Thomas Zimmermann:
> Hi
>
> Am 21.01.21 um 09:27 schrieb Daniel Vetter:
>> On Thu, Jan 21, 2021 at 8:45 AM Thomas Zimmermann
>> wrote:
>>>
>>> Hi Noralf,
>>>
>>> glad to hear from you! Welcome back!
Thanks Thomas!
>>>
>>> Am 20.01.21 um 18:42 schrieb Daniel Vetter:
On Wed, Jan 20, 2021 at 6:10 PM Noralf Trønnes
wrote:
>
> Add a connector type for USB connected display panels.
>
> Signed-off-by: Noralf Trønnes
> ---
I have forgotten to update drm_connector_enum_list which maps type to name.
> include/uapi/drm/drm_mode.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index fed66a03c7ae..33024cc5d26e 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -367,6 +367,7 @@ enum drm_mode_subconnector {
> #define DRM_MODE_CONNECTOR_DPI 17
> #define DRM_MODE_CONNECTOR_WRITEBACK 18
> #define DRM_MODE_CONNECTOR_SPI 19
> +#define DRM_MODE_CONNECTOR_USB 20
>>>
>>> I would not call it USB. I could imagine that at some point a generic
>>> USB protocol could serve simple displays (i.e. in the sense of USB HID
>>> or data or imaging). (Maybe Thunderbold already counts.) Anyway, USB
>>> should be reserved for this case.
>>
>> We end up calling those DisplayPort, since that's what's being
>> transported over thunderbolt or usb-C. So the usb connector would be
>> called usb-C. I think the reason we don't do fancy connector names is
>> that adding them is a bit a pain. Plus drm/i915 specifically has some
>> very quirky connector enumerating that doesn't match much with reality
>> unfortunately anyway :-/
>
> In the case of the other USB drivers, IIRC we use the connector type
> that is at the output (i.e., HDMI in the case of udl). I think we should
> do the same here. Or use 'Unknown'.
>
There are 2 DRM USB drivers and they use:
- udl: DRM_MODE_CONNECTOR_DVII
- gm12u320: DRM_MODE_CONNECTOR_VGA
gm12u320 is a mini projector so it doesn't actually have a VGA
connector. I have never seen a udl device but I assume it has a DVII
connector?
For display adapters it makes sense to use the connector on the adapter
as the reported connector, but for display panels that don't have any
connector except for the cable that is connected to the hosts USB
connector, why can't it be called a USB connector? That's the connector
the user sees.
Ofc as Daniel mentions it's a downside that userspace doesn't know about
the connector type, and who knows when it will updated (if I don't do it).
Weston will name it: "UNNAMED-%d"
Mutter: "Unknown%d-%d"
X: "Unknown%d-%d"
Sam and Laurent has discussed adding a PANEL connector type instead of
adding more connector types for panel connectors. I think that would
have been a better choice instead of the SPI connector type that I added
in 2019. But I think PANEL was meant for panels connected to an internal
connector.
Here's my protocol connector types and how it's mapped to DRM:
#define GUD_CONNECTOR_TYPE_PANEL0
#define GUD_CONNECTOR_TYPE_VGA 1
#define GUD_CONNECTOR_TYPE_COMPOSITE2
#define GUD_CONNECTOR_TYPE_SVIDEO 3
#define GUD_CONNECTOR_TYPE_COMPONENT4
#define GUD_CONNECTOR_TYPE_DVI 5
#define GUD_CONNECTOR_TYPE_DISPLAYPORT 6
#define GUD_CONNECTOR_TYPE_HDMI 7
static int gud_gadget_ctrl_get_connector(struct gud_gadget *gdg,
unsigned int index,
struct gud_connector_descriptor_req
*desc)
{
...
gconn = >connectors[index];
switch (gconn->connector->connector_type) {
case DRM_MODE_CONNECTOR_VGA:
desc->connector_type = GUD_CONNECTOR_TYPE_VGA;
break;
case DRM_MODE_CONNECTOR_DVII:
fallthrough;
case DRM_MODE_CONNECTOR_DVID:
fallthrough;
case DRM_MODE_CONNECTOR_DVIA:
desc->connector_type = GUD_CONNECTOR_TYPE_DVI;
break;
case DRM_MODE_CONNECTOR_Composite:
desc->connector_type = GUD_CONNECTOR_TYPE_COMPOSITE;
break;
case DRM_MODE_CONNECTOR_SVIDEO:
desc->connector_type = GUD_CONNECTOR_TYPE_SVIDEO;
break;
case DRM_MODE_CONNECTOR_Component:
desc->connector_type = GUD_CONNECTOR_TYPE_COMPONENT;
break;
case DRM_MODE_CONNECTOR_DisplayPort:
desc->connector_type = GUD_CONNECTOR_TYPE_DISPLAYPORT;
break;
case DRM_MODE_CONNECTOR_HDMIA:
fallthrough;
case DRM_MODE_CONNECTOR_HDMIB:
desc->connector_type = GUD_CONNECTOR_TYPE_HDMI;
break;
default:
desc->connector_type = GUD_CONNECTOR_TYPE_PANEL;
break;
};
int
Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type
On 1/21/21 4:40 PM, Steven Price wrote:
On 21/01/2021 12:22, Carsten Haitzler wrote:
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
Yup. typo not spotted by me. Thanks. Also - i spotted an accidental
whitespace change along the way so can fix both in a new patch.
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
This seems like an underlying bug/lack of clear documentation for the
underlying find_*_bit() functions. dp_for_each_set_bit() tries to do the
right thing:
Correct. This was a general problem I spotted - the bit funcs were
written to want a unsigned long but were being used on u32's by just
casting the ptr to the type and this did indeed have technical issues.
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), ((unsigned long *)&(mask)),
sizeof(mask) * 8)
i.e. passing the actual size of type. However because of the case to
unsigned long (and subsequent accesses using that type) the compiler is
free to make accesses beyond the size of the variable (and indeed this
is completely broken on big-endian). The implementation actually
requires that the bitmap is really an array of unsigned long - no other
type will work.
Precisely. So a bit loose. The bit funcs are used widely enough, so
just fixing this code here to pass in the expected type is probably
the least disruptive fix.
So I think the fix should also include fixing the dp_for_each_set_bit()
macro - the cast is bogus as it stands.
Yup. Removing the cast does indeed find more badness that needs
fixing. I'll do an updated patch with this.
Doing that I also get warnings on komeda_pipeline::avail_comps and
komeda_pipeline::supported_inputs - although I note there are other
bitmasks mentioned.
The other option is to fix dp_for_each_set_bit() itself using a
little hack:
- for_each_set_bit((bit), ((unsigned long *)&(mask)),
sizeof(mask) * 8)
+ for_each_set_bit((bit), (&((unsigned long){mask})),
sizeof(mask) * 8)
With that I don't think you need any other change as the mask is
actually
in a new unsigned long on the stack.
That would be wonderful if it worked :). Unfortunately your above
proposal leads to:
./drivers/gpu/drm/arm/display/komeda/../include/malidp_utils.h:17:27:
error: lvalue required as unary ‘&’ operand
17 | for_each_set_bit((bit), (&((unsigned long)(mask))),
sizeof(mask) * 8)
| ^
Looks like you didn't notice the subtle change above. My change uses
braces ('{}') around 'mask' - I believe it's a GCC extension ("compound
literals") and it creates an lvalue so you can then take the address of
it...
Oh... ewww. I did indeed skip the {}'s and just looked at them as ()'s
:) I'm not so hot on using such extensions if it can be avoided. :) I
just removed the cast and fixed up all the usages. Patch will come with
this.
I'm not sure if it's a good approach to the problem or not. The
alternative is to fix up various places to use unsigned longs so you can
use the unwrapped for_each_set_bit().
Steve
./include/linux/bitops.h:34:30: note: in definition of macro
‘for_each_set_bit’
34 | (bit) = find_next_bit((addr), (size), (bit) + 1))
| ^~~~
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c:1243:2:
note: in expansion of macro ‘dp_for_each_set_bit’
1243 | dp_for_each_set_bit(id, disabling_comps) {
| ^~~
Basically can't take address of an "unnamed local var". :| That is with:
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), (&((unsigned long)(mask))),
sizeof(mask) * 8)
I could try have the dp_for_each macro create new local vars on its
own a bit like:
#define dp_for_each_set_bit(bit, mask) \
unsigned long __local_mask = mask; \
for_each_set_bit((bit), (&__local_mask), sizeof(mask) * 8)
But we all know where this leads... (multiple bad places with adding
warnings and potential and pitfalls that then lead with ever more
invasive changes to address like if code in future might do if (x)
dp_for_each...). I'd prefer to be able to write code more loosely
(pass in any time and it just does the right thing), but trying to
balance this with least disruption and ugliness.
Steve
Signed-off-by: Carsten Haitzler
---
.../drm/arm/display/komeda/komeda_pipeline_state.c | 14
--
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index e8b1e15312d8..f7dddb9f015d 100644
---
[PATCH v2] drm/i915/hdcp: Disable the QSES check for HDCP 1.4 over MST
From: Sean Paul
The HDCP 1.4 spec does not require the QUERY_STREAM_ENCRYPTION_STATUS
check, it was always a nice-to-have. After deploying this across various
devices, we've determined that some MST bridge chips do not properly
support this call for HDCP 1.4 (namely Synaptics and Realtek).
I had considered creating a quirk for this, but I think it's more
prudent to just disable the check entirely since I don't have an idea
how widespread support is.
Acked-by: Daniel Vetter
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210106223909.34476-1-s...@poorly.run
#v1
Changes in v2:
-Rebased on -tip
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index f372e25edab4..4dba5bb15af5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -722,16 +722,6 @@ static bool intel_dp_mst_get_qses_status(struct
intel_digital_port *dig_port,
return reply.auth_completed && reply.encryption_enabled;
}
-static
-bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
- struct intel_connector *connector)
-{
- if (!intel_dp_hdcp_check_link(dig_port, connector))
- return false;
-
- return intel_dp_mst_get_qses_status(dig_port, connector);
-}
-
static int
intel_dp_mst_hdcp2_stream_encryption(struct intel_connector *connector,
bool enable)
@@ -805,7 +795,7 @@ static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim
= {
.read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
.toggle_signalling = intel_dp_hdcp_toggle_signalling,
.stream_encryption = intel_dp_mst_hdcp_stream_encryption,
- .check_link = intel_dp_mst_hdcp_check_link,
+ .check_link = intel_dp_hdcp_check_link,
.hdcp_capable = intel_dp_hdcp_capable,
.write_2_2_msg = intel_dp_hdcp2_write_msg,
.read_2_2_msg = intel_dp_hdcp2_read_msg,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2021-01-21: drm/i915 fixes for v5.11-rc5: - HDCP fixes - PMU wakeref fix - Fix HWSP validity race - Fix DP protocol converter accidental 4:4:4->4:2:0 conversion for RGB BR, Jani. The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31: Linux 5.11-rc4 (2021-01-17 16:37:05 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-01-21 for you to fetch changes up to 1c4995b0a576d24bb7ead991fb037c8b47ab6e32: drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4 (2021-01-19 10:44:06 +0200) drm/i915 fixes for v5.11-rc5: - HDCP fixes - PMU wakeref fix - Fix HWSP validity race - Fix DP protocol converter accidental 4:4:4->4:2:0 conversion for RGB Anshuman Gupta (2): drm/i915/hdcp: Update CP property in update_pipe drm/i915/hdcp: Get conn while content_type changed Chris Wilson (2): drm/i915/gt: Prevent use of engine->wa_ctx after error drm/i915: Check for rq->hwsp validity after acquiring RCU lock Tvrtko Ursulin (1): drm/i915/pmu: Don't grab wakeref when enabling events Ville Syrjälä (1): drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4 drivers/gpu/drm/i915/display/intel_ddi.c| 2 +- drivers/gpu/drm/i915/display/intel_dp.c | 9 +++ drivers/gpu/drm/i915/display/intel_dp.h | 3 ++- drivers/gpu/drm/i915/display/intel_hdcp.c | 9 +++ drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 9 ++- drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++ drivers/gpu/drm/i915/gt/intel_timeline.c| 10 drivers/gpu/drm/i915/i915_pmu.c | 30 --- drivers/gpu/drm/i915/i915_request.h | 37 + 9 files changed, 74 insertions(+), 38 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type
On 21/01/2021 12:22, Carsten Haitzler wrote:
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
Yup. typo not spotted by me. Thanks. Also - i spotted an accidental
whitespace change along the way so can fix both in a new patch.
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
This seems like an underlying bug/lack of clear documentation for the
underlying find_*_bit() functions. dp_for_each_set_bit() tries to do the
right thing:
Correct. This was a general problem I spotted - the bit funcs were
written to want a unsigned long but were being used on u32's by just
casting the ptr to the type and this did indeed have technical issues.
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), ((unsigned long *)&(mask)),
sizeof(mask) * 8)
i.e. passing the actual size of type. However because of the case to
unsigned long (and subsequent accesses using that type) the compiler is
free to make accesses beyond the size of the variable (and indeed this
is completely broken on big-endian). The implementation actually
requires that the bitmap is really an array of unsigned long - no other
type will work.
Precisely. So a bit loose. The bit funcs are used widely enough, so just
fixing this code here to pass in the expected type is probably the least
disruptive fix.
So I think the fix should also include fixing the dp_for_each_set_bit()
macro - the cast is bogus as it stands.
Yup. Removing the cast does indeed find more badness that needs fixing.
I'll do an updated patch with this.
Doing that I also get warnings on komeda_pipeline::avail_comps and
komeda_pipeline::supported_inputs - although I note there are other
bitmasks mentioned.
The other option is to fix dp_for_each_set_bit() itself using a little
hack:
- for_each_set_bit((bit), ((unsigned long *)&(mask)),
sizeof(mask) * 8)
+ for_each_set_bit((bit), (&((unsigned long){mask})),
sizeof(mask) * 8)
With that I don't think you need any other change as the mask is actually
in a new unsigned long on the stack.
That would be wonderful if it worked :). Unfortunately your above
proposal leads to:
./drivers/gpu/drm/arm/display/komeda/../include/malidp_utils.h:17:27:
error: lvalue required as unary ‘&’ operand
17 | for_each_set_bit((bit), (&((unsigned long)(mask))),
sizeof(mask) * 8)
| ^
Looks like you didn't notice the subtle change above. My change uses
braces ('{}') around 'mask' - I believe it's a GCC extension ("compound
literals") and it creates an lvalue so you can then take the address of
it...
I'm not sure if it's a good approach to the problem or not. The
alternative is to fix up various places to use unsigned longs so you can
use the unwrapped for_each_set_bit().
Steve
./include/linux/bitops.h:34:30: note: in definition of macro
‘for_each_set_bit’
34 | (bit) = find_next_bit((addr), (size), (bit) + 1))
| ^~~~
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c:1243:2: note:
in expansion of macro ‘dp_for_each_set_bit’
1243 | dp_for_each_set_bit(id, disabling_comps) {
| ^~~
Basically can't take address of an "unnamed local var". :| That is with:
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), (&((unsigned long)(mask))),
sizeof(mask) * 8)
I could try have the dp_for_each macro create new local vars on its own
a bit like:
#define dp_for_each_set_bit(bit, mask) \
unsigned long __local_mask = mask; \
for_each_set_bit((bit), (&__local_mask), sizeof(mask) * 8)
But we all know where this leads... (multiple bad places with adding
warnings and potential and pitfalls that then lead with ever more
invasive changes to address like if code in future might do if (x)
dp_for_each...). I'd prefer to be able to write code more loosely (pass
in any time and it just does the right thing), but trying to balance
this with least disruption and ugliness.
Steve
Signed-off-by: Carsten Haitzler
---
.../drm/arm/display/komeda/komeda_pipeline_state.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index e8b1e15312d8..f7dddb9f015d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -1232,7 +1232,8 @@ komeda_pipeline_unbound_components(struct
komeda_pipeline *pipe,
struct komeda_pipeline_state *old =
priv_to_pipe_st(pipe->obj.state);
Re: [PATCH] drm: Update todo.rst
On Thu, Jan 21, 2021 at 02:21:53PM +0100, Maxime Ripard wrote: > Hi Daniel, > > On Thu, Jan 21, 2021 at 12:29:19PM +0100, Daniel Vetter wrote: > > Interrnship season is starting, let's review this. One thing that's > > ^ internship > > > pending is Maxime's work to roll out drm_atomic_state pointers to all > > callbacks, he said he'll remove that entry once it's all done. > > I plan on sending it by the end of the week Typos fixed and pushed with your irc-ack. -Daniel > > > Signed-off-by: Daniel Vetter > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: David Airlie > > Cc: Daniel Vetter > > --- > > Documentation/gpu/todo.rst | 28 +++- > > 1 file changed, 15 insertions(+), 13 deletions(-) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index 009d8e6c7e3c..492768dd2fd9 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -577,20 +577,24 @@ Contact: Daniel Vetter > > > > Level: Intermediate > > > > -KMS cleanups > > - > > +Object lifetime fixes > > +- > > + > > +There's two related issues here > > + > > +- Cleanup up the various ->destroy callbacks, which often are all the same > > + simple code. > > > > -Some of these date from the very introduction of KMS in 2008 ... > > +- Lots of drivers erroneously allocate DRM modeset objects using > > devm_kzalloc, > > + which results in use-after free issues on driver unload. This can be > > serious > > + trouble even for drivers for hardwared integrated on the SoC due to > > ^ hardware? > > > + EPROBE_DEFERRED backoff. > > Thanks! > Maxime -- 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
[pull] amdgpu drm-fixes-5.11
Hi Dave, Daniel, Fixes for 5.11. The following changes since commit c8f6364f35f32786dd40336cfa35b9166d91b8ab: Merge branch '04.00-ampere-lite-fixes' of git://github.com/skeggsb/linux into drm-fixes (2021-01-15 13:26:44 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.11-2021-01-21 for you to fetch changes up to 39263a2f886817a376fc27ba9af14c5053f0934b: drm/amdgpu: update mmhub mgcg for mmhub_v2_3 (2021-01-21 10:46:05 -0500) amd-drm-fixes-5.11-2021-01-21: amdgpu: - Green Sardine fixes - Vangogh fixes - Renoir fixes - Misc display fixes Aaron Liu (1): drm/amdgpu: update mmhub mgcg for mmhub_v2_3 Aric Cyr (1): drm/amd/display: Allow PSTATE chnage when no displays are enabled Bing Guo (1): drm/amd/display: Change function decide_dp_link_settings to avoid infinite looping Huang Rui (1): drm/amdgpu: remove gpu info firmware of green sardine Jake Wang (1): drm/amd/display: Update dram_clock_change_latency for DCN2.1 Jinzhou Su (1): drm/amdgpu: modify GCR_GENERAL_CNTL for Vangogh Nicholas Kazlauskas (1): drm/amd/display: Use hardware sequencer functions for PG control Prike Liang (1): drm/amdgpu/pm: no need GPU status set since mmnbif_gpu_BIF_DOORBELL_FENCE_CNTL added in FSDL Sung Lee (1): drm/amd/display: DCN2X Find Secondary Pipe properly in MPO + ODM Case Vladimir Stempen (1): drm/amd/display: Fixed corruptions on HPDRX link loss restore drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 - drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 4 +- drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c| 84 -- .../amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c | 6 +- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 7 +- .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 18 +++-- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 9 ++- .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 7 +- .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +- drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c| 2 +- 10 files changed, 100 insertions(+), 40 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] drm/tidss: Annotate dma-fence critical section in commit path
Ends right after hw_done(), totally standard case.
Acked-by: Jyri Sarha
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
b/drivers/gpu/drm/tidss/tidss_kms.c
index 09485c7f0d6f..95f8e0f78e32 100644
--- a/drivers/gpu/drm/tidss/tidss_kms.c
+++ b/drivers/gpu/drm/tidss/tidss_kms.c
@@ -4,6 +4,8 @@
* Author: Tomi Valkeinen
*/
+#include
+
#include
#include
#include
@@ -26,6 +28,7 @@ static void tidss_atomic_commit_tail(struct drm_atomic_state
*old_state)
{
struct drm_device *ddev = old_state->dev;
struct tidss_device *tidss = to_tidss(ddev);
+ bool fence_cookie = dma_fence_begin_signalling();
dev_dbg(ddev->dev, "%s\n", __func__);
@@ -36,6 +39,7 @@ static void tidss_atomic_commit_tail(struct drm_atomic_state
*old_state)
drm_atomic_helper_commit_modeset_enables(ddev, old_state);
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_flip_done(ddev, old_state);
drm_atomic_helper_cleanup_planes(ddev, old_state);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] drm/tegra: Annotate dma-fence critical section in commit path
Again ends just after drm_atomic_helper_commit_hw_done(), but with the
twist that we need to make sure we're only annotate the custom
version. And not the other clause which just calls
drm_atomic_helper_commit_tail_rpm(), which is already annotated.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e45c8414e2a3..ef2b79a903b1 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -65,11 +65,14 @@ static void tegra_atomic_commit_tail(struct
drm_atomic_state *old_state)
struct tegra_drm *tegra = drm->dev_private;
if (tegra->hub) {
+ bool fence_cookie = dma_fence_begin_signalling();
+
drm_atomic_helper_commit_modeset_disables(drm, old_state);
tegra_display_hub_atomic_commit(drm, old_state);
drm_atomic_helper_commit_planes(drm, old_state, 0);
drm_atomic_helper_commit_modeset_enables(drm, old_state);
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_vblanks(drm, old_state);
drm_atomic_helper_cleanup_planes(drm, old_state);
} else {
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/11] drm/rcar-du: Annotate dma-fence critical section in commit path
Ends right after drm_atomic_helper_commit_hw_done(), absolutely nothing fancy going on here. Signed-off-by: Daniel Vetter Cc: Laurent Pinchart Cc: Kieran Bingham Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index fdb8a0d127ad..734e2e614fd2 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -442,6 +442,7 @@ static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state) struct drm_crtc_state *crtc_state; struct drm_crtc *crtc; unsigned int i; + bool fence_cookie = dma_fence_begin_signalling(); /* * Store RGB routing to DPAD0 and DPAD1, the hardware will be configured @@ -468,6 +469,7 @@ static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state) drm_atomic_helper_commit_modeset_enables(dev, old_state); drm_atomic_helper_commit_hw_done(old_state); + dma_fence_end_signalling(fence_cookie); drm_atomic_helper_wait_for_flip_done(dev, old_state); drm_atomic_helper_cleanup_planes(dev, old_state); -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/11] drm/omapdrm: Annotate dma-fence critical section in commit path
Nothing special, just put the end right after hw_done(). Note that in
one path there's a wait for the flip/update to complete. But as far as
I understand from comments and code that's only relevant for modesets,
and skipped if there wasn't a modeset done on a given crtc.
For a bit more clarity pull the hw_done() call out of the if/else,
that way it's a bit clearer flow. But happy to shuffle this around as
is seen fit.
Reviewed-by: Tomi Valkeinen
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 28bbad1353ee..8632139e0f01 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -68,6 +68,7 @@ static void omap_atomic_commit_tail(struct drm_atomic_state
*old_state)
{
struct drm_device *dev = old_state->dev;
struct omap_drm_private *priv = dev->dev_private;
+ bool fence_cookie = dma_fence_begin_signalling();
dispc_runtime_get(priv->dispc);
@@ -90,8 +91,6 @@ static void omap_atomic_commit_tail(struct drm_atomic_state
*old_state)
omap_atomic_wait_for_completion(dev, old_state);
drm_atomic_helper_commit_planes(dev, old_state, 0);
-
- drm_atomic_helper_commit_hw_done(old_state);
} else {
/*
* OMAP3 DSS seems to have issues with the work-around above,
@@ -101,10 +100,12 @@ static void omap_atomic_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_planes(dev, old_state, 0);
drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_commit_hw_done(old_state);
}
+ drm_atomic_helper_commit_hw_done(old_state);
+
+ dma_fence_end_signalling(fence_cookie);
+
/*
* Wait for completion of the page flips to ensure that old buffers
* can't be touched by the hardware anymore before cleaning up planes.
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/11] drm/komeda: Annotate dma-fence critical section in commit path
Like the helpers, nothing special. Well except not, because we the
critical section extends until after hw_done(), since that's the last
thing which could hold up a subsequent atomic commit. That means the
wait_for_flip_done is included, but that's not a problem, we're
allowed to call dma_fence_wait() from signalling critical sections.
Even on our own fence (which this does), it's just a bit confusing.
But in a way those last 2 function calls are already part of the fence
signalling critical section for the next atomic commit.
Reading this I'm wondering why komeda waits for flip_done() before
calling hw_done(), which is a bit backwards (but hey hw can be
special). Might be good to throw a comment in there that explains why,
because the original commit that added this just doesn't.
v2: Small rebase
Reviewed-by: James Qian Wang (v1)
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 034ee08482e0..aeda4e5ec4f4 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -73,6 +73,7 @@ static const struct drm_driver komeda_kms_driver = {
static void komeda_kms_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -85,6 +86,8 @@ static void komeda_kms_commit_tail(struct drm_atomic_state
*old_state)
drm_atomic_helper_wait_for_flip_done(dev, old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_cleanup_planes(dev, old_state);
}
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/11] drm/imx: Annotate dma-fence critical section in commit path
drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup
apparrently), so it's the entire function. And a nice comment
explaining why thw wait_for_flip_done is ahead, unlike the usual
sequence.
Aside, I think since the atomic helpers do track plane disabling now
separately this might no longer be a real problem since:
commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648
Author: Maarten Lankhorst
Date: Mon Sep 4 12:48:37 2017 +0200
drm/atomic: Fix freeing connector/plane state too early by tracking
commits, v3.
Plus the subsequent bugfixes of course, this was tricky to get right.
Signed-off-by: Daniel Vetter
Cc: Philipp Zabel
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index d1a9841adeed..3ed1cc07cad1 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -81,6 +81,7 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
struct drm_plane_state *old_plane_state, *new_plane_state;
bool plane_disabling = false;
int i;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -111,6 +112,7 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
}
drm_atomic_helper_commit_hw_done(state);
+ dma_fence_end_signalling(fence_cookie);
}
static const struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers =
{
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/11] drm/atmel: Use drm_atomic_helper_commit
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines deleted. But I'm not looking at that
stuff, I'm just going through all the atomic commit functions and make
sure they have properly annotated dma-fence critical sections
everywhere.
v2:
- Also delete the workqueue (Sam)
- drop the @commit kerneldoc, I missed that one.
Reviewed-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 107 +--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 7 --
2 files changed, 2 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 98fb53b75f77..65af56e47129 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
void *data)
return IRQ_HANDLED;
}
-struct atmel_hlcdc_dc_commit {
- struct work_struct work;
- struct drm_device *dev;
- struct drm_atomic_state *state;
-};
-
-static void
-atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
-{
- struct drm_device *dev = commit->dev;
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct drm_atomic_state *old_state = commit->state;
-
- /* Apply the atomic update. */
- drm_atomic_helper_commit_modeset_disables(dev, old_state);
- drm_atomic_helper_commit_planes(dev, old_state, 0);
- drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
- drm_atomic_helper_cleanup_planes(dev, old_state);
-
- drm_atomic_state_put(old_state);
-
- /* Complete the commit, wake up any waiter. */
- spin_lock(>commit.wait.lock);
- dc->commit.pending = false;
- wake_up_all_locked(>commit.wait);
- spin_unlock(>commit.wait.lock);
-
- kfree(commit);
-}
-
-static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
-{
- struct atmel_hlcdc_dc_commit *commit =
- container_of(work, struct atmel_hlcdc_dc_commit, work);
-
- atmel_hlcdc_dc_atomic_complete(commit);
-}
-
-static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct atmel_hlcdc_dc_commit *commit;
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- /* Allocate the commit object. */
- commit = kzalloc(sizeof(*commit), GFP_KERNEL);
- if (!commit) {
- ret = -ENOMEM;
- goto error;
- }
-
- INIT_WORK(>work, atmel_hlcdc_dc_atomic_work);
- commit->dev = dev;
- commit->state = state;
-
- spin_lock(>commit.wait.lock);
- ret = wait_event_interruptible_locked(dc->commit.wait,
- !dc->commit.pending);
- if (ret == 0)
- dc->commit.pending = true;
- spin_unlock(>commit.wait.lock);
-
- if (ret)
- goto err_free;
-
- /* We have our own synchronization through the commit lock. */
- BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
- /* Swap state succeeded, this is the point of no return. */
- drm_atomic_state_get(state);
- if (async)
- queue_work(dc->wq, >work);
- else
- atmel_hlcdc_dc_atomic_complete(commit);
-
- return 0;
-
-err_free:
- kfree(commit);
-error:
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
-}
-
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
- .atomic_commit = atmel_hlcdc_dc_atomic_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
@@ -712,11 +619,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc)
return -ENOMEM;
- dc->wq = alloc_ordered_workqueue("atmel-hlcdc-dc", 0);
- if (!dc->wq)
- return -ENOMEM;
-
- init_waitqueue_head(>commit.wait);
dc->desc = match->data;
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
@@ -724,7 +626,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
ret =
[PATCH 05/11] drm/malidp: Annotate dma-fence critical section in commit path
Again needs to be put right after the call to drm_atomic_helper_commit_hw_done(), since that's the last thing which can hold up a subsequent atomic commit. No surprises here. Acked-by: Liviu Dudau Signed-off-by: Daniel Vetter Cc: "James (Qian) Wang" Cc: Liviu Dudau Cc: Mihail Atanassov --- drivers/gpu/drm/arm/malidp_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index fceda010d65a..d83c7366b348 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -234,6 +234,7 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state *state) struct drm_crtc *crtc; struct drm_crtc_state *old_crtc_state; int i; + bool fence_cookie = dma_fence_begin_signalling(); pm_runtime_get_sync(drm->dev); @@ -260,6 +261,8 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state *state) malidp_atomic_commit_hw_done(state); + dma_fence_end_signalling(fence_cookie); + pm_runtime_put(drm->dev); drm_atomic_helper_cleanup_planes(drm, state); -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/vblank: Annotate with dma-fence signalling section
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vblank.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 30912d8f82a5..f2aeb9bf325f 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -24,6 +24,7 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
#include
@@ -1922,7 +1923,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
{
struct drm_vblank_crtc *vblank = >vblank[pipe];
unsigned long irqflags;
- bool disable_irq;
+ bool disable_irq, fence_cookie;
if (drm_WARN_ON_ONCE(dev, !drm_dev_has_vblank(dev)))
return false;
@@ -1930,6 +1931,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return false;
+ fence_cookie = dma_fence_begin_signalling();
+
spin_lock_irqsave(>event_lock, irqflags);
/* Need timestamp lock to prevent concurrent execution with
@@ -1942,6 +1945,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (!vblank->enabled) {
spin_unlock(>vblank_time_lock);
spin_unlock_irqrestore(>event_lock, irqflags);
+ dma_fence_end_signalling(fence_cookie);
return false;
}
@@ -1968,6 +1972,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (disable_irq)
vblank_disable_fn(>disable_timer);
+ dma_fence_end_signalling(fence_cookie);
+
return true;
}
EXPORT_SYMBOL(drm_handle_vblank);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] drm/atomic-helper: Add dma-fence annotations
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
implementations of this hook right now), so bad flag day. And also a
bit leaky abstraction.
Hence just do it function-by-function.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 4a66768b6057..69121d2925bd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1567,6 +1567,7 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -1578,6 +1579,8 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1597,6 +1600,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -1609,6 +1613,8 @@ void drm_atomic_helper_commit_tail_rpm(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1624,6 +1630,9 @@ static void commit_tail(struct drm_atomic_state
*old_state)
ktime_t start;
s64 commit_time_ms;
unsigned int i, new_self_refresh_mask = 0;
+ bool fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
funcs = dev->mode_config.helper_private;
@@ -1652,6 +1661,8 @@ static void commit_tail(struct drm_atomic_state
*old_state)
if (new_crtc_state->self_refresh_active)
new_self_refresh_mask |= BIT(i);
+ dma_fence_end_signalling(fence_cookie);
+
if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
@@ -1810,6 +1821,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
bool nonblock)
{
int ret;
+ bool fence_cookie;
if (state->async_update) {
ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -1832,6 +1844,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;
+ fence_cookie = dma_fence_begin_signalling();
+
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret)
@@ -1869,6 +1883,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
*/
drm_atomic_state_get(state);
+ dma_fence_end_signalling(fence_cookie);
if (nonblock)
queue_work(system_unbound_wq, >commit_work);
else
@@ -1877,6 +1892,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
return 0;
err:
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
}
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11] drm/vkms: Annotate vblank timer
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Tested-by: Melissa Wen
Reviewed-by: Rodrigo Siqueira
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 0443b7deeaef..6164349cdf11 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
+#include
+
#include
#include
#include
@@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
struct drm_crtc *crtc = >crtc;
struct vkms_crtc_state *state;
u64 ret_overrun;
- bool ret;
+ bool ret, fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
output->period_ns);
@@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
DRM_DEBUG_DRIVER("Composer worker already queued\n");
}
+ dma_fence_end_signalling(fence_cookie);
+
return HRTIMER_RESTART;
}
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] dma_fence critical sections annotations for atomic
Hi all, Finally gotten around to refreshing all the various fence anntotions I've hast last summer. Or well parts of it: - entire amdgpu and drm/scheduler annotations postponed for now, because there's way too many splats in there that need some work - in recent patches I've seen quite a few dma_resv_lock or kmalloc in atomic_commit_tail, which doesn't work in full generality with the rules for dma_fences we've discussed and encoded in lockdep. These annotations should catch stuff like this. Review comments and testing very much welcome. Cheers, Daniel Daniel Vetter (11): drm/atomic-helper: Add dma-fence annotations drm/vkms: Annotate vblank timer drm/vblank: Annotate with dma-fence signalling section drm/komeda: Annotate dma-fence critical section in commit path drm/malidp: Annotate dma-fence critical section in commit path drm/atmel: Use drm_atomic_helper_commit drm/imx: Annotate dma-fence critical section in commit path drm/omapdrm: Annotate dma-fence critical section in commit path drm/rcar-du: Annotate dma-fence critical section in commit path drm/tegra: Annotate dma-fence critical section in commit path drm/tidss: Annotate dma-fence critical section in commit path .../gpu/drm/arm/display/komeda/komeda_kms.c | 3 + drivers/gpu/drm/arm/malidp_drv.c | 3 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 107 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 7 -- drivers/gpu/drm/drm_atomic_helper.c | 16 +++ drivers/gpu/drm/drm_vblank.c | 8 +- drivers/gpu/drm/imx/imx-drm-core.c| 2 + drivers/gpu/drm/omapdrm/omap_drv.c| 9 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 + drivers/gpu/drm/tegra/drm.c | 3 + drivers/gpu/drm/tidss/tidss_kms.c | 4 + drivers/gpu/drm/vkms/vkms_crtc.c | 8 +- 12 files changed, 54 insertions(+), 118 deletions(-) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-gt-next
Hi Dave & Daniel,
Here is the final PR for v5.12.
One more fix for the clear residuals security mitigation.
Per-engine reset for Gen7 to avoid collateral damage when some
workloads misbehave, flip priority boosting when using explicit
fences (sync_file), improving suspend/freeze speed and avoiding
casual eviction of used framebuffers.
The rest is usual refactoring, cleanup and prep for upcoming
features.
Regards, Joonas
PS. There will be one warning due to duplicate Fixes: line (one pointing
to drm-intel-gt-next and other to drm-intel-fixes).
dim: ace44e13e577 ("drm/i915/gt: Clear CACHE_MODE prior to clearing
residuals"): Fixes: SHA1 in not pointing at an ancestor:
dim: 09aa9e45863e ("drm/i915/gt: Restore clear-residual mitigations for
Ivybridge, Baytrail")
I think it's fine to add in advance, assuming the -fixes has been pulled,
to avoid missing such patch. Otherwise the chance is that the tooling
misses picking the Fixes for Fixes which has happened in past.
***
drm-intel-gt-next-2021-01-21-1:
Cross-subsystem Changes:
- Includes gvt-gt-next-2021-01-18 + header check fix for GVT
Driver Changes:
- Fix for #2955: Clear potentially malicious register state before
executing clear residuals security mitigation (Chris)
- Fixes that lead to marking per-engine-reset as supported on Gen7
(Chris)
- Remove per-client stats from debugfs/i915_gem_objects) (Tvrtko, Chris)
- Add arbitration check before semaphore wait (Chris)
- Apply interactive priority to explicit flip fences (Chris)
- Make GEM errors non-fatal by default to help capturing logs during
development (Chris)
- Fix object page offset within a region in error capture (CQ, Matt A)
- Close race between enable_breadcrumbs and cancel_breadcrumbs (Chris)
- Almagamate clflushes on suspend/freeze to speed up S/R (Chris)
- Protect used framebuffers from casual eviction (Chris)
- Fix the sgt.pfn sanity check (Kui, Matt A)
- Reduce locking around i915_request.lock and ctx->engines_mutex (Chris)
- Simplify tracking for engine->fw_active and stats.active (Chris)
- Constrain pool objects by mapping type (Chris, Matt A)
- Use shrinkable status for unknown swizzle quirks (Chris)
- Do not suspend bonded requests if one hangs (Chris)
- Restore "Skip over completed active execlists" optimization (Chris)
- Move stolen node into GEM object union (Chris)
. Split gem_create into own file (Matt A)
- Convert object_create into object_init in LMEM region code (Matt A)
- Reduce test_and_set_bit to set_bit in i915_request_submit() (Chris)
- Mark up protected uses of 'i915_request_completed' (Chris)
- Remove extraneous inline modifiers (Chris)
- Add function to define defaults for GuC/HuC enable (John)
- Improve code locality by moving closer to single user (Matt A, Chris)
- Compiler warning fixes (Matt A, Chris)
- Selftest / CI improvements (Chris)
The following changes since commit fb5cfcaa2efbb4c71abb1dfbc8f4da727e0bfd89:
Merge tag 'drm-intel-gt-next-2021-01-14' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-01-15 15:03:36
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel
tags/drm-intel-gt-next-2021-01-21-1
for you to fetch changes up to 69b4b99842201bc24c98ba66b922d8879e190483:
drm/i915/gvt: Add missing forward decl of intel_vgpu for HDRTEST (2021-01-21
15:51:21 +0200)
Cross-subsystem Changes:
- Includes gvt-gt-next-2021-01-18 + header check fix for GVT
Driver Changes:
- Fix for #2955: Clear potentially malicious register state before
executing clear residuals security mitigation (Chris)
- Fixes that lead to marking per-engine-reset as supported on Gen7
(Chris)
- Remove per-client stats from debugfs/i915_gem_objects) (Tvrtko, Chris)
- Add arbitration check before semaphore wait (Chris)
- Apply interactive priority to explicit flip fences (Chris)
- Make GEM errors non-fatal by default to help capturing logs during
development (Chris)
- Fix object page offset within a region in error capture (CQ, Matt A)
- Close race between enable_breadcrumbs and cancel_breadcrumbs (Chris)
- Almagamate clflushes on suspend/freeze to speed up S/R (Chris)
- Protect used framebuffers from casual eviction (Chris)
- Fix the sgt.pfn sanity check (Kui, Matt A)
- Reduce locking around i915_request.lock and ctx->engines_mutex (Chris)
- Simplify tracking for engine->fw_active and stats.active (Chris)
- Constrain pool objects by mapping type (Chris, Matt A)
- Use shrinkable status for unknown swizzle quirks (Chris)
- Do not suspend bonded requests if one hangs (Chris)
- Restore "Skip over completed active execlists" optimization (Chris)
- Move stolen node into GEM object union (Chris)
. Split gem_create into own file (Matt A)
- Convert object_create into object_init in LMEM region code (Matt A)
- Reduce test_and_set_bit to set_bit in i915_request_submit() (Chris)
- Mark up protected uses of 'i915_request_completed' (Chris)
-
Re: possible IO map leak in drm/gem
(cc'ing dri-devel)
Hi,
thanks for reporting the bug.
Am 21.01.21 um 15:35 schrieb Chuck Lever:
Hi Thomas-
I was not able to find an appropriate mailing list entry in MAINTAINERS,
That would be dri-devel@lists.freedesktop.org
so I'm mailing you directly as committer of record for:
43676605f890 ("drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers")
I've noticed that since putting v5.11-rc on my test systems, overnight
on an otherwise idle system the load average seems to grow as the result
of a kernel worker thread.
Earlier this week I fixed a couple of leaks in that code. Could you
please apply the patch at [1] and report back if it fixes the issue.
If it's a separate problem, I'll take a closer look.
Best regards
Thomas
[1]
https://lore.kernel.org/dri-devel/20210118144639.27307-1-tzimmerm...@suse.de/
I used "perf top" to see what it had gotten up to, and it appears that
it was spending lots of time walking an interval tree on behalf of
memtype_reserve().
The most frequently-observed stack trace seems to be:
kworker/3:1-2355 [003] 60950.150928: function:
memtype_reserve
kworker/3:1-2355 [003] 60950.150942: kernel_stack:
=> c0c66083
=> memtype_reserve (a005f9d5)
=> __ioremap_caller (a005aac1)
=> ttm_bo_vmap (c040f266)
=> drm_gem_vram_vmap (c042c5cd)
=> drm_gem_vmap (c0506a7f)
=> drm_client_buffer_vmap (c0523741)
=> drm_fb_helper_damage_work (c049a34a)
=> process_one_work (a00dd92e)
=> worker_thread (a00dde46)
=> kthread (a00e22c4)
=> ret_from_fork (a0004192)
I see a regular call to memtype_reserve(), but never a matching call to
memtype_free(), thus I suspect a leak of I/O maps in this code.
--
Chuck Lever
--
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
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Update todo.rst
On Thu, Jan 21, 2021 at 3:31 PM Thomas Zimmermann wrote: > > Hi > > we talked about making dma_resv the default lock for GEM objects. Could > you add an entry for this? Some interns might feel adventurous. :) Level: Too hard for Daniel Not sure that's a great internship tasks :-P But yeah I'll try to type up something around this maybe. -Daniel > > Best regards > Thomas > > Am 21.01.21 um 12:29 schrieb Daniel Vetter: > > Interrnship season is starting, let's review this. One thing that's > > pending is Maxime's work to roll out drm_atomic_state pointers to all > > callbacks, he said he'll remove that entry once it's all done. > > > > Signed-off-by: Daniel Vetter > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: David Airlie > > Cc: Daniel Vetter > > --- > > Documentation/gpu/todo.rst | 28 +++- > > 1 file changed, 15 insertions(+), 13 deletions(-) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index 009d8e6c7e3c..492768dd2fd9 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -577,20 +577,24 @@ Contact: Daniel Vetter > > > > Level: Intermediate > > > > -KMS cleanups > > - > > +Object lifetime fixes > > +- > > + > > +There's two related issues here > > + > > +- Cleanup up the various ->destroy callbacks, which often are all the same > > + simple code. > > > > -Some of these date from the very introduction of KMS in 2008 ... > > +- Lots of drivers erroneously allocate DRM modeset objects using > > devm_kzalloc, > > + which results in use-after free issues on driver unload. This can be > > serious > > + trouble even for drivers for hardwared integrated on the SoC due to > > + EPROBE_DEFERRED backoff. > > > > -- Make ->funcs and ->helper_private vtables optional. There's a bunch of > > empty > > - function tables in drivers, but before we can remove them we need to > > make sure > > - that all the users in helpers and drivers do correctly check for a NULL > > - vtable. > > +Both these problems can be solved by switching over to drmm_kzalloc(), and > > the > > +various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), > > +drmm_universal_plane_alloc(), ... and so on. > > > > -- Cleanup up the various ->destroy callbacks. A lot of them just wrapt the > > - drm_*_cleanup implementations and can be removed. Some tack a kfree() at > > the > > - end, for which we could add drm_*_cleanup_kfree(). And then there's the > > (for > > - historical reasons) misnamed drm_primary_helper_destroy() function. > > +Contact: Daniel Vetter > > > > Level: Intermediate > > > > @@ -626,8 +630,6 @@ See the documentation of :ref:`VKMS ` for more > > details. This is an ideal > > internship task, since it only requires a virtual machine and can be > > sized to > > fit the available time. > > > > -Contact: Daniel Vetter > > - > > Level: See details > > > > Backlight Refactoring > > > > -- > 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] drm: Update todo.rst
Hi we talked about making dma_resv the default lock for GEM objects. Could you add an entry for this? Some interns might feel adventurous. :) Best regards Thomas Am 21.01.21 um 12:29 schrieb Daniel Vetter: Interrnship season is starting, let's review this. One thing that's pending is Maxime's work to roll out drm_atomic_state pointers to all callbacks, he said he'll remove that entry once it's all done. Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter --- Documentation/gpu/todo.rst | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 009d8e6c7e3c..492768dd2fd9 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -577,20 +577,24 @@ Contact: Daniel Vetter Level: Intermediate -KMS cleanups - +Object lifetime fixes +- + +There's two related issues here + +- Cleanup up the various ->destroy callbacks, which often are all the same + simple code. -Some of these date from the very introduction of KMS in 2008 ... +- Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc, + which results in use-after free issues on driver unload. This can be serious + trouble even for drivers for hardwared integrated on the SoC due to + EPROBE_DEFERRED backoff. -- Make ->funcs and ->helper_private vtables optional. There's a bunch of empty - function tables in drivers, but before we can remove them we need to make sure - that all the users in helpers and drivers do correctly check for a NULL - vtable. +Both these problems can be solved by switching over to drmm_kzalloc(), and the +various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), +drmm_universal_plane_alloc(), ... and so on. -- Cleanup up the various ->destroy callbacks. A lot of them just wrapt the - drm_*_cleanup implementations and can be removed. Some tack a kfree() at the - end, for which we could add drm_*_cleanup_kfree(). And then there's the (for - historical reasons) misnamed drm_primary_helper_destroy() function. +Contact: Daniel Vetter Level: Intermediate @@ -626,8 +630,6 @@ See the documentation of :ref:`VKMS ` for more details. This is an ideal internship task, since it only requires a virtual machine and can be sized to fit the available time. -Contact: Daniel Vetter - Level: See details Backlight Refactoring -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/7] ARM: dts: imx6dl-prtvt7: fix PWM cell count for the backlight node.
Hi Oleksij, On Thu, Jan 21, 2021 at 3:12 AM Oleksij Rempel wrote: > > At some point PWM cell count was changed, but it didn't triggered any It changed in this commit: commit fa28d8212ede9c533ae87a737571a9d3b3eebb29 Author: Uwe Kleine-König Date: Fri Jul 10 07:19:37 2020 +0200 ARM: dts: imx: default to #pwm-cells = <3> in the SoC dtsi files The imx-pwm driver supports 3 cells and this is the more flexible setting. So use it by default and overwrite it back to two for the files that reference the PWMs with just 2 cells to minimize changes. This allows to drop explicit setting to 3 cells for the boards that already depend on this. The boards that are now using 2 cells explicitly can be converted to 3 individually. Signed-off-by: Uwe Kleine-König Signed-off-by: Shawn Guo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/scheduler: Job timeout handler returns status (v3)
On 20/01/2021 20:09, Luben Tuikov wrote: This patch does not change current behaviour. The driver's job timeout handler now returns status indicating back to the DRM layer whether the device (GPU) is no longer available, such as after it's been unplugged, or whether all is normal, i.e. current behaviour. All drivers which make use of the drm_sched_backend_ops' .timedout_job() callback have been accordingly renamed and return the would've-been default value of DRM_GPU_SCHED_STAT_NOMINAL to restart the task's timeout timer--this is the old behaviour, and is preserved by this patch. v2: Use enum as the status of a driver's job timeout callback method. v3: Return scheduler/device information, rather than task information. Cc: Alexander Deucher Cc: Andrey Grodzovsky Cc: Christian König Cc: Daniel Vetter Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: Qiang Yu Cc: Rob Herring Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig Cc: Eric Anholt Reported-by: kernel test robot Signed-off-by: Luben Tuikov Acked-by: Steven Price ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dma-fence: allow signaling drivers to set fence timestamp
Hi Veera, On Wed, 20 Jan 2021 at 02:00, John Stultz wrote: > > On Fri, Jan 15, 2021 at 4:31 PM Veera Sundaram Sankaran > wrote: > > > > Some drivers have hardware capability to get the precise HW timestamp > > of certain events based on which the fences are triggered. The delta > > between the event HW timestamp & current HW reference timestamp can > > be used to calculate the timestamp in kernel's CLOCK_MONOTONIC time > > domain. This allows it to set accurate timestamp factoring out any > > software and IRQ latencies. Add a timestamp variant of fence signal > > function, dma_fence_signal_timestamp to allow drivers to update the > > precise timestamp for fences. Thank you for the patches! Daniel, Christian, Gustavo: if there are no objections, I will queue up this series via drm-misc-next. > > > > Changes in v2: > > - Add a new fence signal variant instead of modifying fence struct > > > > Changes in v3: > > - Add timestamp domain information to commit-text and > > dma_fence_signal_timestamp documentation > > > > Signed-off-by: Veera Sundaram Sankaran > > --- > > drivers/dma-buf/dma-fence.c | 70 > > - > > include/linux/dma-fence.h | 3 ++ > > 2 files changed, 66 insertions(+), 7 deletions(-) > > Thanks for respinning this! > > Reviewed-by: John Stultz > > -john Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH 3/3] dma-buf: heaps: Rework heep allocation hooks to return struct dma_buf instead of fd
Hi John,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> Every heap needs to create a dmabuf and then export it to a fd
> via dma_buf_fd(), so to consolidate things a bit, have the heaps
> just return a struct dmabuf * and let the top level
> dma_heap_buffer_alloc() call handle creating the fd via
> dma_buf_fd().
Thanks for the patch! LGTM, feels a lot neater now. I'll merge into
drm-misc-next.
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/dma-heap.c | 14 +-
> drivers/dma-buf/heaps/cma_heap.c| 22 +++---
> drivers/dma-buf/heaps/system_heap.c | 21 +++--
> include/linux/dma-heap.h| 12 ++--
> 4 files changed, 33 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index afd22c9dbdcf..6b5db954569f 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -52,6 +52,9 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap,
> size_t len,
> unsigned int fd_flags,
> unsigned int heap_flags)
> {
> + struct dma_buf *dmabuf;
> + int fd;
> +
> /*
> * Allocations from all heaps have to begin
> * and end on page boundaries.
> @@ -60,7 +63,16 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap,
> size_t len,
> if (!len)
> return -EINVAL;
>
> - return heap->ops->allocate(heap, len, fd_flags, heap_flags);
> + dmabuf = heap->ops->allocate(heap, len, fd_flags, heap_flags);
> + if (IS_ERR(dmabuf))
> + return PTR_ERR(dmabuf);
> +
> + fd = dma_buf_fd(dmabuf, fd_flags);
> + if (fd < 0) {
> + dma_buf_put(dmabuf);
> + /* just return, as put will call release and that will free */
> + }
> + return fd;
> }
>
> static int dma_heap_open(struct inode *inode, struct file *file)
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 0c76cbc3fb11..985c41ffd85b 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -272,10 +272,10 @@ static const struct dma_buf_ops cma_heap_buf_ops = {
> .release = cma_heap_dma_buf_release,
> };
>
> -static int cma_heap_allocate(struct dma_heap *heap,
> - unsigned long len,
> - unsigned long fd_flags,
> - unsigned long heap_flags)
> +static struct dma_buf *cma_heap_allocate(struct dma_heap *heap,
> +unsigned long len,
> +unsigned long fd_flags,
> +unsigned long heap_flags)
> {
> struct cma_heap *cma_heap = dma_heap_get_drvdata(heap);
> struct cma_heap_buffer *buffer;
> @@ -290,7 +290,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
>
> buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> if (!buffer)
> - return -ENOMEM;
> + return ERR_PTR(-ENOMEM);
>
> INIT_LIST_HEAD(>attachments);
> mutex_init(>lock);
> @@ -349,15 +349,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
> ret = PTR_ERR(dmabuf);
> goto free_pages;
> }
> -
> - ret = dma_buf_fd(dmabuf, fd_flags);
> - if (ret < 0) {
> - dma_buf_put(dmabuf);
> - /* just return, as put will call release and that will free */
> - return ret;
> - }
> -
> - return ret;
> + return dmabuf;
>
> free_pages:
> kfree(buffer->pages);
> @@ -366,7 +358,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
> free_buffer:
> kfree(buffer);
>
> - return ret;
> + return ERR_PTR(ret);
> }
>
> static const struct dma_heap_ops cma_heap_ops = {
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> index 2321c91891f6..7b154424aeb3 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -332,10 +332,10 @@ static struct page *alloc_largest_available(unsigned
> long size,
> return NULL;
> }
>
> -static int system_heap_allocate(struct dma_heap *heap,
> - unsigned long len,
> - unsigned long fd_flags,
> - unsigned long heap_flags)
> +static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
> +
Re: [RESEND][PATCH 1/3] dma-buf: system_heap: Make sure to return an error if we abort
Hi John,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> If we abort from the allocation due to a fatal_signal_pending(),
> be sure we report an error so any return code paths don't trip
> over the fact that the allocation didn't succeed.
Thanks for the patch; LGTM, will push into drm-misc-next.
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Suggested-by: Suren Baghdasaryan
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/system_heap.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> index 17e0e9a68baf..405351aad2a8 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -363,8 +363,10 @@ static int system_heap_allocate(struct dma_heap *heap,
> * Avoid trying to allocate memory if the process
> * has been killed by SIGKILL
> */
> - if (fatal_signal_pending(current))
> + if (fatal_signal_pending(current)) {
> + ret = -EINTR;
> goto free_buffer;
> + }
>
> page = alloc_largest_available(size_remaining, max_order);
> if (!page)
> --
> 2.17.1
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer with error -12
I still have no idea what's going on here.
The KASAN messages from the DC code are completely unrelated.
Please add the full dmesg to your bug report.
Christian.
Am 20.01.21 um 01:59 schrieb Mikhail Gavrilov:
On Fri, 15 Jan 2021 at 03:43, Mikhail Gavrilov
wrote:
In rc4, the number of warnings has dropped dramatically.
No more errors "kasan slab-out-of-bounds" and no "DMA-API device
driver failed to check map error".
But still not fixed "sleeping function called from invalid context at
include/linux/sched/mm.h:196" and "BUG: key 88810b0d9148 has not
been registered!"
Second issue Navi specific because it started to happen in 5.10 kernel
after replacing Radeon VII to 6900XT.
1.
BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:196
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 500, name: systemd-udevd
1 lock held by systemd-udevd/500:
#0: 888107690258 (>mutex){}-{3:3}, at:
device_driver_attach+0xa3/0x250
CPU: 9 PID: 500 Comm: systemd-udevd Not tainted
5.11.0-0.rc4.129.fc34.x86_64+debug #1
Hardware name: System manufacturer System Product Name/ROG STRIX
X570-I GAMING, BIOS 2802 10/21/2020
Call Trace:
dump_stack+0xae/0xe5
___might_sleep.cold+0x150/0x17e
? dcn30_clock_source_create+0x53/0x110 [amdgpu]
kmem_cache_alloc_trace+0x23f/0x270
dcn30_clock_source_create+0x53/0x110 [amdgpu]
dcn30_create_resource_pool+0x998/0x4890 [amdgpu]
? dcn30_calc_max_scaled_time+0x40/0x40 [amdgpu]
? lock_is_held_type+0xb8/0xf0
? unpoison_range+0x3a/0x60
? kasan_kmalloc.constprop.0+0x84/0xa0
? dc_create_resource_pool+0x26e/0x5e0 [amdgpu]
dc_create_resource_pool+0x26e/0x5e0 [amdgpu]
dc_create+0x636/0x1bc0 [amdgpu]
? lock_acquire+0x2dd/0x7a0
? sched_clock+0x5/0x10
? sched_clock_cpu+0x18/0x170
? find_held_lock+0x33/0x110
? dc_create_state+0xa0/0xa0 [amdgpu]
? lock_downgrade+0x6b0/0x6b0
? module_assert_mutex_or_preempt+0x3e/0x70
? lock_is_held_type+0xb8/0xf0
? unpoison_range+0x3a/0x60
? kasan_kmalloc.constprop.0+0x84/0xa0
amdgpu_dm_init.isra.0+0x479/0x640 [amdgpu]
? vprintk_emit+0x1c0/0x460
? dev_vprintk_emit+0x2d8/0x31a
? sched_clock+0x5/0x10
? dm_resume+0x13b0/0x13b0 [amdgpu]
? dev_attr_show.cold+0x35/0x35
? lock_downgrade+0x6b0/0x6b0
? dev_printk_emit+0x8c/0xa8
? dev_vprintk_emit+0x31a/0x31a
? wait_for_completion_io+0x240/0x240
? __dev_printk+0x71/0xdf
? smu_hw_init.cold+0x16b/0x18a [amdgpu]
? smu_suspend+0x240/0x240 [amdgpu]
? navi10_ih_irq_init+0xea3/0x2420 [amdgpu]
dm_hw_init+0xe/0x20 [amdgpu]
amdgpu_device_init.cold+0x3031/0x4940 [amdgpu]
? amdgpu_device_cache_pci_state+0xf0/0xf0 [amdgpu]
? pci_bus_read_config_byte+0x140/0x140
? do_pci_enable_device+0x1f8/0x260
? pci_find_saved_ext_cap+0x110/0x110
? pci_enable_bridge+0xf9/0x1e0
? pci_dev_check_d3cold+0x107/0x250
? pci_enable_device_flags+0x201/0x340
amdgpu_driver_load_kms+0x167/0x8a0 [amdgpu]
amdgpu_pci_probe+0x235/0x360 [amdgpu]
? amdgpu_pci_remove+0xd0/0xd0 [amdgpu]
local_pci_probe+0xd8/0x170
pci_device_probe+0x318/0x5c0
? kernfs_create_link+0x16c/0x230
? pci_device_remove+0x1d0/0x1d0
really_probe+0x224/0xc40
driver_probe_device+0x1f2/0x380
device_driver_attach+0x1df/0x250
__driver_attach+0xf6/0x260
? device_driver_attach+0x250/0x250
bus_for_each_dev+0x114/0x180
? subsys_dev_iter_exit+0x10/0x10
bus_add_driver+0x352/0x570
driver_register+0x20f/0x390
? __pci_register_driver+0x13a/0x210
? 0xc1d8d000
do_one_initcall+0xfb/0x530
? perf_trace_initcall_level+0x3d0/0x3d0
? __memset+0x2b/0x30
? unpoison_range+0x3a/0x60
do_init_module+0x1ce/0x7a0
load_module+0x9841/0xa380
? module_frob_arch_sections+0x20/0x20
? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
? sched_clock_cpu+0x18/0x170
? sched_clock+0x5/0x10
? lock_acquire+0x2dd/0x7a0
? sched_clock+0x5/0x10
? lock_is_held_type+0xb8/0xf0
? __do_sys_init_module+0x18b/0x220
__do_sys_init_module+0x18b/0x220
? load_module+0xa380/0xa380
? ktime_get_coarse_real_ts64+0x12f/0x160
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f2c109da07e
Code: 48 8b 0d f5 1d 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f
84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 8b 0d c2 1d 0c 00 f7 d8 64 89 01 48
RSP: 002b:7ffc84d33f88 EFLAGS: 0246 ORIG_RAX: 00af
RAX: ffda RBX: 55b87f8260a0 RCX: 7f2c109da07e
RDX: 55b87f834060 RSI: 01e2cbf6 RDI: 7f2c0b7e0010
RBP: 7f2c0b7e0010 R08: 55b87f8281e0 R09: 7ffc84d30a26
R10: 55bd2404cc18 R11: 0246 R12: 55b87f834060
R13: 55b87f831ca0 R14: R15: 55b87f832640
[drm] Display Core initialized with v3.2.116!
[drm] DMUB hardware initialized: version=0x0201
usb 1-3.2: Device not responding to setup address.
usb 1-3.2: device not accepting address 5, error -71
[drm] REG_WAIT timeout 1us * 10 tries -
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
On Thu, 21 Jan 2021, Fabio Estevam wrote: > On Thu, Jan 21, 2021 at 9:10 AM Jani Nikula wrote: > >> Kinda catch-22 because next has dropped current drm-intel-next because >> it doesn't build because of the issue this patch fixes. ;) > > Ok, so I built drm-intel-next and I was able to reproduce the buid > error as reported by Stephen. > > Applied this patch and it builds fine now. Thanks, much appreciated. Pushed to drm-intel-next. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH v2] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Wed, Jan 20, 2021 at 4:22 AM Christian König wrote: > > Am 19.01.21 um 23:57 schrieb Hridya Valsaraju: > > This patch allows statistics to be enabled for each DMA-BUF in > > sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > > > > The following stats will be exposed by the interface: > > > > /sys/kernel/dmabuf/buffers//exporter_name > > /sys/kernel/dmabuf/buffers//size > > /sys/kernel/dmabuf/buffers//attachments//device > > /sys/kernel/dmabuf/buffers//attachments//map_counter > > > > The inode_number is unique for each DMA-BUF and was added earlier [1] > > in order to allow userspace to track DMA-BUF usage across different > > processes. > > > > Currently, this information is exposed in > > /sys/kernel/debug/dma_buf/bufinfo. > > However, since debugfs is considered unsafe to be mounted in production, > > it is being duplicated in sysfs. > > > > This information will be used to derive DMA-BUF > > per-exporter stats and per-device usage stats for Android Bug reports. > > The corresponding userspace changes can be found at [2]. > > Telemetry tools will also capture this information(along with other > > memory metrics) periodically as well as on important events like a > > foreground app kill (which might have been triggered by Low Memory > > Killer). It will also contribute to provide a snapshot of the system > > memory usage on other events such as OOM kills and Application Not > > Responding events. > > > > A shell script that can be run on a classic Linux environment to read > > out the DMA-BUF statistics can be found at [3](suggested by John > > Stultz). > > > > The patch contains the following improvements over the previous version: > > 1) Each attachment is represented by its own directory to allow creating > > a symlink to the importing device and to also provide room for future > > expansion. > > 2) The number of distinct mappings of each attachment is exposed in a > > separate file. > > 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > > inorder to make the interface expandable in future. > > > > All of the improvements above are based on suggestions/feedback from > > Daniel Vetter and Christian König. > > > > [1]: https://lore.kernel.org/patchwork/patch/1088791/ > > [2]: > > https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) > > [3]: > > https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 > > > > Signed-off-by: Hridya Valsaraju > > --- > > Changes in v2: > > -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition > > of other DMA-BUF-related sysfs stats in future. Based on feedback from > > Daniel Vetter. > > -Each attachment has its own directory to represent attaching devices as > > symlinks and to introduce map_count as a separate file. Based on > > feedback from Daniel Vetter and Christian König. Thank you both! > > -Commit messages updated to point to userspace code in AOSP that will > > read the DMA-BUF sysfs stats. > > > > .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 > > drivers/dma-buf/Kconfig | 11 + > > drivers/dma-buf/Makefile | 1 + > > drivers/dma-buf/dma-buf-sysfs-stats.c | 283 ++ > > drivers/dma-buf/dma-buf-sysfs-stats.h | 62 > > drivers/dma-buf/dma-buf.c | 37 +++ > > include/linux/dma-buf.h | 20 ++ > > 7 files changed, 466 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h > > > > diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > new file mode 100644 > > index ..6f7c65209f07 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > @@ -0,0 +1,52 @@ > > +What:/sys/kernel/dmabuf/buffers > > +Date:January 2021 > > +KernelVersion: v5.12 > > +Contact: Hridya Valsaraju > > +Description: The /sys/kernel/dmabuf/buffers directory contains a > > + snapshot of the internal state of every DMA-BUF. > > + /sys/kernel/dmabuf/buffers/ will contain the > > + statistics for the DMA-BUF with the unique inode number > > + > > +Users: kernel memory tuning/debugging tools > > + > > +What: > > /sys/kernel/dmabuf/buffers//exporter_name > > +Date:January 2021 > > +KernelVersion: v5.12 > > +Contact: Hridya Valsaraju > > +Description: This file is read-only and contains the name of the exporter > > of > > + the DMA-BUF. > > + > > +What:/sys/kernel/dmabuf/buffers//size > > +Date:January 2021 > > +KernelVersion: v5.12 > > +Contact: Hridya
Re: [Linaro-mm-sig] [PATCH v2] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Wed, Jan 20, 2021 at 4:42 AM Daniel Vetter wrote: > > On Wed, Jan 20, 2021 at 1:22 PM Christian König > wrote: > > > > Am 19.01.21 um 23:57 schrieb Hridya Valsaraju: > > > This patch allows statistics to be enabled for each DMA-BUF in > > > sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > > > > > > The following stats will be exposed by the interface: > > > > > > /sys/kernel/dmabuf/buffers//exporter_name > > > /sys/kernel/dmabuf/buffers//size > > > /sys/kernel/dmabuf/buffers//attachments//device > > > /sys/kernel/dmabuf/buffers//attachments//map_counter > > > > > > The inode_number is unique for each DMA-BUF and was added earlier [1] > > > in order to allow userspace to track DMA-BUF usage across different > > > processes. > > > > > > Currently, this information is exposed in > > > /sys/kernel/debug/dma_buf/bufinfo. > > > However, since debugfs is considered unsafe to be mounted in production, > > > it is being duplicated in sysfs. > > > > > > This information will be used to derive DMA-BUF > > > per-exporter stats and per-device usage stats for Android Bug reports. > > > The corresponding userspace changes can be found at [2]. > > > Telemetry tools will also capture this information(along with other > > > memory metrics) periodically as well as on important events like a > > > foreground app kill (which might have been triggered by Low Memory > > > Killer). It will also contribute to provide a snapshot of the system > > > memory usage on other events such as OOM kills and Application Not > > > Responding events. > > > > > > A shell script that can be run on a classic Linux environment to read > > > out the DMA-BUF statistics can be found at [3](suggested by John > > > Stultz). > > > > > > The patch contains the following improvements over the previous version: > > > 1) Each attachment is represented by its own directory to allow creating > > > a symlink to the importing device and to also provide room for future > > > expansion. > > > 2) The number of distinct mappings of each attachment is exposed in a > > > separate file. > > > 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > > > inorder to make the interface expandable in future. > > > > > > All of the improvements above are based on suggestions/feedback from > > > Daniel Vetter and Christian König. > > > > > > [1]: https://lore.kernel.org/patchwork/patch/1088791/ > > > [2]: > > > https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) > > > [3]: > > > https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 > > > > > > Signed-off-by: Hridya Valsaraju > > > --- > > > Changes in v2: > > > -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition > > > of other DMA-BUF-related sysfs stats in future. Based on feedback from > > > Daniel Vetter. > > > -Each attachment has its own directory to represent attaching devices as > > > symlinks and to introduce map_count as a separate file. Based on > > > feedback from Daniel Vetter and Christian König. Thank you both! > > > -Commit messages updated to point to userspace code in AOSP that will > > > read the DMA-BUF sysfs stats. > > > > > > .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 > > > drivers/dma-buf/Kconfig | 11 + > > > drivers/dma-buf/Makefile | 1 + > > > drivers/dma-buf/dma-buf-sysfs-stats.c | 283 ++ > > > drivers/dma-buf/dma-buf-sysfs-stats.h | 62 > > > drivers/dma-buf/dma-buf.c | 37 +++ > > > include/linux/dma-buf.h | 20 ++ > > > 7 files changed, 466 insertions(+) > > > create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c > > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h > > > > > > diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > > b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > > new file mode 100644 > > > index ..6f7c65209f07 > > > --- /dev/null > > > +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > > @@ -0,0 +1,52 @@ > > > +What:/sys/kernel/dmabuf/buffers > > > +Date:January 2021 > > > +KernelVersion: v5.12 > > > +Contact: Hridya Valsaraju > > > +Description: The /sys/kernel/dmabuf/buffers directory contains a > > > + snapshot of the internal state of every DMA-BUF. > > > + /sys/kernel/dmabuf/buffers/ will contain the > > > + statistics for the DMA-BUF with the unique inode number > > > + > > > +Users: kernel memory tuning/debugging tools > > > + > > > +What: > > > /sys/kernel/dmabuf/buffers//exporter_name > > > +Date:January 2021 > > > +KernelVersion: v5.12 > > > +Contact: Hridya Valsaraju > > > +Description:
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
On Thu, Jan 21, 2021 at 9:10 AM Jani Nikula wrote: > Kinda catch-22 because next has dropped current drm-intel-next because > it doesn't build because of the issue this patch fixes. ;) Ok, so I built drm-intel-next and I was able to reproduce the buid error as reported by Stephen. Applied this patch and it builds fine now. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Added orientation quirk for OneGX1 Pro
The OneGX1 Pro has a fairly unique combination of generic strings,
but we additionally match on the BIOS date just to be safe.
Signed-off-by: Jared Baldridge
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 58f5dc2f6dd5..f6bdec7fa925 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -84,6 +84,13 @@ static const struct drm_dmi_panel_orientation_data
itworks_tw891 = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data onegx1_pro = {
+ .width = 1200,
+ .height = 1920,
+ .bios_dates = (const char * const []){ "12/17/2020", NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data lcd720x1280_rightside_up = {
.width = 720,
.height = 1280,
@@ -211,6 +218,13 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGM"),
},
.driver_data = (void *)_rightside_up,
+ }, {/* OneGX1 Pro */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "SYSTEM_MANUFACTURER"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "SYSTEM_PRODUCT_NAME"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"),
+ },
+ .driver_data = (void *)_pro,
}, {/* VIOS LTH17 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Wed, Jan 20, 2021 at 1:11 AM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> > >
> > > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> > > >
> > > > On the success of virtio_gpu_object_create, add size of newly allocated
> > > > bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
> > > > bo lost its last refcount, subtract the bo size from the tracked
> > > > total_mem if the original underlying memory allocation is successful.
> > > >
> > > > Signed-off-by: Yiwei Zhang
> > >
> > > Isn't this something that ideally we'd for everyone? Also tracepoint
> > > for showing the total feels like tracepoint abuse, usually we show
> > > totals somewhere in debugfs or similar, and tracepoint just for what's
> > > happening (i.e. which object got deleted/created).
> > >
> > > What is this for exactly?
> > > -Daniel
> > >
> > > > ---
> > > > drivers/gpu/drm/virtio/Kconfig | 1 +
> > > > drivers/gpu/drm/virtio/virtgpu_drv.h| 4
> > > > drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++
> > > > 3 files changed, 24 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/virtio/Kconfig
> > > > b/drivers/gpu/drm/virtio/Kconfig
> > > > index b925b8b1da16..e103b7e883b1 100644
> > > > --- a/drivers/gpu/drm/virtio/Kconfig
> > > > +++ b/drivers/gpu/drm/virtio/Kconfig
> > > > @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> > > > select DRM_KMS_HELPER
> > > > select DRM_GEM_SHMEM_HELPER
> > > > select VIRTIO_DMA_SHARED_BUFFER
> > > > + select TRACE_GPU_MEM
> > > > help
> > > >This is the virtual GPU driver for virtio. It can be used
> > > > with
> > > >QEMU based VMMs (like KVM or Xen).
> > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > index 6a232553c99b..7c60e7486bc4 100644
> > > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > @@ -249,6 +249,10 @@ struct virtio_gpu_device {
> > > > spinlock_t resource_export_lock;
> > > > /* protects map state and host_visible_mm */
> > > > spinlock_t host_visible_lock;
> > > > +
> > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > + atomic64_t total_mem;
> > > > +#endif
> > > > };
> > > >
> > > > struct virtio_gpu_fpriv {
> > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > index d69a5b6da553..1e16226cebbe 100644
> > > > --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > @@ -25,12 +25,29 @@
> > > >
> > > > #include
> > > > #include
> > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > +#include
> > > > +#endif
> > > >
> > > > #include "virtgpu_drv.h"
> > > >
> > > > static int virtio_gpu_virglrenderer_workaround = 1;
> > > > module_param_named(virglhack, virtio_gpu_virglrenderer_workaround,
> > > > int, 0400);
> > > >
> > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> > > > *vgdev,
> > > > + s64 delta)
> > > > +{
> > > > + u64 total_mem = atomic64_add_return(delta, >total_mem);
> > > > +
> > > > + trace_gpu_mem_total(0, 0, total_mem);
> > > > +}
> > > > +#else
> > > > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> > > > *, s64)
> > > > +{
> > > > +}
> > > > +#endif
> > > > +
> > > > int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
> > > > uint32_t *resid)
> > > > {
> > > > if (virtio_gpu_virglrenderer_workaround) {
> > > > @@ -104,6 +121,7 @@ static void virtio_gpu_free_object(struct
> > > > drm_gem_object *obj)
> > > > struct virtio_gpu_device *vgdev =
> > > > bo->base.base.dev->dev_private;
> > > >
> > > > if (bo->created) {
> > > > + virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> > > > virtio_gpu_cmd_unref_resource(vgdev, bo);
> > > > virtio_gpu_notify(vgdev);
> > > > /* completion handler calls virtio_gpu_cleanup_object()
> > > > */
> > > > @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct
> > > > virtio_gpu_device *vgdev,
> > > > virtio_gpu_object_attach(vgdev, bo, ents, nents);
> > > > }
> > > >
> > > > + virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> > > > *bo_ptr = bo;
> > > > return 0;
> > > >
> > > > --
> > > > 2.30.0.284.gd98b1dd5eaa7-goog
> > > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> > Thanks for your reply! Android Cuttlefish virtual platform is using
> > the virtio-gpu driver, and we currently are carrying this small patch
> > at the downstream side. This is essential for us because:
> > (1)
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> >
> > On the success of virtio_gpu_object_create, add size of newly allocated
> > bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
> > bo lost its last refcount, subtract the bo size from the tracked
> > total_mem if the original underlying memory allocation is successful.
> >
> > Signed-off-by: Yiwei Zhang
>
> Isn't this something that ideally we'd for everyone? Also tracepoint
> for showing the total feels like tracepoint abuse, usually we show
> totals somewhere in debugfs or similar, and tracepoint just for what's
> happening (i.e. which object got deleted/created).
>
> What is this for exactly?
> -Daniel
>
> > ---
> > drivers/gpu/drm/virtio/Kconfig | 1 +
> > drivers/gpu/drm/virtio/virtgpu_drv.h| 4
> > drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++
> > 3 files changed, 24 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> > index b925b8b1da16..e103b7e883b1 100644
> > --- a/drivers/gpu/drm/virtio/Kconfig
> > +++ b/drivers/gpu/drm/virtio/Kconfig
> > @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> > select DRM_KMS_HELPER
> > select DRM_GEM_SHMEM_HELPER
> > select VIRTIO_DMA_SHARED_BUFFER
> > + select TRACE_GPU_MEM
> > help
> >This is the virtual GPU driver for virtio. It can be used with
> >QEMU based VMMs (like KVM or Xen).
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > index 6a232553c99b..7c60e7486bc4 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > @@ -249,6 +249,10 @@ struct virtio_gpu_device {
> > spinlock_t resource_export_lock;
> > /* protects map state and host_visible_mm */
> > spinlock_t host_visible_lock;
> > +
> > +#ifdef CONFIG_TRACE_GPU_MEM
> > + atomic64_t total_mem;
> > +#endif
> > };
> >
> > struct virtio_gpu_fpriv {
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> > b/drivers/gpu/drm/virtio/virtgpu_object.c
> > index d69a5b6da553..1e16226cebbe 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> > @@ -25,12 +25,29 @@
> >
> > #include
> > #include
> > +#ifdef CONFIG_TRACE_GPU_MEM
> > +#include
> > +#endif
> >
> > #include "virtgpu_drv.h"
> >
> > static int virtio_gpu_virglrenderer_workaround = 1;
> > module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int,
> > 0400);
> >
> > +#ifdef CONFIG_TRACE_GPU_MEM
> > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> > *vgdev,
> > + s64 delta)
> > +{
> > + u64 total_mem = atomic64_add_return(delta, >total_mem);
> > +
> > + trace_gpu_mem_total(0, 0, total_mem);
> > +}
> > +#else
> > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device *,
> > s64)
> > +{
> > +}
> > +#endif
> > +
> > int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t
> > *resid)
> > {
> > if (virtio_gpu_virglrenderer_workaround) {
> > @@ -104,6 +121,7 @@ static void virtio_gpu_free_object(struct
> > drm_gem_object *obj)
> > struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
> >
> > if (bo->created) {
> > + virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> > virtio_gpu_cmd_unref_resource(vgdev, bo);
> > virtio_gpu_notify(vgdev);
> > /* completion handler calls virtio_gpu_cleanup_object() */
> > @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> > *vgdev,
> > virtio_gpu_object_attach(vgdev, bo, ents, nents);
> > }
> >
> > + virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> > *bo_ptr = bo;
> > return 0;
> >
> > --
> > 2.30.0.284.gd98b1dd5eaa7-goog
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Thanks for your reply! Android Cuttlefish virtual platform is using
the virtio-gpu driver, and we currently are carrying this small patch
at the downstream side. This is essential for us because:
(1) Android has deprecated debugfs on production devices already
(2) Android GPU drivers are not DRM based, and this won't change in a
short term.
Android relies on this tracepoint + eBPF to make the GPU memory totals
available at runtime on production devices, which has been enforced
already. Not only game developers can have a reliable kernel total GPU
memory to look at, but also Android leverages this to take GPU memory
usage out from the system lost ram.
I'm not sure whether the other DRM drivers would like to integrate
this tracepoint(maybe upstream drivers will move away from debugfs
later as well?), but at least we hope virtio-gpu can take
[PATCH v2] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
This patch allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. The following stats will be exposed by the interface: /sys/kernel/dmabuf/buffers//exporter_name /sys/kernel/dmabuf/buffers//size /sys/kernel/dmabuf/buffers//attachments//device /sys/kernel/dmabuf/buffers//attachments//map_counter The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes. Currently, this information is exposed in /sys/kernel/debug/dma_buf/bufinfo. However, since debugfs is considered unsafe to be mounted in production, it is being duplicated in sysfs. This information will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events. A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz). The patch contains the following improvements over the previous version: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future. All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König. [1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 Signed-off-by: Hridya Valsaraju --- Changes in v2: -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition of other DMA-BUF-related sysfs stats in future. Based on feedback from Daniel Vetter. -Each attachment has its own directory to represent attaching devices as symlinks and to introduce map_count as a separate file. Based on feedback from Daniel Vetter and Christian König. Thank you both! -Commit messages updated to point to userspace code in AOSP that will read the DMA-BUF sysfs stats. .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-sysfs-stats.c | 283 ++ drivers/dma-buf/dma-buf-sysfs-stats.h | 62 drivers/dma-buf/dma-buf.c | 37 +++ include/linux/dma-buf.h | 20 ++ 7 files changed, 466 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index ..6f7c65209f07 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -0,0 +1,52 @@ +What: /sys/kernel/dmabuf/buffers +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/ will contain the + statistics for the DMA-BUF with the unique inode number + +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers//exporter_name +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//size +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. + +What: /sys/kernel/dmabuf/buffers//attachments +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This directory will contain subdirectories representing every + attachment of the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//attachments/ +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This directory will contain
Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
Yup. typo not spotted by me. Thanks. Also - i spotted an accidental
whitespace change along the way so can fix both in a new patch.
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
This seems like an underlying bug/lack of clear documentation for the
underlying find_*_bit() functions. dp_for_each_set_bit() tries to do the
right thing:
Correct. This was a general problem I spotted - the bit funcs were
written to want a unsigned long but were being used on u32's by just
casting the ptr to the type and this did indeed have technical issues.
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask)
* 8)
i.e. passing the actual size of type. However because of the case to
unsigned long (and subsequent accesses using that type) the compiler is
free to make accesses beyond the size of the variable (and indeed this
is completely broken on big-endian). The implementation actually
requires that the bitmap is really an array of unsigned long - no other
type will work.
Precisely. So a bit loose. The bit funcs are used widely enough, so just
fixing this code here to pass in the expected type is probably the least
disruptive fix.
So I think the fix should also include fixing the dp_for_each_set_bit()
macro - the cast is bogus as it stands.
Yup. Removing the cast does indeed find more badness that needs fixing.
I'll do an updated patch with this.
Doing that I also get warnings on komeda_pipeline::avail_comps and
komeda_pipeline::supported_inputs - although I note there are other
bitmasks mentioned.
The other option is to fix dp_for_each_set_bit() itself using a little
hack:
- for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask)
* 8)
+ for_each_set_bit((bit), (&((unsigned long){mask})), sizeof(mask)
* 8)
With that I don't think you need any other change as the mask is actually
in a new unsigned long on the stack.
That would be wonderful if it worked :). Unfortunately your above
proposal leads to:
./drivers/gpu/drm/arm/display/komeda/../include/malidp_utils.h:17:27:
error: lvalue required as unary ‘&’ operand
17 | for_each_set_bit((bit), (&((unsigned long)(mask))),
sizeof(mask) * 8)
| ^
./include/linux/bitops.h:34:30: note: in definition of macro
‘for_each_set_bit’
34 | (bit) = find_next_bit((addr), (size), (bit) + 1))
| ^~~~
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c:1243:2: note:
in expansion of macro ‘dp_for_each_set_bit’
1243 | dp_for_each_set_bit(id, disabling_comps) {
| ^~~
Basically can't take address of an "unnamed local var". :| That is with:
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), (&((unsigned long)(mask))),
sizeof(mask) * 8)
I could try have the dp_for_each macro create new local vars on its own
a bit like:
#define dp_for_each_set_bit(bit, mask) \
unsigned long __local_mask = mask; \
for_each_set_bit((bit), (&__local_mask), sizeof(mask) * 8)
But we all know where this leads... (multiple bad places with adding
warnings and potential and pitfalls that then lead with ever more
invasive changes to address like if code in future might do if (x)
dp_for_each...). I'd prefer to be able to write code more loosely (pass
in any time and it just does the right thing), but trying to balance
this with least disruption and ugliness.
Steve
Signed-off-by: Carsten Haitzler
---
.../drm/arm/display/komeda/komeda_pipeline_state.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index e8b1e15312d8..f7dddb9f015d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -1232,7 +1232,8 @@ komeda_pipeline_unbound_components(struct
komeda_pipeline *pipe,
struct komeda_pipeline_state *old =
priv_to_pipe_st(pipe->obj.state);
struct komeda_component_state *c_st;
struct komeda_component *c;
- u32 disabling_comps, id;
+ u32 id;
+ unsigned long disabling_comps;
WARN_ON(!old);
@@ -1262,7 +1263,6 @@ int komeda_release_unclaimed_resources(struct
komeda_pipeline *pipe,
st = komeda_pipeline_get_new_state(pipe, drm_st);
else
st = komeda_pipeline_get_state_and_set_crtc(pipe, drm_st,
NULL);
-
NIT: Random white space change
if
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
On Thu, 21 Jan 2021, Fabio Estevam wrote: > On Thu, Jan 21, 2021 at 8:41 AM Jani Nikula wrote: > >> On top of what? Current drm-tip? > > It was on top of next-20210121. Kinda catch-22 because next has dropped current drm-intel-next because it doesn't build because of the issue this patch fixes. ;) BR, Jani. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: device naming cleanup
Rename ttm_bo_device to ttm_device.
Rename ttm_bo_driver to ttm_device_funcs.
Rename ttm_bo_global to ttm_global.
Move global and device related functions to ttm_device.[ch].
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 26 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 8 +-
drivers/gpu/drm/drm_gem_vram_helper.c | 14 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 20 +-
drivers/gpu/drm/nouveau/nouveau_bo.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +-
drivers/gpu/drm/nouveau/nouveau_ttm.h | 8 +-
drivers/gpu/drm/qxl/qxl_drv.h | 4 +-
drivers/gpu/drm/qxl/qxl_release.c | 6 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 19 +-
drivers/gpu/drm/radeon/radeon.h | 6 +-
drivers/gpu/drm/radeon/radeon_object.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 38 +-
drivers/gpu/drm/ttm/Makefile | 2 +-
drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 256 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 24 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 24 +-
drivers/gpu/drm/ttm/ttm_device.c | 195 +++
drivers/gpu/drm/ttm/ttm_execbuf_util.c| 8 +-
drivers/gpu/drm/ttm/ttm_range_manager.c | 4 +-
drivers/gpu/drm/ttm/ttm_resource.c| 4 +-
drivers/gpu/drm/ttm/ttm_tt.c | 26 +-
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 16 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 14 +-
include/drm/drm_gem_vram_helper.h | 6 +-
include/drm/ttm/ttm_bo_api.h | 35 +-
include/drm/ttm/ttm_bo_driver.h | 328 +-
include/drm/ttm/ttm_device.h | 319 +
include/drm/ttm/ttm_resource.h| 4 +-
include/drm/ttm/ttm_tt.h | 10 +-
41 files changed, 759 insertions(+), 715 deletions(-)
create mode 100644 drivers/gpu/drm/ttm/ttm_device.c
create mode 100644 include/drm/ttm/ttm_device.h
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f77443cd9c17..ab4ac3b2651e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1053,7 +1053,7 @@ static inline struct drm_device *adev_to_drm(struct
amdgpu_device *adev)
return >ddev;
}
-static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
+static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_device *bdev)
{
return container_of(bdev, struct amdgpu_device, mman.bdev);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
index 3107b9575929..5af464933976 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
@@ -40,13 +40,13 @@ static atomic_t fence_seq = ATOMIC_INIT(0);
* All the BOs in a process share an eviction fence. When process X wants
* to map VRAM memory but TTM can't find enough space, TTM will attempt to
* evict BOs from its LRU list. TTM checks if the BO is valuable to evict
- * by calling ttm_bo_driver->eviction_valuable().
+ * by calling ttm_device_funcs->eviction_valuable().
*
- * ttm_bo_driver->eviction_valuable() - will return false if the BO belongs
+ * ttm_device_funcs->eviction_valuable() - will return false if the BO belongs
* to process X. Otherwise, it will return true to indicate BO can be
* evicted by TTM.
*
- * If ttm_bo_driver->eviction_valuable returns true, then TTM will continue
+ * If ttm_device_funcs->eviction_valuable returns true, then TTM will continue
* the evcition process for that BO by calling ttm_bo_evict --> amdgpu_bo_move
* --> amdgpu_copy_buffer(). This sets up job in GPU scheduler.
*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 0db933026722..fde2d899b2c4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -71,7 +71,7 @@
*/
static int amdgpu_gart_dummy_page_init(struct amdgpu_device *adev)
{
- struct page *dummy_page = ttm_bo_glob.dummy_read_page;
+ struct page *dummy_page = ttm_glob.dummy_read_page;
if
Re: [PATCH v3 3/3] drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler
Hi Dmitry,
W dniu 17.01.2021 o 01:23, Dmitry Baryshkov pisze:
> drm hotplug handling code (drm_client_dev_hotplug()) can wait on mutex,
> thus delaying further lt9611uxc IRQ events processing. It was observed
> occasionally during bootups, when drm_client_modeset_probe() was waiting
> for EDID ready event, which was delayed because IRQ handler was stuck
> trying to deliver hotplug event.
> Move hotplug notifications from IRQ handler to separate work to be able
> to process IRQ events without delays.
>
> Signed-off-by: Dmitry Baryshkov
> Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
> Reviewed-by: Bjorn Andersson
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 30 +-
> 1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> index b708700e182d..209e39923914 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -36,6 +37,7 @@ struct lt9611uxc {
> struct mutex ocm_lock;
>
> struct wait_queue_head wq;
> + struct work_struct work;
>
> struct device_node *dsi0_node;
> struct device_node *dsi1_node;
> @@ -52,6 +54,7 @@ struct lt9611uxc {
>
> bool hpd_supported;
> bool edid_read;
> + bool hdmi_connected;
> uint8_t fw_version;
> };
>
> @@ -151,15 +154,26 @@ static irqreturn_t lt9611uxc_irq_thread_handler(int
> irq, void *dev_id)
> }
>
> if (irq_status & BIT(1)) {
> - if (lt9611uxc->connector.dev)
> - drm_kms_helper_hotplug_event(lt9611uxc->connector.dev);
> - else
> - drm_bridge_hpd_notify(>bridge, !!(hpd_status
> & BIT(1)));
> + lt9611uxc->hdmi_connected = !!(hpd_status & BIT(1));
No need for !!, int->bool implicit conversion will do the thing.
> + schedule_work(>work);
> }
>
> return IRQ_HANDLED;
> }
>
> +static void lt9611uxc_hpd_work(struct work_struct *work)
> +{
> + struct lt9611uxc *lt9611uxc = container_of(work, struct lt9611uxc,
> work);
> +
> + if (lt9611uxc->connector.dev)
> + drm_kms_helper_hotplug_event(lt9611uxc->connector.dev);
> + else
> + drm_bridge_hpd_notify(>bridge,
> + lt9611uxc->hdmi_connected ?
> + connector_status_connected :
> + connector_status_disconnected);
I am little bit worried about accessing lt9611uxc->hdmi_connected - it
is set in different thread, and there is no explicit sync code between
them. I guess it is possible to loss proper HPD signal, especially if
the HPD line is unstable (is there signal debouncing?).
> +}
> +
> static void lt9611uxc_reset(struct lt9611uxc *lt9611uxc)
> {
> gpiod_set_value_cansleep(lt9611uxc->reset_gpio, 1);
> @@ -447,7 +461,7 @@ static enum drm_connector_status
> lt9611uxc_bridge_detect(struct drm_bridge *brid
> struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
> unsigned int reg_val = 0;
> int ret;
> - int connected = 1;
> + bool connected = true;
>
> if (lt9611uxc->hpd_supported) {
> lt9611uxc_lock(lt9611uxc);
> @@ -457,8 +471,9 @@ static enum drm_connector_status
> lt9611uxc_bridge_detect(struct drm_bridge *brid
> if (ret)
> dev_err(lt9611uxc->dev, "failed to read hpd status:
> %d\n", ret);
> else
> - connected = reg_val & BIT(1);
> + connected = !!(reg_val & BIT(1));
Again no no need for !!.
I saw in v2 there was R-B tags added by Bjorn to other two patches,
please do not forgot them next time.
Regards
Andrzej
> }
> + lt9611uxc->hdmi_connected = connected;
>
> return connected ? connector_status_connected :
> connector_status_disconnected;
> @@ -931,6 +946,8 @@ static int lt9611uxc_probe(struct i2c_client *client,
> lt9611uxc->fw_version = ret;
>
> init_waitqueue_head(>wq);
> + INIT_WORK(>work, lt9611uxc_hpd_work);
> +
> ret = devm_request_threaded_irq(dev, client->irq, NULL,
> lt9611uxc_irq_thread_handler,
> IRQF_ONESHOT, "lt9611uxc", lt9611uxc);
> @@ -967,6 +984,7 @@ static int lt9611uxc_remove(struct i2c_client *client)
> struct lt9611uxc *lt9611uxc = i2c_get_clientdata(client);
>
> disable_irq(client->irq);
> + flush_scheduled_work();
> lt9611uxc_audio_exit(lt9611uxc);
> drm_bridge_remove(>bridge);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
On Thu, Jan 21, 2021 at 8:41 AM Jani Nikula wrote: > On top of what? Current drm-tip? It was on top of next-20210121. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
On Thu, 21 Jan 2021, Fabio Estevam wrote:
> Hi Jani,
>
> On Thu, Jan 21, 2021 at 8:22 AM Jani Nikula wrote:
>
>> Sean, Rob, or anyone with an arm toolchain for msm available, could I
>> trouble you to build test this please?
>
> I tried to build after applying your patch:
On top of what? Current drm-tip?
BR,
Jani.
>
> CC drivers/gpu/drm/msm/dp/dp_ctrl.o
> drivers/gpu/drm/msm/dp/dp_ctrl.c: In function ‘dp_ctrl_use_fixed_nvid’:
> drivers/gpu/drm/msm/dp/dp_ctrl.c:1429:11: error: too few arguments to
> function ‘drm_dp_has_quirk’
> 1429 | return (drm_dp_has_quirk(>panel->desc,
> | ^~~~
> In file included from drivers/gpu/drm/msm/dp/dp_ctrl.c:15:
> ./include/drm/drm_dp_helper.h:2101:1: note: declared here
> 2101 | drm_dp_has_quirk(const struct drm_dp_desc *desc, u32 edid_quirks,
> | ^~~~
> make[4]: *** [scripts/Makefile.build:287:
> drivers/gpu/drm/msm/dp/dp_ctrl.o] Error 1
> make[3]: *** [scripts/Makefile.build:530: drivers/gpu/drm/msm] Error 2
> make[2]: *** [scripts/Makefile.build:530: drivers/gpu/drm] Error 2
> make[1]: *** [scripts/Makefile.build:530: drivers/gpu] Error 2
> make: *** [Makefile:1819: drivers] Error 2
>
> I had to add the extra parameter like this:
>
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1420,16 +1420,14 @@ void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
> static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
> {
> u8 *dpcd = ctrl->panel->dpcd;
> - u32 edid_quirks = 0;
>
> - edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
> /*
> * For better interop experience, used a fixed NVID=0x8000
> * whenever connected to a VGA dongle downstream.
> */
> if (drm_dp_is_branch(dpcd))
> - return (drm_dp_has_quirk(>panel->desc, edid_quirks,
> - DP_DPCD_QUIRK_CONSTANT_N));
> + return (drm_dp_has_quirk(>panel->desc, 0,
> +DP_DPCD_QUIRK_CONSTANT_N));
>
> return false;
> }
>
> and then it builds.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
Hi Jani,
On Thu, Jan 21, 2021 at 8:22 AM Jani Nikula wrote:
> Sean, Rob, or anyone with an arm toolchain for msm available, could I
> trouble you to build test this please?
I tried to build after applying your patch:
CC drivers/gpu/drm/msm/dp/dp_ctrl.o
drivers/gpu/drm/msm/dp/dp_ctrl.c: In function ‘dp_ctrl_use_fixed_nvid’:
drivers/gpu/drm/msm/dp/dp_ctrl.c:1429:11: error: too few arguments to
function ‘drm_dp_has_quirk’
1429 | return (drm_dp_has_quirk(>panel->desc,
| ^~~~
In file included from drivers/gpu/drm/msm/dp/dp_ctrl.c:15:
./include/drm/drm_dp_helper.h:2101:1: note: declared here
2101 | drm_dp_has_quirk(const struct drm_dp_desc *desc, u32 edid_quirks,
| ^~~~
make[4]: *** [scripts/Makefile.build:287:
drivers/gpu/drm/msm/dp/dp_ctrl.o] Error 1
make[3]: *** [scripts/Makefile.build:530: drivers/gpu/drm/msm] Error 2
make[2]: *** [scripts/Makefile.build:530: drivers/gpu/drm] Error 2
make[1]: *** [scripts/Makefile.build:530: drivers/gpu] Error 2
make: *** [Makefile:1819: drivers] Error 2
I had to add the extra parameter like this:
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1420,16 +1420,14 @@ void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
{
u8 *dpcd = ctrl->panel->dpcd;
- u32 edid_quirks = 0;
- edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
/*
* For better interop experience, used a fixed NVID=0x8000
* whenever connected to a VGA dongle downstream.
*/
if (drm_dp_is_branch(dpcd))
- return (drm_dp_has_quirk(>panel->desc, edid_quirks,
- DP_DPCD_QUIRK_CONSTANT_N));
+ return (drm_dp_has_quirk(>panel->desc, 0,
+DP_DPCD_QUIRK_CONSTANT_N));
return false;
}
and then it builds.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Update todo.rst
Interrnship season is starting, let's review this. One thing that's pending is Maxime's work to roll out drm_atomic_state pointers to all callbacks, he said he'll remove that entry once it's all done. Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter --- Documentation/gpu/todo.rst | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 009d8e6c7e3c..492768dd2fd9 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -577,20 +577,24 @@ Contact: Daniel Vetter Level: Intermediate -KMS cleanups - +Object lifetime fixes +- + +There's two related issues here + +- Cleanup up the various ->destroy callbacks, which often are all the same + simple code. -Some of these date from the very introduction of KMS in 2008 ... +- Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc, + which results in use-after free issues on driver unload. This can be serious + trouble even for drivers for hardwared integrated on the SoC due to + EPROBE_DEFERRED backoff. -- Make ->funcs and ->helper_private vtables optional. There's a bunch of empty - function tables in drivers, but before we can remove them we need to make sure - that all the users in helpers and drivers do correctly check for a NULL - vtable. +Both these problems can be solved by switching over to drmm_kzalloc(), and the +various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), +drmm_universal_plane_alloc(), ... and so on. -- Cleanup up the various ->destroy callbacks. A lot of them just wrapt the - drm_*_cleanup implementations and can be removed. Some tack a kfree() at the - end, for which we could add drm_*_cleanup_kfree(). And then there's the (for - historical reasons) misnamed drm_primary_helper_destroy() function. +Contact: Daniel Vetter Level: Intermediate @@ -626,8 +630,6 @@ See the documentation of :ref:`VKMS ` for more details. This is an ideal internship task, since it only requires a virtual machine and can be sized to fit the available time. -Contact: Daniel Vetter - Level: See details Backlight Refactoring -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm: Improve the output_poll_changed description
On Thu, Jan 21, 2021 at 4:09 AM ZhiJie.Zhang wrote:
>
> From: zhangzhijie
>
> this callback was used by drm_kms_helper_hotplug_event()
>
> V2: (Thanks for Daniel's suggestions)
> - remove the FIXME below.since with the drm_client
> - infrastructure and the generic fbdev emulation we've
> - resolved this all very neatly now.
>
> V3: Add comments that This hook is deprecated
> - new implementation methods instead of this hook
>
> Signed-off-by: ZhiJie.Zhang
> ---
> include/drm/drm_mode_config.h | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..fbc0da25d7c5 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -103,14 +103,13 @@ struct drm_mode_config_funcs {
> * Callback used by helpers to inform the driver of output
> configuration
> * changes.
> *
> -* Drivers implementing fbdev emulation with the helpers can call
> -* drm_fb_helper_hotplug_changed from this hook to inform the fbdev
> -* helper of output changes.
Not sure why this isn't clear, but the above is important information
that we should keep. Maybe good to fix up the formatting to make it a
hyperlink, and your addition here is fine too, but the above is the
important part really.
-Daniel
> +* Drivers implementing fbdev emulation use
> drm_kms_helper_hotplug_event()
> +* to call this hook to inform the fbdev helper of output changes.
> *
> -* FIXME:
> -*
> -* Except that there's no vtable for device-level helper callbacks
> -* there's no reason this is a core function.
> +* This hook is deprecated, drivers should instead use
> +* drm_fbdev_generic_setup() which takes care of any necessary
> +* hotplug event forwarding already without further involvement by
> +* the driver.
> */
> void (*output_poll_changed)(struct drm_device *dev);
>
> --
> 2.29.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] drm/msm/dp: fix build after dp quirk helper change
On Wed, 20 Jan 2021, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
Thanks for the review.
Sean, Rob, or anyone with an arm toolchain for msm available, could I
trouble you to build test this please?
BR,
Jani.
>
> On Wed, 2021-01-20 at 13:07 +0200, Jani Nikula wrote:
>> Commit 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based
>> quirks"") removed drm_dp_get_edid_quirks() and changed the signature of
>> drm_dp_has_quirk() while they were still being used in msm. Fix the
>> breakage. Functionally, removing the EDID-based quirks has no impact on
>> msm.
>>
>> [The above commit was merged to drm-intel-next; make two wrongs a right
>> by merging this fix through drm-intel-next as well.]
>>
>> Reported-by: Stephen Rothwell
>> References:
>> http://lore.kernel.org/r/20210120105715.4391d...@canb.auug.org.au
>> Fixes: 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based quirks"")
>> Cc: Lyude Paul
>> Acked-by: Daniel Vetter
>> Cc: Rob Clark
>> Cc: Sean Paul
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: Jani Nikula
>>
>> ---
>>
>> Note: I admit to not even build testing this one. I'd need a config,
>> possibly also a toolchain setup for that.
>> ---
>> drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> index e3462f5d96d7..36b39c381b3f 100644
>> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> @@ -1420,16 +1420,14 @@ void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
>> static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
>> {
>> u8 *dpcd = ctrl->panel->dpcd;
>> - u32 edid_quirks = 0;
>>
>> - edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
>> /*
>> * For better interop experience, used a fixed NVID=0x8000
>> * whenever connected to a VGA dongle downstream.
>> */
>> if (drm_dp_is_branch(dpcd))
>> - return (drm_dp_has_quirk(>panel->desc, edid_quirks,
>> - DP_DPCD_QUIRK_CONSTANT_N));
>> + return (drm_dp_has_quirk(>panel->desc,
>> + DP_DPCD_QUIRK_CONSTANT_N));
>>
>> return false;
>> }
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/rockchip: dsi: move all lane config except LCDC mux to bind()
В Вс, 13/12/2020 в 12:58 -0800, Thomas Hebb пишет:
> When we first enable the DSI encoder, we currently program some per-chip
> configuration that we look up in rk3399_chip_data based on the device
> tree compatible we match. This data configures various parameters of the
> MIPI lanes, including on RK3399 whether DSI1 is slaved to DSI0 in a
> dual-mode configuration. It also selects which LCDC (i.e. VOP) to scan
> out from.
>
> This causes a problem in RK3399 dual-mode configurations, though: panel
> prepare() callbacks run before the encoder gets enabled and expect to be
> able to write commands to the DSI bus, but the bus isn't fully
> functional until the lane and master/slave configuration have been
> programmed. As a result, dual-mode panels (and possibly others too) fail
> to turn on when the rockchipdrm driver is initially loaded.
>
> Because the LCDC mux is the only thing we don't know until enable time
> (and is the only thing that can ever change), we can actually move most
> of the initialization to bind() and get it out of the way early. That's
> what this change does. (Rockchip's 4.4 BSP kernel does it in mode_set(),
> which also avoids the issue, but bind() seems like the more correct
> place to me.)
>
> Tested on a Google Scarlet board (Acer Chromebook Tab 10), which has a
> Kingdisplay KD097D04 dual-mode panel. Prior to this change, the panel's
> backlight would turn on but no image would appear when initially loading
> rockchipdrm. If I kept rockchipdrm loaded and reloaded the panel driver,
> it would come on. With this change, the panel successfully turns on
> during initial rockchipdrm load as expected.
>
> Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
> driver")
> Signed-off-by: Thomas Hebb
> ---
> Resending since I wasn't subscribed to dri-devel
>
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 36 ++-
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index ce044db8c97e..d0c9610ad220 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -691,13 +691,8 @@ static const struct dw_mipi_dsi_phy_ops
> dw_mipi_dsi_rockchip_phy_ops = {
> .get_timing = dw_mipi_dsi_phy_get_timing,
> };
>
>
> -static void dw_mipi_dsi_rockchip_config(struct dw_mipi_dsi_rockchip *dsi,
> - int mux)
> +static void dw_mipi_dsi_rockchip_config(struct dw_mipi_dsi_rockchip *dsi)
> {
> - if (dsi->cdata->lcdsel_grf_reg)
> - regmap_write(dsi->grf_regmap, dsi->cdata->lcdsel_grf_reg,
> - mux ? dsi->cdata->lcdsel_lit : dsi->cdata->lcdsel_big);
> -
> if (dsi->cdata->lanecfg1_grf_reg)
> regmap_write(dsi->grf_regmap, dsi->cdata->lanecfg1_grf_reg,
> dsi->cdata->lanecfg1);
> @@ -711,6 +706,13 @@ static void dw_mipi_dsi_rockchip_config(struct
> dw_mipi_dsi_rockchip *dsi,
> dsi->cdata->enable);
> }
>
>
> +static void dw_mipi_dsi_rockchip_set_lcdsel(struct dw_mipi_dsi_rockchip *dsi,
> + int mux)
> +{
> + regmap_write(dsi->grf_regmap, dsi->cdata->lcdsel_grf_reg,
> + mux ? dsi->cdata->lcdsel_lit : dsi->cdata->lcdsel_big);
> +}
> +
> static int
> dw_mipi_dsi_encoder_atomic_check(struct drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> @@ -766,9 +768,9 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
> *encoder)
> return;
> }
>
>
> - dw_mipi_dsi_rockchip_config(dsi, mux);
> + dw_mipi_dsi_rockchip_set_lcdsel(dsi, mux);
> if (dsi->slave)
> - dw_mipi_dsi_rockchip_config(dsi->slave, mux);
> + dw_mipi_dsi_rockchip_set_lcdsel(dsi->slave, mux);
>
>
> clk_disable_unprepare(dsi->grf_clk);
> }
> @@ -922,6 +924,24 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> return ret;
> }
>
>
> + /*
> + * With the GRF clock running, write lane and dual-mode configurations
> + * that won't change immediately. If we waited until enable() to do
> + * this, things like panel preparation would not be able to send
> + * commands over DSI.
> + */
> + ret = clk_prepare_enable(dsi->grf_clk);
> + if (ret) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
> + return ret;
> + }
> +
> + dw_mipi_dsi_rockchip_config(dsi);
> + if (dsi->slave)
> + dw_mipi_dsi_rockchip_config(dsi->slave);
> +
> + clk_disable_unprepare(dsi->grf_clk);
> +
> ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
Have tested this patch on a Pine64
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
On Wed, Jan 20, 2021 at 8:16 PM Andrey Grodzovsky
wrote:
>
>
> On 1/20/21 3:38 AM, Daniel Vetter wrote:
> > On Wed, Jan 20, 2021 at 5:21 AM Andrey Grodzovsky
> > wrote:
> >>
> >> On 1/19/21 5:01 PM, Daniel Vetter wrote:
> >>> On Tue, Jan 19, 2021 at 10:22 PM Andrey Grodzovsky
> >>> wrote:
> On 1/19/21 8:45 AM, Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
>
> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
>
> Handle all DMA IOMMU gropup related dependencies before the
> group is removed.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46
> ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
> 6 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 478a7d8..2953420 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -51,6 +51,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> @@ -1041,6 +1042,10 @@ struct amdgpu_device {
> boolin_pci_err_recovery;
> struct pci_saved_state *pci_state;
> +
> + struct notifier_block nb;
> + struct blocking_notifier_head notifier;
> + struct list_head device_bo_list;
> };
> static inline struct amdgpu_device *drm_to_adev(struct drm_device
> *ddev)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 45e23e3..e99f4f1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -70,6 +70,8 @@
> #include
> #include
> +#include
> +
> MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
> MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
> MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
> @@ -3200,6 +3202,39 @@ static const struct attribute
> *amdgpu_dev_attributes[] = {
> };
> +static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct amdgpu_device *adev = container_of(nb, struct amdgpu_device,
> nb);
> + struct amdgpu_bo *bo = NULL;
> +
> + /*
> + * Following is a set of IOMMU group dependencies taken care of before
> + * device's IOMMU group is removed
> + */
> + if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
> +
> + spin_lock(_bo_glob.lru_lock);
> + list_for_each_entry(bo, >device_bo_list, bo) {
> + if (bo->tbo.ttm)
> + ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
> + }
> + spin_unlock(_bo_glob.lru_lock);
>
> That approach won't work. ttm_tt_unpopulate() might sleep on an IOMMU
> lock.
>
> You need to use a mutex here or even better make sure you can access the
> device_bo_list without a lock in this moment.
>
> I'd also be worried about the notifier mutex getting really badly in the
> way.
>
> Plus I'm worried why we even need this, it sounds a bit like papering
> over
> the iommu subsystem. Assuming we clean up all our iommu mappings in our
> device hotunplug/unload code, why do we still need to have an additional
> iommu notifier on top, with all kinds of additional headaches? The iommu
> shouldn't clean up before the devices in its group have cleaned up.
>
> I think we need more info here on what the exact problem is first.
> -Daniel
>
>
> Originally I experienced the crash bellow on IOMMU enabled device, it
> happens post device removal from PCI topology -
> during shutting down of user client holding last reference to drm device
> file (X in my case).
> The crash is because by the time I get to this point struct
> device->iommu_group pointer is NULL
> already since the IOMMU group for the device is unset during PCI
> removal. So this contradicts what you said above
> that the iommu shouldn't clean up before the devices in its group have
> cleaned up.
> So instead of guessing when is the right place to place all IOMMU
> related cleanups it makes sense
> to get notification from IOMMU subsystem in the form of event
> IOMMU_GROUP_NOTIFY_DEL_DEVICE
> and use that place to do all the relevant cleanups.
> >>> Yeah
Re: [PATCH 1/1] drm/scheduler: Job timeout handler returns status (v3)
Am 20.01.21 um 21:09 schrieb Luben Tuikov:
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the device (GPU) is no longer available, such as
after it's been unplugged, or whether all is
normal, i.e. current behaviour.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_GPU_SCHED_STAT_NOMINAL to restart the task's
timeout timer--this is the old behaviour, and is
preserved by this patch.
v2: Use enum as the status of a driver's job
timeout callback method.
v3: Return scheduler/device information, rather
than task information.
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
Reported-by: kernel test robot
Signed-off-by: Luben Tuikov
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 7 +-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32 +
include/drm/gpu_scheduler.h | 18 +++---
7 files changed, 52 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..759b34799221 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_gpu_sched_stat amdgpu_job_timedout(struct drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent))
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_GPU_SCHED_STAT_NOMINAL;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, );
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_GPU_SCHED_STAT_NOMINAL;
} else {
drm_sched_suspend_timeout(>sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_GPU_SCHED_STAT_NOMINAL;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..2a9439cbb0fb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_job(struct
drm_sched_job *sched_job)
return fence;
}
-static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
+static enum drm_gpu_sched_stat etnaviv_sched_timedout_job(struct drm_sched_job
+ *sched_job)
{
struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
struct etnaviv_gpu *gpu = submit->gpu;
@@ -120,9 +121,13 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
drm_sched_resubmit_jobs(>sched);
+ drm_sched_start(>sched, true);
+ return DRM_GPU_SCHED_STAT_NOMINAL;
+
out_no_timeout:
/* restart scheduler after GPU is usable again */
drm_sched_start(>sched, true);
+ return DRM_GPU_SCHED_STAT_NOMINAL;
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index 63b4c5643f9c..6e4273852712 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -415,7 +415,7 @@ static void lima_sched_build_error_task_list(struct
lima_sched_task *task)
mutex_unlock(>error_task_list_lock);
}
-static void lima_sched_timedout_job(struct drm_sched_job *job)
+static enum drm_gpu_sched_stat lima_sched_timedout_job(struct drm_sched_job
*job)
{
struct lima_sched_pipe *pipe = to_lima_pipe(job->sched);
struct lima_sched_task *task = to_lima_task(job);
@@ -449,6 +449,8 @@ static void lima_sched_timedout_job(struct drm_sched_job
*job)
drm_sched_resubmit_jobs(>base);
drm_sched_start(>base, true);
+
+ return
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
Am 20.01.21 um 20:38 schrieb Andrey Grodzovsky:
Ping
Andrey
On 1/20/21 12:01 AM, Andrey Grodzovsky wrote:
On 1/19/21 3:48 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46
++
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
6 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 478a7d8..2953420 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1041,6 +1042,10 @@ struct amdgpu_device {
bool in_pci_err_recovery;
struct pci_saved_state *pci_state;
+
+ struct notifier_block nb;
+ struct blocking_notifier_head notifier;
+ struct list_head device_bo_list;
};
static inline struct amdgpu_device *drm_to_adev(struct
drm_device *ddev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 45e23e3..e99f4f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -70,6 +70,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -3200,6 +3202,39 @@ static const struct attribute
*amdgpu_dev_attributes[] = {
};
+static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct amdgpu_device *adev = container_of(nb, struct
amdgpu_device, nb);
+ struct amdgpu_bo *bo = NULL;
+
+ /*
+ * Following is a set of IOMMU group dependencies taken care
of before
+ * device's IOMMU group is removed
+ */
+ if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
+
+ spin_lock(_bo_glob.lru_lock);
+ list_for_each_entry(bo, >device_bo_list, bo) {
+ if (bo->tbo.ttm)
+ ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
+ }
+ spin_unlock(_bo_glob.lru_lock);
That approach won't work. ttm_tt_unpopulate() might sleep on an
IOMMU lock.
You need to use a mutex here or even better make sure you can access
the device_bo_list without a lock in this moment.
Christian.
I can think of switching to RCU list ? Otherwise, elements are added
on BO create and deleted on BO destroy, how can i prevent any of
those from
happening while in this section besides mutex ? Make a copy list and
run over it instead ?
RCU won't work since the BO is not RCU protected.
What you can try something like this:
spin_lock(_bo_glob.lru_lock);
while (list_not_empty(>device_bo_list)) {
bo = list_first_entry(>device_bo_list);
list_del(bo->...);
spin_unlock(_bo_glob.lru_lock);
ttm_tt_unpopulate(bo);
spin_lock(_bo_glob.lru_lock);
}...
Regards,
Christian.
Andrey
+
+ if (adev->irq.ih.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, >irq.ih);
+ if (adev->irq.ih1.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, >irq.ih1);
+ if (adev->irq.ih2.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, >irq.ih2);
+
+ amdgpu_gart_dummy_page_fini(adev);
+ }
+
+ return NOTIFY_OK;
+}
+
+
/**
* amdgpu_device_init - initialize the driver
*
@@ -3304,6 +3339,8 @@ int amdgpu_device_init(struct amdgpu_device
*adev,
INIT_WORK(>xgmi_reset_work,
amdgpu_device_xgmi_reset_func);
+ INIT_LIST_HEAD(>device_bo_list);
+
adev->gfx.gfx_off_req_count = 1;
adev->pm.ac_power = power_supply_is_system_supplied() > 0;
@@ -3575,6 +3612,15 @@ int amdgpu_device_init(struct
amdgpu_device *adev,
if (amdgpu_device_cache_pci_state(adev->pdev))
pci_restore_state(pdev);
+ BLOCKING_INIT_NOTIFIER_HEAD(>notifier);
+ adev->nb.notifier_call = amdgpu_iommu_group_notifier;
+
+ if (adev->dev->iommu_group) {
+ r = iommu_group_register_notifier(adev->dev->iommu_group,
>nb);
+ if (r)
+ goto failed;
+ }
+
return 0;
failed:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 0db9330..486ad6d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct
amdgpu_device *adev)
*
* Frees the dummy page used by the driver (all asics).
*/
-static void
Re: [PATCH v4 0/3] Generic USB Display driver
On Thursday, January 21st, 2021 at 10:59 AM, Thomas Zimmermann wrote: > Well, I'd strongly ask to not call it "generic", because it isn't. We > have other USB drivers and anyone can make a USB display with these > protocols as well. That doesn't make them generic. A USB-standardized > protocol would be generic. Maybe call it custom, or home-made. Maybe rename it to "GUD USB Display driver"? :P ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] drm/uapi: Add USB connector type
Hi
Am 21.01.21 um 09:27 schrieb Daniel Vetter:
On Thu, Jan 21, 2021 at 8:45 AM Thomas Zimmermann wrote:
Hi Noralf,
glad to hear from you! Welcome back!
Am 20.01.21 um 18:42 schrieb Daniel Vetter:
On Wed, Jan 20, 2021 at 6:10 PM Noralf Trønnes wrote:
Add a connector type for USB connected display panels.
Signed-off-by: Noralf Trønnes
---
include/uapi/drm/drm_mode.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fed66a03c7ae..33024cc5d26e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -367,6 +367,7 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_DPI 17
#define DRM_MODE_CONNECTOR_WRITEBACK 18
#define DRM_MODE_CONNECTOR_SPI 19
+#define DRM_MODE_CONNECTOR_USB 20
I would not call it USB. I could imagine that at some point a generic
USB protocol could serve simple displays (i.e. in the sense of USB HID
or data or imaging). (Maybe Thunderbold already counts.) Anyway, USB
should be reserved for this case.
We end up calling those DisplayPort, since that's what's being
transported over thunderbolt or usb-C. So the usb connector would be
called usb-C. I think the reason we don't do fancy connector names is
that adding them is a bit a pain. Plus drm/i915 specifically has some
very quirky connector enumerating that doesn't match much with reality
unfortunately anyway :-/
In the case of the other USB drivers, IIRC we use the connector type
that is at the output (i.e., HDMI in the case of udl). I think we should
do the same here. Or use 'Unknown'.
Best regards
Thomas
-Daniel
Best regards
Thomas
Beware, new connector types have in the past resulted in userspace
burning Maybe it's become better ...
Acked-by: Daniel Vetter
/**
* struct drm_mode_get_connector - Get connector metadata.
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
--
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
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] Generic USB Display driver
Hi Am 20.01.21 um 18:00 schrieb Noralf Trønnes: Hi, A while back I had the idea to turn a Raspberry Pi Zero into a $5 USB to HDMI/SDTV/DSI/DPI display adapter. The reason for calling it 'Generic' is so anyone can make a USB display/adapter against this driver, all that's needed is to add a USB vid:pid. Well, I'd strongly ask to not call it "generic", because it isn't. We have other USB drivers and anyone can make a USB display with these protocols as well. That doesn't make them generic. A USB-standardized protocol would be generic. Maybe call it custom, or home-made. Best regards Thomas Unfortunately I've had some compounding health problems that have severally limited the time I can spend in front of a computer. For this reason I've decided to keep the gadget driver out-of-tree and focus on getting the host driver merged first. See the wiki[1] for more information and images for the Raspberry Pi Zero/4. One big change this time is that I've followed Peter Stuge's advice to not let DRM stuff leak into the USB protocol. This has made the protocol easier to understand just from reading the header file. Noralf. [1] https://github.com/notro/gud/wiki Noralf Trønnes (3): drm/uapi: Add USB connector type drm/probe-helper: Check epoch counter in output_poll_execute() drm: Add Generic USB Display driver MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_probe_helper.c | 7 +- drivers/gpu/drm/gud/Kconfig | 14 + drivers/gpu/drm/gud/Makefile| 4 + drivers/gpu/drm/gud/gud_connector.c | 722 drivers/gpu/drm/gud/gud_drv.c | 620 drivers/gpu/drm/gud/gud_internal.h | 148 ++ drivers/gpu/drm/gud/gud_pipe.c | 472 ++ include/drm/gud.h | 356 ++ include/uapi/drm/drm_mode.h | 1 + 12 files changed, 2354 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/gud/Kconfig create mode 100644 drivers/gpu/drm/gud/Makefile create mode 100644 drivers/gpu/drm/gud/gud_connector.c create mode 100644 drivers/gpu/drm/gud/gud_drv.c create mode 100644 drivers/gpu/drm/gud/gud_internal.h create mode 100644 drivers/gpu/drm/gud/gud_pipe.c create mode 100644 include/drm/gud.h -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Wed, Jan 20, 2021 at 10:52:11AM -0800, Yiwei Zhang wrote:
> On Wed, Jan 20, 2021 at 5:33 AM Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > > > > + select TRACE_GPU_MEM
> >
> > > > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> >
> > That doesn't make sense btw.
>
> Do you recommend we just select it or leave it an option?
The patch selects it (which makes sense given the small size).
The #ifdef is pointless then ...
> > > > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > > > +static inline void virtio_gpu_trace_total_mem(struct
> > > > > > > virtio_gpu_device *vgdev,
> > > > > > > + s64 delta)
> > > > > > > +{
> > > > > > > + u64 total_mem = atomic64_add_return(delta,
> > > > > > > >total_mem);
> > > > > > > +
> > > > > > > + trace_gpu_mem_total(0, 0, total_mem);
> >
> > Hmm, so no per process tracking (pid arg hard-coded to zero)?
> > Any plans for that?
> > The cgroups patches mentioned by Daniel should address that btw.
>
> Android GPU vendors do report the totals for each process as well. For
> Cuttlefish virtual platform, we haven't yet required that, and want to
> get the global total in place first.
That means no plans yet?
> > > > > Android relies on this tracepoint + eBPF to make the GPU memory totals
> > > > > available at runtime on production devices, which has been enforced
> > > > > already. Not only game developers can have a reliable kernel total GPU
> > > > > memory to look at, but also Android leverages this to take GPU memory
> > > > > usage out from the system lost ram.
> >
> > Sounds like you define "gpu memory" as "system memory used to store gpu
> > data". Is that correct? What about device memory?
>
> The total definition does include all device memory being used as well
> for numa devices.(If my understanding of your question is correct.)
device memory == gpu-owned memory, typically exposed to as pci memory bar.
qemu stdvga for example stores gem objects in device memory (unless it
runs out of vram, then ttm allocates from / moves into main memory).
> > > > > I'm not sure whether the other DRM drivers would like to integrate
> > > > > this tracepoint(maybe upstream drivers will move away from debugfs
> > > > > later as well?), but at least we hope virtio-gpu can take this.
> >
> > Well, it is basically the same for all drivers using the gem shmem
> > helpers. So I see little reason why we should do that at virtio-gpu
> > level.
>
> This can be a starting point. Another reason would be I'm fearing that
> this tracepoint approach might be more difficult to get upstreamed at
> drm layer level, since later we may want to get to per-process total
> tracking, which would be making more sense at device driver level.
Tracking in __drm_gem_shmem_create + drm_gem_shmem_free_object should
give you pretty much the same results, with the major difference being
that it works for all shmem-based drivers.
Of course just moving the trace points doesn't solve the other issues
discussed.
> > > Android GPU vendors have integrated this tracepoint to track gpu
> > > memory usage total(mapped into the gpu address space), which consists
> > > of below:
> > > (1) directly allocated via physical page allocator
> > > (2) imported external memory backed by dma-bufs
> > > (3) allocated exportable memory backed by dma-bufs
> >
> > Hmm, the tracepoint doesn't track which of the three groups the memory
> > belongs to. Which I think is important, specifically group (2) because
> > that might already be accounted for by the exporting driver ...
>
> The tracepoint only cares about a total number, but I'm not against
> the idea to extend the tracepoint with categorization. However, I
> believe the dma-bufs core can track which dma-buf gets attached/mapped
> to some devices. So that those overlap between dma-buf heaps and the
> gpu memory total we are tracking here can be canceled out.
Yep, maybe. Which is *exactly* why Daniel keeps asking for the big
picture and how this integrates/interacts with the dma-buf accounting
which seems to be in the works too.
Note that dma-bufs are not only used for cross-device sharing. They are
also used to pass handles from one application to another (application
to wayland compositor or x server for example). Which doesn't matter
much for the totals, but for per-process accounting you need a plan how
to account these shared buffers.
> > I suspect once you figured that you'll notice that this little hack is
> > rather incomplete.
>
> Despite the dma-buf side effort, we still wish to have this tracepoint
> integrated in virtio-gpu just for a global total at this moment.
I don't feel like merging patches with obvious shortcomings which have
a high chance to end up as technical dept.
The question how this interacts with dma-buf accounting must be
clarified.
I'd also suggest to join forces with the cgroups people. The problem
space has alot of overlap. Even if we end up with multiple ways to
export the
Re: [PATCH 24/31] memory: tegra20: convert to use devm_pm_opp_* API
01.01.2021 19:55, Yangtao Li пишет: > Use devm_pm_opp_* API to simplify code. > > Signed-off-by: Yangtao Li > --- > drivers/memory/tegra/tegra20-emc.c | 29 + > 1 file changed, 9 insertions(+), 20 deletions(-) There are also tegra30-emc.c and tegra124-emc.c with a similar OPP code. But could we please not touch these memory drivers? I already have a prepared patch which replaces all the tegra_emc_opp_table_init() with a single common helper that will use devm_opp_* helpers. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/ingenic: Register devm action to cleanup encoders
Le mer. 20 janv. 2021 à 15:04, Daniel Vetter a
écrit :
On Wed, Jan 20, 2021 at 2:21 PM Paul Cercueil
wrote:
Le mer. 20 janv. 2021 à 14:01, Daniel Vetter a
écrit :
> On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil
> wrote:
>>
>> Since the encoders have been devm-allocated, they will be freed
way
>> before drm_mode_config_cleanup() is called. To avoid
use-after-free
>> conditions, we then must ensure that drm_encoder_cleanup() is
called
>> before the encoders are freed.
>>
>> v2: Use the new __drmm_simple_encoder_alloc() function
>>
>> Fixes: c369cb27c267 ("drm/ingenic: Support multiple
panels/bridges")
>> Cc: # 5.8+
>> Signed-off-by: Paul Cercueil
>> ---
>>
>> Notes:
>> Use the V1 of this patch to fix v5.11 and older kernels.
This
>> V2 only
>> applies on the current drm-misc-next branch.
>>
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16 +++-
>> 1 file changed, 7 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> index 7bb31fbee29d..158433b4c084 100644
>> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> @@ -1014,20 +1014,18 @@ static int ingenic_drm_bind(struct
device
>> *dev, bool has_components)
>> bridge =
>> devm_drm_panel_bridge_add_typed(dev, panel,
>>
>> DRM_MODE_CONNECTOR_DPI);
>>
>> - encoder = devm_kzalloc(dev, sizeof(*encoder),
>> GFP_KERNEL);
>> - if (!encoder)
>> - return -ENOMEM;
>> + encoder = __drmm_simple_encoder_alloc(drm,
>> sizeof(*encoder), 0,
>
> Please don't use the __ prefixed functions, those are the internal
> ones. The official one comes with type checking and all that
included.
> Otherwise lgtm.
> -Daniel
The non-prefixed one assumes that I want to allocate a struct that
contains the encoder, not just the drm_encoder itself.
Hm, but using the internal one is also a bit too ugly. A
drm_plain_simple_enocder_alloc(drm, type) wrapper would be the right
thing here I think? Setting the offsets and struct sizes directly in
these in drivers really doesn't feel like a good idea. I think simple
encoder is the only case where we really have a need for a
non-embeddable struct.
-Daniel
Alright, I will add a wrapper.
Cheers,
-Paul
>> +
>> DRM_MODE_ENCODER_DPI);
>> + if (IS_ERR(encoder)) {
>> + ret = PTR_ERR(encoder);
>> + dev_err(dev, "Failed to init encoder:
>> %d\n", ret);
>> + return ret;
>> + }
>>
>> encoder->possible_crtcs = 1;
>>
>> drm_encoder_helper_add(encoder,
>> _drm_encoder_helper_funcs);
>>
>> - ret = drm_simple_encoder_init(drm, encoder,
>> DRM_MODE_ENCODER_DPI);
>> - if (ret) {
>> - dev_err(dev, "Failed to init encoder:
>> %d\n", ret);
>> - return ret;
>> - }
>> -
>> ret = drm_bridge_attach(encoder, bridge, NULL,
0);
>> if (ret) {
>> dev_err(dev, "Unable to attach
bridge\n");
>> --
>> 2.29.2
>>
>
>
> --
> 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
[PATCH v2 6/7] ARM: dts: imx6dl-prtvt7: fix PWM cell count for the backlight node.
At some point PWM cell count was changed, but it didn't triggered any
error, since this DT was overwriting "#pwm-cells".
To make sure, we are in sync with the kernel driver, remove this
property and fix the pwm consumer.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
index 8a1491975da8..83b461eb33a2 100644
--- a/arch/arm/boot/dts/imx6dl-prtvt7.dts
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -21,7 +21,7 @@ memory@1000 {
backlight_lcd: backlight-lcd {
compatible = "pwm-backlight";
- pwms = < 0 50>;
+ pwms = < 0 50 0>;
brightness-levels = <0 20 81 248 1000>;
default-brightness-level = <20>;
num-interpolated-steps = <21>;
@@ -320,7 +320,6 @@ _di0_disp0 {
};
{
- #pwm-cells = <2>;
pinctrl-names = "default";
pinctrl-0 = <_pwm1>;
status = "okay";
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/ingenic: Register devm action to cleanup encoders
Le mer. 20 janv. 2021 à 14:01, Daniel Vetter a
écrit :
On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil
wrote:
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that drm_encoder_cleanup() is called
before the encoders are freed.
v2: Use the new __drmm_simple_encoder_alloc() function
Fixes: c369cb27c267 ("drm/ingenic: Support multiple panels/bridges")
Cc: # 5.8+
Signed-off-by: Paul Cercueil
---
Notes:
Use the V1 of this patch to fix v5.11 and older kernels. This
V2 only
applies on the current drm-misc-next branch.
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 7bb31fbee29d..158433b4c084 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -1014,20 +1014,18 @@ static int ingenic_drm_bind(struct device
*dev, bool has_components)
bridge =
devm_drm_panel_bridge_add_typed(dev, panel,
DRM_MODE_CONNECTOR_DPI);
- encoder = devm_kzalloc(dev, sizeof(*encoder),
GFP_KERNEL);
- if (!encoder)
- return -ENOMEM;
+ encoder = __drmm_simple_encoder_alloc(drm,
sizeof(*encoder), 0,
Please don't use the __ prefixed functions, those are the internal
ones. The official one comes with type checking and all that included.
Otherwise lgtm.
-Daniel
The non-prefixed one assumes that I want to allocate a struct that
contains the encoder, not just the drm_encoder itself.
-Paul
+
DRM_MODE_ENCODER_DPI);
+ if (IS_ERR(encoder)) {
+ ret = PTR_ERR(encoder);
+ dev_err(dev, "Failed to init encoder:
%d\n", ret);
+ return ret;
+ }
encoder->possible_crtcs = 1;
drm_encoder_helper_add(encoder,
_drm_encoder_helper_funcs);
- ret = drm_simple_encoder_init(drm, encoder,
DRM_MODE_ENCODER_DPI);
- if (ret) {
- dev_err(dev, "Failed to init encoder:
%d\n", ret);
- return ret;
- }
-
ret = drm_bridge_attach(encoder, bridge, NULL, 0);
if (ret) {
dev_err(dev, "Unable to attach bridge\n");
--
2.29.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
[PATCH v2 5/7] ARM: dts: imx6dl-prtvt7: Remove backlight enable gpio
The backlight power is controlled through the reg_bl_12v0 regulator.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
index 836026a0e219..8a1491975da8 100644
--- a/arch/arm/boot/dts/imx6dl-prtvt7.dts
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -21,14 +21,11 @@ memory@1000 {
backlight_lcd: backlight-lcd {
compatible = "pwm-backlight";
- pinctrl-names = "default";
- pinctrl-0 = <_backlight>;
pwms = < 0 50>;
brightness-levels = <0 20 81 248 1000>;
default-brightness-level = <20>;
num-interpolated-steps = <21>;
power-supply = <_bl_12v0>;
- enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
};
display {
@@ -362,12 +359,6 @@ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS0x130b0
>;
};
- pinctrl_backlight: backlightgrp {
- fsl,pins = <
- MX6QDL_PAD_DISP0_DAT7__GPIO4_IO28 0x1b0b0
- >;
- };
-
pinctrl_can1phy: can1phy {
fsl,pins = <
/* CAN1_SR */
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] dt-bindings: display: simple: add Innolux G070Y2-T02 panel
Add binding for the Innolux G070Y2-T02 panel. It is 7" WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit. Signed-off-by: Oleksij Rempel --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 3207608d1178..f7a1465313db 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -152,6 +152,8 @@ properties: - innolux,at070tn92 # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel - innolux,g070y2-l01 +# Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel + - innolux,g070y2-t02 # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel - innolux,g101ice-l01 # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 4/7] ARM: dts: imx6dl-prtvt7: add TSC2046 touchscreen node
Add touchscreen support to the Protonic VT7 board.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
index d9cb1e41cc10..63ae2065834c 100644
--- a/arch/arm/boot/dts/imx6dl-prtvt7.dts
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -266,6 +266,26 @@ {
pinctrl-names = "default";
pinctrl-0 = <_ecspi2>;
status = "okay";
+
+ touchscreen@0 {
+ compatible = "ti,tsc2046";
+ reg = <0>;
+ pinctrl-0 = <_tsc>;
+ pinctrl-names ="default";
+ spi-max-frequency = <10>;
+ interrupts-extended = < 20 IRQ_TYPE_EDGE_FALLING>;
+ pendown-gpio = < 20 GPIO_ACTIVE_LOW>;
+
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ touchscreen-max-pressure = <4095>;
+
+ ti,vref-delay-usecs = /bits/ 16 <100>;
+ ti,x-plate-ohms = /bits/ 16 <800>;
+ ti,y-plate-ohms = /bits/ 16 <300>;
+
+ wakeup-source;
+ };
};
{
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state
Artificially use 'plane' and 'old_plane_state' to avoid 'not used' warning. The precedent has already been set by other macros in the same file. Acked-by: Daniel Vetter Signed-off-by: Liu Ying --- v5->v6: * Fix commit message typo - s/Artifically/Artificially/ v4->v5: * No change. v3->v4: * Add Daniel's A-b tag. v2->v3: * Add a missing blank line. v1->v2: * No change. include/drm/drm_atomic.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index ce7023e..6ade7a1 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -908,7 +908,10 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p); (__i)++) \ for_each_if ((__state)->planes[__i].ptr && \ ((plane) = (__state)->planes[__i].ptr, \ - (old_plane_state) = (__state)->planes[__i].old_state, 1)) + (void)(plane) /* Only to avoid unused-but-set-variable warning */, \ + (old_plane_state) = (__state)->planes[__i].old_state, \ + (void)(old_plane_state) /* Only to avoid unused-but-set-variable warning */, 1)) + /** * for_each_new_plane_in_state - iterate over all planes in an atomic update * @__state: drm_atomic_state pointer -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..9e05c83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+ fetches display data before the display pipeline needs the data to drive
+ pixels in the active display region. This data is transformed, or resolved,
+ from a variety of tiled buffer formats into linear format, if needed.
+ The DPR works with a double bank memory structure. This memory structure is
+ implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+ as A and B. Each bank is either 4 or 8 lines high depending on the source
+ frame buffer format.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-dpr-channel
+ - fsl,imx8qm-dpr-channel
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: apb clock
+ - description: b clock
+ - description: rtram clock
+
+ clock-names:
+items:
+ - const: apb
+ - const: b
+ - const: rtram
+
+ fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+ fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ List of phandle which points to Prefetch Resolve Gaskets(PRGs)
+ associated with this DPRC instance.
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - fsl,sc-resource
+ - fsl,prgs
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts = ;
+clocks = <_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <_prg4>, <_prg5>;
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4, 03/10] soc: mediatek: mmsys: move register operation into mmsys path select function
On Wed, 2021-01-20 at 20:38 +0100, Matthias Brugger wrote:
> On Tue, Jan 05, 2021 at 11:06:26AM +0800, Yongqiang Niu wrote:
> > move register operation into mmsys path select function
>
> Why do you want to do that. It seems the register access pattern is the
> same for all SoCs so far supported, so I don't see the need to duplicate
> the code in every SoC.
>
> Regards,
> Matthias
mt2701 and mt8173 ovl mout en already different.
mt2701 ovl mout en register offset is 0x30
mt8173 olv mout en register offset is 0x40
only the use case is different;
mt2701 ovl->color0
mt8173 ovl->rmda0
there make different define for this different.
#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN0x030
for the future mt8183, ovl mout en register offset will change to
0xf00
this is only one different sample, there will be more and more
different, so we add this patch for different soc
>
> >
> > Signed-off-by: Yongqiang Niu
> > ---
> > drivers/soc/mediatek/mmsys/mtk-mmsys.c | 140
> > +
> > 1 file changed, 71 insertions(+), 69 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> > b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> > index 6c03282..64c8030 100644
> > --- a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> > +++ b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> > @@ -106,141 +106,161 @@ struct mtk_mmsys {
> > .clk_driver = "clk-mt8183-mm",
> > };
> >
> > -static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > - enum mtk_ddp_comp_id next,
> > - unsigned int *addr)
> > +static void mtk_mmsys_ddp_mout_en(void __iomem *config_regs,
> > + enum mtk_ddp_comp_id cur,
> > + enum mtk_ddp_comp_id next,
> > + bool enable)
> > {
> > - unsigned int value;
> > + unsigned int addr, value, reg;
> >
> > if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
> > - *addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
> > value = OVL0_MOUT_EN_COLOR0;
> > } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> > - *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> > value = OVL_MOUT_EN_RDMA;
> > } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
> > - *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> > value = OD_MOUT_EN_RDMA0;
> > } else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
> > - *addr = DISP_REG_CONFIG_DISP_UFOE_MOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_UFOE_MOUT_EN;
> > value = UFOE_MOUT_EN_DSI0;
> > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > - *addr = DISP_REG_CONFIG_DISP_OVL1_MOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_OVL1_MOUT_EN;
> > value = OVL1_MOUT_EN_COLOR1;
> > } else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
> > - *addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
> > value = GAMMA_MOUT_EN_RDMA1;
> > } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> > - *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> > value = OD1_MOUT_EN_RDMA1;
> > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
> > - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > value = RDMA0_SOUT_DPI0;
> > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
> > - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > value = RDMA0_SOUT_DPI1;
> > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
> > - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > value = RDMA0_SOUT_DSI1;
> > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> > - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > value = RDMA0_SOUT_DSI2;
> > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> > - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> > value = RDMA0_SOUT_DSI3;
> > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> > - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> > +
[PATCH v1 3/7] ARM: dts: imx6dl-prtvt7: Add display and panel nodes
Add Innolux G070Y2-T02 panel to the Protonic VT7 board.
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
index ae6da241f13e..d9cb1e41cc10 100644
--- a/arch/arm/boot/dts/imx6dl-prtvt7.dts
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -31,6 +31,30 @@ backlight_lcd: backlight-lcd {
enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
};
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-0 = <_ipu1_disp>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+
keys {
compatible = "gpio-keys";
autorepeat;
@@ -138,6 +162,18 @@ led-debug0 {
};
};
+ panel {
+ compatible = "innolux,g070y2-t02";
+ backlight = <_lcd>;
+ power-supply = <_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
reg_bl_12v0: regulator-bl-12v0 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -149,6 +185,13 @@ reg_bl_12v0: regulator-bl-12v0 {
enable-active-high;
};
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
reg_1v8: regulator-1v8 {
compatible = "regulator-fixed";
regulator-name = "1v8";
@@ -260,6 +303,10 @@ {
status = "okay";
};
+_di0_disp0 {
+ remote-endpoint = <_in>;
+};
+
{
#pwm-cells = <2>;
pinctrl-names = "default";
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach
Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a
écrit :
On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil
wrote:
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the
other
DRM objects in the call to drm_mode_config_cleanup(). However,
since our
drm_connector is devm-allocated, by the time
drm_mode_config_cleanup()
will be called, our connector will be long gone. Therefore, the
connector must be cleaned up when the bridge is detached to avoid
use-after-free conditions.
For -fixes this sounds ok, but for -next I think switching to drmm_
would be much better.
The API would need to change to have access to the drm_device struct,
though. That would be quite a big patch, there are a few dozens source
files that use this API already.
Cheers,
-Paul
v2: Cleanup connector only if it was created
Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper
from the lvds-encoder bridge.")
Cc: # 4.12+
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/panel.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/bridge/panel.c
b/drivers/gpu/drm/bridge/panel.c
index 0ddc37551194..df86b0ee0549 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge
*bridge,
static void panel_bridge_detach(struct drm_bridge *bridge)
{
+ struct panel_bridge *panel_bridge =
drm_bridge_to_panel_bridge(bridge);
+ struct drm_connector *connector = _bridge->connector;
+
+ /* Cleanup the connector if we know it was initialized */
+ if (!!panel_bridge->connector.dev)
+ drm_connector_cleanup(connector);
}
static void panel_bridge_pre_enable(struct drm_bridge *bridge)
--
2.29.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
[PATCH v2 3/7] ARM: dts: imx6dl-prtvt7: Add display and panel nodes
Add Innolux G070Y2-T02 panel to the Protonic VT7 board.
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
index ae6da241f13e..d9cb1e41cc10 100644
--- a/arch/arm/boot/dts/imx6dl-prtvt7.dts
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -31,6 +31,30 @@ backlight_lcd: backlight-lcd {
enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
};
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-0 = <_ipu1_disp>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+
keys {
compatible = "gpio-keys";
autorepeat;
@@ -138,6 +162,18 @@ led-debug0 {
};
};
+ panel {
+ compatible = "innolux,g070y2-t02";
+ backlight = <_lcd>;
+ power-supply = <_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
reg_bl_12v0: regulator-bl-12v0 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -149,6 +185,13 @@ reg_bl_12v0: regulator-bl-12v0 {
enable-active-high;
};
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
reg_1v8: regulator-1v8 {
compatible = "regulator-fixed";
regulator-name = "1v8";
@@ -260,6 +303,10 @@ {
status = "okay";
};
+_di0_disp0 {
+ remote-endpoint = <_in>;
+};
+
{
#pwm-cells = <2>;
pinctrl-names = "default";
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/31] opp: Add devres wrapper for dev_pm_opp_set_regulators and dev_pm_opp_put_regulators
01.01.2021 19:54, Yangtao Li пишет: > Add devres wrapper for dev_pm_opp_set_regulators() > dev_pm_opp_put_regulators () to simplify driver code. > > Signed-off-by: Yangtao Li > --- > drivers/opp/core.c | 50 ++ > include/linux/pm_opp.h | 9 > 2 files changed, 59 insertions(+) Reviewed-by: Dmitry Osipenko Tested-by: Dmitry Osipenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/31] opp: Add devres wrapper for dev_pm_opp_of_add_table
01.01.2021 19:54, Yangtao Li пишет: > Add devres wrapper for dev_pm_opp_of_add_table() to simplify driver > code. > > Signed-off-by: Yangtao Li > --- > drivers/opp/of.c | 36 > include/linux/pm_opp.h | 6 ++ > 2 files changed, 42 insertions(+) Reviewed-by: Dmitry Osipenko Tested-by: Dmitry Osipenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..3ff46e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+ RTRAM controller and Display Controller. The main function is to convert
+ the AXI interface to the RTRAM interface, which includes re-mapping the
+ ARADDR to a RTRAM address.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-prg
+ - fsl,imx8qm-prg
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: rtram clock
+ - description: apb clock
+
+ clock-names:
+items:
+ - const: rtram
+ - const: apb
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <_prg0_lpcg IMX_LPCG_CLK_0>,
+ <_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/7] dt-bindings: display: simple: add Innolux G070Y2-T02 panel
Add binding for the Innolux G070Y2-T02 panel. It is 7" WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit. Signed-off-by: Oleksij Rempel --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 3207608d1178..f7a1465313db 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -152,6 +152,8 @@ properties: - innolux,at070tn92 # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel - innolux,g070y2-l01 +# Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel + - innolux,g070y2-t02 # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel - innolux,g101ice-l01 # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/7] drm: panel-simple: Add support for the Innolux G070Y2-T02 panel
Add compatible and timings for the Innolux G070Y2-T02 panel. It is 7"
WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
drivers/gpu/drm/panel/panel-simple.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 41bbec72b2da..14996ca264f3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2149,6 +2149,19 @@ static const struct panel_desc innolux_g070y2_l01 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct panel_desc innolux_g070y2_t02 = {
+ .modes = _at070tn92_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 92,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct display_timing innolux_g101ice_l01_timing = {
.pixelclock = { 6040, 7110, 7470 },
.hactive = { 1280, 1280, 1280 },
@@ -4135,6 +4148,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,g070y2-l01",
.data = _g070y2_l01,
+ }, {
+ .compatible = "innolux,g070y2-t02",
+ .data = _g070y2_t02,
}, {
.compatible = "innolux,g101ice-l01",
.data = _g101ice_l01
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector will be long gone. Therefore, the
connector must be cleaned up when the bridge is detached to avoid
use-after-free conditions.
v2: Cleanup connector only if it was created
Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
lvds-encoder bridge.")
Cc: # 4.12+
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/panel.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 0ddc37551194..df86b0ee0549 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
static void panel_bridge_detach(struct drm_bridge *bridge)
{
+ struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+ struct drm_connector *connector = _bridge->connector;
+
+ /* Cleanup the connector if we know it was initialized */
+ if (!!panel_bridge->connector.dev)
+ drm_connector_cleanup(connector);
}
static void panel_bridge_pre_enable(struct drm_bridge *bridge)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] devicetree fixes for Protonic and Plymovent boards
changes v2: - imx6dl-prtvt7: remove touchscreen-inverted-* Oleksij Rempel (7): dt-bindings: display: simple: add Innolux G070Y2-T02 panel drm: panel-simple: Add support for the Innolux G070Y2-T02 panel ARM: dts: imx6dl-prtvt7: Add display and panel nodes ARM: dts: imx6dl-prtvt7: add TSC2046 touchscreen node ARM: dts: imx6dl-prtvt7: Remove backlight enable gpio ARM: dts: imx6dl-prtvt7: fix PWM cell count for the backlight node. ARM: dts: imx6dl-plym2m: remove touchscreen-size-* properties .../bindings/display/panel/panel-simple.yaml | 2 + arch/arm/boot/dts/imx6dl-plym2m.dts | 2 - arch/arm/boot/dts/imx6dl-prtvt7.dts | 74 --- drivers/gpu/drm/panel/panel-simple.c | 16 4 files changed, 81 insertions(+), 13 deletions(-) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/7] ARM: dts: imx6dl-plym2m: remove touchscreen-size-* properties
Remove touchscreen-size-* properties. This values are not correct, event if it
works with ts_test tool, it fails to work properly with weston.
And the real range of values reported by the driver (or measured by the
controller) is close to max values and may change with time on resistive
panels. So, it make no sense to keep this values in the device tree.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-plym2m.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts
b/arch/arm/boot/dts/imx6dl-plym2m.dts
index 4d0d3d3386af..c97274f0df07 100644
--- a/arch/arm/boot/dts/imx6dl-plym2m.dts
+++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
@@ -138,8 +138,6 @@ touchscreen@0 {
interrupts-extended = < 20 IRQ_TYPE_EDGE_FALLING>;
pendown-gpio = < 20 GPIO_ACTIVE_LOW>;
- touchscreen-size-x = <800>;
- touchscreen-size-y = <480>;
touchscreen-inverted-x;
touchscreen-inverted-y;
touchscreen-max-pressure = <4095>;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/scheduler: Job timeout handler returns status (v3)
Panfrost hunks Acked-by: Alyssa Rosenzweig signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] drm: panel-simple: Add support for the Innolux G070Y2-T02 panel
Add compatible and timings for the Innolux G070Y2-T02 panel. It is 7"
WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
drivers/gpu/drm/panel/panel-simple.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 41bbec72b2da..14996ca264f3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2149,6 +2149,19 @@ static const struct panel_desc innolux_g070y2_l01 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct panel_desc innolux_g070y2_t02 = {
+ .modes = _at070tn92_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 92,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct display_timing innolux_g101ice_l01_timing = {
.pixelclock = { 6040, 7110, 7470 },
.hactive = { 1280, 1280, 1280 },
@@ -4135,6 +4148,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,g070y2-l01",
.data = _g070y2_l01,
+ }, {
+ .compatible = "innolux,g070y2-t02",
+ .data = _g070y2_t02,
}, {
.compatible = "innolux,g101ice-l01",
.data = _g101ice_l01
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
On Wed, 2021-01-20 at 11:27 +0200, Laurentiu Palcu wrote: > Hi Liu Ying, > > On Wed, Jan 20, 2021 at 04:42:50PM +0800, Liu Ying wrote: > > Hi Laurentiu, > > > > On Fri, 2021-01-15 at 19:27 +0200, Laurentiu Palcu wrote: > > > Hi Liu Ying, > > > > > > I promised I would have a second, more in-depth, look at this and I > > > finally > > > managed to do it. > > > > Thanks. > > > > > I have to admit it was a challenge. Partially because I'm not very > > > familiar > > > with DPU but mostly because of the abundance of macros used. It's true, > > > macros > > > make the code more compact. However they made the entire code hard to > > > read, > > > as neither ctags nor cscope were able to cross-reference it properly, and > > > I > > > fear it will be even harder to maintain in the long run... :/ For example, > > > trying to figure out where dpu_*_hw_init() functions were called from was > > > no > > > easy task. Or dpu_*_put(). Or dpu_*_get(). :/ > > > > > > Also, most of the macros are not in-line with Linux Kernel coding > > > style when it comes to macro usage: they affect control flow and some > > > depend > > > on other local variables being already defined. > > > > > > The good news is most macros can be replaced with helper functions and it > > > would > > > not add too much extra code. > > > > Ok, I'll remove macros where possible. > > > > > More comments below. > > > > Please find feedbacks below. > > > > > On Fri, Dec 18, 2020 at 11:23:52AM +0800, Liu Ying wrote: > > > > This patch introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM > > > > support. > > > > > > > > DPU is comprised of two main components that include a blit engine for > > > > 2D graphics accelerations(with composition support) and a display > > > > controller > > > > for display output processing, as well as a command sequencer. Outside > > > > of > > > > DPU, optional prefetch engines, a.k.a, Prefetch Resolve Gasket(PRG) and > > > > Display Prefetch Resolve(DPR), can fetch data from memory prior to some > > > > DPU > > > > fetchunits of blit engine and display controller. The prefetch engines > > > > support reading linear formats and resolving Vivante GPU tile formats. > > > > > > > > This patch adds kernel modesetting support for the display controller > > > > part. > > > > The driver supports two CRTCs per display controller, planes backed by > > > > four fetchunits(decode0/1, fetchlayer, fetchwarp), fetchunit allocation > > > > logic for the two CRTCs, prefetch engines(with tile resolving > > > > supported), > > > > plane upscaling/deinterlacing/yuv2rgb CSC/alpha blending and CRTC gamma > > > > correction. The registers of the controller is accessed without command > > > > sequencer involved, instead just by using CPU. > > > > > > > > Reference manual can be found at: > > > > https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM > > > > > > > > Signed-off-by: Liu Ying > > > > --- > > > > v4->v5: > > > > * Rebase up onto the latest drm-misc-next branch and remove the hook to > > > > drm_atomic_helper_legacy_gamma_set(), because it was dropped by the > > > > newly > > > > landed commit 'drm: automatic legacy gamma support'. > > > > * Remove a redundant blank line from dpu_plane_atomic_update(). > > > > > > > > v3->v4: > > > > * No change. > > > > > > > > v2->v3: > > > > * Fix build warnings Reported-by: kernel test robot . > > > > * Drop build dependency on IMX_SCU, as dummy SCU functions have been > > > > added in > > > > header files by the patch 'firmware: imx: add dummy functions' which > > > > has > > > > landed in linux-next/master branch. > > > > > > > > v1->v2: > > > > * Add compatible for i.MX8qm DPU, as this is tested with i.MX8qm LVDS > > > > displays. > > > > (Laurentiu) > > > > * Fix PRG burst size and stride. (Laurentiu) > > > > * Put 'ports' OF node to fix the bail-out logic in dpu_drm_probe(). > > > > (Laurentiu) > > > > > > > > drivers/gpu/drm/imx/Kconfig | 1 + > > > > drivers/gpu/drm/imx/Makefile | 1 + > > > > drivers/gpu/drm/imx/dpu/Kconfig | 10 + > > > > drivers/gpu/drm/imx/dpu/Makefile | 10 + > > > > drivers/gpu/drm/imx/dpu/dpu-constframe.c | 170 ++ > > > > drivers/gpu/drm/imx/dpu/dpu-core.c| 881 > > > > > > > > drivers/gpu/drm/imx/dpu/dpu-crtc.c| 925 > > > > ++ > > > > drivers/gpu/drm/imx/dpu/dpu-crtc.h| 62 ++ > > > > drivers/gpu/drm/imx/dpu/dpu-disengcfg.c | 114 > > > > drivers/gpu/drm/imx/dpu/dpu-dprc.c| 721 +++ > > > > drivers/gpu/drm/imx/dpu/dpu-dprc.h| 40 ++ > > > > drivers/gpu/drm/imx/dpu/dpu-drv.c | 297 ++ > > > > drivers/gpu/drm/imx/dpu/dpu-drv.h | 28 + > > > > drivers/gpu/drm/imx/dpu/dpu-extdst.c | 296 ++ > > > > drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c | 291 ++ > > > >
[PATCH] drm/imx: fix memory leak when fails to init
Put DRM device on initialization failure path rather than directly
return error code.
Fixes: a67d5088ceb8 ("drm/imx: drop explicit drm_mode_config_cleanup")
Signed-off-by: Pan Bian
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index d1a9841adeed..e6a88c8cbd69 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -215,7 +215,7 @@ static int imx_drm_bind(struct device *dev)
ret = drmm_mode_config_init(drm);
if (ret)
- return ret;
+ goto err_kms;
ret = drm_vblank_init(drm, MAX_CRTC);
if (ret)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/ingenic: Register devm action to cleanup encoders
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that drm_encoder_cleanup() is called
before the encoders are freed.
v2: Use the new __drmm_simple_encoder_alloc() function
Fixes: c369cb27c267 ("drm/ingenic: Support multiple panels/bridges")
Cc: # 5.8+
Signed-off-by: Paul Cercueil
---
Notes:
Use the V1 of this patch to fix v5.11 and older kernels. This V2 only
applies on the current drm-misc-next branch.
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 7bb31fbee29d..158433b4c084 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -1014,20 +1014,18 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
bridge = devm_drm_panel_bridge_add_typed(dev, panel,
DRM_MODE_CONNECTOR_DPI);
- encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);
- if (!encoder)
- return -ENOMEM;
+ encoder = __drmm_simple_encoder_alloc(drm, sizeof(*encoder), 0,
+ DRM_MODE_ENCODER_DPI);
+ if (IS_ERR(encoder)) {
+ ret = PTR_ERR(encoder);
+ dev_err(dev, "Failed to init encoder: %d\n", ret);
+ return ret;
+ }
encoder->possible_crtcs = 1;
drm_encoder_helper_add(encoder,
_drm_encoder_helper_funcs);
- ret = drm_simple_encoder_init(drm, encoder,
DRM_MODE_ENCODER_DPI);
- if (ret) {
- dev_err(dev, "Failed to init encoder: %d\n", ret);
- return ret;
- }
-
ret = drm_bridge_attach(encoder, bridge, NULL, 0);
if (ret) {
dev_err(dev, "Unable to attach bridge\n");
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: dp-connector: Drop maxItems from -supply
The meta-schema recently gained a definition for the common -supply$
property, which denotes that maxItems is not a valid property. Drop this
to clear up the binding validation error.
Fixes: a46c112512de ("dt-bindings: dp-connector: add binding for DisplayPort
connector")
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/display/connector/dp-connector.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
index 1c17d60e7760..22792a79e7ce 100644
--- a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
+++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
@@ -26,7 +26,6 @@ properties:
dp-pwr-supply:
description: Power supply for the DP_PWR pin
-maxItems: 1
port:
$ref: /schemas/graph.yaml#/properties/port
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
Hi, This is the v6 series to introduce i.MX8qm/qxp Display Processing Unit(DPU) DRM support. DPU is comprised of a blit engine for 2D graphics, a display controller and a command sequencer. Outside of DPU, optional prefetch engines can fetch data from memory prior to some DPU fetchunits of blit engine and display controller. The pre-fetchers support linear formats and Vivante GPU tile formats. Reference manual can be found at: https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM This patch set adds kernel modesetting support for the display controller part. It supports two CRTCs per display controller, several planes, prefetch engines and some properties of CRTC and plane. Currently, the registers of the controller is accessed without command sequencer involved, instead just by using CPU. DRM connectors would be created from the DPU KMS driver. If people want to try this series with i.MX8qxp, clock patches can be found at Shawn's i.MX for-next git branch, and power domain patches have already landed in 5.11-rc1. Version2 dropped the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. It depends on the below series to do basic conversions for the platforms which has not landed yet: https://www.spinics.net/lists/linux-mmc/msg61965.html I've sent the below series to add downstream bridges(embedded in i.MX8qm/qxp) to support LVDS displays: https://www.spinics.net/lists/arm-kernel/msg868239.html Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines. Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver uses it. Patch 5 introduces the DPU DRM support. Patch 6 updates MAINTAINERS. Welcome comments, thanks. v5->v6: * Use graph schema in the DPU dt-binding. * Do not use macros where possible in the DPU DRM driver. (Laurentiu) * Break dpu_plane_atomic_check() into some smaller functions. (Laurentiu) * Address some minor comments from Laurentiu on the DPU DRM driver. * Add dpu_crtc_err() helper marco in the DPU DRM driver to tell dmesg which CRTC generates error. * Drop calling dev_set_drvdata() from dpu_drm_bind/unbind() in the DPU DRM driver as it is done in dpu_drm_probe(). * Some trivial tweaks. v4->v5: * Rebase up onto the latest drm-misc-next branch and remove the hook to drm_atomic_helper_legacy_gamma_set() from patch 5/6, because it was dropped by the newly landed commit 'drm: automatic legacy gamma support'. * Remove a redundant blank line from dpu_plane_atomic_update() in patch 5/6. v3->v4: * Improve compatible properties in DPU and prefetch engines' dt bindings by using enum instead of oneOf+const. * Add Rob's R-b tags on dt binding patches(patch 1/6, 2/6 and 3/6). * Add Daniel's A-b tag on patch 4/6. v2->v3: * Fix DPU DRM driver build warnings which are Reported-by: kernel test robot . * Drop DPU DRM driver build dependency on IMX_SCU, as dummy SCU functions have been added in header files by the patch 'firmware: imx: add dummy functions' which has landed in linux-next/master branch. * Add a missing blank line in include/drm/drm_atomic.h. v1->v2: * Test this patch set also with i.MX8qm LVDS displays. * Drop the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. This depends on a not-yet-landed patch set to do basic conversions for the platforms. * Fix dt binding yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm in DPU's dt binding documentation. * Use new dt binding way to add clocks in the dt binding examples. * Address several comments from Laurentiu on the DPU DRM patch. Liu Ying (6): dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state drm/imx: Introduce i.MX8qm/qxp DPU DRM MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver .../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++ .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 387 +++ .../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++ MAINTAINERS|9 + drivers/gpu/drm/imx/Kconfig|1 + drivers/gpu/drm/imx/Makefile |1 + drivers/gpu/drm/imx/dpu/Kconfig| 10 + drivers/gpu/drm/imx/dpu/Makefile | 10 + drivers/gpu/drm/imx/dpu/dpu-constframe.c | 171 +++ drivers/gpu/drm/imx/dpu/dpu-core.c | 1094 drivers/gpu/drm/imx/dpu/dpu-crtc.c | 967 + drivers/gpu/drm/imx/dpu/dpu-crtc.h | 66 ++ drivers/gpu/drm/imx/dpu/dpu-disengcfg.c| 117 +++ drivers/gpu/drm/imx/dpu/dpu-dprc.c | 718 + drivers/gpu/drm/imx/dpu/dpu-dprc.h | 40 +
