[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19

2021-01-23 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201497

--- Comment #20 from Jay Tuckey (jay@tuckey.email) ---
Hi, I'm also running into this issue, using an RX Vega 64 with an Asus ROG
display. Let me know if there's any logs or testing that I can do to assist.

-- 
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


[PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.

2021-01-23 Thread Mario Kleiner
According to the CTA 861.G spec, HDMI_STATIC_METADATA_TYPE1 is
not 1, but zero, so fix this enum.

While this doesn't cause problems in the kernel yet, as the
constant isn't actively used by drivers yet, it did create
confusion while debugging HDR problems in yours truly, and
also potential bugs in userspace components, as the wrong
enum propagates to components, e.g., like it did already
into intel-gpu-tools (tests/kms_hdr.c) or is used as wrong
reference when writing future new userspace HDR components
like compositors.

Fixes: fbb5d0353c62 ("drm: Add HDR source metadata property")
Signed-off-by: Mario Kleiner 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Cc: Ville Syrjälä 
---
 include/linux/hdmi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 9850d59d6f1c..c8ec982ff498 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -156,7 +156,7 @@ enum hdmi_content_type {
 };
 
 enum hdmi_metadata_type {
-   HDMI_STATIC_METADATA_TYPE1 = 1,
+   HDMI_STATIC_METADATA_TYPE1 = 0,
 };
 
 enum hdmi_eotf {
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 209713] amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state

2021-01-23 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209713

--- Comment #10 from Klaus Mueller (kmuel...@justmail.de) ---
Uups, it's the other crash now:
2021-01-23T18:45:31.955962+01:00 localhost kernel: [23110.401847]
[drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR*
[CRTC:62:crtc-0] flip_done timed out
2021-01-23T18:45:31.955989+01:00 localhost kernel: [23110.401869]
[drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR*
[CRTC:62:crtc-0] flip_done timed out
2021-01-23T18:45:42.709289+01:00 localhost kernel: [23121.153848]
[drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR*
[PLANE:52:plane-3] flip_done timed out
2021-01-23T18:45:42.709318+01:00 localhost kernel: [23121.153944] [
cut here ]
2021-01-23T18:45:42.709320+01:00 localhost kernel: [23121.154112] WARNING: CPU:
4 PID: 2627 at
../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7272
amdgpu_dm_atomic_commit_tail+0x22b1/0x2360 [amdgpu]

let's wait ...

-- 
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


[Bug 209713] amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state

2021-01-23 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209713

--- Comment #9 from Klaus Mueller (kmuel...@justmail.de) ---
no - same behavior as before with 5.10.9 and Mesa 20.3.3

-- 
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: [RESEND][PATCH 2/3] dma-buf: heaps: Add a WARN_ON should the vmap_cnt go negative

2021-01-23 Thread Suren Baghdasaryan
On Thu, Jan 21, 2021 at 11:56 PM Sumit Semwal  wrote:
>
> 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?

Hi Sumit,
My worry was that buffer->vmap_cnt could silently go negative. But if
this warning is not consistent with other places we do refcounted
vmap/vunmap then feel free to ignore my suggestion.
Thanks!

>
> 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 0/3] Generic USB Display driver

2021-01-23 Thread Noralf Trønnes



Den 21.01.2021 11.20, skrev Simon Ser:
> 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.

I agree that Generic probably isn't the best term to use here. Naming
stuff is hard. Maybe: Open USB Display Protocol - oudp?

> 
> Maybe rename it to "GUD USB Display driver"? :P
> 

Oh that's a recursive acronym :-) That would save me all the work of
renaming. I think I'll go with that, thanks.

Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 0/6] Add Unisoc's drm kms module

2021-01-23 Thread Kevin Tang
Hi Daniel,
Do you have some more comments for our patch?

Kevin Tang  于2021年1月5日周二 下午9:46写道:

> ChangeList:
> RFC v1:
> 1. only upstream modeset and atomic at first commit.
> 2. remove some unused code;
> 3. use alpha and blend_mode properties;
> 3. add yaml support;
> 4. remove auto-adaptive panel driver;
> 5. bugfix
>
> RFC v2:
> 1. add sprd crtc and plane module for KMS, preparing for multi crtc
> 2. remove gem drivers, use generic CMA handlers
> 3. remove redundant "module_init", all the sub modules loading by KMS
>
> RFC v3:
> 1. multi crtc design have problem, so rollback to v1
>
> RFC v4:
> 1. update to gcc-linaro-7.5.0
> 2. update to Linux 5.6-rc3
> 3. remove pm_runtime support
> 4. add COMPILE_TEST, remove unused kconfig
> 5. "drm_dev_put" on drm_unbind
> 6. fix some naming convention issue
> 7. remove semaphore lock for crtc flip
> 8. remove static variables
>
> RFC v5:
> 1. optimize encoder and connector code implementation
> 2. use "platform_get_irq" and "platform_get_resource"
> 3. drop useless function return type, drop unless debug log
> 4. custom properties should be separate, so drop it
> 5. use DRM_XXX replase pr_xxx
> 6. drop dsi hal callback ops
> 7. drop unless callback ops checking
> 8. add comments for sprd dpu structure
>
> RFC v6:
> 1. Access registers via readl/writel
> 2. Checking for unsupported KMS properties (format, rotation, blend_mode,
> etc) on plane_check ops
> 3. Remove always true checks for dpu core ops
>
> RFC v7:
> 1. Fix DTC unit name warnings
> 2. Fix the problem of maintainers
> 3. Call drmm_mode_config_init to mode config init
> 4. Embed drm_device in sprd_drm and use devm_drm_dev_alloc
> 5. Replace DRM_XXX with drm_xxx on KMS module, but not suitable for other
> subsystems
> 6. Remove plane_update stuff, dpu handles all the HW update in
> crtc->atomic_flush
> 7. Dsi Code structure adjustment, all move to "sprd/"
>
> v0:
> 1. Remove dpu_core_ops stuff layer for sprd drtc driver, but dpu_layer
> need to keeping.
>Because all the HW update in crtc->atomic_flush, we need temporary
> storage all layers for
>the dpu pageflip of atomic_flush.
> 2. Add ports subnode with port@X.
>
> v1:
> 1. Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
> 2. Add commit messages for Unisoc's virtual nodes.
>
> v2:
> 1. Use drm_xxx to replace all DRM_XXX.
> 2. Use kzalloc to replace devm_kzalloc for sprd_dsi/sprd_dpu structure
> init.
> 3. Remove dpu_core_ops midlayer.
>
> v3:
> 1. Remove dpu_layer midlayer and commit layers by aotmic_update
>
> Kevin Tang (6):
>   dt-bindings: display: add Unisoc's drm master bindings
>   drm/sprd: add Unisoc's drm kms master
>   dt-bindings: display: add Unisoc's dpu bindings
>   drm/sprd: add Unisoc's drm display controller driver
>   dt-bindings: display: add Unisoc's mipi dsi controller bindings
>   drm/sprd: add Unisoc's drm mipi dsi driver
>
>  .../display/sprd/sprd,display-subsystem.yaml   |   64 +
>  .../bindings/display/sprd/sprd,sharkl3-dpu.yaml|   77 +
>  .../display/sprd/sprd,sharkl3-dsi-host.yaml|  102 ++
>  drivers/gpu/drm/Kconfig|2 +
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/sprd/Kconfig   |   13 +
>  drivers/gpu/drm/sprd/Makefile  |8 +
>  drivers/gpu/drm/sprd/dw_dsi_ctrl.c |  794 +++
>  drivers/gpu/drm/sprd/dw_dsi_ctrl.h | 1475
> 
>  drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c |  157 +++
>  drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h |   26 +
>  drivers/gpu/drm/sprd/megacores_pll.c   |  317 +
>  drivers/gpu/drm/sprd/megacores_pll.h   |  146 ++
>  drivers/gpu/drm/sprd/sprd_dpu.c|  985 +
>  drivers/gpu/drm/sprd/sprd_dpu.h|  120 ++
>  drivers/gpu/drm/sprd/sprd_drm.c|  224 +++
>  drivers/gpu/drm/sprd/sprd_drm.h|   19 +
>  drivers/gpu/drm/sprd/sprd_dsi.c| 1162 +++
>  drivers/gpu/drm/sprd/sprd_dsi.h|  107 ++
>  19 files changed, 5799 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
>  create mode 100644
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
>  create mode 100644
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
>  create mode 100644 drivers/gpu/drm/sprd/Kconfig
>  create mode 100644 drivers/gpu/drm/sprd/Makefile
>  create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c
>  create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h
>  create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c
>  create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h
>  create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c
>  create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h
>  create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c
>  

Re: [PATCH v1 1/2] drm/gma500: Convert to use new SCU IPC API

2021-01-23 Thread Andy Shevchenko
On Fri, Jan 22, 2021 at 03:16:55PM +0100, Patrik Jakobsson wrote:
> On Fri, Jan 22, 2021 at 12:39 PM Andy Shevchenko
>  wrote:
> >
> > Convert the GMA500 driver to use the new SCU IPC API. This allows us
> > to get rid of the duplicate PMC IPC implementation which is now covered
> > in SCU IPC driver.
> >
> > Signed-off-by: Andy Shevchenko 
> > Acked-by: Linus Walleij 
> 
> Both patches look good. Do you want me to take them through drm-misc? 
> Otherwise:
> Acked-by: Patrik Jakobsson 

I guess it's fine to go via drm-misc, but we might need an immutable branch/tag
in the future (in case the rest cleanups that are dependent but have not sent
yet will pending v5.12).

-- 
With Best Regards,
Andy Shevchenko


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: linux-next: Tree for Jan 22 (amdgpu)

2021-01-23 Thread Randy Dunlap
On 1/21/21 11:06 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20210121:
> 

on i386:

ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!



-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v1 2/2] drm/gma500: Get rid of duplicate NULL checks

2021-01-23 Thread Andy Shevchenko
Since GPIOs are optional we don't need to repeat checks that are done
in the GPIO API. Remove them for good.

Signed-off-by: Andy Shevchenko 
Acked-by: Linus Walleij 
---
 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c 
b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
index 7d012db6352b..3dab94463656 100644
--- a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
+++ b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
@@ -518,11 +518,9 @@ void tc35876x_toshiba_bridge_panel_off(struct drm_device 
*dev)
 
dev_dbg(_client->dev, "%s\n", __func__);
 
-   if (bridge_bl_enable)
-   gpiod_set_value_cansleep(bridge_bl_enable, 0);
+   gpiod_set_value_cansleep(bridge_bl_enable, 0);
 
-   if (backlight_voltage)
-   gpiod_set_value_cansleep(backlight_voltage, 0);
+   gpiod_set_value_cansleep(backlight_voltage, 0);
 }
 
 void tc35876x_toshiba_bridge_panel_on(struct drm_device *dev)
@@ -567,8 +565,7 @@ void tc35876x_toshiba_bridge_panel_on(struct drm_device 
*dev)
"i2c write failed (%d)\n", ret);
}
 
-   if (bridge_bl_enable)
-   gpiod_set_value_cansleep(bridge_bl_enable, 1);
+   gpiod_set_value_cansleep(bridge_bl_enable, 1);
 
tc35876x_brightness_control(dev, dev_priv->brightness_adjusted);
 }
@@ -642,20 +639,17 @@ static int tc35876x_bridge_probe(struct i2c_client 
*client,
bridge_reset = devm_gpiod_get_optional(>dev, "bridge-reset", 
GPIOD_OUT_LOW);
if (IS_ERR(bridge_reset))
return PTR_ERR(bridge_reset);
-   if (bridge_reset)
-   gpiod_set_consumer_name(bridge_reset, "tc35876x bridge reset");
+   gpiod_set_consumer_name(bridge_reset, "tc35876x bridge reset");
 
bridge_bl_enable = devm_gpiod_get_optional(>dev, "bl-en", 
GPIOD_OUT_LOW);
if (IS_ERR(bridge_bl_enable))
return PTR_ERR(bridge_bl_enable);
-   if (bridge_bl_enable)
-   gpiod_set_consumer_name(bridge_bl_enable, "tc35876x panel bl 
en");
+   gpiod_set_consumer_name(bridge_bl_enable, "tc35876x panel bl en");
 
backlight_voltage = devm_gpiod_get_optional(>dev, "vadd", 
GPIOD_OUT_LOW);
if (IS_ERR(backlight_voltage))
return PTR_ERR(backlight_voltage);
-   if (backlight_voltage)
-   gpiod_set_consumer_name(backlight_voltage, "tc35876x panel 
vadd");
+   gpiod_set_consumer_name(backlight_voltage, "tc35876x panel vadd");
 
tc35876x_client = client;
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

2021-01-23 Thread Chenyang Li
This patch adds an initial DRM driver for the Loongson LS7A1000
bridge chip(LS7A). The LS7A bridge chip contains two display
controllers, support dual display output. The maximum support for
each channel display is to 1920x1080@60Hz.
At present, DC device detection and DRM driver registration are
completed, the crtc/plane/encoder/connector objects has been
implemented.
On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use
of dual screen, and support dual screen clone mode and expansion
mode.

v4:
- Move the mode_valid function to the crtc.

v3:
- Move the mode_valid function to the connector and optimize it.
- Fix num_crtc calculation method.

v2:
- Complete the case of 32-bit color in CRTC.

Signed-off-by: Chenyang Li 
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/loongson/Kconfig  |  14 +
 drivers/gpu/drm/loongson/Makefile |  14 +
 drivers/gpu/drm/loongson/loongson_connector.c |  48 
 drivers/gpu/drm/loongson/loongson_crtc.c  | 241 
 drivers/gpu/drm/loongson/loongson_device.c|  54 
 drivers/gpu/drm/loongson/loongson_drv.c   | 269 ++
 drivers/gpu/drm/loongson/loongson_drv.h   | 131 +
 drivers/gpu/drm/loongson/loongson_encoder.c   |  37 +++
 drivers/gpu/drm/loongson/loongson_plane.c | 102 +++
 11 files changed, 913 insertions(+)
 create mode 100644 drivers/gpu/drm/loongson/Kconfig
 create mode 100644 drivers/gpu/drm/loongson/Makefile
 create mode 100644 drivers/gpu/drm/loongson/loongson_connector.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_crtc.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_device.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_drv.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_drv.h
 create mode 100644 drivers/gpu/drm/loongson/loongson_encoder.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..6ed1b6dc2f25 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -374,6 +374,8 @@ source "drivers/gpu/drm/xen/Kconfig"
 
 source "drivers/gpu/drm/vboxvideo/Kconfig"
 
+source "drivers/gpu/drm/loongson/Kconfig"
+
 source "drivers/gpu/drm/lima/Kconfig"
 
 source "drivers/gpu/drm/panfrost/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index fefaff4c832d..f87da730ea6d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -119,6 +119,7 @@ obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
 obj-$(CONFIG_DRM_XEN) += xen/
 obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
+obj-$(CONFIG_DRM_LOONGSON) += loongson/
 obj-$(CONFIG_DRM_LIMA)  += lima/
 obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
diff --git a/drivers/gpu/drm/loongson/Kconfig b/drivers/gpu/drm/loongson/Kconfig
new file mode 100644
index ..43eb0c80cc12
--- /dev/null
+++ b/drivers/gpu/drm/loongson/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config DRM_LOONGSON
+   tristate "DRM support for LS7A1000 bridge chipset"
+   depends on DRM && PCI
+   depends on CPU_LOONGSON64
+   select DRM_KMS_HELPER
+   select DRM_VRAM_HELPER
+   select DRM_TTM
+   select DRM_TTM_HELPER
+   default n
+   help
+ Support the display controllers found on the Loongson LS7A1000
+ bridge.
diff --git a/drivers/gpu/drm/loongson/Makefile 
b/drivers/gpu/drm/loongson/Makefile
new file mode 100644
index ..22d063953b78
--- /dev/null
+++ b/drivers/gpu/drm/loongson/Makefile
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Makefile for loongson drm drivers.
+# This driver provides support for the
+# Direct Rendering Infrastructure (DRI)
+
+ccflags-y := -Iinclude/drm
+loongson-y := loongson_drv.o \
+   loongson_crtc.o \
+   loongson_plane.o \
+   loongson_device.o \
+   loongson_connector.o \
+   loongson_encoder.o
+obj-$(CONFIG_DRM_LOONGSON) += loongson.o
diff --git a/drivers/gpu/drm/loongson/loongson_connector.c 
b/drivers/gpu/drm/loongson/loongson_connector.c
new file mode 100644
index ..6b1f0ffa33bd
--- /dev/null
+++ b/drivers/gpu/drm/loongson/loongson_connector.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "loongson_drv.h"
+
+static int loongson_get_modes(struct drm_connector *connector)
+{
+   int count;
+
+   count = drm_add_modes_noedid(connector, 1920, 1080);
+   drm_set_preferred_mode(connector, 1024, 768);
+
+   return count;
+}
+
+static const struct drm_connector_helper_funcs loongson_connector_helper = {
+   .get_modes = loongson_get_modes,
+};
+
+static const struct drm_connector_funcs loongson_connector_funcs = {
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy = drm_connector_cleanup,
+   .reset = 

[PATCH v1 1/2] drm/gma500: Convert to use new SCU IPC API

2021-01-23 Thread Andy Shevchenko
Convert the GMA500 driver to use the new SCU IPC API. This allows us
to get rid of the duplicate PMC IPC implementation which is now covered
in SCU IPC driver.

Signed-off-by: Andy Shevchenko 
Acked-by: Linus Walleij 
---
 drivers/gpu/drm/gma500/Kconfig |  1 +
 drivers/gpu/drm/gma500/mdfld_device.c  |  2 --
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |  2 --
 drivers/gpu/drm/gma500/mdfld_output.c  |  8 ++--
 drivers/gpu/drm/gma500/oaktrail_device.c   |  3 ---
 drivers/gpu/drm/gma500/psb_drv.h   |  3 +++
 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 12 +++-
 7 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0e23c93a1094..1ef2cda5b5c2 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -30,6 +30,7 @@ config DRM_GMA3600
 config DRM_MEDFIELD
bool "Intel Medfield support (Experimental)"
depends on DRM_GMA500 && X86_INTEL_MID
+   select INTEL_SCU_IPC
help
  Say yes to include support for the Intel Medfield platform.
 
diff --git a/drivers/gpu/drm/gma500/mdfld_device.c 
b/drivers/gpu/drm/gma500/mdfld_device.c
index b83d59b21de5..12193e591327 100644
--- a/drivers/gpu/drm/gma500/mdfld_device.c
+++ b/drivers/gpu/drm/gma500/mdfld_device.c
@@ -8,8 +8,6 @@
 #include 
 #include 
 
-#include 
-
 #include "mdfld_dsi_output.h"
 #include "mdfld_output.h"
 #include "mid_bios.h"
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 4aab76613bd9..38ec49b71499 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -30,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 #include "mdfld_dsi_dpi.h"
 #include "mdfld_dsi_output.h"
 #include "mdfld_dsi_pkg_sender.h"
diff --git a/drivers/gpu/drm/gma500/mdfld_output.c 
b/drivers/gpu/drm/gma500/mdfld_output.c
index c95966bb0c96..518417f49be8 100644
--- a/drivers/gpu/drm/gma500/mdfld_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_output.c
@@ -25,6 +25,8 @@
  * Scott Rowe 
 */
 
+#include 
+
 #include "mdfld_output.h"
 #include "mdfld_dsi_dpi.h"
 #include "mdfld_dsi_output.h"
@@ -58,11 +60,14 @@ static void mdfld_init_panel(struct drm_device *dev, int 
mipi_pipe,
}
 }
 
-
 int mdfld_output_init(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
 
+   dev_priv->scu = devm_intel_scu_ipc_dev_get(>pdev->dev);
+   if (!dev_priv->scu)
+   return -EPROBE_DEFER;
+
/* FIXME: hardcoded for now */
dev_priv->mdfld_panel_id = TC35876X;
/* MIPI panel 1 */
@@ -71,4 +76,3 @@ int mdfld_output_init(struct drm_device *dev)
mdfld_init_panel(dev, 1, HDMI);
return 0;
 }
-
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c 
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 8754290b0e23..0c1a66b20f27 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -10,9 +10,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include 
 
 #include "intel_bios.h"
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 5b7f7a312d53..938efdddc27c 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -428,6 +428,8 @@ struct psb_ops;
 
 #define PSB_NUM_PIPE   3
 
+struct intel_scu_ipc_dev;
+
 struct drm_psb_private {
struct drm_device *dev;
struct pci_dev *aux_pdev; /* Currently only used by mrst */
@@ -567,6 +569,7 @@ struct drm_psb_private {
 * Used for modifying backlight from
 * xrandr -- consider removing and using HAL instead
 */
+   struct intel_scu_ipc_dev *scu;
struct backlight_device *backlight_device;
struct drm_property *backlight_property;
bool backlight_enabled;
diff --git a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c 
b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
index e5bdd99ad453..7d012db6352b 100644
--- a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
+++ b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
@@ -444,6 +444,7 @@ static inline u16 calc_clkdiv(unsigned long baseclk, 
unsigned int f)
 
 static void tc35876x_brightness_init(struct drm_device *dev)
 {
+   struct drm_psb_private *dev_priv = dev->dev_private;
int ret;
u8 pwmctrl;
u16 clkdiv;
@@ -451,23 +452,23 @@ static void tc35876x_brightness_init(struct drm_device 
*dev)
/* Make sure the PWM reference is the 19.2 MHz system clock. Read first
 * instead of setting directly to catch potential conflicts between PWM
 * users. */
-   ret = intel_scu_ipc_ioread8(GPIOPWMCTRL, );
+   ret = intel_scu_ipc_dev_ioread8(dev_priv->scu, GPIOPWMCTRL, );
if (ret || pwmctrl != 0x01) {
if (ret)
dev_err(>pdev->dev, "GPIOPWMCTRL read failed\n");
else

Re: fbcon: remove soft scrollback code (missing Doc. patch)

2021-01-23 Thread Phillip Susi


Geert Uytterhoeven writes:

Judging from some of the comments in the code, it looks like you were
one of the original authors of fbcon?  I haven't been able to find any
of these sczbot crash reports, and am not sure how fuzzing syscalls
would really affect this code ( it's not really handling a buch of
ioctls or otherwise taking arguments from user space ) , but I am a bit
confused as to why the softback was implemented the way that it was.

vgacon simply copies the main buffer to vram in ->set_origin() and then
changes the pointers to operate out of the much larger vram while that
virtual terminal is active.  If I understand it correctly, it looks like
fbcon instead opts to operate out of the main buffer but rescue lines as
they are scrolled off and relocate them to the softback buffer.  This
seems to be rather more convoluted.

I'm thinking of re-implementing scrollback more like the way vgacon does
it: allocate a big "vram" buffer and operate out of that.  Obviously
->scroll() and ->scrolldelta() have to actually repaint the screen rather
than simply change the pointer register, but that should be about the
only difference.

I have also noticed that there was some code to use hardware panning of
the video buffer rather than having to do a block bitblt to scroll the
contents of the screen, but that it was disabled because virtually no
video drivers actually implemented it?  That seems like a shame, but if
it is so, then there's no sense carrying the dead code so I think I'll
clean that up now.

Now that I look at it again, everything is simply always redrawn now
instead of even doing a simple bitblt.  Daniel, you mentioned that
almost nobody supports hardware acceleration, but even without any
specific hardware support, surely even if bitblt() is implemented just
as a memcpy(), it has to be faster than redrawing all of the characters
doesn't it?  Getting rid of the panning if it isn't generally supported
I can see, but I don't understand killing bitblt even if most devices
don't accelerate it.

In addition, I noticed that ->screen_pos() was changed to just return
vc_origin+offset.  fbcon is the only console driver to implement
->screenpos() and if not implemented, vt defaults to using
vc_visible_origin+offset, so it looks like this function isn't needed at
all anymore and ->screen_pos() can be removed from struct consw.

Does this make sense or am I talking crazy?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds

2021-01-23 Thread Lukasz Luba




On 1/22/21 10:24 AM, Steven Price wrote:

On 22/01/2021 10:00, Lukasz Luba wrote:



On 1/22/21 8:21 AM, Steven Price wrote:

On 21/01/2021 17:04, Lukasz Luba wrote:
The simple_ondemand devfreq governor uses two thresholds to decide 
about

the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds 
needed
governor data with thresholds values gathered experimentally in 
different

workloads.

Signed-off-by: Lukasz Luba 
---
Hi all,

This patch aims to improve the panfrost performance in various 
workloads,

(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with 
panfrost.

These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.

Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114


It would be good to state which platform this is on as this obviously 
can vary depending on the OPPs available.


Sorry about that. It was Rock Pi 4B and I have mesa 20.2.4.



Of course the real fix here would be to improve the utilisation of 
the GPU[1] so we actually hit the 90% threshold more easily (AFAICT 
kbase uses the default 90/5 thresholds), but this seems like a 
reasonable change for now.


Agree, improving the scheduler would be the best option. I'll have a
look at that patch and why it got this 10% lower performance. Maybe
I would find something during testing.


I'm afraid it'll probably need a fair bit of work to rebase - things 
have changed around that code. I'm hoping that most of the problem was 
really around how Mesa was driving the GPU at that time and things 
should be better. The DDK (hacked to talk Panfrost ioctls) saw a 
performance improvement.


Let me know if you hit problems and need any help.


OK, I will contact you when I face some problems.





Reviewed-by: Steven Price 


Thank you for the review. I guess this patch would go through drm tree?


Yes, I'll push it to drm-misc-next later.


Thank you!

Lukasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/nouveau: remove set but not used variable ‘pdev’ in nouveau_bios_init

2021-01-23 Thread Ye Bin
Fix follow warning:
drivers/gpu/drm/nouveau/nouveau_bios.c:2086:18: warning: variable ‘pdev’ set 
but not used [-Wunused-but-set-variable]
  struct pci_dev *pdev;
  ^~~~

Reported-by: Hulk Robot 
Signed-off-by: Ye Bin 
---
 drivers/gpu/drm/nouveau/nouveau_bios.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 7cc683b8dc7a..e8c445eb1100 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -2083,13 +2083,11 @@ nouveau_bios_init(struct drm_device *dev)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvbios *bios = >vbios;
-   struct pci_dev *pdev;
int ret;
 
/* only relevant for PCI devices */
if (!dev_is_pci(dev->dev))
return 0;
-   pdev = to_pci_dev(dev->dev);
 
if (!NVInitVBIOS(dev))
return -ENODEV;
-- 
2.25.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5

2021-01-23 Thread Lucas Nussbaum
On 21/01/21 at 11:57 +0100, Maxime Ripard wrote:
> From: Dom Cobley 
> 
> Fixes failure with 4096x1080 resolutions
> 
> [  284.315379] WARNING: CPU: 1 PID: 901 at 
> drivers/gpu/drm/vc4/vc4_plane.c:981 vc4_plane_mode_set+0x1374/0x13c4
> [  284.315385] Modules linked in: ir_rc5_decoder rpivid_hevc(C) 
> bcm2835_codec(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) bcm2835_gpiomem 
> v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 
> videobuf2_common videodev mc cdc_acm xpad ir_rc6_decoder rc_rc6_mce 
> gpio_ir_recv fuse
> [  284.315509] CPU: 1 PID: 901 Comm: kodi.bin Tainted: G C
> 5.10.7 #1
> [  284.315514] Hardware name: BCM2711
> [  284.315518] Backtrace:
> [  284.315533] [] (dump_backtrace) from [] 
> (show_stack+0x20/0x24)
> [  284.315540]  r7: r6: r5:6813 r4:c18ecf1c
> [  284.315549] [] (show_stack) from [] 
> (dump_stack+0xc4/0xf0)
> [  284.315558] [] (dump_stack) from [] (__warn+0xfc/0x158)
> [  284.315564]  r9: r8:0009 r7:03d5 r6:0009 r5:c08cc7dc 
> r4:c0fd09b8
> [  284.315572] [] (__warn) from [] 
> (warn_slowpath_fmt+0x74/0xe4)
> [  284.315577]  r7:c08cc7dc r6:03d5 r5:c0fd09b8 r4:
> [  284.315584] [] (warn_slowpath_fmt) from [] 
> (vc4_plane_mode_set+0x1374/0x13c4)
> [  284.315589]  r8: r7: r6:1000 r5:c404c600 r4:c2e34600
> [  284.315596] [] (vc4_plane_mode_set) from [] 
> (vc4_plane_atomic_check+0x40/0x1c0)
> [  284.315601]  r10:0001 r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640 
> r5:c3d636c0
> [  284.315605]  r4:c2e34600
> [  284.315614] [] (vc4_plane_atomic_check) from [] 
> (drm_atomic_helper_check_planes+0xec/0x1ec)
> [  284.315620]  r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640 r5:c3d636c0 
> r4:0006
> [  284.315627] [] (drm_atomic_helper_check_planes) from 
> [] (drm_atomic_helper_check+0x54/0x9c)
> [  284.315633]  r9:c2e35400 r8:0006 r7: r6:c2ba7800 r5:c3d636c0 
> r4:
> [  284.315641] [] (drm_atomic_helper_check) from [] 
> (vc4_atomic_check+0x25c/0x454)
> [  284.315645]  r7: r6:c2ba7800 r5:0001 r4:c3d636c0
> [  284.315652] [] (vc4_atomic_check) from [] 
> (drm_atomic_check_only+0x5cc/0x7e0)
> [  284.315658]  r10:c404c6c8 r9: r8:c472c480 r7:0003 r6:c3d636c0 
> r5:
> [  284.315662]  r4:003c r3:c08b7a4c
> [  284.315670] [] (drm_atomic_check_only) from [] 
> (drm_mode_atomic_ioctl+0x758/0xa7c)
> [  284.315675]  r10:c3d46000 r9:c3d636c0 r8:c2ce8a70 r7:027e3a54 r6:0043 
> r5:c1fbb800
> [  284.315679]  r4:0281a858
> [  284.315688] [] (drm_mode_atomic_ioctl) from [] 
> (drm_ioctl_kernel+0xc4/0x108)
> [  284.315693]  r10:c03864bc r9:c1fbb800 r8:c3d47e64 r7:c089b308 r6:0002 
> r5:c2ba7800
> [  284.315697]  r4:
> [  284.315705] [] (drm_ioctl_kernel) from [] 
> (drm_ioctl+0x1e8/0x3a0)
> [  284.315711]  r9:c1fbb800 r8:00bc r7:c3d47e64 r6:0038 r5:c0e59570 
> r4:0038
> [  284.315719] [] (drm_ioctl) from [] 
> (sys_ioctl+0x35c/0x914)
> [  284.315724]  r10:c2d08200 r9: r8:c36fa300 r7:befdd870 r6:c03864bc 
> r5:c36fa301
> [  284.315728]  r4:c03864bc
> [  284.315735] [] (sys_ioctl) from [] 
> (ret_fast_syscall+0x0/0x28)
> [  284.315739] Exception stack(0xc3d47fa8 to 0xc3d47ff0)
> [  284.315745] 7fa0:   027eb750 befdd870  c03864bc 
> befdd870 
> [  284.315750] 7fc0: 027eb750 befdd870 c03864bc 0036 027e3948 0281a640 
> 0281a850 027e3a50
> [  284.315756] 7fe0: b4b64100 befdd844 b4b5ba2c b49c994c
> [  284.315762]  r10:0036 r9:c3d46000 r8:c0200204 r7:0036 r6:c03864bc 
> r5:befdd870
> [  284.315765]  r4:027eb750
> 
> Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 

Tested-By: Lucas Nussbaum 

- Lucas


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1 1/2] drm/gma500: Convert to use new SCU IPC API

2021-01-23 Thread Andy Shevchenko
On Fri, Jan 22, 2021 at 04:15:33PM +0100, Patrik Jakobsson wrote:
> On Fri, Jan 22, 2021 at 3:51 PM Andy Shevchenko
>  wrote:
> >
> > On Fri, Jan 22, 2021 at 03:16:55PM +0100, Patrik Jakobsson wrote:
> > > On Fri, Jan 22, 2021 at 12:39 PM Andy Shevchenko
> > >  wrote:
> > > >
> > > > Convert the GMA500 driver to use the new SCU IPC API. This allows us
> > > > to get rid of the duplicate PMC IPC implementation which is now covered
> > > > in SCU IPC driver.
> > > >
> > > > Signed-off-by: Andy Shevchenko 
> > > > Acked-by: Linus Walleij 
> > >
> > > Both patches look good. Do you want me to take them through drm-misc? 
> > > Otherwise:
> > > Acked-by: Patrik Jakobsson 
> >
> > I guess it's fine to go via drm-misc, but we might need an immutable 
> > branch/tag
> > in the future (in case the rest cleanups that are dependent but have not 
> > sent
> > yet will pending v5.12).
> 
> Right, so you need this included before you remove the duplicate PMC
> IPC implementation? Then I think it's better you take the patches
> through whatever tree the PMC IPC changes go. You have my ack.

Got it, thanks!

-- 
With Best Regards,
Andy Shevchenko


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds

2021-01-23 Thread Lukasz Luba




On 1/21/21 5:15 PM, Daniel Lezcano wrote:

On 21/01/2021 18:04, Lukasz Luba wrote:

The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in different
workloads.

Signed-off-by: Lukasz Luba 
---
Hi all,

This patch aims to improve the panfrost performance in various workloads,
(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with panfrost.
These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.

Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114

In future the devfreq framework would expose via sysfs these two
tunables, so they can be adjusted by the middleware based on currently
running workload (game, desktop, web browser, etc). These new values
should be good enough, though.

Regards,
Lukasz Luba

  drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 +-
  drivers/gpu/drm/panfrost/panfrost_devfreq.h |  2 ++
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..7c5ffc81dce1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -130,8 +130,16 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
  
+	/*

+* Setup default thresholds for the simple_ondemand governor.
+* The values are chosen based on experiments.
+*/
+   pfdevfreq->gov_data.upthreshold = 45;
+   pfdevfreq->gov_data.downdifferential = 5;
+
devfreq = devm_devfreq_add_device(dev, _devfreq_profile,
- DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ >gov_data);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
ret = PTR_ERR(devfreq);
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..1e2a4de941aa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -4,6 +4,7 @@
  #ifndef __PANFROST_DEVFREQ_H__
  #define __PANFROST_DEVFREQ_H__
  
+#include 

  #include 
  #include 
  
@@ -17,6 +18,7 @@ struct panfrost_devfreq {

struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
+   struct devfreq_simple_ondemand_data gov_data;
bool opp_of_table_added;
  
  	ktime_t busy_time;


I think it is simpler to do:

+static struct devfreq_simple_ondemand_data panfrost_ondemand_data = {
+   .upthreshold = 45,
+   .downdifferential = 5,
+};

[ ... ]

devfreq = devm_devfreq_add_device(dev, _devfreq_profile,
- DEVFREQ_GOV_SIMPLE_ONDEMAND,
NULL);
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ _ondemand_data);




Yes, it's simpler. The driver would probably never have to serve two
GPUs. I've tried to keep this thing inside the panfrost struct,
forgetting about it.

Steven already reviewed the patch, so it can probably stay.
I will keep it in mind. Thank you for the comments.

Regards,
Lukasz
___
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.

2021-01-23 Thread Oleksij Rempel
On Thu, Jan 21, 2021 at 11:17:42AM -0300, Fabio Estevam wrote:
> 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 

OK, nice. Thx!

Should I resend this series without this patch?

Regards,
Oleksij
-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds

2021-01-23 Thread Lukasz Luba




On 1/22/21 8:21 AM, Steven Price wrote:

On 21/01/2021 17:04, Lukasz Luba wrote:

The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in different
workloads.

Signed-off-by: Lukasz Luba 
---
Hi all,

This patch aims to improve the panfrost performance in various workloads,
(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with 
panfrost.

These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.

Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114


It would be good to state which platform this is on as this obviously 
can vary depending on the OPPs available.


Sorry about that. It was Rock Pi 4B and I have mesa 20.2.4.



Of course the real fix here would be to improve the utilisation of the 
GPU[1] so we actually hit the 90% threshold more easily (AFAICT kbase 
uses the default 90/5 thresholds), but this seems like a reasonable 
change for now.


Agree, improving the scheduler would be the best option. I'll have a
look at that patch and why it got this 10% lower performance. Maybe
I would find something during testing.



Reviewed-by: Steven Price 


Thank you for the review. I guess this patch would go through drm tree?

Regards,
Lukasz



Thanks,

Steve

[1] When I get some time I need to rework the "queue jobs on the 
hardware"[2] patch I posted ages ago. Last time it actually caused a 
performance regression though...


[2] https://lore.kernel.org/r/20190816093107.30518-2-steven.price%40arm.com


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


linux-firmware for Qualcomm SM8250 platforms

2021-01-23 Thread Dmitry Baryshkov

Hello linux-firmware maintainers,

We'd like to submit firmware for Qualcomm SM8250-based platforms. 
Firmware successfully tested on Qualcomm Robotics RB5 platform.


The following changes since commit d5288624259300c558480c21a860fcf94187d29d:

  brcm: Add NVRAM for Vamrs 96boards Rock960 (2021-01-09 07:31:33 -0500)

are available in the Git repository at:

  https://github.com/lumag/linux-firmware qcom-rb5

for you to fetch changes up to df822a848cceb185d2d50a39140ba0c9cd9f33e9::

  qcom: Add venus firmware files for VPU-1.0 (2021-01-23 01:10:05 +0300)


Dmitry Baryshkov (4):
  qcom: add firmware files for Adreno a650
  qcom: Add SM8250 Audio DSP firmware
  qcom: Add SM8250 Compute DSP firmware
  qcom: Add venus firmware files for VPU-1.0

 WHENCE   |  26 ++
 qcom/a650_gmu.bin| Bin 0 -> 41548 bytes
 qcom/a650_sqe.fw | Bin 0 -> 31488 bytes
 qcom/sm8250/a650_zap.mbn | Bin 0 -> 13964 bytes
 qcom/sm8250/adsp.mbn | Bin 0 -> 15515796 bytes
 qcom/sm8250/adspr.jsn|  21 +
 qcom/sm8250/adspua.jsn   |  27 +++
 qcom/sm8250/cdsp.mbn | Bin 0 -> 588 bytes
 qcom/sm8250/cdspr.jsn|  21 +
 qcom/vpu-1.0/venus.b00   | Bin 0 -> 692 bytes
 qcom/vpu-1.0/venus.b01   | Bin 0 -> 7528 bytes
 qcom/vpu-1.0/venus.b02   | Bin 0 -> 300 bytes
 qcom/vpu-1.0/venus.b03   | Bin 0 -> 20 bytes
 qcom/vpu-1.0/venus.b04   | Bin 0 -> 20 bytes
 qcom/vpu-1.0/venus.b05   | Bin 0 -> 20 bytes
 qcom/vpu-1.0/venus.b06   | Bin 0 -> 20 bytes
 qcom/vpu-1.0/venus.b07   | Bin 0 -> 24 bytes
 qcom/vpu-1.0/venus.b08   | Bin 0 -> 16 bytes
 qcom/vpu-1.0/venus.b09   | Bin 0 -> 883152 bytes
 qcom/vpu-1.0/venus.b10   | Bin 0 -> 41360 bytes
 qcom/vpu-1.0/venus.b19   |   1 +
 qcom/vpu-1.0/venus.mbn   | Bin 0 -> 1973540 bytes
 qcom/vpu-1.0/venus.mdt   | Bin 0 -> 8220 bytes
 23 files changed, 96 insertions(+)
 create mode 100644 qcom/a650_gmu.bin
 create mode 100644 qcom/a650_sqe.fw
 create mode 100644 qcom/sm8250/a650_zap.mbn
 create mode 100644 qcom/sm8250/adsp.mbn
 create mode 100644 qcom/sm8250/adspr.jsn
 create mode 100644 qcom/sm8250/adspua.jsn
 create mode 100644 qcom/sm8250/cdsp.mbn
 create mode 100644 qcom/sm8250/cdspr.jsn
 create mode 100644 qcom/vpu-1.0/venus.b00
 create mode 100644 qcom/vpu-1.0/venus.b01
 create mode 100644 qcom/vpu-1.0/venus.b02
 create mode 100644 qcom/vpu-1.0/venus.b03
 create mode 100644 qcom/vpu-1.0/venus.b04
 create mode 100644 qcom/vpu-1.0/venus.b05
 create mode 100644 qcom/vpu-1.0/venus.b06
 create mode 100644 qcom/vpu-1.0/venus.b07
 create mode 100644 qcom/vpu-1.0/venus.b08
 create mode 100644 qcom/vpu-1.0/venus.b09
 create mode 100644 qcom/vpu-1.0/venus.b10
 create mode 100644 qcom/vpu-1.0/venus.b19
 create mode 100644 qcom/vpu-1.0/venus.mbn
 create mode 100644 qcom/vpu-1.0/venus.mdt



--
With best wishes
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: possible IO map leak in drm/gem

2021-01-23 Thread Chuck Lever


> On Jan 21, 2021, at 10:05 AM, Chuck Lever  wrote:
> 
> 
> 
>> On Jan 21, 2021, at 9:47 AM, Thomas Zimmermann  wrote:
>> 
>> (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.
> 
> Thomas, thank you for your quick response. I've installed your patch
> on one system and it looks promising already. I'll let it soak overnight.

All symptoms appear to be gone. Fwiw,

Tested-by: Chuck Lever 


>> 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: >> trace>
>>> => 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
> 
> --
> Chuck Lever

--
Chuck Lever



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting

2021-01-23 Thread Xin Ji
On Wed, Jan 20, 2021 at 04:57:56PM +0800, Nicolas Boichat wrote:
> On Tue, Jan 12, 2021 at 4:59 PM Xin Ji  wrote:
> >
> > Hi Rob Herring, thanks for the comments.
> >
> > On Mon, Jan 11, 2021 at 04:14:35PM -0600, Rob Herring wrote:
> > > On Thu, Dec 31, 2020 at 10:21:12AM +0800, Xin Ji wrote:
> > > > Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add
> > > > swing setting for adjusting DP tx PHY swing
> > > >
> > > > Signed-off-by: Xin Ji 
> > > > ---
> > > >  .../bindings/display/bridge/analogix,anx7625.yaml  | 25 
> > > > --
> > > >  1 file changed, 23 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > >  
> > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > index 60585a4..4eb0ea3 100644
> > > > --- 
> > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > +++ 
> > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > @@ -34,6 +34,16 @@ properties:
> > > >  description: used for reset chip control, RESET_N pin B7.
> > > >  maxItems: 1
> > > >
> > > > +  analogix,swing-setting:
> > > > +type: uint8-array
> > >
> > > Humm, this should have be rejected by the meta-schema.
> > We needs define an array to adjust DP tx PHY swing, the developer hopes 
> > these
> > settings are changeable, so I moved the register data to DT. Can you
> > give me some suggestion if it is rejected by the meta-schema?
> > >
> > > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > >
> > > This is how types are defined other than boolean or nodes (object).
> > >
> > > > +description: an array of swing register setting for DP tx PHY
> > > > +
> > > > +  analogix,mipi-dpi-in:
> > > > +type: int
> > > > +$ref: /schemas/types.yaml#/definitions/uint32
> > > > +description: indicate the MIPI rx signal type is DPI or DSI
> > >
> > > Why does this need to be in DT, you should be able to determine this
> > > based on what you are connected to.
> > As the anx7625 can receive MIPI DSI and DPI data (depends on hardware
> > implement, we have a project which have two anx7625, one is DSI input,
> > the other is DPI input), we needs to let driver know what kind of MIPI
> > rx signal input. And there is no other way to tell driver the MIPI rx
> > signal type, we needs define this flag.
> > >
> > > > +
> > > >ports:
> > > >  type: object
> > > >
> > > > @@ -49,8 +59,8 @@ properties:
> > > >Video port for panel or connector.
> > > >
> > > >  required:
> > > > -- port@0
> > > > -- port@1
> > > > +  - port@0
> > > > +  - port@1
> > > >
> > > >  required:
> > > >- compatible
> > > > @@ -72,6 +82,17 @@ examples:
> > > >  reg = <0x58>;
> > > >  enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> > > >  reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> > > > +analogix,swing-setting = <0x00 0x14>, <0x01 0x54>,
> > > > +<0x02 0x64>, <0x03 0x74>, <0x04 0x29>,
> > > > +<0x05 0x7b>, <0x06 0x77>, <0x07 0x5b>,
> > > > +<0x08 0x7f>, <0x0c 0x20>, <0x0d 0x60>,
> > > > +<0x10 0x60>, <0x12 0x40>, <0x13 0x60>,
> > > > +<0x14 0x14>, <0x15 0x54>, <0x16 0x64>,
> > > > +<0x17 0x74>, <0x18 0x29>, <0x19 0x7b>,
> > > > +<0x1a 0x77>, <0x1b 0x5b>, <0x1c 0x7f>,
> > > > +<0x20 0x20>, <0x21 0x60>, <0x24 0x60>,
> > > > +<0x26 0x40>, <0x27 0x60>;
> > >
> > > This is a matrix, which is different from an array type.
> > OK, I'll change to array if this vendor define has been accepted.
> 
> I also wonder if we want to split the parameters per lane, and simply
> have a flat array (instead of reg/value pairs like you have now).
> 
> Registers 0x00 to 0x13 have to do with Lane 0 (and 0x14 to 0x27 with
> Lane 1): you can almost tell from the example values, they repeat. I'm
> not sure if there's any value splitting those further (I don't think
> anybody will be able to tune those without ANX's help).
> 
> So, maybe something like:
> anx,swing-setting = <<[reg values for lane 0]>, <[reg values for lane 1]>>
> where <[reg values for lane 0]> would be something like <0x14, 0x54,
> 0x64, ...> (that is, all the values between 0x00 and 0x13).
Hi Nicolas, it is a good way, 0x00 to 0x13 for lane0, 0x14 to 0x27 for lane1.
I'll split the parameters per lane.

Thanks,
Xin
> 
> > >
> > > > +analogix,mipi-dpi-in = <0>;
> > > >
> > > >  ports {
> > > >  #address-cells = <1>;
> > > > --
> > > > 2.7.4
> > > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/vc4: Correct lbm size and calculation

2021-01-23 Thread Maxime Ripard
Hi Lucas,

On Thu, Jan 21, 2021 at 05:26:22PM +0100, Lucas Nussbaum wrote:
> Hi Maxime,
> 
> On 21/01/21 at 12:04 +0100, Maxime Ripard wrote:
> > Hi Lucas, Ryutaroh,
> > 
> > On Thu, Jan 21, 2021 at 11:57:58AM +0100, Maxime Ripard wrote:
> > > From: Dom Cobley 
> > > 
> > > LBM base address is measured in units of pixels per cycle.
> > > That is 4 for 2711 (hvs5) and 2 for 2708.
> > > 
> > > We are wasting 75% of lbm by indexing without the scaling.
> > > But we were also using too high a size for the lbm resulting
> > > in partial corruption (right hand side) of vertically
> > > scaled images, usually at 4K or lower resolutions with more layers.
> > > 
> > > The physical RAM of LBM on 2711 is 8 * 1920 * 16 * 12-bit
> > > (pixels are stored 12-bits per component regardless of format).
> > > 
> > > The LBM adress indexes work in units of pixels per clock,
> > > so for 4 pixels per clock that means we have 32 * 1920 = 60K
> > > 
> > > Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> > > Signed-off-by: Dom Cobley 
> > > Signed-off-by: Maxime Ripard 
> > 
> > This one should fix your issue
> > 
> > Feel free to test it and let me know if it's not the case
> 
> I confirm that the patches fix the issue I was seeing.

Great. Can I add your Tested-by (and Ryutaroh, can I add yours as well?)

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: linux-next: Tree for Jan 22 (drm/i915)

2021-01-23 Thread Randy Dunlap
On 1/21/21 11:06 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20210121:
> 
> The drm-intel tree lost its build failure.
> 
> The notifications tree gained conflicts against the keys tree.
> 
> Non-merge commits (relative to Linus' tree): 4819
>  5269 files changed, 192976 insertions(+), 126175 deletions(-)
> 
> 
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" and checkout or reset to the new
> master.
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log
> files in the Next directory.  Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig and htmldocs. And finally, a simple boot test
> of the powerpc pseries_le_defconfig kernel in qemu (with and without
> kvm enabled).
> 
> Below is a summary of the state of the merge.
> 
> I am currently merging 333 trees (counting Linus' and 86 trees of bug
> fix patches pending for the current merge release).
> 
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
> 
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
> 
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
> 

on x86_64:

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]

../drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_freeze_late’:
../drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of 
function ‘wbinvd_on_all_cpus’; did you mean ‘wrmsr_on_cpus’? 
[-Werror=implicit-function-declaration]
  wbinvd_on_all_cpus();



Full randconfig file is attached.

-- 
~Randy


config-r7373.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel