dri-devel December 2017

dri-devel@lists.freedesktop.org

236 participants
1514 discussions

[PATCH v3] drm/etnaviv: make THERMAL selectable
by Philipp Zabel 01 Dec '17

01 Dec '17

The etnaviv driver causes a link failure if it is built-in but THERMAL is built as a module: drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': etnaviv_gpu.c:(.text+0x4c4): undefined reference to `thermal_of_cooling_device_register' etnaviv_gpu.c:(.text+0x600): undefined reference to `thermal_cooling_device_unregister' drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind': etnaviv_gpu.c:(.text+0x2aac): undefined reference to `thermal_cooling_device_unregister' Adding a Kconfig dependency on THERMAL || !THERMAL to avoid this causes a dependency loop on x86_64: drivers/gpu/drm/tve200/Kconfig:1:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/tve200/Kconfig:1: symbol DRM_TVE200 depends on CMA For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" mm/Kconfig:489: symbol CMA is selected by DRM_ETNAVIV For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/etnaviv/Kconfig:2: symbol DRM_ETNAVIV depends on THERMAL For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/thermal/Kconfig:5: symbol THERMAL is selected by ACPI_VIDEO For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/acpi/Kconfig:189: symbol ACPI_VIDEO is selected by BACKLIGHT_CLASS_DEVICE For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/backlight/Kconfig:158: symbol BACKLIGHT_CLASS_DEVICE is selected by DRM_PARADE_PS8622 For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/bridge/Kconfig:62: symbol DRM_PARADE_PS8622 depends on DRM_BRIDGE For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_TVE200 To work around this, add a new option DRM_ETNAVIV_THERMAL to optionally enable thermal throttling support and make DRM_ETNAVIV select THERMAL at the same time. Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- Changes since v2 [1]: - Drop select THERMAL from DRM_ETNAVIV_THERMAL, DRM_ETNAVIV selects THERMAL to allow thermal throttling support with THERMAL=m and DRM_ETNAVIV=m. [1] https://patchwork.kernel.org/patch/10087271/ --- drivers/gpu/drm/etnaviv/Kconfig | 9 +++++++++ drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 8 +++++--- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig index a29b8f59eb15d..3f58b4077767d 100644 --- a/drivers/gpu/drm/etnaviv/Kconfig +++ b/drivers/gpu/drm/etnaviv/Kconfig @@ -6,6 +6,7 @@ config DRM_ETNAVIV depends on MMU select SHMEM select SYNC_FILE + select THERMAL if DRM_ETNAVIV_THERMAL select TMPFS select WANT_DEV_COREDUMP select CMA if HAVE_DMA_CONTIGUOUS @@ -13,6 +14,14 @@ config DRM_ETNAVIV help DRM driver for Vivante GPUs. +config DRM_ETNAVIV_THERMAL + bool "enable ETNAVIV thermal throttling" + depends on DRM_ETNAVIV + default y + help + Compile in support for thermal throttling. + Say Y unless you want to risk burning your SoC. + config DRM_ETNAVIV_REGISTER_LOGGING bool "enable ETNAVIV register logging" depends on DRM_ETNAVIV diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index e19cbe05da2a3..968cbc2be9c45 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -1738,7 +1738,7 @@ static int etnaviv_gpu_bind(struct device *dev, struct device *master, struct etnaviv_gpu *gpu = dev_get_drvdata(dev); int ret; - if (IS_ENABLED(CONFIG_THERMAL)) { + if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL)) { gpu->cooling = thermal_of_cooling_device_register(dev->of_node, (char *)dev_name(dev), gpu, &cooling_ops); if (IS_ERR(gpu->cooling)) @@ -1751,7 +1751,8 @@ static int etnaviv_gpu_bind(struct device *dev, struct device *master, ret = etnaviv_gpu_clk_enable(gpu); #endif if (ret < 0) { - thermal_cooling_device_unregister(gpu->cooling); + if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL)) + thermal_cooling_device_unregister(gpu->cooling); return ret; } @@ -1808,7 +1809,8 @@ static void etnaviv_gpu_unbind(struct device *dev, struct device *master, gpu->drm = NULL; - thermal_cooling_device_unregister(gpu->cooling); + if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL)) + thermal_cooling_device_unregister(gpu->cooling); gpu->cooling = NULL; } -- 2.11.0

1 0

[PATCH v2] drm/etnaviv: make THERMAL selectable
by Philipp Zabel 01 Dec '17

01 Dec '17

The etnaviv driver causes a link failure if it is built-in but THERMAL is built as a module: drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': etnaviv_gpu.c:(.text+0x4c4): undefined reference to `thermal_of_cooling_device_register' etnaviv_gpu.c:(.text+0x600): undefined reference to `thermal_cooling_device_unregister' drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind': etnaviv_gpu.c:(.text+0x2aac): undefined reference to `thermal_cooling_device_unregister' Adding a Kconfig dependency on THERMAL || !THERMAL to avoid this causes a dependency loop on x86_64: drivers/gpu/drm/tve200/Kconfig:1:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/tve200/Kconfig:1: symbol DRM_TVE200 depends on CMA For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" mm/Kconfig:489: symbol CMA is selected by DRM_ETNAVIV For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/etnaviv/Kconfig:2: symbol DRM_ETNAVIV depends on THERMAL For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/thermal/Kconfig:5: symbol THERMAL is selected by ACPI_VIDEO For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/acpi/Kconfig:189: symbol ACPI_VIDEO is selected by BACKLIGHT_CLASS_DEVICE For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/backlight/Kconfig:158: symbol BACKLIGHT_CLASS_DEVICE is selected by DRM_PARADE_PS8622 For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/bridge/Kconfig:62: symbol DRM_PARADE_PS8622 depends on DRM_BRIDGE For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_TVE200 To work around this, add a new option DRM_ETNAVIV_THERMAL to optionally enable thermal throttling support and make DRM_ETNAVIV select THERMAL at the same time. Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- Changes since v1 [1]: - Merge with dba536cd9538 ("drm/etnaviv: add THERMAL dependency") - Remove build warning, default y should be enough to avoid accidentally enabling thermal support but not etnaviv thermal throttling. [1] https://patchwork.kernel.org/patch/10087265/ --- drivers/gpu/drm/etnaviv/Kconfig | 10 ++++++++++ drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 8 +++++--- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig index a29b8f59eb15d..c446e867b3a24 100644 --- a/drivers/gpu/drm/etnaviv/Kconfig +++ b/drivers/gpu/drm/etnaviv/Kconfig @@ -6,6 +6,7 @@ config DRM_ETNAVIV depends on MMU select SHMEM select SYNC_FILE + select THERMAL if DRM_ETNAVIV_THERMAL select TMPFS select WANT_DEV_COREDUMP select CMA if HAVE_DMA_CONTIGUOUS @@ -13,6 +14,15 @@ config DRM_ETNAVIV help DRM driver for Vivante GPUs. +config DRM_ETNAVIV_THERMAL + bool "enable ETNAVIV thermal throttling" + depends on DRM_ETNAVIV + default y + select THERMAL + help + Compile in support for thermal throttling. + Say Y unless you want to risk burning your SoC. + config DRM_ETNAVIV_REGISTER_LOGGING bool "enable ETNAVIV register logging" depends on DRM_ETNAVIV diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index e19cbe05da2a3..968cbc2be9c45 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -1738,7 +1738,7 @@ static int etnaviv_gpu_bind(struct device *dev, struct device *master, struct etnaviv_gpu *gpu = dev_get_drvdata(dev); int ret; - if (IS_ENABLED(CONFIG_THERMAL)) { + if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL)) { gpu->cooling = thermal_of_cooling_device_register(dev->of_node, (char *)dev_name(dev), gpu, &cooling_ops); if (IS_ERR(gpu->cooling)) @@ -1751,7 +1751,8 @@ static int etnaviv_gpu_bind(struct device *dev, struct device *master, ret = etnaviv_gpu_clk_enable(gpu); #endif if (ret < 0) { - thermal_cooling_device_unregister(gpu->cooling); + if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL)) + thermal_cooling_device_unregister(gpu->cooling); return ret; } @@ -1808,7 +1809,8 @@ static void etnaviv_gpu_unbind(struct device *dev, struct device *master, gpu->drm = NULL; - thermal_cooling_device_unregister(gpu->cooling); + if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL)) + thermal_cooling_device_unregister(gpu->cooling); gpu->cooling = NULL; } -- 2.11.0

1 0

Re: linux-next: build failure after merge of the etnaviv tree
by Stephen Rothwell 01 Dec '17

01 Dec '17

Hi Lucas, On Tue, 28 Nov 2017 11:44:46 +1100 Stephen Rothwell <sfr(a)canb.auug.org.au> wrote: > > After merging the etnaviv tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/gpu/drm/tve200/Kconfig:1:error: recursive dependency detected! > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/tve200/Kconfig:1: symbol DRM_TVE200 depends on CMA > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > mm/Kconfig:489: symbol CMA is selected by DRM_ETNAVIV > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/etnaviv/Kconfig:2: symbol DRM_ETNAVIV depends on THERMAL > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/thermal/Kconfig:5: symbol THERMAL is selected by ACPI_VIDEO > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/acpi/Kconfig:189: symbol ACPI_VIDEO is selected by BACKLIGHT_CLASS_DEVICE > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/video/backlight/Kconfig:158: symbol BACKLIGHT_CLASS_DEVICE is selected by DRM_PARADE_PS8622 > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/bridge/Kconfig:62: symbol DRM_PARADE_PS8622 depends on DRM_BRIDGE > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_TVE200 > warning: (PMAC_BACKLIGHT && DRM_NOUVEAU && HT16K33 && FB_TFT) selects FB_BACKLIGHT which has unmet direct dependencies (HAS_IOMEM && FB) > * > * Restart config... > * > * > * Multiplexer I2C Chip support > * > GPIO-based I2C arbitration (I2C_ARB_GPIO_CHALLENGE) [M/n/?] m > GPIO-based I2C multiplexer (I2C_MUX_GPIO) [M/n/?] m > General Purpose I2C multiplexer (I2C_MUX_GPMUX) [M/n/?] m > LTC LTC4306/5 I2C multiplexer (I2C_MUX_LTC4306) [N/m/?] (NEW) aborted! > > Console input/output is redirected. Run 'make oldconfig' to update configuration. > > scripts/kconfig/Makefile:38: recipe for target 'silentoldconfig' failed > > Caused by commit > > dba536cd9538 ("drm/etnaviv: add THERMAL dependency") > > I got the abobe warnings while doing "make allmodconfig" and then the > error when doing the actual build. > > I have used the etnaviv tree from next-20171127 for today. I am still getting this failure. -- Cheers, Stephen Rothwell

2 1

[PATCH] drm: Fix link-status kerneldoc line lengths
by Sean Paul 01 Dec '17

01 Dec '17

I'm adding some stuff below it and it's killing my editor's vibe. Cc: Manasi Navare <manasi.d.navare(a)intel.com> Signed-off-by: Sean Paul <seanpaul(a)chromium.org> --- drivers/gpu/drm/drm_connector.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 704fc8934616..f14b48e6e839 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -759,10 +759,11 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name, * should update this value using drm_mode_connector_set_tile_property(). * Userspace cannot change this property. * link-status: - * Connector link-status property to indicate the status of link. The default - * value of link-status is "GOOD". If something fails during or after modeset, - * the kernel driver may set this to "BAD" and issue a hotplug uevent. Drivers - * should update this value using drm_mode_connector_set_link_status_property(). + * Connector link-status property to indicate the status of link. The + * default value of link-status is "GOOD". If something fails during or + * after modeset, the kernel driver may set this to "BAD" and issue a + * hotplug uevent. Drivers should update this value using + * drm_mode_connector_set_link_status_property(). * * Connectors also have one standardized atomic property: * -- 2.15.0.531.g2ccb3012c9-goog

2 2

[PATCH v2 0/4] DRM driver for ILI9225 display panels
by David Lechner 01 Dec '17

01 Dec '17

This is a new driver for ILI9225 based display panels. v2 changes: * New patch for ilitek vendor prefix. * Use "ilitek" instead of "generic" in dt-bindings * New patch to export 2 mipi_dbi_* functions * Clean up ILI9225 driver based on feedback David Lechner (4): dt-bindings: Add vendor prefix for ilitek dt-bindings: Add binding for Ilitek ILI9225 display panels drm/tinydrm: export mipi_dbi_buf_copy and mipi_dbi_spi_cmd_max_speed drm/tinydrm: add driver for ILI9225 panels .../devicetree/bindings/display/ilitek,ili9225.txt | 25 ++ .../devicetree/bindings/vendor-prefixes.txt | 1 + MAINTAINERS | 6 + drivers/gpu/drm/tinydrm/Kconfig | 10 + drivers/gpu/drm/tinydrm/Makefile | 1 + drivers/gpu/drm/tinydrm/ili9225.c | 468 +++++++++++++++++++++ drivers/gpu/drm/tinydrm/mipi-dbi.c | 24 +- include/drm/tinydrm/mipi-dbi.h | 4 +- 8 files changed, 534 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c -- 2.7.4

4 10

[PATCH 0/7] drm/omap: Module parameter for display order configuration
by Peter Ujfalusi 01 Dec '17

01 Dec '17

Hi, Changes since RFC: - Comments from Laurent have been addressed: - Get alias ID once and store it for later use in sorting - Commit message updated for 'drm/omap: Manage the usable omap_dss_device list within omap_drm_private' patch - I have kept the first patch to convert to use devm_kzalloc for the private struct as I still think it is as correct as the way Laurent is proposing. The series adds support for changing the order of the displays defined by DT display aliases. The motivation to do such a thing is that for example the fb emulation is treating the first display/crtc as the 'main' display and will create the fb emulation based on the first display's properties. There are many custom applications using DRM directly and they assume that the first connector is the 'main' display. Afaik weston provides no means either to change the 'main/preferred' display. It should be the work of user space application (except the fb emulation) to somehow deal with the 'main' display selection for their needs, but unfortunately they are not capable of diong so for some reason. We have boards with LCD panel and HDMI for example and in DT the LCD is set as display0, but in certain useage scenarios it is desired to have the HDMI as the 'main' display instead of the LCD. With the kernel cmd line parameter it is possible to change the pre defined order without recompiling the kernel/DT. If the board have two active displays: 0 - LCD 1 - HDMI then: omapdrm.displays=0,1 - represents the original order (LCD, HDMI) omapdrm.displays=1,0 - represents reverse order (HDMI, LCD) omapdrm.displays=0 - only the LCD is enabled omapdrm.displays=1 - only the HDMI is enabled omapdrm.displays=-1 - disable all displays The first 6 patch of the series is doing some generic clean up and prepares the code so the display ordering is going to be easy to add. Regards, Peter --- Peter Ujfalusi (7): drm/omap: Use devm_kzalloc() to allocate omap_drm_private drm/omap: Allocate drm_device earlier and unref it as last step drm/omap: Manage the usable omap_dss_device list within omap_drm_private drm/omap: Separate the dssdevs array setup from the connect function drm/omap: Do dss_device (display) ordering in omap_drv.c drm/omap: dss: Remove display ordering from dss/display.c drm/omap: Add kernel parameter to specify the desired display order drivers/gpu/drm/omapdrm/dss/display.c | 15 +-- drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 +- drivers/gpu/drm/omapdrm/omap_drv.c | 240 ++++++++++++++++++++++++---------- drivers/gpu/drm/omapdrm/omap_drv.h | 3 + 4 files changed, 181 insertions(+), 80 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

1 7

[PATCH 0/4] drm/omap: DMM: Error handling
by Peter Ujfalusi 01 Dec '17

01 Dec '17

Hi, the following series adds basic error handling and reporting for the dmm/tiler driver. With the error handling in place we can catch the problems early to avoid more serious consequences. Regards, Peter --- Peter Ujfalusi (4): drm/omap: DMM: Fix DMM_IRQSTAT_ERR_MASK definition drm/omap: DMM: In case of error/timeout in wait_status() print the reason drm/omap: DMM: Print information if we received an error interrupt drm/omap: DMM: Check for DMM readiness after successful transaction commit drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 12 ++++++------ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 22 ++++++++++++++++++++-- 2 files changed, 26 insertions(+), 8 deletions(-) -- 2.14.1 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 5

[PATCH v3 0/3] drm/omap: Support for dispc memory bandwidth limit
by Peter Ujfalusi 01 Dec '17

01 Dec '17

Hi, Changes since v2: - Rebased on drm-next (v2 was based on drm-next and my 'drm/omap: Module parameter for display order configuration' series, thus it was not applying cleanly. - Added Acked-by from Rob to the dt-binding changes Changes since v1: - Use the crtc->mode_valid and not connector->mode_valid as the limit is really posed by the 'crtc' (DISPC) - Bandwidth calculation changed: do the calculation in place + extended comment - looked for better place to document the max-memory-bandwidth, but can not find any suitable document. Creating a new txt file for only one property did not seemed feasable. This series will add simple memory bandwidth limit support to reject modes which, if used with one plane in full size would fail the limit. Regards, Peter --- Peter Ujfalusi (3): dt-bindings: display/ti: Add optional property to set memory bandwidth limit drm/omap: dss: Add support for reporting memory bandwidth limitation drm/omap: Filter displays mode based on bandwidth limit .../devicetree/bindings/display/ti/ti,dra7-dss.txt | 5 +++ .../bindings/display/ti/ti,omap2-dss.txt | 4 +++ .../bindings/display/ti/ti,omap3-dss.txt | 4 +++ .../bindings/display/ti/ti,omap4-dss.txt | 4 +++ .../bindings/display/ti/ti,omap5-dss.txt | 4 +++ drivers/gpu/drm/omapdrm/dss/dispc.c | 13 ++++++++ drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 ++ drivers/gpu/drm/omapdrm/omap_crtc.c | 37 ++++++++++++++++++++++ drivers/gpu/drm/omapdrm/omap_drv.c | 5 +++ drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++ 10 files changed, 81 insertions(+) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 4

[PATCH] drm/prime: skip CPU sync in map/unmap dma_buf
by Lucas Stach 01 Dec '17

01 Dec '17

Dma-bufs should already be device coherent, as they are only pulled in the CPU domain via the begin/end cpu_access calls. As we cache the mapping set up by dma_map_sg a CPU sync at this point will not actually guarantee proper coherency on non-coherent architectures, so we can as well stop pretending. This is an important performance fix for architectures which need explicit cache synchronization and userspace doing lots of dma-buf imports. Improves Weston on Etnaviv performance 5x, where before this patch > 90% of Weston CPU time was spent synchronizing caches for buffers which are already device coherent. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/drm_prime.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 8de93a226c24..9a17725b0f7a 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -218,8 +218,9 @@ static void drm_gem_map_detach(struct dma_buf *dma_buf, sgt = prime_attach->sgt; if (sgt) { if (prime_attach->dir != DMA_NONE) - dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, - prime_attach->dir); + dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->nents, + prime_attach->dir, + DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sgt); } @@ -277,7 +278,8 @@ static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach, sgt = obj->dev->driver->gem_prime_get_sg_table(obj); if (!IS_ERR(sgt)) { - if (!dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir)) { + if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir, + DMA_ATTR_SKIP_CPU_SYNC)) { sg_free_table(sgt); kfree(sgt); sgt = ERR_PTR(-ENOMEM); -- 2.11.0

3 2

Re: [PATCH] drm/imx: always call wait_for_flip_done in commit_tail
by Lucas Stach 01 Dec '17

01 Dec '17

Seems, Daniel lost the CC in the reply. Adding again. Am Donnerstag, den 30.11.2017, 14:51 +0100 schrieb Daniel Vetter: > On Thu, Nov 30, 2017 at 02:31:46PM +0100, Lucas Stach wrote: > > drm_atomic_helper_wait_for_vblanks will go away in the future. > > > > The new drm_atomic_helper_setup_commit in 4.15 expects that blocking commits > > have completed flipping before the commit_tail returns. This must be ensured > > by calling wait_for_vblanks or wait_for_flip_done, where flip_done might do > > a less agressive wait, which is fine for imx-drm. > > > > Fixes: 080de2e5be2d (drm/atomic: Check for busy planes/connectors before > > setting the commit) > > Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> > > > Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> > > Anyone volunteering for all the other drivers? Or at least a todo entry? Yeah, I'll look into converting the other drivers. But needs to wait until next week. Regards, Lucas > -Daniel > > > --- > > drivers/gpu/drm/imx/imx-drm-core.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c > > index 179f9aeefd98..db6afaa3f25f 100644 > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > @@ -134,9 +134,16 @@ static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state) > > > > plane_disabling = true; > > > > } > > > > > > - if (plane_disabling) { > > > > - drm_atomic_helper_wait_for_vblanks(dev, state); > > > > + /* > > > > + * The flip done wait is only strictly required by imx-drm if a deferred > > > > + * plane disable is in-flight. As the core requires blocking commits > > > > + * to wait for the flip it is done here unconditionally. This keeps the > > > > + * workitem around a bit longer than required for the majority of > > > > + * non-blocking commits, but we accept that for the sake of simplicity. > > > > + */ > > > > + drm_atomic_helper_wait_for_flip_done(dev, state); > > > > > > + if (plane_disabling) { > > > > for_each_old_plane_in_state(state, plane, old_plane_state, i) > > > > ipu_plane_disable_deferred(plane); > > > > -- > > 2.11.0 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel(a)lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > >

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2017