date:20210215

https://bugzilla.kernel.org/show_bug.cgi?id=197327

Shixin Zeng (zeng.shi...@gmail.com) changed:

   What|Removed |Added

 CC||zeng.shi...@gmail.com

--- Comment #11 from Shixin Zeng (zeng.shi...@gmail.com) ---
Created attachment 295309
  --> https://bugzilla.kernel.org/attachment.cgi?id=295309&action=edit
Skip VCE on R7-240

I am having the same issue with my card R7 240, and decided to do some research
on this and found out that this card didn't seem to have VCE at all
(https://en.wikipedia.org/wiki/Video_Coding_Engine), so it seems to be only a
cosmetic issue. Skipping it eliminated the error message for me, and is not
causing any other issues for me.

Other card ids can be added in the same way once this is tested and determined
to be the right way to fix it.

-- 
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 v3 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

2021-02-15 Thread Deepak Rawat

DRM driver for hyperv synthetic video device, based on hyperv_fb
framebuffer driver. Also added config option "DRM_HYPERV" to enabled
this driver.

v2:
- Add support for gen2 VM
- Fixed review comments

v3:
- Split into multiple files as suggested by Thomas Zimmermann
- Fixed hibernation issue as suggested by Dexuan Cui
- Use ioremap_cache as suggested by Dexuan Cui
- Incorporated other review comments

Signed-off-by: Deepak Rawat 
---
 drivers/gpu/drm/Kconfig |  12 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/hyperv/Makefile |   8 +
 drivers/gpu/drm/hyperv/hyperv_drm.h |  51 ++
 drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 313 +
 drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 240 ++
 drivers/gpu/drm/hyperv/hyperv_drm_proto.c   | 486 
 7 files changed,  insertions(+)
 create mode 100644 drivers/gpu/drm/hyperv/Makefile
 create mode 100644 drivers/gpu/drm/hyperv/hyperv_drm.h
 create mode 100644 drivers/gpu/drm/hyperv/hyperv_drm_drv.c
 create mode 100644 drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
 create mode 100644 drivers/gpu/drm/hyperv/hyperv_drm_proto.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8bf103de1594..c17f4e9dcd82 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -382,6 +382,18 @@ source "drivers/gpu/drm/tidss/Kconfig"
 
 source "drivers/gpu/drm/xlnx/Kconfig"
 
+config DRM_HYPERV
+   tristate "DRM Support for hyperv synthetic video device"
+   depends on DRM && PCI && MMU && HYPERV
+   select DRM_KMS_HELPER
+   select DRM_GEM_SHMEM_HELPER
+   help
+This is a KMS driver for hyperv synthetic video device. Choose this
+option if you would like to enable drm driver for Hyper-V virtual
+machine.
+
+If M is selected the module will be called hyperv_drm.
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 926adef289db..294e321cd23f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -125,3 +125,4 @@ obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
 obj-$(CONFIG_DRM_MCDE) += mcde/
 obj-$(CONFIG_DRM_TIDSS) += tidss/
 obj-y  += xlnx/
+obj-$(CONFIG_DRM_HYPERV) += hyperv/
diff --git a/drivers/gpu/drm/hyperv/Makefile b/drivers/gpu/drm/hyperv/Makefile
new file mode 100644
index ..0039b03db0be
--- /dev/null
+++ b/drivers/gpu/drm/hyperv/Makefile
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+hyperv_drm-y := \
+   hyperv_drm_proto.o \
+   hyperv_drm_modeset.o \
+   hyperv_drm_drv.o
+
+obj-$(CONFIG_DRM_HYPERV) += hyperv_drm.o
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm.h 
b/drivers/gpu/drm/hyperv/hyperv_drm.h
new file mode 100644
index ..4f8c627b303a
--- /dev/null
+++ b/drivers/gpu/drm/hyperv/hyperv_drm.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2012-2021 Microsoft
+ */
+
+#ifndef _HYPERV_DRM_H_
+#define _HYPERV_DRM_H_
+
+#define VMBUS_MAX_PACKET_SIZE 0x4000
+
+struct hyperv_drm_device {
+   /* drm */
+   struct drm_device dev;
+   struct drm_simple_display_pipe pipe;
+   struct drm_connector connector;
+
+   /* mode */
+   u32 screen_width_max;
+   u32 screen_height_max;
+   u32 preferred_width;
+   u32 preferred_height;
+   u32 screen_depth;
+
+   /* hw */
+   struct resource *mem;
+   void __iomem *vram;
+   unsigned long fb_base;
+   unsigned long fb_size;
+   struct completion wait;
+   u32 synthvid_version;
+   u32 mmio_megabytes;
+
+   u8 init_buf[VMBUS_MAX_PACKET_SIZE];
+   u8 recv_buf[VMBUS_MAX_PACKET_SIZE];
+
+   struct hv_device *hdev;
+};
+
+#define to_hv(_dev) container_of(_dev, struct hyperv_drm_device, dev)
+
+/* hyperv_drm_modeset */
+int hyperv_mode_config_init(struct hyperv_drm_device *hv);
+
+/* hyperv_drm_proto */
+int hyperv_update_vram_location(struct hv_device *hdev, phys_addr_t vram_pp);
+int hyperv_update_situation(struct hv_device *hdev, u8 active, u32 bpp,
+   u32 w, u32 h, u32 pitch);
+int hyperv_update_dirt(struct hv_device *hdev, struct drm_rect *rect);
+int hyperv_connect_vsp(struct hv_device *hdev);
+
+#endif
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c 
b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
new file mode 100644
index ..b72c1a169125
--- /dev/null
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2012-2021 Microsoft
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hyperv_drm.h"
+
+#define DRIVER_NAME "hyperv_drm"
+#define DRIVER_DESC "DRM driver for hyperv synthetic video device"
+#define DRIVER_DATE "2020"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+#define PCI_VENDOR_ID_MICROSOFT 0x1414
+#define PCI_DEVICE_ID_HYPERV_V

[PATCH v3 2/2] MAINTAINERS: Add maintainer for hyperv video device

2021-02-15 Thread Deepak Rawat

Maintainer for hyperv synthetic video device.

Signed-off-by: Deepak Rawat 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d6dd31cb5ad1..b4aaf1810c7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6057,6 +6057,14 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/xlnx/
 F: drivers/gpu/drm/xlnx/
 
+DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
+M: Deepak Rawat 
+L: linux-hyp...@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/tiny/hyperv_drm.c
+
 DRM DRIVERS FOR ZTE ZX
 M: Shawn Guo 
 L: dri-devel@lists.freedesktop.org
-- 
2.30.0

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

Re: DMA-buf and uncached system memory

2021-02-15 Thread Nicolas Dufresne

Le lundi 15 février 2021 à 09:58 +0100, Christian König a écrit :
> Hi guys,
> 
> we are currently working an Freesync and direct scan out from system 
> memory on AMD APUs in A+A laptops.
> 
> On problem we stumbled over is that our display hardware needs to scan 
> out from uncached system memory and we currently don't have a way to 
> communicate that through DMA-buf.
> 
> For our specific use case at hand we are going to implement something 
> driver specific, but the question is should we have something more 
> generic for this?

Hopefully I'm getting this right, but this makes me think of a long standing
issue I've met with Intel DRM and UVC driver. If I let the UVC driver allocate
the buffer, and import the resulting DMABuf (cacheable memory written with a cpu
copy in the kernel) into DRM, we can see cache artifact being displayed. While
if I use the DRM driver memory (dumb buffer in that case) it's clean because
there is a driver specific solution to that.

There is no obvious way for userspace application to know what's is right/wrong
way and in fact it feels like the kernel could solve this somehow without having
to inform userspace (perhaps).

> 
> After all the system memory access pattern is a PCIe extension and as 
> such something generic.
> 
> Regards,
> Christian.


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

Re: DMA-buf and uncached system memory

2021-02-15 Thread Nicolas Dufresne

Le lundi 15 février 2021 à 13:10 +0100, Christian König a écrit :
> 
> 
> Am 15.02.21 um 13:00 schrieb Thomas Zimmermann:
> > Hi
> > 
> > Am 15.02.21 um 10:49 schrieb Thomas Zimmermann:
> > > Hi
> > > 
> > > Am 15.02.21 um 09:58 schrieb Christian König:
> > > > Hi guys,
> > > > 
> > > > we are currently working an Freesync and direct scan out from system 
> > > > memory on AMD APUs in A+A laptops.
> > > > 
> > > > On problem we stumbled over is that our display hardware needs to 
> > > > scan out from uncached system memory and we currently don't have a 
> > > > way to communicate that through DMA-buf.
> > 
> > Re-reading this paragrah, it sounds more as if you want to let the 
> > exporter know where to move the buffer. Is this another case of the 
> > missing-pin-flag problem?
> 
> No, your original interpretation was correct. Maybe my writing is a bit 
> unspecific.
> 
> The real underlying issue is that our display hardware has a problem 
> with latency when accessing system memory.
> 
> So the question is if that also applies to for example Intel hardware or 
> other devices as well or if it is just something AMD specific?

I do believe that the answer is yes, Intel display have similar issue with
latency, hence requires un-cached memory.

> 
> Regards,
> Christian.
> 
> > 
> > Best regards
> > Thomas
> > 
> > > > 
> > > > For our specific use case at hand we are going to implement 
> > > > something driver specific, but the question is should we have 
> > > > something more generic for this?
> > > 
> > > For vmap operations, we return the address as struct dma_buf_map, 
> > > which contains additional information about the memory buffer. In 
> > > vram helpers, we have the interface drm_gem_vram_offset() that 
> > > returns the offset of the GPU device memory.
> > > 
> > > Would it be feasible to combine both concepts into a dma-buf 
> > > interface that returns the device-memory offset plus the additional 
> > > caching flag?
> > > 
> > > There'd be a structure and a getter function returning the structure.
> > > 
> > > struct dma_buf_offset {
> > >  bool cached;
> > >  u64 address;
> > > };
> > > 
> > > // return offset in *off
> > > int dma_buf_offset(struct dma_buf *buf, struct dma_buf_off *off);
> > > 
> > > Whatever settings are returned by dma_buf_offset() are valid while 
> > > the dma_buf is pinned.
> > > 
> > > Best regards
> > > Thomas
> > > 
> > > > 
> > > > After all the system memory access pattern is a PCIe extension and 
> > > > as such something generic.
> > > > 
> > > > Regards,
> > > > Christian.
> > > > ___
> > > > 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

RE: [PATCH V4] drm/stm: Fix bus_flags handling

2021-02-15 Thread Philippe CORNU

Dear Marek,
Applied on drm-misc-next.
Many thanks for your patch,
Philippe :-)


ST Restricted

-Original Message-
From: Marek Vasut  
Sent: Wednesday, January 27, 2021 12:08
To: dri-devel@lists.freedesktop.org
Cc: Marek Vasut ; Yannick FERTRE ; 
Alexandre TORGUE ; Antonio BORNEO 
; Benjamin Gaignard ; Maxime 
Coquelin ; Philippe CORNU ; 
Sam Ravnborg ; Vincent ABRIOU ; 
linux-arm-ker...@lists.infradead.org; linux-st...@st-md-mailman.stormreply.com
Subject: [PATCH V4] drm/stm: Fix bus_flags handling

The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW or 
DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no matter 
what polarity the next bridge or display might require, these flags are never 
set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set, and the LTDC 
behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and DISPLAY_FLAGS_DE_HIGH were 
always set.

The fix for this problem is taken almost verbatim from MXSFB driver. In case 
there is a bridge attached to the LTDC, the bridge might have extra polarity 
requirements, so extract bus_flags from the bridge and use them for LTDC 
configuration. Otherwise, extract bus_flags from the connector, which is the 
display.

Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
Signed-off-by: Marek Vasut 
Signed-off-by: Yannick Fertre 
Cc: Alexandre Torgue 
Cc: Antonio Borneo 
Cc: Benjamin Gaignard 
Cc: Maxime Coquelin 
Cc: Philippe Cornu 
Cc: Sam Ravnborg 
Cc: Vincent Abriou 
Cc: Yannick Fertre 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
---
V2: Check if ldev->bridge->timings is non-NULL before accessing it
V3: get bus_flags from connector (from Yannick)
- Display controller could support several connectors (not connected at
  the same time). ie: stm32mp15c-DK2 board have 2 connectors (HDMI + DSI).
  Driver check which connector is connected to get the bus flag.
V4: get bridge from encoder (from Yannick)
---
 drivers/gpu/drm/stm/ltdc.c | 33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index 
6e28e6b60e72..acc9f6694eb6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -544,13 +544,42 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc 
*crtc)  {
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
struct drm_device *ddev = crtc->dev;
+   struct drm_connector_list_iter iter;
+   struct drm_connector *connector = NULL;
+   struct drm_encoder *encoder = NULL;
+   struct drm_bridge *bridge = NULL;
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
struct videomode vm;
u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
u32 total_width, total_height;
+   u32 bus_flags = 0;
u32 val;
int ret;
 
+   /* get encoder from crtc */
+   drm_for_each_encoder(encoder, ddev)
+   if (encoder->crtc == crtc)
+   break;
+
+   if (encoder) {
+   /* get bridge from encoder */
+   list_for_each_entry(bridge, &encoder->bridge_chain, chain_node)
+   if (bridge->encoder == encoder)
+   break;
+
+   /* Get the connector from encoder */
+   drm_connector_list_iter_begin(ddev, &iter);
+   drm_for_each_connector_iter(connector, &iter)
+   if (connector->encoder == encoder)
+   break;
+   drm_connector_list_iter_end(&iter);
+   }
+
+   if (bridge && bridge->timings)
+   bus_flags = bridge->timings->input_bus_flags;
+   else if (connector)
+   bus_flags = connector->display_info.bus_flags;
+
if (!pm_runtime_active(ddev->dev)) {
ret = pm_runtime_get_sync(ddev->dev);
if (ret) {
@@ -586,10 +615,10 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
 
-   if (vm.flags & DISPLAY_FLAGS_DE_LOW)
+   if (bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= GCR_DEPOL;
 
-   if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
val |= GCR_PCPOL;
 
reg_update_bits(ldev->regs, LTDC_GCR,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Allow spatial dither to 10 bpc on all != DCE-11.0.

2021-02-15 Thread Mario Kleiner

On Mon, Feb 15, 2021 at 8:09 PM Alex Deucher  wrote:

> On Fri, Feb 12, 2021 at 5:30 PM Mario Kleiner
>  wrote:
> >
> > Spatial dithering to 10 bpc depth was disabled for all DCE's.
> > Restrict this to DCE-11.0, but allow it on other DCE's.
> >
> > Testing on DCE-8.3 and DCE-11.2 did not show any obvious ill
> > effects, but a measureable precision improvement (via colorimeter)
> > when displaying a fp16 framebuffer to a 10 bpc DP or HDMI connected
> > HDR-10 monitor.
> >
> > Alex suggests this may have been a workaround for some DCE-11.0
> > Carrizo and Stoney Asics, so lets try to restrict this to DCE 11.0.
> >
> > Signed-off-by: Mario Kleiner 
> > Cc: Alex Deucher 
> > ---
> >  drivers/gpu/drm/amd/display/dc/dce/dce_opp.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
> > index 4600231da6cb..4ed886cdb8d8 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
> > @@ -216,9 +216,12 @@ static void set_spatial_dither(
> > REG_UPDATE(FMT_BIT_DEPTH_CONTROL,
> > FMT_TEMPORAL_DITHER_EN, 0);
> >
> > -   /* no 10bpc on DCE11*/
> > -   if (params->flags.SPATIAL_DITHER_ENABLED == 0 ||
> > -   params->flags.SPATIAL_DITHER_DEPTH == 2)
> > +   if (params->flags.SPATIAL_DITHER_ENABLED == 0)
> > +   return;
> > +
> > +   /* No dithering to 10 bpc on DCE-11.0 */
> > +   if (params->flags.SPATIAL_DITHER_DEPTH == 2 &&
> > +   opp110->base.ctx->dce_version == DCE_VERSION_11_0)
> > return;
>
> I'm inclined to just remove this check altogether.  This is just the
> dithering control.  I think the limitations are more around the
> formats (e.g., FP formats) than the dithering.
>
> Alex
>
>
Certainly no objections from myself.
-mario



>
> >
> > /* only use FRAME_COUNTER_MAX if frameRandom == 1*/
> > --
> > 2.25.1
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 3/3] drm: Switch to %p4cc format modifier

2021-02-15 Thread Petr Mladek

On Mon 2021-02-15 13:40:30, Sakari Ailus wrote:
> Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
> large number of temporary variables at the same time.
> 
> Signed-off-by: Sakari Ailus 

Reviewed-by: Petr Mladek 

I wonder if I could this via printk tree. Or if should rather go
via DRM tree.

Anyway, there will be v8 with small changes in the 1st patch.

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

Re: [PATCH v7 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

2021-02-15 Thread Petr Mladek

On Mon 2021-02-15 13:40:29, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.
> 
> Signed-off-by: Sakari Ailus 

Reviewed-by: Petr Mladek 

I am curious whether I could take this via printk tree or if Mauro
would prefer to take this via his tree.

Anyway, there will be v8 with small changes in the 1st patch.

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

Re: [PATCH v7 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

2021-02-15 Thread Petr Mladek

On Mon 2021-02-15 17:54:47, Andy Shevchenko wrote:
> On Mon, Feb 15, 2021 at 03:56:50PM +0200, Sakari Ailus wrote:
> > On Mon, Feb 15, 2021 at 03:31:29PM +0200, Andy Shevchenko wrote:
> > > On Mon, Feb 15, 2021 at 01:40:28PM +0200, Sakari Ailus wrote:
> > > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > > > pixel formats denoted by fourccs. The fourcc encoding is the same for 
> > > > both
> > > > so the same implementation can be used.
> > > 
> > > This version I almost like, feel free to add
> > > Reviewed-by: From: Andy Shevchenko 
> > > after considering addressing below nit-picks.
> 
> > > > +Examples::
> > > > +
> > > > +   %p4cc   BG12 little-endian (0x32314742)
> > > 
> > > No examples with spaces / non-printable / non-ascii characters
> > 
> > I can sure add an example that has a space. But do you think I really
> > should add an example where invalid information is being printed?
> 
> I think you have to provide better coverage of what user can get out of this.
> Perhaps one example with space and non-printable character is enough.
> 
> > > > +   char output[sizeof("1234 little-endian (0x01234567)")];
> > > 
> > > 1234 -> ABCD ? (Or XY12 to be closer to the reality)
> > 
> > I count in numbers... albeit the hexadecimal number there starts from zero.
> > 
> > I guess both would work though.
> > 
> > 0123 would be consistent.
> 
> Since letters can be printed the above is confusing a bit. I think XY12 is
> closer to the reality than 0123.

Ailus, are you going to send v8 with the two small changes? I mean a
selftest with the space and the above sample code.

Anyway, feel free to add:

Reviewed-by: Petr Mladek 

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

Re: [RFC v3 10/10] drm/dp: Extract i915's eDP backlight code into DRM helpers

2021-02-15 Thread Lyude Paul

On Mon, 2021-02-15 at 19:34 +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 09.02.21 um 00:03 schrieb Lyude Paul:
> > > 
> > > > +   } else {
> > > > +   buf[0] = level;
> > > > +   }
> > > > +
> > > > +   ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
> > > > buf,
> > > > sizeof(buf));
> > > > +   if (ret != sizeof(buf)) {
> > > > +   DRM_ERROR("%s: Failed to write aux backlight level:
> > > > %d\n",
> > > > aux->name, ret);
> > > 
> > > Since you're adding this code, you should probably convert to drm_err()
> > > helpers as well. Here and elsewhere.
> > 
> > this is next up on my todo list JFYI-I don't do it right now because there
> > isn't
> > actually any backpointer to the drm driver (and you can't just use the
> > parent of
> > the aux device, since that technically doesn't need to be the drm driver).
> > 
> > I'd add it in this series, but that's going to involve updating functions
> > across
> > the tree like drm_dp_aux_init() so I'd like to do it in a different patch
> > series
> 
> Ok, sure. Makes sense.

I'm actually probably just going to do it anyway, since it seems like a want of
folks really want to keep the drm_dbg_*() prints around
> 
> Best regards
> Thomas
> 
> > 
> > > 
> > > > +   return ret < 0 ? ret : -EIO;
> > > > +   }
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> > > > +
> > > > +static int
> > > > +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
> > > > drm_edp_backlight_info *bl,
> > > > +    bool enable)
> > > > +{
> > > > +   int ret;
> > > > +   u8 buf;
> > > > +
> > > > +   /* The panel uses something other then DPCD for enabling it's
> > > > backlight */
> > > 
> > > 'its'
> > > 
> > > Best regards
> > > Thomas
> > > 
> > > > +   if (!bl->aux_enable)
> > > > +   return 0;
> > > > +
> > > > +   ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
> > > > &buf);
> > > > +   if (ret != 1) {
> > > > +   DRM_ERROR("%s: Failed to read eDP display control
> > > > register:
> > > > %d\n", aux->name, ret);
> > > > +   return ret < 0 ? ret : -EIO;
> > > > +   }
> > > > +   if (enable)
> > > > +   buf |= DP_EDP_BACKLIGHT_ENABLE;
> > > > +   else
> > > > +   buf &= ~DP_EDP_BACKLIGHT_ENABLE;
> > > > +
> > > > +   ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
> > > > buf);
> > > > +   if (ret != 1) {
> > > > +   DRM_ERROR("%s: Failed to write eDP display control
> > > > register:
> > > > %d\n", aux->name, ret);
> > > > +   return ret < 0 ? ret : -EIO;
> > > > +   }
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > > +/**
> > > > + * drm_edp_backlight_enable() - Enable an eDP panel's backlight using
> > > > DPCD
> > > > + * @aux: The DP AUX channel to use
> > > > + * @bl: Backlight capability info from drm_edp_backlight_init()
> > > > + * @level: The initial backlight level to set via AUX, if there is one
> > > > + *
> > > > + * This function handles enabling DPCD backlight controls on a panel
> > > > over
> > > > DPCD, while additionally
> > > > + * restoring any important backlight state such as the given backlight
> > > > level, the brightness byte
> > > > + * count, backlight frequency, etc.
> > > > + *
> > > > + * Note that certain panels, while supporting brightness level controls
> > > > over DPCD, may not support
> > > > + * having their backlights enabled via the standard
> > > > %DP_EDP_DISPLAY_CONTROL_REGISTER. On such panels
> > > > + * &drm_edp_backlight_info.aux_enable will be set to %false, this
> > > > function
> > > > will skip the step of
> > > > + * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver
> > > > must
> > > > perform the required
> > > > + * implementation specific step for enabling the backlight after
> > > > calling
> > > > this function.
> > > > + *
> > > > + * Returns: %0 on success, negative error code on failure.
> > > > + */
> > > > +int drm_edp_backlight_enable(struct drm_dp_aux *aux, const struct
> > > > drm_edp_backlight_info *bl,
> > > > +    const u16 level)
> > > > +{
> > > > +   int ret;
> > > > +   u8 dpcd_buf, new_dpcd_buf;
> > > > +
> > > > +   ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > > > &dpcd_buf);
> > > > +   if (ret != 1) {
> > > > +   DRM_DEBUG_KMS("%s: Failed to read backlight mode: %d\n",
> > > > aux->name, ret);
> > > > +   return ret < 0 ? ret : -EIO;
> > > > +   }
> > > > +
> > > > +   new_dpcd_buf = dpcd_buf;
> > > > +
> > > > +   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> > > > DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
> > > > +   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> > > > +   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> >

[Bug 211745] Latest 5.11 git doesn't boot.

https://bugzilla.kernel.org/show_bug.cgi?id=211745

Robert M. Muncrief (rmuncr...@humanavance.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
(In reply to Alex Deucher from comment #9)
> Only reporters can close kernel bugs.  Please close if this is not an issue.

I've closed it as invalid since I'm not sure what the issue was and there was
no specific code fix I'm aware of.

-- 
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 211745] Latest 5.11 git doesn't boot.

https://bugzilla.kernel.org/show_bug.cgi?id=211745

--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
Only reporters can close kernel bugs.  Please close if this is not an issue.

-- 
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 211745] Latest 5.11 git doesn't boot.

https://bugzilla.kernel.org/show_bug.cgi?id=211745

--- Comment #8 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
(In reply to Alex Deucher from comment #7)
> Can you bisect?  

I can bisect, but I updated and compiled linux-mainline with the final 5.11
from the Arch AUR this morning and my system boots just fine. I did a couple of
quick tests playing videos, running VMs, etc. and everything looks good. So you
can close this bug.  

I've done some system updates since yesterday so later today I'm going to
compile the same linux-git again, and if it fails compile the current
linux-git. If that fails then I'm going to compare  the linux-git and
linux-mainline PKGBUILD files to see if the the error was caused by the
linux-git build. I've used linux-git many times over the years and never had a
problem with it but who knows. It's definitely worth checking out though.  

Thank you for your help and attention, and thanks to all the kernel devs for
their awesome work. It is greatly appreciated.

-- 
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: [PATCH] drm/radeon: Remove unused function pointer typedef radeon_packet3_check_t

Applied.  Thanks!

Alex

On Mon, Feb 15, 2021 at 5:43 AM Christian König
 wrote:
>
>
>
> Am 15.02.21 um 11:21 schrieb Chen Lin:
> > From: Chen Lin 
> >
> > Remove the 'radeon_packet3_check_t' typedef as it is not used.
> >
> > Signed-off-by: Chen Lin 
>
> Reviewed-by: Christian König 
>
> > ---
> >   drivers/gpu/drm/radeon/radeon.h |3 ---
> >   1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon.h 
> > b/drivers/gpu/drm/radeon/radeon.h
> > index 5f3adba..a1c38b5 100644
> > --- a/drivers/gpu/drm/radeon/radeon.h
> > +++ b/drivers/gpu/drm/radeon/radeon.h
> > @@ -,9 +,6 @@ struct radeon_cs_packet {
> >   typedef int (*radeon_packet0_check_t)(struct radeon_cs_parser *p,
> > struct radeon_cs_packet *pkt,
> > unsigned idx, unsigned reg);
> > -typedef int (*radeon_packet3_check_t)(struct radeon_cs_parser *p,
> > -   struct radeon_cs_packet *pkt);
> > -
> >
> >   /*
> >* AGP
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Allow spatial dither to 10 bpc on all != DCE-11.0.

On Fri, Feb 12, 2021 at 5:30 PM Mario Kleiner
 wrote:
>
> Spatial dithering to 10 bpc depth was disabled for all DCE's.
> Restrict this to DCE-11.0, but allow it on other DCE's.
>
> Testing on DCE-8.3 and DCE-11.2 did not show any obvious ill
> effects, but a measureable precision improvement (via colorimeter)
> when displaying a fp16 framebuffer to a 10 bpc DP or HDMI connected
> HDR-10 monitor.
>
> Alex suggests this may have been a workaround for some DCE-11.0
> Carrizo and Stoney Asics, so lets try to restrict this to DCE 11.0.
>
> Signed-off-by: Mario Kleiner 
> Cc: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_opp.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
> index 4600231da6cb..4ed886cdb8d8 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
> @@ -216,9 +216,12 @@ static void set_spatial_dither(
> REG_UPDATE(FMT_BIT_DEPTH_CONTROL,
> FMT_TEMPORAL_DITHER_EN, 0);
>
> -   /* no 10bpc on DCE11*/
> -   if (params->flags.SPATIAL_DITHER_ENABLED == 0 ||
> -   params->flags.SPATIAL_DITHER_DEPTH == 2)
> +   if (params->flags.SPATIAL_DITHER_ENABLED == 0)
> +   return;
> +
> +   /* No dithering to 10 bpc on DCE-11.0 */
> +   if (params->flags.SPATIAL_DITHER_DEPTH == 2 &&
> +   opp110->base.ctx->dce_version == DCE_VERSION_11_0)
> return;

I'm inclined to just remove this check altogether.  This is just the
dithering control.  I think the limitations are more around the
formats (e.g., FP formats) than the dithering.

Alex


>
> /* only use FRAME_COUNTER_MAX if frameRandom == 1*/
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE

On Wed, Feb 10, 2021 at 6:49 PM Gustavo A. R. Silva
 wrote:
>
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of one-element or zero-length arrays should no longer be used[2].
>
> Use flexible-array member in struct NISLANDS_SMC_SWSTATE, instead of
> one-element array.
>
> Also, this helps with the ongoing efforts to enable -Warray-bounds by
> fixing the following warnings:
>
> drivers/gpu/drm/radeon/ni_dpm.c: In function ‘ni_convert_power_state_to_smc’:
> drivers/gpu/drm/radeon/ni_dpm.c:2521:20: warning: array subscript 1 is above 
> array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2521 |   smc_state->levels[i].dpm2.MaxPS =
>   |   ~^~~
> drivers/gpu/drm/radeon/ni_dpm.c:2523:20: warning: array subscript 1 is above 
> array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2523 |   smc_state->levels[i].dpm2.NearTDPDec = NISLANDS_DPM2_NEAR_TDP_DEC;
>   |   ~^~~
> drivers/gpu/drm/radeon/ni_dpm.c:2524:20: warning: array subscript 1 is above 
> array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2524 |   smc_state->levels[i].dpm2.AboveSafeInc = 
> NISLANDS_DPM2_ABOVE_SAFE_INC;
>   |   ~^~~
> drivers/gpu/drm/radeon/ni_dpm.c:2525:20: warning: array subscript 1 is above 
> array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2525 |   smc_state->levels[i].dpm2.BelowSafeInc = 
> NISLANDS_DPM2_BELOW_SAFE_INC;
>   |   ~^~~
> drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above 
> array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2526 |   smc_state->levels[i].stateFlags |=
>   |   ^~
> drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above 
> array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2526 |   smc_state->levels[i].stateFlags |=
>   |   ^~
>  2527 |((i != (state->performance_level_count - 1)) && power_boost_limit) 
> ?
>   |
> 
>  2528 |PPSMC_STATEFLAG_POWERBOOST : 0;
>   |~~
> drivers/gpu/drm/radeon/ni_dpm.c:2442:20: warning: array subscript 1 is above 
> array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2442 |   smc_state->levels[i + 1].aT = cpu_to_be32(a_t);
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] 
> https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays
>
> Link: https://github.com/KSPP/linux/issues/79
> Link: https://github.com/KSPP/linux/issues/109
> Build-tested-by: kernel test robot 
> Link: https://lore.kernel.org/lkml/6023ed54.bfiy+9uz81i6nq19%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/nislands_smc.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/nislands_smc.h 
> b/drivers/gpu/drm/radeon/nislands_smc.h
> index 3cf8fc0d83f4..7395cb6b3cac 100644
> --- a/drivers/gpu/drm/radeon/nislands_smc.h
> +++ b/drivers/gpu/drm/radeon/nislands_smc.h
> @@ -134,11 +134,11 @@ typedef struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL 
> NISLANDS_SMC_HW_PERFORMANCE_LEV
>
>  struct NISLANDS_SMC_SWSTATE
>  {
> -uint8_t flags;
> -uint8_t levelCount;
> -uint8_t padding2;
> -uint8_t padding3;
> -NISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[1];
> +   uint8_t flags;
> +   uint8_t levelCount;
> +   uint8_t padding2;
> +   uint8_t padding3;
> +   NISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[];
>  };
>
>  typedef struct NISLANDS_SMC_SWSTATE NISLANDS_SMC_SWSTATE;
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/amd/pm: Replace one-element array with flexible-array in struct _ATOM_Vega10_GFXCLK_Dependency_Table

On Wed, Feb 10, 2021 at 6:36 PM Gustavo A. R. Silva
 wrote:
>
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of one-element or zero-length arrays should no longer be used[2].
>
> Use flexible-array member in struct _ATOM_Vega10_GFXCLK_Dependency_Table,
> instead of one-element array.
>
> Also, this helps with the ongoing efforts to enable -Warray-bounds and
> fix the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c: In function 
> ‘vega10_get_pp_table_entry_callback_func’:
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:3113:30: 
> warning: array subscript 4 is above array bounds of 
> ‘ATOM_Vega10_GFXCLK_Dependency_Record[1]’ {aka ‘struct 
> _ATOM_Vega10_GFXCLK_Dependency_Record[1]’} [-Warray-bounds]
>  3113 | gfxclk_dep_table->entries[4].ulClk;
>   | ~^~~
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] 
> https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays
>
> Link: https://github.com/KSPP/linux/issues/79
> Link: https://github.com/KSPP/linux/issues/109
> Build-tested-by: kernel test robot 
> Link: https://lore.kernel.org/lkml/6023ff3d.wy3ssckgrqpdplvo%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h 
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
> index c934e9612c1b..9c479bd9a786 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
> @@ -161,9 +161,9 @@ typedef struct _ATOM_Vega10_MCLK_Dependency_Record {
>  } ATOM_Vega10_MCLK_Dependency_Record;
>
>  typedef struct _ATOM_Vega10_GFXCLK_Dependency_Table {
> -UCHAR ucRevId;
> -UCHAR ucNumEntries; /* Number of 
> entries. */
> -ATOM_Vega10_GFXCLK_Dependency_Record entries[1];/* 
> Dynamically allocate entries. */
> +   UCHAR ucRevId;
> +   UCHAR ucNumEntries; /* Number of 
> entries. */
> +   ATOM_Vega10_GFXCLK_Dependency_Record entries[]; /* 
> Dynamically allocate entries. */
>  } ATOM_Vega10_GFXCLK_Dependency_Table;
>
>  typedef struct _ATOM_Vega10_MCLK_Dependency_Table {
> --
> 2.27.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/amd/pm: Replace one-element array with flexible-array in struct SISLANDS_SMC_SWSTATE

On Wed, Feb 10, 2021 at 5:40 PM Gustavo A. R. Silva
 wrote:
>
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of one-element or zero-length arrays should no longer be used[2].
>
> Refactor the code according to the use of a flexible-array member in
> struct SISLANDS_SMC_SWSTATE, instead of a one-element array, and use
> the struct_size() helper to calculate the size for the allocation.
>
> Also, this helps with the ongoing efforts to enable -Warray-bounds and
> fix the following warnings:
>
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2448:20: warning: array
> subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’
> {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2449:20: warning: array
> subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’
> {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2450:20: warning: array
> subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’
> {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2451:20: warning: array
> subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’
> {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2452:20: warning: array
> subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’
> {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:5570:20: warning: array
> subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’
> {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] 
> https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays
>
> Link: https://github.com/KSPP/linux/issues/79
> Link: https://github.com/KSPP/linux/issues/109
> Build-tested-by: kernel test robot 
> Link: 
> https://lore.kernel.org/lkml/6023be58.sk66l%2fv4vusji5mi%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/pm/powerplay/si_dpm.c   |  6 ++
>  drivers/gpu/drm/amd/pm/powerplay/sislands_smc.h | 10 +-
>  2 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c 
> b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> index afa1711c9620..62291358fb1c 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> @@ -5715,11 +5715,9 @@ static int si_upload_sw_state(struct amdgpu_device 
> *adev,
> int ret;
> u32 address = si_pi->state_table_start +
> offsetof(SISLANDS_SMC_STATETABLE, driverState);
> -   u32 state_size = sizeof(SISLANDS_SMC_SWSTATE) +
> -   ((new_state->performance_level_count - 1) *
> -sizeof(SISLANDS_SMC_HW_PERFORMANCE_LEVEL));
> SISLANDS_SMC_SWSTATE *smc_state = &si_pi->smc_statetable.driverState;
> -
> +   size_t state_size = struct_size(smc_state, levels,
> +   new_state->performance_level_count);
> memset(smc_state, 0, state_size);
>
> ret = si_convert_power_state_to_smc(adev, amdgpu_new_state, 
> smc_state);
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/sislands_smc.h 
> b/drivers/gpu/drm/amd/pm/powerplay/sislands_smc.h
> index d2930eceaf3c..0f7554052c90 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/sislands_smc.h
> +++ b/drivers/gpu/drm/amd/pm/powerplay/sislands_smc.h
> @@ -182,11 +182,11 @@ typedef struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL 
> SISLANDS_SMC_HW_PERFORMANCE_LEV
>
>  struct SISLANDS_SMC_SWSTATE
>  {
> -uint8_t flags;
> -uint8_t levelCount;
> -uint8_t padding2;
> -uint8_t padding3;
> -SISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[1];
> +   uint8_t flags;
> +   uint8_t levelCount;
> +   uint8_t padding2;
> +   uint8_t padding3;
> +   SISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[];
>  };
>
>  typedef struct SISLANDS_SMC_SWSTATE SISLANDS_SMC_SWSTATE;
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesk

Re: [PATCH][next] drm/amd/display: Fix potential integer overflow

On Wed, Feb 10, 2021 at 4:23 PM Gustavo A. R. Silva
 wrote:
>
> Fix potential integer overflow by casting actual_calculated_clock_100hz
> to u64, in order to give the compiler complete information about the
> proper arithmetic to use.
>
> Notice that such variable is used in a context that expects
> an expression of type u64 (64 bits, unsigned) and the following
> expression is currently being evaluated using 32-bit arithmetic:
>
> actual_calculated_clock_100hz * post_divider
>
> Fixes: 7a03fdf628af ("drm/amd/display: fix 64bit division issue on 32bit OS")
> Addresses-Coverity-ID: 1501691 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> index bc942725b9d8..dec58b3c42e4 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> @@ -240,7 +240,7 @@ static bool calc_fb_divider_checking_tolerance(
> pll_settings->calculated_pix_clk_100hz =
> actual_calculated_clock_100hz;
> pll_settings->vco_freq =
> -   div_u64(actual_calculated_clock_100hz * post_divider, 
> 10);
> +   div_u64((u64)actual_calculated_clock_100hz * 
> post_divider, 10);
> return true;
> }
> return false;
> --
> 2.27.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/amd/pm: fix spelling mistake in various messages "power_dpm_force_perfomance_level"

On Wed, Feb 10, 2021 at 7:03 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> There are spelling mistakes in error and warning messages, the text
> power_dpm_force_perfomance_level is missing a letter r and should be
> power_dpm_force_performance_level.  Fix them.
>
> Signed-off-by: Colin Ian King 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 2 +-
>  drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +-
>  drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c 
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> index ed05a30d1139..d1358a6dd2c8 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> @@ -1487,7 +1487,7 @@ static int smu10_set_fine_grain_clk_vol(struct pp_hwmgr 
> *hwmgr,
> }
>
> if (!smu10_data->fine_grain_enabled) {
> -   pr_err("pp_od_clk_voltage is not accessible if 
> power_dpm_force_perfomance_level is not in manual mode!\n");
> +   pr_err("pp_od_clk_voltage is not accessible if 
> power_dpm_force_performance_level is not in manual mode!\n");
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c 
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index 093b01159408..8abb25a28117 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -1462,7 +1462,7 @@ static int vangogh_od_edit_dpm_table(struct smu_context 
> *smu, enum PP_OD_DPM_TAB
>
> if (!(smu_dpm_ctx->dpm_level == AMD_DPM_FORCED_LEVEL_MANUAL)) {
> dev_warn(smu->adev->dev,
> -   "pp_od_clk_voltage is not accessible if 
> power_dpm_force_perfomance_level is not in manual mode!\n");
> +   "pp_od_clk_voltage is not accessible if 
> power_dpm_force_performance_level is not in manual mode!\n");
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c 
> b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
> index 5faa509f0dba..b59156dfca19 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
> @@ -351,7 +351,7 @@ static int renoir_od_edit_dpm_table(struct smu_context 
> *smu,
>
> if (!(smu_dpm_ctx->dpm_level == AMD_DPM_FORCED_LEVEL_MANUAL)) {
> dev_warn(smu->adev->dev,
> -   "pp_od_clk_voltage is not accessible if 
> power_dpm_force_perfomance_level is not in manual mode!\n");
> +   "pp_od_clk_voltage is not accessible if 
> power_dpm_force_performance_level is not in manual mode!\n");
> return -EINVAL;
> }
>
> --
> 2.30.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm: Move vmap out of commit tail for SHMEM-based drivers


Hi

Am 05.02.21 um 10:05 schrieb Gerd Hoffmann:

   Hi,


I smoke-tested the code by running fbdev, Xorg and weston with the
converted mgag200 driver.


Looks sane to me.
Survived cirrus smoke test too.


Reviewers are hard to find. Since you reviewed the shadow-plane 
conversion for cirrus; may I ask you for a review of a similar patchset 
in the ast driver. It's mostly about moving code around. In the end, ast 
cursors will use generic shadow planes as well.



https://lore.kernel.org/dri-devel/20210209134632.12157-1-tzimmerm...@suse.de/

If you have something where I can help out with a review, let me know.

Best regards
Thomas



Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 

take care,
   Gerd



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

[PATCH AUTOSEL 5.10 1/6] drm/xlnx: fix kmemleak by sending vblank_event in atomic_disable

2021-02-15 Thread Sasha Levin

From: Quanyang Wang 

[ Upstream commit a7e02f7796c163ac8297b30223bf24bade9f8a50 ]

When running xrandr to change resolution of DP, the kmemleak as below
can be observed:

unreferenced object 0x00080a351000 (size 256):
  comm "Xorg", pid 248, jiffies 4294899614 (age 19.960s)
  hex dump (first 32 bytes):
98 a0 bc 01 08 00 ff ff 01 00 00 00 00 00 00 00  
ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x30/0x40
[] kmem_cache_alloc+0x3d4/0x588
[<88ea9bd7>] drm_atomic_helper_setup_commit+0x84/0x5f8
[<2290a264>] drm_atomic_helper_commit+0x58/0x388
[] drm_atomic_commit+0x4c/0x60
[] drm_atomic_connector_commit_dpms+0xe8/0x110
[<20ade187>] drm_mode_obj_set_property_ioctl+0x1b0/0x450
[<918206d6>] drm_connector_property_set_ioctl+0x3c/0x68
[<8d51e7a5>] drm_ioctl_kernel+0xc4/0x118
[<2a819b75>] drm_ioctl+0x214/0x448
[<8ca4e588>] __arm64_sys_ioctl+0xa8/0xf0
[<34e15a35>] el0_svc_common.constprop.0+0x74/0x190
[<1b93d916>] do_el0_svc+0x24/0x90
[] el0_svc+0x14/0x20
[] el0_sync_handler+0xb0/0xb8
[<3e79c15f>] el0_sync+0x174/0x180

This is because there is a scenario that a drm_crtc_commit commit is
allocated but not freed. The drm subsystem require/release references
to a CRTC commit by calling drm_crtc_commit_get/put, and when
drm_crtc_commit_put find that commit.ref.refcount is zero, it will
call __drm_crtc_commit_free to free this CRTC commit. Among these
drm_crtc_commit_get/put pairs, there is a drm_crtc_commit_get in
drm_atomic_helper_setup_commit as below:

...
new_crtc_state->event->base.completion = &commit->flip_done;
new_crtc_state->event->base.completion_release = release_crtc_commit;
drm_crtc_commit_get(commit);
...

This reference to the CRTC commit should be released at the function
release_crtc_commit by calling e->completion_release(e->completion) in
drm_send_event_locked. So we need to call drm_send_event_locked at
two places: handling vblank event in the irq handler and the crtc disable
helper. But in zynqmp_disp_crtc_atomic_disable, it only marks the flip
is done and not call drm_crtc_commit_put. This result that the refcount
of this commit is always non-zero and this commit will never be freed.

Since the function drm_crtc_send_vblank_event has operations both sending
a flip_done signal and releasing reference to the CRTC commit, let's use
it instead.

Signed-off-by: Quanyang Wang 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20210202064121.173362-1-quanyang.w...@windriver.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 98bd48f13fd11..8cd8af35cfaac 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1398,19 +1398,11 @@ static void zynqmp_disp_enable(struct zynqmp_disp *disp)
  */
 static void zynqmp_disp_disable(struct zynqmp_disp *disp)
 {
-   struct drm_crtc *crtc = &disp->crtc;
-
zynqmp_disp_audio_disable(&disp->audio);
 
zynqmp_disp_avbuf_disable_audio(&disp->avbuf);
zynqmp_disp_avbuf_disable_channels(&disp->avbuf);
zynqmp_disp_avbuf_disable(&disp->avbuf);
-
-   /* Mark the flip is done as crtc is disabled anyway */
-   if (crtc->state->event) {
-   complete_all(crtc->state->event->base.completion);
-   crtc->state->event = NULL;
-   }
 }
 
 static inline struct zynqmp_disp *crtc_to_disp(struct drm_crtc *crtc)
@@ -1499,6 +1491,13 @@ zynqmp_disp_crtc_atomic_disable(struct drm_crtc *crtc,
 
drm_crtc_vblank_off(&disp->crtc);
 
+   spin_lock_irq(&crtc->dev->event_lock);
+   if (crtc->state->event) {
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   crtc->state->event = NULL;
+   }
+   spin_unlock_irq(&crtc->dev->event_lock);
+
clk_disable_unprepare(disp->pclk);
pm_runtime_put_sync(disp->dev);
 }
-- 
2.27.0

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

Re: [RFC v3 10/10] drm/dp: Extract i915's eDP backlight code into DRM helpers


Hi

Am 09.02.21 um 00:03 schrieb Lyude Paul:



+   } else {
+   buf[0] = level;
+   }
+
+   ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
sizeof(buf));
+   if (ret != sizeof(buf)) {
+   DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
aux->name, ret);


Since you're adding this code, you should probably convert to drm_err()
helpers as well. Here and elsewhere.


this is next up on my todo list JFYI-I don't do it right now because there isn't
actually any backpointer to the drm driver (and you can't just use the parent of
the aux device, since that technically doesn't need to be the drm driver).

I'd add it in this series, but that's going to involve updating functions across
the tree like drm_dp_aux_init() so I'd like to do it in a different patch series


Ok, sure. Makes sense.

Best regards
Thomas






+   return ret < 0 ? ret : -EIO;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_edp_backlight_set_level);
+
+static int
+drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+    bool enable)
+{
+   int ret;
+   u8 buf;
+
+   /* The panel uses something other then DPCD for enabling it's
backlight */


'its'

Best regards
Thomas


+   if (!bl->aux_enable)
+   return 0;
+
+   ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, &buf);
+   if (ret != 1) {
+   DRM_ERROR("%s: Failed to read eDP display control register:
%d\n", aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+   if (enable)
+   buf |= DP_EDP_BACKLIGHT_ENABLE;
+   else
+   buf &= ~DP_EDP_BACKLIGHT_ENABLE;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
+   if (ret != 1) {
+   DRM_ERROR("%s: Failed to write eDP display control register:
%d\n", aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+
+   return 0;
+}
+
+/**
+ * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The initial backlight level to set via AUX, if there is one
+ *
+ * This function handles enabling DPCD backlight controls on a panel over
DPCD, while additionally
+ * restoring any important backlight state such as the given backlight
level, the brightness byte
+ * count, backlight frequency, etc.
+ *
+ * Note that certain panels, while supporting brightness level controls
over DPCD, may not support
+ * having their backlights enabled via the standard
%DP_EDP_DISPLAY_CONTROL_REGISTER. On such panels
+ * &drm_edp_backlight_info.aux_enable will be set to %false, this function
will skip the step of
+ * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must
perform the required
+ * implementation specific step for enabling the backlight after calling
this function.
+ *
+ * Returns: %0 on success, negative error code on failure.
+ */
+int drm_edp_backlight_enable(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+    const u16 level)
+{
+   int ret;
+   u8 dpcd_buf, new_dpcd_buf;
+
+   ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
&dpcd_buf);
+   if (ret != 1) {
+   DRM_DEBUG_KMS("%s: Failed to read backlight mode: %d\n",
aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+
+   new_dpcd_buf = dpcd_buf;
+
+   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT, bl-

pwmgen_bit_count);

+   if (ret != 1)
+   DRM_DEBUG_KMS("%s: Failed to write aux pwmgen bit
count: %d\n",
+ aux->name, ret);
+   }
+
+   if (bl->pwm_freq_pre_divider) {
+   ret = drm_dp_dpcd_writeb(aux, DP_EDP_BACKLIGHT_FREQ_SET, bl-

pwm_freq_pre_divider);

+   if (ret != 1)
+   DRM_DEBUG_KMS("%s: Failed to write aux backlight
frequency: %d\n",
+ aux->name, ret);
+   else
+   new_dpcd_buf |=
DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+   }
+
+   if (new_dpcd_buf != dpcd_buf) {
+   ret = drm_dp_dpcd_writeb(aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf);
+   if (ret != 1) {
+   DRM_DEBUG_KMS("%s: Failed to write aux backlight
mode: %d\n",
+ aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+   }
+
+   ret = drm_edp_backlight_set_level(aux, bl, level);
+   if (re

Re: KASAN: vmalloc-out-of-bounds Write in imageblit

2021-02-15 Thread syzbot

syzbot has found a reproducer for the following issue on:

HEAD commit:f40ddce8 Linux 5.11
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14216df4d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=51ab7ccac30c
dashboard link: https://syzkaller.appspot.com/bug?extid=858dc7a2f7ef07c2c219
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15f53924d0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=138b494cd0

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+858dc7a2f7ef07c2c...@syzkaller.appspotmail.com

==
BUG: KASAN: vmalloc-out-of-bounds in fast_imageblit 
drivers/video/fbdev/core/sysimgblt.c:229 [inline]
BUG: KASAN: vmalloc-out-of-bounds in sys_imageblit+0x12f4/0x1430 
drivers/video/fbdev/core/sysimgblt.c:275
Write of size 4 at addr c9000bc91000 by task syz-executor566/8649

CPU: 3 PID: 8649 Comm: syz-executor566 Not tainted 5.11.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 print_address_description.constprop.0.cold+0x5/0x2c6 mm/kasan/report.c:230
 __kasan_report mm/kasan/report.c:396 [inline]
 kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
 fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline]
 sys_imageblit+0x12f4/0x1430 drivers/video/fbdev/core/sysimgblt.c:275
 drm_fb_helper_sys_imageblit drivers/gpu/drm/drm_fb_helper.c:794 [inline]
 drm_fbdev_fb_imageblit+0x15c/0x350 drivers/gpu/drm/drm_fb_helper.c:2266
 bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline]
 bit_putcs+0x6e1/0xd20 drivers/video/fbdev/core/bitblit.c:188
 fbcon_putcs+0x35a/0x450 drivers/video/fbdev/core/fbcon.c:1304
 do_update_region+0x399/0x630 drivers/tty/vt/vt.c:676
 redraw_screen+0x658/0x790 drivers/tty/vt/vt.c:1035
 fbcon_modechanged+0x593/0x6d0 drivers/video/fbdev/core/fbcon.c:2656
 fbcon_update_vcs+0x3a/0x50 drivers/video/fbdev/core/fbcon.c:2701
 do_fb_ioctl+0x62e/0x690 drivers/video/fbdev/core/fbmem.c:1110
 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1185
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x43fd49
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7fff0eaf1448 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 00019c10 RCX: 0043fd49
RDX: 2080 RSI: 4601 RDI: 0003
RBP:  R08: 7fff0eaf15e8 R09: 7fff0eaf15e8
R10: 7fff0eaf0ec0 R11: 0246 R12: 7fff0eaf145c
R13: 431bde82d7b634db R14: 004ae018 R15: 00400488


Memory state around the buggy address:
 c9000bc90f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c9000bc90f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>c9000bc91000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ^
 c9000bc91080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
 c9000bc91100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==

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

[PATCH] vgacon: drop unused vga_init_done

2021-02-15 Thread Stephen Kitt

Commit 973c096f6a85 ("vgacon: remove software scrollback support")
removed all uses of vga_init_done, so let's get rid of it entirely.

Signed-off-by: Stephen Kitt 
---
 drivers/video/console/vgacon.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 17876f0179b5..36bded9c9876 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -79,7 +79,6 @@ static struct uni_pagedir *vgacon_uni_pagedir;
 static int vgacon_refcount;
 
 /* Description of the hardware situation */
-static boolvga_init_done;
 static unsigned long   vga_vram_base   __read_mostly;  /* Base of 
video memory */
 static unsigned long   vga_vram_end__read_mostly;  /* End of video 
memory */
 static unsigned intvga_vram_size   __read_mostly;  /* Size of 
video memory */
@@ -360,8 +359,6 @@ static const char *vgacon_startup(void)
vgacon_xres = screen_info.orig_video_cols * VGA_FONTWIDTH;
vgacon_yres = vga_scan_lines;
 
-   vga_init_done = true;
-
return display_desc;
 }
 

base-commit: f40ddce88593482919761f74910f42f4b84c004b
-- 
2.29.2

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

Re: [PATCH v7 3/3] drm: Switch to %p4cc format modifier

On Mon, Feb 15, 2021 at 07:26:55PM +0200, Sakari Ailus wrote:
> On Mon, Feb 15, 2021 at 03:41:14PM +0200, Andy Shevchenko wrote:
> ...
> > > + seq_printf(m, "\t\tuapi: [FB:%d] ", fb ? fb->base.id : 0);
> > > + if (fb)
> > > + seq_printf(m, "%p4cc", &fb->format->format);
> > > + else
> > > + seq_puts(m, "n/a");
> > 
> > > + seq_printf(m, ",0x%llx,%dx%d, visible=%s, src=" DRM_RECT_FP_FMT ", 
> > > dst=" DRM_RECT_FMT ", rotation=%s\n",
> > 
> > Why not to keep two seq_printf() calls?
> > 
> > if (fb) {
> > seq_printf();
> > } else {
> > seq_printf();
> > }
> > 
> > ?
> 
> I could, but it'd repeat a lot of the same format string that is very
> complicated right now. Therefore I thought it's better to split.

It's fine, why not?

> Or do you mean seq_printf() vs. seq_puts()? checkpatch.pl (rightly) warns
> about it.

If it doesn't take run-time parameters, then definitely
if (fb)
seq_printf();
else
seq_puts();

> > >  fb ? fb->modifier : 0,
> > >  fb ? fb->width : 0, fb ? fb->height : 0,
> > >  plane_visibility(plane_state),

-- 
With Best Regards,
Andy Shevchenko


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

Re: [PATCH v7 3/3] drm: Switch to %p4cc format modifier

On Mon, Feb 15, 2021 at 03:41:14PM +0200, Andy Shevchenko wrote:
...
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index ca41e8c00ad7..a5c9fe2e56b3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -771,21 +771,21 @@ static void intel_plane_uapi_info(struct seq_file *m, 
> > struct intel_plane *plane)
> > const struct intel_plane_state *plane_state =
> > to_intel_plane_state(plane->base.state);
> > const struct drm_framebuffer *fb = plane_state->uapi.fb;
> > -   struct drm_format_name_buf format_name;
> > struct drm_rect src, dst;
> > char rot_str[48];
> >  
> > src = drm_plane_state_src(&plane_state->uapi);
> > dst = drm_plane_state_dest(&plane_state->uapi);
> >  
> > -   if (fb)
> > -   drm_get_format_name(fb->format->format, &format_name);
> > -
> > plane_rotation(rot_str, sizeof(rot_str),
> >plane_state->uapi.rotation);
> >  
> > -   seq_printf(m, "\t\tuapi: [FB:%d] %s,0x%llx,%dx%d, visible=%s, src=" 
> > DRM_RECT_FP_FMT ", dst=" DRM_RECT_FMT ", rotation=%s\n",
> > -  fb ? fb->base.id : 0, fb ? format_name.str : "n/a",
> > +   seq_printf(m, "\t\tuapi: [FB:%d] ", fb ? fb->base.id : 0);
> > +   if (fb)
> > +   seq_printf(m, "%p4cc", &fb->format->format);
> > +   else
> > +   seq_puts(m, "n/a");
> 
> > +   seq_printf(m, ",0x%llx,%dx%d, visible=%s, src=" DRM_RECT_FP_FMT ", 
> > dst=" DRM_RECT_FMT ", rotation=%s\n",
> 
> Why not to keep two seq_printf() calls?
> 
> if (fb) {
>   seq_printf();
> } else {
>   seq_printf();
> }
> 
> ?

I could, but it'd repeat a lot of the same format string that is very
complicated right now. Therefore I thought it's better to split.

Or do you mean seq_printf() vs. seq_puts()? checkpatch.pl (rightly) warns
about it.

> 
> >fb ? fb->modifier : 0,
> >fb ? fb->width : 0, fb ? fb->height : 0,
> >plane_visibility(plane_state),

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

Re: [PATCH v7 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

On Mon, Feb 15, 2021 at 06:05:45PM +0100, Mauro Carvalho Chehab wrote:
> Em Mon, 15 Feb 2021 17:56:27 +0100
> Petr Mladek  escreveu:
> 
> > On Mon 2021-02-15 13:40:29, Sakari Ailus wrote:
> > > Now that we can print FourCC codes directly using printk, make use of the
> > > feature in V4L2 core.
> > > 
> > > Signed-off-by: Sakari Ailus   
> > 
> > Reviewed-by: Petr Mladek 
> > 
> > I am curious whether I could take this via printk tree or if Mauro
> > would prefer to take this via his tree.
> 
> IMO, the best would be if the entire series gets merged via a single
> tree.
> 
> Feel free to merge via the printk one.
> 
> Acked-by: Mauro Carvalho Chehab 

Thanks, Mauro!

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

Re: [PATCH v7 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

Hi Petr,

On Mon, Feb 15, 2021 at 05:51:40PM +0100, Petr Mladek wrote:
> On Mon 2021-02-15 17:54:47, Andy Shevchenko wrote:
> > On Mon, Feb 15, 2021 at 03:56:50PM +0200, Sakari Ailus wrote:
> > > On Mon, Feb 15, 2021 at 03:31:29PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Feb 15, 2021 at 01:40:28PM +0200, Sakari Ailus wrote:
> > > > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and 
> > > > > DRM
> > > > > pixel formats denoted by fourccs. The fourcc encoding is the same for 
> > > > > both
> > > > > so the same implementation can be used.
> > > > 
> > > > This version I almost like, feel free to add
> > > > Reviewed-by: From: Andy Shevchenko 
> > > > after considering addressing below nit-picks.
> > 
> > > > > +Examples::
> > > > > +
> > > > > + %p4cc   BG12 little-endian (0x32314742)
> > > > 
> > > > No examples with spaces / non-printable / non-ascii characters
> > > 
> > > I can sure add an example that has a space. But do you think I really
> > > should add an example where invalid information is being printed?
> > 
> > I think you have to provide better coverage of what user can get out of 
> > this.
> > Perhaps one example with space and non-printable character is enough.
> > 
> > > > > + char output[sizeof("1234 little-endian (0x01234567)")];
> > > > 
> > > > 1234 -> ABCD ? (Or XY12 to be closer to the reality)
> > > 
> > > I count in numbers... albeit the hexadecimal number there starts from 
> > > zero.
> > > 
> > > I guess both would work though.
> > > 
> > > 0123 would be consistent.
> > 
> > Since letters can be printed the above is confusing a bit. I think XY12 is
> > closer to the reality than 0123.
> 
> Ailus, are you going to send v8 with the two small changes? I mean a
> selftest with the space and the above sample code.

Yes, and a few more examples.

> 
> Anyway, feel free to add:
> 
> Reviewed-by: Petr Mladek 

Thank you.

It'd be great if we could merge this through the printk tree. Acks are
needed from the DRM people first.

-- 
Regards,

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

Re: [PATCH v7 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

2021-02-15 Thread Mauro Carvalho Chehab

Em Mon, 15 Feb 2021 17:56:27 +0100
Petr Mladek  escreveu:

> On Mon 2021-02-15 13:40:29, Sakari Ailus wrote:
> > Now that we can print FourCC codes directly using printk, make use of the
> > feature in V4L2 core.
> > 
> > Signed-off-by: Sakari Ailus   
> 
> Reviewed-by: Petr Mladek 
> 
> I am curious whether I could take this via printk tree or if Mauro
> would prefer to take this via his tree.

IMO, the best would be if the entire series gets merged via a single
tree.

Feel free to merge via the printk one.

Acked-by: Mauro Carvalho Chehab 

> 
> Anyway, there will be v8 with small changes in the 1st patch.
> 
> Best Regards,
> Petr



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

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for SN65DSI83/84/85

Hi,

On 15/02/2021 12:25, Jagan Teki wrote:
> On Mon, Feb 15, 2021 at 2:32 PM Neil Armstrong  
> wrote:
>>
>> Hi,
>>
>> On 14/02/2021 18:44, Jagan Teki wrote:
>>> SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge
>>> controller IC's from Texas Instruments.
>>>
>>> SN65DSI83 - Single Channel DSI to Single-link LVDS bridge
>>> SN65DSI84 - Single Channel DSI to Dual-link LVDS bridge
>>> SN65DSI85 - Dual Channel DSI to Dual-link LVDS bridge
>>>
>>> Right now the bridge driver is supporting Channel A with single
>>> link, so dt-bindings documented according to it.
>>
>> Shouldn't it describe Dual-link LVDS already for SN65DSI84/85 and Dual 
>> Channel DSI for SN65DSI85 even if not implemented in the driver ?
> 
> Patch documented only Single link LVDS as it only supported by driver.
> Single link LVDS with Channel A configuration is common across all 3
> variant chips. I have SN65DSI84 with Single link LVDS which is routed
> in Channel A. Idea is to go with Single link and add double link later
> and document the same.

DT Bindings is unrelated to the software support, simply add the second LVDS 
channel endpoint
for SN65DSI84/85 and the second dsi endpoint for SN65DSI85.

Neil

> 
> Jagan.
> 

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

[PATCH] drm/msm/dsi: support CPHY mode for 7nm pll/phy

Add the required changes to support 7nm pll/phy in CPHY mode.

This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.

Signed-off-by: Jonathan Marek 
---
 .../devicetree/bindings/display/msm/dsi.txt   |  1 +
 drivers/gpu/drm/msm/dsi/dsi.c | 12 +--
 drivers/gpu/drm/msm/dsi/dsi.h |  6 +-
 drivers/gpu/drm/msm/dsi/dsi.xml.h |  2 +
 drivers/gpu/drm/msm/dsi/dsi_host.c| 34 +--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 49 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |  3 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 89 ++-
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c |  4 +-
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h |  5 +-
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c | 71 +--
 11 files changed, 210 insertions(+), 66 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index b9a64d3ff184..7ffc86a9816b 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -124,6 +124,7 @@ Required properties:
 Optional properties:
 - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
   regulator is wanted.
+- qcom,dsi-phy-cphy-mode: Boolean value indicating if CPHY mode is wanted.
 - qcom,mdss-mdp-transfer-time-us:  Specifies the dsi transfer time for 
command mode
panels in microseconds. Driver uses 
this number to adjust
the clock rate according to the 
expected transfer time.
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 627048851d99..68d8547f7264 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -13,7 +13,7 @@ struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi 
*msm_dsi)
return msm_dsi->encoder;
 }
 
-static int dsi_get_phy(struct msm_dsi *msm_dsi)
+static int dsi_get_phy(struct msm_dsi *msm_dsi, bool *cphy_mode)
 {
struct platform_device *pdev = msm_dsi->pdev;
struct platform_device *phy_pdev;
@@ -29,6 +29,7 @@ static int dsi_get_phy(struct msm_dsi *msm_dsi)
if (phy_pdev)
msm_dsi->phy = platform_get_drvdata(phy_pdev);
 
+   *cphy_mode = of_property_read_bool(phy_node, "qcom,dsi-phy-cphy-mode");
of_node_put(phy_node);
 
if (!phy_pdev || !msm_dsi->phy) {
@@ -65,6 +66,7 @@ static void dsi_destroy(struct msm_dsi *msm_dsi)
 static struct msm_dsi *dsi_init(struct platform_device *pdev)
 {
struct msm_dsi *msm_dsi;
+   bool cphy_mode;
int ret;
 
if (!pdev)
@@ -79,13 +81,13 @@ static struct msm_dsi *dsi_init(struct platform_device 
*pdev)
msm_dsi->pdev = pdev;
platform_set_drvdata(pdev, msm_dsi);
 
-   /* Init dsi host */
-   ret = msm_dsi_host_init(msm_dsi);
+   /* GET dsi PHY */
+   ret = dsi_get_phy(msm_dsi, &cphy_mode);
if (ret)
goto destroy_dsi;
 
-   /* GET dsi PHY */
-   ret = dsi_get_phy(msm_dsi);
+   /* Init dsi host */
+   ret = msm_dsi_host_init(msm_dsi, cphy_mode);
if (ret)
goto destroy_dsi;
 
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 78ef5d4ed922..8db4edc286ee 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -108,7 +108,7 @@ struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi 
*msm_dsi);
 struct msm_dsi_pll;
 #ifdef CONFIG_DRM_MSM_DSI_PLL
 struct msm_dsi_pll *msm_dsi_pll_init(struct platform_device *pdev,
-   enum msm_dsi_phy_type type, int dsi_id);
+   enum msm_dsi_phy_type type, bool cphy_mode, int id);
 void msm_dsi_pll_destroy(struct msm_dsi_pll *pll);
 int msm_dsi_pll_get_clk_provider(struct msm_dsi_pll *pll,
struct clk **byte_clk_provider, struct clk **pixel_clk_provider);
@@ -118,7 +118,7 @@ int msm_dsi_pll_set_usecase(struct msm_dsi_pll *pll,
enum msm_dsi_phy_usecase uc);
 #else
 static inline struct msm_dsi_pll *msm_dsi_pll_init(struct platform_device 
*pdev,
-enum msm_dsi_phy_type type, int id) {
+enum msm_dsi_phy_type type, bool cphy_mode, int id) {
return ERR_PTR(-ENODEV);
 }
 static inline void msm_dsi_pll_destroy(struct msm_dsi_pll *pll)
@@ -177,7 +177,7 @@ void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host 
*host,
 void msm_dsi_host_destroy(struct mipi_dsi_host *host);
 int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
-int msm_dsi_host_init(struct msm_dsi *msm_dsi);
+int msm_dsi_host_init(struct msm_dsi *msm_dsi, bool cphy_mode);
 int msm_dsi_runtime_suspend(struct device *dev);
 int msm_dsi_runtime_resume(struct device *dev);
 int dsi_link_clk_set_ra

[PATCH v3 1/2] drm/msm: add compatibles for sm8150/sm8250 display

The driver already has support for sm8150/sm8250, but the compatibles were
never added.

Also inverse the non-mdp4 condition in add_display_components() to avoid
having to check every new compatible in the condition.

Signed-off-by: Jonathan Marek 
---
 Documentation/devicetree/bindings/display/msm/dpu.txt | 4 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 2 ++
 drivers/gpu/drm/msm/msm_drv.c | 6 +++---
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
b/Documentation/devicetree/bindings/display/msm/dpu.txt
index 551ae26f60da..5763f43200a0 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
@@ -8,7 +8,7 @@ The DPU display controller is found in SDM845 SoC.
 
 MDSS:
 Required properties:
-- compatible:  "qcom,sdm845-mdss", "qcom,sc7180-mdss"
+- compatible:  "qcom,sdm845-mdss", "qcom,sc7180-mdss", "qcom,sm8150-mdss", 
"qcom,sm8250-mdss"
 - reg: physical base address and length of contoller's registers.
 - reg-names: register region names. The following region is required:
   * "mdss"
@@ -41,7 +41,7 @@ Optional properties:
 
 MDP:
 Required properties:
-- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu"
+- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu", "qcom,sm8150-dpu", 
"qcom,sm8250-dpu"
 - reg: physical base address and length of controller's registers.
 - reg-names : register region names. The following region is required:
   * "mdp"
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 5a8e3e1fc48c..fff12a4c8bfc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1219,6 +1219,8 @@ static const struct dev_pm_ops dpu_pm_ops = {
 static const struct of_device_id dpu_dt_match[] = {
{ .compatible = "qcom,sdm845-dpu", },
{ .compatible = "qcom,sc7180-dpu", },
+   { .compatible = "qcom,sm8150-dpu", },
+   { .compatible = "qcom,sm8250-dpu", },
{}
 };
 MODULE_DEVICE_TABLE(of, dpu_dt_match);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..928f13d4bfbc 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1185,9 +1185,7 @@ static int add_display_components(struct device *dev,
 * Populate the children devices, find the MDP5/DPU node, and then add
 * the interfaces to our components list.
 */
-   if (of_device_is_compatible(dev->of_node, "qcom,mdss") ||
-   of_device_is_compatible(dev->of_node, "qcom,sdm845-mdss") ||
-   of_device_is_compatible(dev->of_node, "qcom,sc7180-mdss")) {
+   if (!of_device_is_compatible(dev->of_node, "qcom,mdp4")) {
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
if (ret) {
DRM_DEV_ERROR(dev, "failed to populate children 
devices\n");
@@ -1320,6 +1318,8 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
{ .compatible = "qcom,sdm845-mdss", .data = (void *)KMS_DPU },
{ .compatible = "qcom,sc7180-mdss", .data = (void *)KMS_DPU },
+   { .compatible = "qcom,sm8150-mdss", .data = (void *)KMS_DPU },
+   { .compatible = "qcom,sm8250-mdss", .data = (void *)KMS_DPU },
{}
 };
 MODULE_DEVICE_TABLE(of, dt_match);
-- 
2.26.1

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

[PATCH v3 0/2] arm64: dts: qcom: sm8250: fix display nodes

Add sm8150/sm8250 compatibles to drm/msm and fix the sm8250
display nodes.

v2: do not remove mmcx-supply from dispcc node
v3: remove references to dp_phy (missed this in v2, sorry for the spam)

Jonathan Marek (2):
  drm/msm: add compatibles for sm8150/sm8250 display
  arm64: dts: qcom: sm8250: fix display nodes

 .../devicetree/bindings/display/msm/dpu.txt   |  4 +--
 arch/arm64/boot/dts/qcom/sm8250.dtsi  | 31 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  2 ++
 drivers/gpu/drm/msm/msm_drv.c |  6 ++--
 4 files changed, 15 insertions(+), 28 deletions(-)

-- 
2.26.1

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

[PATCH v2 1/2] drm/msm: add compatibles for sm8150/sm8250 display

The driver already has support for sm8150/sm8250, but the compatibles were
never added.

Also inverse the non-mdp4 condition in add_display_components() to avoid
having to check every new compatible in the condition.

Signed-off-by: Jonathan Marek 
---
 Documentation/devicetree/bindings/display/msm/dpu.txt | 4 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 2 ++
 drivers/gpu/drm/msm/msm_drv.c | 6 +++---
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
b/Documentation/devicetree/bindings/display/msm/dpu.txt
index 551ae26f60da..5763f43200a0 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
@@ -8,7 +8,7 @@ The DPU display controller is found in SDM845 SoC.
 
 MDSS:
 Required properties:
-- compatible:  "qcom,sdm845-mdss", "qcom,sc7180-mdss"
+- compatible:  "qcom,sdm845-mdss", "qcom,sc7180-mdss", "qcom,sm8150-mdss", 
"qcom,sm8250-mdss"
 - reg: physical base address and length of contoller's registers.
 - reg-names: register region names. The following region is required:
   * "mdss"
@@ -41,7 +41,7 @@ Optional properties:
 
 MDP:
 Required properties:
-- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu"
+- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu", "qcom,sm8150-dpu", 
"qcom,sm8250-dpu"
 - reg: physical base address and length of controller's registers.
 - reg-names : register region names. The following region is required:
   * "mdp"
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 5a8e3e1fc48c..fff12a4c8bfc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1219,6 +1219,8 @@ static const struct dev_pm_ops dpu_pm_ops = {
 static const struct of_device_id dpu_dt_match[] = {
{ .compatible = "qcom,sdm845-dpu", },
{ .compatible = "qcom,sc7180-dpu", },
+   { .compatible = "qcom,sm8150-dpu", },
+   { .compatible = "qcom,sm8250-dpu", },
{}
 };
 MODULE_DEVICE_TABLE(of, dpu_dt_match);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..928f13d4bfbc 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1185,9 +1185,7 @@ static int add_display_components(struct device *dev,
 * Populate the children devices, find the MDP5/DPU node, and then add
 * the interfaces to our components list.
 */
-   if (of_device_is_compatible(dev->of_node, "qcom,mdss") ||
-   of_device_is_compatible(dev->of_node, "qcom,sdm845-mdss") ||
-   of_device_is_compatible(dev->of_node, "qcom,sc7180-mdss")) {
+   if (!of_device_is_compatible(dev->of_node, "qcom,mdp4")) {
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
if (ret) {
DRM_DEV_ERROR(dev, "failed to populate children 
devices\n");
@@ -1320,6 +1318,8 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
{ .compatible = "qcom,sdm845-mdss", .data = (void *)KMS_DPU },
{ .compatible = "qcom,sc7180-mdss", .data = (void *)KMS_DPU },
+   { .compatible = "qcom,sm8150-mdss", .data = (void *)KMS_DPU },
+   { .compatible = "qcom,sm8250-mdss", .data = (void *)KMS_DPU },
{}
 };
 MODULE_DEVICE_TABLE(of, dt_match);
-- 
2.26.1

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

[PATCH v2 0/2] arm64: dts: qcom: sm8250: fix display nodes

Add sm8150/sm8250 compatibles to drm/msm and fix the sm8250
display nodes.

v2: do not remove mmcx-supply from dispcc node

Jonathan Marek (2):
  drm/msm: add compatibles for sm8150/sm8250 display
  arm64: dts: qcom: sm8250: fix display nodes

 .../devicetree/bindings/display/msm/dpu.txt   |  4 +--
 arch/arm64/boot/dts/qcom/sm8250.dtsi  | 33 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  2 ++
 drivers/gpu/drm/msm/msm_drv.c |  6 ++--
 4 files changed, 16 insertions(+), 29 deletions(-)

-- 
2.26.1

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

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

On Mon, Feb 15, 2021 at 04:37:50PM +0200, Jani Nikula wrote:
> On Mon, 15 Feb 2021, Andy Shevchenko  
> wrote:
> > We have already few similar implementation and a lot of code that can 
> > benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> Good luck. I gave up after just four versions. [1]

Thanks for a pointer! I like your version, but here we also discussing a
possibility to do something like %py[DOY]. It will consolidate all those RO or
whatever sections inside one data structure.

> Acked-by: Jani Nikula 
> 
> [1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nik...@intel.com


-- 
With Best Regards,
Andy Shevchenko


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

Re: [PATCH v7 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

On Mon, Feb 15, 2021 at 03:56:50PM +0200, Sakari Ailus wrote:
> On Mon, Feb 15, 2021 at 03:31:29PM +0200, Andy Shevchenko wrote:
> > On Mon, Feb 15, 2021 at 01:40:28PM +0200, Sakari Ailus wrote:
> > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> > > so the same implementation can be used.
> > 
> > This version I almost like, feel free to add
> > Reviewed-by: From: Andy Shevchenko 
> > after considering addressing below nit-picks.

> > > +Examples::
> > > +
> > > + %p4cc   BG12 little-endian (0x32314742)
> > 
> > No examples with spaces / non-printable / non-ascii characters
> 
> I can sure add an example that has a space. But do you think I really
> should add an example where invalid information is being printed?

I think you have to provide better coverage of what user can get out of this.
Perhaps one example with space and non-printable character is enough.

> > > + char output[sizeof("1234 little-endian (0x01234567)")];
> > 
> > 1234 -> ABCD ? (Or XY12 to be closer to the reality)
> 
> I count in numbers... albeit the hexadecimal number there starts from zero.
> 
> I guess both would work though.
> 
> 0123 would be consistent.

Since letters can be printed the above is confusing a bit. I think XY12 is
closer to the reality than 0123.

-- 
With Best Regards,
Andy Shevchenko


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

Re: [PATCH v12] staging: fbtft: add tearing signal detect

On Tue, Feb 2, 2021 at 3:52 AM Carlis  wrote:
> On Mon, 1 Feb 2021 19:40:21 +0200
> Andy Shevchenko  wrote:
>
> > On Sat, Jan 30, 2021 at 8:39 AM carlis  wrote:
> > > On Fri, 29 Jan 2021 16:26:12 +0200
> > > Andy Shevchenko  wrote:
> > > > On Fri, Jan 29, 2021 at 3:56 PM carlis 
> > > > wrote:
> > > > > On Fri, 29 Jan 2021 12:23:08 +0200
> > > > > Andy Shevchenko  wrote:
> >
> > ...
> >
> > > > > Hi, I apologize for what I said in the previous two emails. I
> > > > > missed one email you sent before, and now I probably understand
> > > > > what you meant. Here is a version I modified according to your
> > > > > suggestion:
> >
> > I have realized that you are mocking stuff in the generic fbtft
> > structure for all drivers while only a single one is going to use
> > that. Consider moving everything to the driver in question.

>Do you mean that i define the TE completion and irq_te in the
>fb_st7789v.c as i did before?

Not in global variables. Perhaps it will require to add/update the
custom (to the specific driver) data structure.
But the idea is that all changes should be isolated to that driver.

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

KMSAN: kernel-infoleak in fb_cmap_to_user

2021-02-15 Thread syzbot

Hello,

syzbot found the following issue on:

HEAD commit:29ad81a1 arch/x86: add missing include to sparsemem.h
git tree:   https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=1001ac60d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=c8e3b38ca92283e
dashboard link: https://syzkaller.appspot.com/bug?extid=47fa9c9c648b765305b9
compiler:   Debian clang version 11.0.1-2
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=17ffe738d0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11ca2914d0

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+47fa9c9c648b76530...@syzkaller.appspotmail.com

=
BUG: KMSAN: kernel-infoleak in kmsan_copy_to_user+0x9c/0xb0 
mm/kmsan/kmsan_hooks.c:249
CPU: 1 PID: 8225 Comm: syz-executor269 Not tainted 5.11.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x21c/0x280 lib/dump_stack.c:120
 kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118
 kmsan_internal_check_memory+0x484/0x520 mm/kmsan/kmsan.c:437
 kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249
 instrument_copy_to_user include/linux/instrumented.h:121 [inline]
 _copy_to_user+0x1ac/0x270 lib/usercopy.c:33
 copy_to_user include/linux/uaccess.h:209 [inline]
 fb_cmap_to_user+0x40a/0x990 drivers/video/fbdev/core/fbcmap.c:208
 do_fb_ioctl+0xc53/0x1090 drivers/video/fbdev/core/fbmem.c:1136
 fb_ioctl+0x1e4/0x210 drivers/video/fbdev/core/fbmem.c:1185
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl+0x311/0x4d0 fs/ioctl.c:739
 __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:739
 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x43fbd9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffc68acbf98 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 00400488 RCX: 0043fbd9
RDX: 20007400 RSI: 4604 RDI: 0003
RBP:  R08: 7ffc68acc138 R09: 7ffc68acc138
R10: 7ffc68acba10 R11: 0246 R12: 00403460
R13: 431bde82d7b634db R14: 004ad018 R15: 00400488

Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline]
 kmsan_internal_poison_shadow+0x5c/0xf0 mm/kmsan/kmsan.c:104
 kmsan_slab_alloc+0x8d/0xe0 mm/kmsan/kmsan_hooks.c:76
 slab_alloc_node mm/slub.c:2907 [inline]
 slab_alloc mm/slub.c:2916 [inline]
 __kmalloc+0x378/0x560 mm/slub.c:3998
 kmalloc include/linux/slab.h:557 [inline]
 fb_alloc_cmap_gfp+0x39b/0xa70 drivers/video/fbdev/core/fbcmap.c:104
 fb_alloc_cmap+0x95/0xb0 drivers/video/fbdev/core/fbcmap.c:135
 drm_fb_helper_alloc_fbi+0x106/0x3f0 drivers/gpu/drm/drm_fb_helper.c:563
 drm_fb_helper_generic_probe+0x4f3/0xc70 drivers/gpu/drm/drm_fb_helper.c:2320
 drm_fb_helper_single_fb_probe drivers/gpu/drm/drm_fb_helper.c:1658 [inline]
 __drm_fb_helper_initial_config_and_unlock+0x1cac/0x26c0 
drivers/gpu/drm/drm_fb_helper.c:1816
 drm_fb_helper_initial_config drivers/gpu/drm/drm_fb_helper.c:1911 [inline]
 drm_fbdev_client_hotplug+0xbb8/0xd70 drivers/gpu/drm/drm_fb_helper.c:2413
 drm_fbdev_generic_setup+0x39d/0xa00 drivers/gpu/drm/drm_fb_helper.c:2495
 vkms_init+0x880/0xa02 drivers/gpu/drm/vkms/vkms_drv.c:168
 do_one_initcall+0x362/0x8d0 init/main.c:1226
 do_initcall_level+0x1e7/0x35a init/main.c:1299
 do_initcalls+0x127/0x1cb init/main.c:1315
 do_basic_setup+0x33/0x36 init/main.c:1335
 kernel_init_freeable+0x23d/0x390 init/main.c:1536
 kernel_init+0x1f/0x840 init/main.c:1424
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296

Bytes 0-1 of 2 are uninitialized
Memory access of size 2 starts at 8881455651c0
Data copied to user address 20007300
=


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: DMA-buf and uncached system memory

2021-02-15 Thread David Laight

From: Christian König
> Sent: 15 February 2021 12:05
...
> Snooping the CPU caches introduces some extra latency, so what can
> happen is that the response to the PCIe read comes to late for the
> scanout. The result is an underflow and flickering whenever something is
> in the cache which needs to be flushed first.

Aren't you going to get the same problem if any other endpoints are
doing memory reads?
Possibly even ones that don't require a cache snoop and flush.

What about just the cpu doing a real memory transfer?

Or a combination of the two above happening just before your request.

If you don't have a big enough fifo you'll lose.

I did 'fix' a similar(ish) issue with video DMA latency on an embedded
system based the on SA1100/SA1101 by significantly reducing the clock
to the VGA panel whenever the cpu was doing 'slow io'.
(Interleaving an uncached cpu DRAM write between the slow io cycles
also fixed it.)
But the video was the only DMA device and that was an embedded system.
Given the application note about video latency didn't mention what was
actually happening, I'm not sure how many people actually got it working!

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 211649] "drm/amd/display: reuse current context instead of recreating one" cause hdmi hotplug blackscreen on amdgpu

https://bugzilla.kernel.org/show_bug.cgi?id=211649

--- Comment #13 from Alex Deucher (alexdeuc...@gmail.com) ---
See also:
https://gitlab.freedesktop.org/drm/amd/-/issues/1487

-- 
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 211425] [drm:atom_op_jump] ERROR atombios stuck in loop for more than 20secs aborting

https://bugzilla.kernel.org/show_bug.cgi?id=211425

--- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you narrow down the specific commit?

https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html

-- 
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: [Linaro-mm-sig] DMA-buf and uncached system memory




Am 15.02.21 um 15:41 schrieb David Laight:

From: Christian König

Sent: 15 February 2021 12:05

...

Snooping the CPU caches introduces some extra latency, so what can
happen is that the response to the PCIe read comes to late for the
scanout. The result is an underflow and flickering whenever something is
in the cache which needs to be flushed first.

Aren't you going to get the same problem if any other endpoints are
doing memory reads?


The PCIe device in this case is part of the SoC, so we have a high 
priority channel to memory.


Because of this the hardware designer assumed they have a guaranteed 
memory latency.



Possibly even ones that don't require a cache snoop and flush.

What about just the cpu doing a real memory transfer?

Or a combination of the two above happening just before your request.

If you don't have a big enough fifo you'll lose.

I did 'fix' a similar(ish) issue with video DMA latency on an embedded
system based the on SA1100/SA1101 by significantly reducing the clock
to the VGA panel whenever the cpu was doing 'slow io'.
(Interleaving an uncached cpu DRAM write between the slow io cycles
also fixed it.)
But the video was the only DMA device and that was an embedded system.
Given the application note about video latency didn't mention what was
actually happening, I'm not sure how many people actually got it working!


Yeah, I'm also not sure if AMD doesn't solve this with deeper fifos or 
more prefetching in future designs.


But you gave me at least one example where somebody had similar problems.

Thanks for the feedback,
Christian.



David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig


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

[Bug 211745] Latest 5.11 git doesn't boot.

https://bugzilla.kernel.org/show_bug.cgi?id=211745

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?

-- 
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: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

+Cc: Sakari and printk people

On Mon, Feb 15, 2021 at 4:28 PM Christian König
 wrote:
> Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > We have already few similar implementation and a lot of code that can 
> > benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >
> > Signed-off-by: Andy Shevchenko 
>
> Looks like a good idea to me, feel free to add an Acked-by: Christian
> König  to the series.

Thanks.

> But looking at the use cases for this, wouldn't it make more sense to
> teach kprintf some new format modifier for this?

As a next step? IIRC Sakari has at some point the series converted
yesno and Co. to something which I don't remember the details of.

Guys, what do you think?

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

2021-02-15 Thread Jani Nikula

On Mon, 15 Feb 2021, Andy Shevchenko  wrote:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Good luck. I gave up after just four versions. [1]

Acked-by: Jani Nikula 


BR,
Jani.


[1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nik...@intel.com


>
> Signed-off-by: Andy Shevchenko 
> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c|  6 +-
>  drivers/gpu/drm/i915/i915_utils.h|  6 +-
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +---
>  include/linux/string.h   |  5 +
>  4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>   *
>   */
>  
> +#include 
>  #include 
>  
>  #include 
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>   uint32_t param1;
>  };
>  
> -static inline const char *yesno(bool v)
> -{
> - return v ? "yes" : "no";
> -}
> -
>  /* parse_write_buffer_into_params - Helper function to parse debugfs write 
> buffer into an array
>   *
>   * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h 
> b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long 
> timestamp_jiffies, int to_wait_ms)
>  #define MBps(x) KBps(1000 * (x))
>  #define GBps(x) ((u64)1000 * MBps((x)))
>  
> -static inline const char *yesno(bool v)
> -{
> - return v ? "yes" : "no";
> -}
> -
>  static inline const char *onoff(bool v)
>  {
>   return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c 
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = 
> {
>  /* RSS Configuration.
>   */
>  
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> - static const char *yes = "yes";
> - static const char *no = "no";
> -
> - return x ? yes : no;
> -}
> -
>  static int rss_config_show(struct seq_file *seq, void *v)
>  {
>   struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char 
> *str, const char *prefix
>   return strncmp(str, prefix, len) == 0 ? len : 0;
>  }
>  
> +static inline const char *yesno(bool yes)
> +{
> + return yes ? "yes" : "no";
> +}
> +
>  #endif /* _LINUX_STRING_H_ */

-- 
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 3/6] drm/rockchip: dsi: add ability to work as a phy instead of full dsi

2021-02-15 Thread Helen Koike





On 2/10/21 8:10 AM, Heiko Stuebner wrote:

From: Heiko Stuebner 

SoCs like the rk3288 and rk3399 have 3 mipi dphys on them. One is TX-
only, one is RX-only and one can be configured to do either TX or RX.

The RX phy is statically connected to the first Image Signal Processor,
the TX phy is statically connected to the first DSI controller and
the TXRX phy is connected to both the second DSI controller as well
as the second ISP.

The RX dphy is controlled externally through registers in the "General
Register Files", while the other two are controlled through the
"Configuration and Test Interface" inside their DSI controller's
io-memory area.

The Rockchip dw-dsi controller already controls these dphys for the
TX case in the driver, but when we want to also allow configuration
for RX to the ISP from the media subsystem we need to expose phy-
functionality instead.

So add a bit of infrastructure to allow the dsi driver to work as a
phy and make sure it can be only one or the other at a time.

Similarly as the dsi-controller will be part of the drm-graph when
active, add an empty component to the drm-graph when in phy-mode
to make the rest of the drm-graph not wait for it.

Signed-off-by: Heiko Stuebner 
Tested-by: Sebastian Fricke 
---
  drivers/gpu/drm/rockchip/Kconfig  |   2 +
  .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 341 ++
  2 files changed, 343 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index cb25c0e8fc9b..3094d4533ad6 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -9,6 +9,8 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select GENERIC_PHY if ROCKCHIP_DW_MIPI_DSI
+   select GENERIC_PHY_MIPI_DPHY if ROCKCHIP_DW_MIPI_DSI


maybe alphabetical order?


select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 18e112e30f6e..e322749a5279 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include 

@@ -125,7 +126,9 @@
  #define BANDGAP_AND_BIAS_CONTROL  0x20
  #define TERMINATION_RESISTER_CONTROL  0x21
  #define AFE_BIAS_BANDGAP_ANALOG_PROGRAMMABILITY   0x22
+#define HS_RX_CONTROL_OF_LANE_CLK  0x34
  #define HS_RX_CONTROL_OF_LANE_0   0x44
+#define HS_RX_CONTROL_OF_LANE_10x54
  #define HS_TX_CLOCK_LANE_REQUEST_STATE_TIME_CONTROL   0x60
  #define HS_TX_CLOCK_LANE_PREPARE_STATE_TIME_CONTROL   0x61
  #define HS_TX_CLOCK_LANE_HS_ZERO_STATE_TIME_CONTROL   0x62
@@ -137,6 +140,9 @@
  #define HS_TX_DATA_LANE_HS_ZERO_STATE_TIME_CONTROL0x72
  #define HS_TX_DATA_LANE_TRAIL_STATE_TIME_CONTROL  0x73
  #define HS_TX_DATA_LANE_EXIT_STATE_TIME_CONTROL   0x74
+#define HS_RX_DATA_LANE_THS_SETTLE_CONTROL 0x75
+#define HS_RX_CONTROL_OF_LANE_20x84
+#define HS_RX_CONTROL_OF_LANE_30x94
  
  #define DW_MIPI_NEEDS_PHY_CFG_CLK	BIT(0)

  #define DW_MIPI_NEEDS_GRF_CLK BIT(1)
@@ -171,11 +177,19 @@
  #define RK3399_TXRX_MASTERSLAVEZ  BIT(7)
  #define RK3399_TXRX_ENABLECLK BIT(6)
  #define RK3399_TXRX_BASEDIR   BIT(5)
+#define RK3399_TXRX_SRC_SEL_ISP0   BIT(4)
+#define RK3399_TXRX_TURNREQUESTGENMASK(3, 0)
  
  #define HIWORD_UPDATE(val, mask)	(val | (mask) << 16)
  
  #define to_dsi(nm)	container_of(nm, struct dw_mipi_dsi_rockchip, nm)
  
+enum {

+   DW_DSI_USAGE_IDLE,
+   DW_DSI_USAGE_DSI,
+   DW_DSI_USAGE_PHY,
+};
+
  enum {
BANDGAP_97_07,
BANDGAP_98_05,
@@ -213,6 +227,10 @@ struct rockchip_dw_dsi_chip_data {
u32 lanecfg2_grf_reg;
u32 lanecfg2;
  
+	int (*dphy_rx_init)(struct phy *phy);

+   int (*dphy_rx_power_on)(struct phy *phy);
+   int (*dphy_rx_power_off)(struct phy *phy);
+
unsigned int flags;
unsigned int max_data_lanes;
  };
@@ -236,6 +254,12 @@ struct dw_mipi_dsi_rockchip {
struct phy *phy;
union phy_configure_opts phy_opts;
  
+	/* being a phy for other mipi hosts */

+   unsigned int usage_mode;
+   struct mutex usage_mutex;
+   struct phy *dphy;
+   struct phy_configure_opts_mipi_dphy dphy_config;
+
unsigned int lane_mbps; /* per lane */
u16 input_div;
u16 feedback_div;
@@ -965,6 +989,17 @@ static int dw_mipi_dsi_rockchip_host_attach(void 
*priv_data,
struct device *second;
int ret;
  
+	mutex_lock(&dsi->usage_mutex);

+
+   i

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood


Am 15.02.21 um 15:21 schrieb Andy Shevchenko:

We have already few similar implementation and a lot of code that can benefit
of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Signed-off-by: Andy Shevchenko 


Looks like a good idea to me, feel free to add an Acked-by: Christian 
König  to the series.


But looking at the use cases for this, wouldn't it make more sense to 
teach kprintf some new format modifier for this?


Christian.


---
  .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c|  6 +-
  drivers/gpu/drm/i915/i915_utils.h|  6 +-
  drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +---
  include/linux/string.h   |  5 +
  4 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 360952129b6d..7fde4f90e513 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -23,6 +23,7 @@
   *
   */
  
+#include 

  #include 
  
  #include 

@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
uint32_t param1;
  };
  
-static inline const char *yesno(bool v)

-{
-   return v ? "yes" : "no";
-}
-
  /* parse_write_buffer_into_params - Helper function to parse debugfs write 
buffer into an array
   *
   * Function takes in attributes passed to debugfs write entry
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index abd4dcd9f79c..e6da5a951132 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -27,6 +27,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long 
timestamp_jiffies, int to_wait_ms)
  #define MBps(x) KBps(1000 * (x))
  #define GBps(x) ((u64)1000 * MBps((x)))
  
-static inline const char *yesno(bool v)

-{
-   return v ? "yes" : "no";
-}
-
  static inline const char *onoff(bool v)
  {
return v ? "on" : "off";
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 7d49fd4edc9e..c857d73abbd7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -34,6 +34,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
  /* RSS Configuration.
   */
  
-/* Small utility function to return the strings "yes" or "no" if the supplied

- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
-   static const char *yes = "yes";
-   static const char *no = "no";
-
-   return x ? yes : no;
-}
-
  static int rss_config_show(struct seq_file *seq, void *v)
  {
struct adapter *adapter = seq->private;
diff --git a/include/linux/string.h b/include/linux/string.h
index 9521d8cab18e..fd946a5e18c8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char 
*str, const char *prefix
return strncmp(str, prefix, len) == 0 ? len : 0;
  }
  
+static inline const char *yesno(bool yes)

+{
+   return yes ? "yes" : "no";
+}
+
  #endif /* _LINUX_STRING_H_ */


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

Re: [PATCH v4] MAINTAINERS: move Milo Kim to credits

2021-02-15 Thread Lee Jones

On Mon, 15 Feb 2021, Emil Velikov wrote:

> Greetings everyone,
> 
> On Mon, 15 Feb 2021 at 08:52, Lee Jones  wrote:
> >
> > On Fri, 12 Feb 2021, Krzysztof Kozlowski wrote:
> >
> > > Milo Kim's email in TI bounces with permanent error (550: Invalid
> > > recipient).  Last email from him on LKML was in 2017.  Move Milo Kim to
> > > credits and remove the separate driver entries for:
> > >  - TI LP855x backlight driver,
> > >  - TI LP8727 charger driver,
> > >  - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers.
> > >
> > > Signed-off-by: Krzysztof Kozlowski 
> > > Cc: Mark Brown 
> > > Cc: Jonathan Cameron 
> > > Cc: Jingoo Han 
> > > Cc: Lee Jones 
> > > Cc: Pavel Machek 
> > > Cc: Thierry Reding 
> > > Cc: Sebastian Reichel 
> > > Cc: Daniel Thompson 
> > >
> > > ---
> > >
> > > Dear Lee,
> > >
> > > Could you take care about this patch?
> >
> > Yes, but I'll be sending out my pull-request for v5.12 in the next
> > couple of days (maybe even today if I can find some time), so this
> > will have to wait until v5.13.
> >
> Would it make sense to keep the MAINTAINERS entries as "orphan"?
> Checking with linux-next, the drivers are still present in-tree.

Please see:

 https://lore.kernel.org/patchwork/patch/1379016/

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 3/3] string: Move enableddisabled() helper under string.h hood

We have already an implementation and a lot of code that can benefit
of the enableddisabled() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -
 include/linux/string.h| 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index d2ac357896d4..b05d72b4dd93 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long 
timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *enableddisabled(bool v)
-{
-   return v ? "enabled" : "disabled";
-}
-
 void add_taint_for_CI(struct drm_i915_private *i915, unsigned int taint);
 static inline void __add_taint_for_CI(unsigned int taint)
 {
diff --git a/include/linux/string.h b/include/linux/string.h
index 2a0589e945d9..25f055aa4c31 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -318,4 +318,9 @@ static inline const char *onoff(bool on)
return on ? "on" : "off";
 }
 
+static inline const char *enableddisabled(bool enabled)
+{
+   return enabled ? "enabled" : "disabled";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

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

[PATCH v1 2/3] string: Move onoff() helper under string.h hood

We have already an implementation and a lot of code that can benefit
of the onoff() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -
 include/linux/string.h| 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index e6da5a951132..d2ac357896d4 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long 
timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *onoff(bool v)
-{
-   return v ? "on" : "off";
-}
-
 static inline const char *enableddisabled(bool v)
 {
return v ? "enabled" : "disabled";
diff --git a/include/linux/string.h b/include/linux/string.h
index fd946a5e18c8..2a0589e945d9 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -313,4 +313,9 @@ static inline const char *yesno(bool yes)
return yes ? "yes" : "no";
 }
 
+static inline const char *onoff(bool on)
+{
+   return on ? "on" : "off";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

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

[PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

We have already few similar implementation and a lot of code that can benefit
of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Signed-off-by: Andy Shevchenko 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c|  6 +-
 drivers/gpu/drm/i915/i915_utils.h|  6 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +---
 include/linux/string.h   |  5 +
 4 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 360952129b6d..7fde4f90e513 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -23,6 +23,7 @@
  *
  */
 
+#include 
 #include 
 
 #include 
@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
uint32_t param1;
 };
 
-static inline const char *yesno(bool v)
-{
-   return v ? "yes" : "no";
-}
-
 /* parse_write_buffer_into_params - Helper function to parse debugfs write 
buffer into an array
  *
  * Function takes in attributes passed to debugfs write entry
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index abd4dcd9f79c..e6da5a951132 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -27,6 +27,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long 
timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *yesno(bool v)
-{
-   return v ? "yes" : "no";
-}
-
 static inline const char *onoff(bool v)
 {
return v ? "on" : "off";
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 7d49fd4edc9e..c857d73abbd7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -34,6 +34,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
 /* RSS Configuration.
  */
 
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
-   static const char *yes = "yes";
-   static const char *no = "no";
-
-   return x ? yes : no;
-}
-
 static int rss_config_show(struct seq_file *seq, void *v)
 {
struct adapter *adapter = seq->private;
diff --git a/include/linux/string.h b/include/linux/string.h
index 9521d8cab18e..fd946a5e18c8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char 
*str, const char *prefix
return strncmp(str, prefix, len) == 0 ? len : 0;
 }
 
+static inline const char *yesno(bool yes)
+{
+   return yes ? "yes" : "no";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

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

Re: [PATCH v4] MAINTAINERS: move Milo Kim to credits

2021-02-15 Thread Emil Velikov

Greetings everyone,

On Mon, 15 Feb 2021 at 08:52, Lee Jones  wrote:
>
> On Fri, 12 Feb 2021, Krzysztof Kozlowski wrote:
>
> > Milo Kim's email in TI bounces with permanent error (550: Invalid
> > recipient).  Last email from him on LKML was in 2017.  Move Milo Kim to
> > credits and remove the separate driver entries for:
> >  - TI LP855x backlight driver,
> >  - TI LP8727 charger driver,
> >  - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers.
> >
> > Signed-off-by: Krzysztof Kozlowski 
> > Cc: Mark Brown 
> > Cc: Jonathan Cameron 
> > Cc: Jingoo Han 
> > Cc: Lee Jones 
> > Cc: Pavel Machek 
> > Cc: Thierry Reding 
> > Cc: Sebastian Reichel 
> > Cc: Daniel Thompson 
> >
> > ---
> >
> > Dear Lee,
> >
> > Could you take care about this patch?
>
> Yes, but I'll be sending out my pull-request for v5.12 in the next
> couple of days (maybe even today if I can find some time), so this
> will have to wait until v5.13.
>
Would it make sense to keep the MAINTAINERS entries as "orphan"?
Checking with linux-next, the drivers are still present in-tree.

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

Re: [PATCH v7 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

Hi Andy,

On Mon, Feb 15, 2021 at 03:31:29PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 15, 2021 at 01:40:28PM +0200, Sakari Ailus wrote:
> > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> > so the same implementation can be used.
> 
> This version I almost like, feel free to add
> Reviewed-by: From: Andy Shevchenko 
> after considering addressing below nit-picks.
> 
> > Suggested-by: Mauro Carvalho Chehab 
> > Signed-off-by: Sakari Ailus 
> > Reviewed-by: Petr Mladek 
> > Reviewed-by: Sergey Senozhatsky 
> > ---
> >  Documentation/core-api/printk-formats.rst | 16 ++
> >  lib/test_printf.c | 17 ++
> >  lib/vsprintf.c| 39 +++
> >  scripts/checkpatch.pl |  6 ++--
> >  4 files changed, 76 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/core-api/printk-formats.rst 
> > b/Documentation/core-api/printk-formats.rst
> > index 160e710d992f..da2aa065dc42 100644
> > --- a/Documentation/core-api/printk-formats.rst
> > +++ b/Documentation/core-api/printk-formats.rst
> > @@ -567,6 +567,22 @@ For printing netdev_features_t.
> >  
> >  Passed by reference.
> >  
> > +V4L2 and DRM FourCC code (pixel format)
> > +---
> > +
> > +::
> > +
> > +   %p4cc
> > +
> > +Print a FourCC code used by V4L2 or DRM, including format endianness and
> > +its numerical value as hexadecimal.
> > +
> > +Passed by reference.
> > +
> > +Examples::
> > +
> > +   %p4cc   BG12 little-endian (0x32314742)
> 
> No examples with spaces / non-printable / non-ascii characters

I can sure add an example that has a space. But do you think I really
should add an example where invalid information is being printed?

> 
> > +
> >  Thanks
> >  ==
> >  
> > diff --git a/lib/test_printf.c b/lib/test_printf.c
> > index 7d60f24240a4..9848510a2786 100644
> > --- a/lib/test_printf.c
> > +++ b/lib/test_printf.c
> > @@ -647,6 +647,22 @@ static void __init fwnode_pointer(void)
> > software_node_unregister_nodes(softnodes);
> >  }
> >  
> > +static void __init fourcc_pointer(void)
> > +{
> > +   struct {
> > +   u32 code;
> > +   char *str;
> > +   } const try[] = {
> > +   { 0x3231564e, "NV12 little-endian (0x3231564e)", },
> > +   { 0xb231564e, "NV12 big-endian (0xb231564e)", },
> > +   { 0x10111213, " little-endian (0x10111213)", },
> > +   };
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(try); i++)
> > +   test(try[i].str, "%p4cc", &try[i].code);
> > +}
> > +
> >  static void __init
> >  errptr(void)
> >  {
> > @@ -692,6 +708,7 @@ test_pointer(void)
> > flags();
> > errptr();
> > fwnode_pointer();
> > +   fourcc_pointer();
> >  }
> >  
> >  static void __init selftest(void)
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index 3b53c73580c5..432b5a2d1e90 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -1733,6 +1733,42 @@ char *netdev_bits(char *buf, char *end, const void 
> > *addr,
> > return special_hex_number(buf, end, num, size);
> >  }
> >  
> > +static noinline_for_stack
> > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > +   struct printf_spec spec, const char *fmt)
> > +{
> > +   char output[sizeof("1234 little-endian (0x01234567)")];
> 
> 1234 -> ABCD ? (Or XY12 to be closer to the reality)

I count in numbers... albeit the hexadecimal number there starts from zero.

I guess both would work though.

0123 would be consistent.

-- 
Regards,

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

Re: [PATCH v7 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

Hi Andy,

On Mon, Feb 15, 2021 at 03:34:04PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 15, 2021 at 01:40:29PM +0200, Sakari Ailus wrote:
> > Now that we can print FourCC codes directly using printk, make use of the
> > feature in V4L2 core.
> 
> Reviewed-by: Andy Shevchenko 
> See also below.

Thanks for the review, and the tag!

> 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++-
> >  1 file changed, 21 insertions(+), 64 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 31d1342e61e8..31662c3a8c9e 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool 
> > write_only)
> >  {
> > const struct v4l2_fmtdesc *p = arg;
> >  
> > -   pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, 
> > mbus_code=0x%04x, description='%.*s'\n",
> > +   pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, 
> > mbus_code=0x%04x, description='%.*s'\n",
> > p->index, prt_names(p->type, v4l2_type_names),
> > -   p->flags, (p->pixelformat & 0xff),
> > -   (p->pixelformat >>  8) & 0xff,
> > -   (p->pixelformat >> 16) & 0xff,
> > -   (p->pixelformat >> 24) & 0xff,
> > -   p->mbus_code,
> > +   p->flags, &p->pixelformat, p->mbus_code,
> > (int)sizeof(p->description), p->description);
> >  }
> >  
> > @@ -293,12 +289,8 @@ static void v4l_print_format(const void *arg, bool 
> > write_only)
> > case V4L2_BUF_TYPE_VIDEO_CAPTURE:
> > case V4L2_BUF_TYPE_VIDEO_OUTPUT:
> > pix = &p->fmt.pix;
> > -   pr_cont(", width=%u, height=%u, pixelformat=%c%c%c%c, field=%s, 
> > bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, 
> > quantization=%u, xfer_func=%u\n",
> > -   pix->width, pix->height,
> > -   (pix->pixelformat & 0xff),
> > -   (pix->pixelformat >>  8) & 0xff,
> > -   (pix->pixelformat >> 16) & 0xff,
> > -   (pix->pixelformat >> 24) & 0xff,
> > +   pr_cont(", width=%u, height=%u, pixelformat=%p4cc, field=%s, 
> > bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, 
> > quantization=%u, xfer_func=%u\n",
> > +   pix->width, pix->height, &pix->pixelformat,
> > prt_names(pix->field, v4l2_field_names),
> > pix->bytesperline, pix->sizeimage,
> > pix->colorspace, pix->flags, pix->ycbcr_enc,
> > @@ -307,12 +299,8 @@ static void v4l_print_format(const void *arg, bool 
> > write_only)
> > case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> > case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> > mp = &p->fmt.pix_mp;
> > -   pr_cont(", width=%u, height=%u, format=%c%c%c%c, field=%s, 
> > colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, 
> > xfer_func=%u\n",
> > -   mp->width, mp->height,
> > -   (mp->pixelformat & 0xff),
> > -   (mp->pixelformat >>  8) & 0xff,
> > -   (mp->pixelformat >> 16) & 0xff,
> > -   (mp->pixelformat >> 24) & 0xff,
> > +   pr_cont(", width=%u, height=%u, format=%p4cc, field=%s, 
> > colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, 
> > xfer_func=%u\n",
> > +   mp->width, mp->height, &mp->pixelformat,
> > prt_names(mp->field, v4l2_field_names),
> > mp->colorspace, mp->num_planes, mp->flags,
> > mp->ycbcr_enc, mp->quantization, mp->xfer_func);
> > @@ -337,13 +325,9 @@ static void v4l_print_format(const void *arg, bool 
> > write_only)
> > case V4L2_BUF_TYPE_VBI_CAPTURE:
> > case V4L2_BUF_TYPE_VBI_OUTPUT:
> > vbi = &p->fmt.vbi;
> > -   pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, 
> > sample_format=%c%c%c%c, start=%u,%u, count=%u,%u\n",
> > +   pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, 
> > sample_format=%p4cc, start=%u,%u, count=%u,%u\n",
> > vbi->sampling_rate, vbi->offset,
> > -   vbi->samples_per_line,
> > -   (vbi->sample_format & 0xff),
> > -   (vbi->sample_format >>  8) & 0xff,
> > -   (vbi->sample_format >> 16) & 0xff,
> > -   (vbi->sample_format >> 24) & 0xff,
> > +   vbi->samples_per_line, &vbi->sample_format,
> > vbi->start[0], vbi->start[1],
> > vbi->count[0], vbi->count[1]);
> > break;
> > @@ -360,21 +344,13 @@ static void v4l_print_format(const void *arg, bool 
> > write_only)
> > case V4L2_BUF_TYPE_SDR_CAPTURE:
> > case V4L2_BUF_TYPE_SDR_OUTPUT:
> > sdr = &p->fmt.s

Re: ITE66121 HDMI driver

2021-02-15 Thread Paul Cercueil





Le lun. 15 févr. 2021 à 14:39, Neil Armstrong 
 a écrit :

On 15/02/2021 13:01, Paul Cercueil wrote:



 Le lun. 15 févr. 2021 à 10:05, Neil Armstrong 
 a écrit :

 Hi,

 On 14/02/2021 00:54, Paul Cercueil wrote:

  Hi Phong and Neil,

  I see you sent a patchset to support the ITE66121 HDMI 
transmitter, last version being the V2 back in March 2020.


  Do you still plan to mainline it?


 Yes, we still plan to mainline it.


 Ok, great!



  I do have a device with a ITE66121 chip, so I can help to clean 
the driver and have it mainlined. But right now I cannot get the 
driver to work, while the chip is properly detected and correct 
DDC data is read,, my PC monitor does not detect any signal.


 Having DDC read working is a good point...

 Did you check the DPI data setup ? the chip supports dual data 
rate input, and the last version only supported it via a DT 
property.


 If "dual data rate" means two pixels per pixclock tick, then my SoC 
does not support it. I did try both modes though.


 The other thing is that my SoC has no VDE/HDE pins, so (according 
to the manual) I have to have the chip recreate these signals from 
videomode information. Which I did, and I get the "video stable" 
status bit, but I still cannot get anything on screen.


What is the mode you're trying to achieve ?


For now 720p in single data rate, RGB888, with VSYNC/HSYNC available 
but no DE.


let me send a v3 with all the comments from v2 fixed and re-start a 
discussion from this patchset.


Alright, please Cc me for the V3.

Cheers,
-Paul


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

Re: [PATCH v7 3/3] drm: Switch to %p4cc format modifier

Hi Andy,

On Mon, Feb 15, 2021 at 03:41:14PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 15, 2021 at 01:40:30PM +0200, Sakari Ailus wrote:
> > Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
> > large number of temporary variables at the same time.
> 
> What a nice clean up!
> Reviewed-by: Andy Shevchenko 

Thanks!

> after addressing nit-picks below.
> 
> Side note (no need to implement esp. right now): it seems often it's coupled
> with modifier, would be nice to have them together that %p4ccM or so can do it
> in one go.

...

> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 03262472059c..5cf45aa6eedc 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -30,11 +30,6 @@
> >  #include 
> >  #include 
> >  
> > -static char printable_char(int c)
> > -{
> > -   return isascii(c) && isprint(c) ? c : '?';
> > -}
> 
> If it goes as an ABI than your dot is incompatible with this and '?' should be
> used instead in the patch 1. And I bend towards suggested '?' rather than '.'.
> 
> Also it means that you probably would need different specifiers for full and
> short formats.

I thought of that, but then the resulting string would be indeed different
and comparing short and long formats would be harder. Remember this is for
debug prints. If the format is too long, then it should be made shorter,
but during the earlier review rounds people have expressed interest in
having this information there.

"?" can be expanded by the shell whereas "." is not. If DRM folks think we
should go back to "?" I'm fine with that. Also note that there's something
wrong with the fourcc code to begin with if it's got either "." or "?".

-- 
Regards,

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

Re: [PATCH v7 3/3] drm: Switch to %p4cc format modifier

On Mon, Feb 15, 2021 at 01:40:30PM +0200, Sakari Ailus wrote:
> Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
> large number of temporary variables at the same time.

What a nice clean up!
Reviewed-by: Andy Shevchenko 
after addressing nit-picks below.

Side note (no need to implement esp. right now): it seems often it's coupled
with modifier, would be nice to have them together that %p4ccM or so can do it
in one go.

> Signed-off-by: Sakari Ailus 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  5 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  5 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  5 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  5 ++--
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  5 ++--
>  .../arm/display/komeda/komeda_format_caps.h   | 11 
>  .../arm/display/komeda/komeda_framebuffer.c   |  4 +--
>  .../gpu/drm/arm/display/komeda/komeda_plane.c |  6 ++---
>  drivers/gpu/drm/arm/malidp_mw.c   |  7 ++
>  drivers/gpu/drm/drm_atomic.c  |  8 ++
>  drivers/gpu/drm/drm_crtc.c|  7 ++
>  drivers/gpu/drm/drm_fourcc.c  | 25 ---
>  drivers/gpu/drm/drm_framebuffer.c | 11 +++-
>  drivers/gpu/drm/drm_mipi_dbi.c|  5 ++--
>  drivers/gpu/drm/drm_plane.c   |  8 ++
>  .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c   |  5 ++--
>  drivers/gpu/drm/i915/display/intel_display.c  | 14 +++
>  .../drm/i915/display/intel_display_debugfs.c  | 19 ++
>  drivers/gpu/drm/i915/display/intel_sprite.c   |  6 ++---
>  drivers/gpu/drm/mcde/mcde_display.c   |  6 ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  6 ++---
>  drivers/gpu/drm/nouveau/nouveau_display.c |  9 +++
>  drivers/gpu/drm/radeon/atombios_crtc.c| 10 +++-
>  drivers/gpu/drm/sun4i/sun4i_backend.c |  6 ++---
>  drivers/gpu/drm/vkms/vkms_writeback.c |  7 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 15 +--
>  include/drm/drm_fourcc.h  |  1 -
>  27 files changed, 64 insertions(+), 157 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 7944781e1086..ea825b4f8ee8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1862,7 +1862,6 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
>   u32 tmp, viewport_w, viewport_h;
>   int r;
>   bool bypass_lut = false;
> - struct drm_format_name_buf format_name;
>  
>   /* no fb bound */
>   if (!atomic && !crtc->primary->fb) {
> @@ -1981,8 +1980,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
>  #endif
>   break;
>   default:
> - DRM_ERROR("Unsupported screen format %s\n",
> -   drm_get_format_name(target_fb->format->format, 
> &format_name));
> + DRM_ERROR("Unsupported screen format %p4cc\n",
> +   &target_fb->format->format);
>   return -EINVAL;
>   }
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 1b6ff0470011..a360a6dec198 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1904,7 +1904,6 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
>   u32 tmp, viewport_w, viewport_h;
>   int r;
>   bool bypass_lut = false;
> - struct drm_format_name_buf format_name;
>  
>   /* no fb bound */
>   if (!atomic && !crtc->primary->fb) {
> @@ -2023,8 +2022,8 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
>  #endif
>   break;
>   default:
> - DRM_ERROR("Unsupported screen format %s\n",
> -   drm_get_format_name(target_fb->format->format, 
> &format_name));
> + DRM_ERROR("Unsupported screen format %p4cc\n",
> +   &target_fb->format->format);
>   return -EINVAL;
>   }
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index 83a88385b762..ef124ac853b6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> @@ -1820,7 +1820,6 @@ static int dce_v6_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
>   u32 viewport_w, viewport_h;
>   int r;
>   bool bypass_lut = false;
> - struct drm_format_name_buf format_name;
>  
>   /* no fb bound */
>   if (!atomic && !crtc->primary->fb) {
> @@ -1929,8 +1928,8 @@ static int dce_v6_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
>  #endif
>   break;
>   default:
> - DRM_ERROR("Unsupported screen format %s\n",
> -   drm_get_format_name(target_fb->format->format, 
> &format_name));
> +

Re: [PATCH v2 1/2] drm/msm: Call shutdown conditionally

2021-02-15 Thread Fabio Estevam

Gentle ping...

On Fri, Jan 29, 2021 at 8:09 AM Fabio Estevam  wrote:
>
> Hi Rob,
>
> Any comments on this series, please?
>
> On Tue, Jan 19, 2021 at 8:15 PM Fabio Estevam  wrote:
> >
> > Issuing a 'reboot' command in i.MX5 leads to the following flow:
> >
> > [   24.557742] [] (msm_atomic_commit_tail) from []
> > (commit_tail+0xa4/0x1b0)
> > [   24.566349] [] (commit_tail) from []
> > (drm_atomic_helper_commit+0x154/0x188)
> > [   24.575193] [] (drm_atomic_helper_commit) from
> > [] (drm_atomic_helper_disable_all+0x154/0x1c0)
> > [   24.585599] [] (drm_atomic_helper_disable_all) from
> > [] (drm_atomic_helper_shutdown+0x94/0x12c)
> > [   24.596094] [] (drm_atomic_helper_shutdown) from
> >
> > In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
> > of the Qualcomm display controllers), causing a NULL pointer
> > dereference in msm_atomic_commit_tail():
> >
> > [   24.268964] 8<--- cut here ---
> > [   24.274602] Unable to handle kernel NULL pointer dereference at
> > virtual address 
> > [   24.283434] pgd = (ptrval)
> > [   24.286387] [] *pgd=ca212831
> > [   24.290788] Internal error: Oops: 17 [#1] SMP ARM
> > [   24.295609] Modules linked in:
> > [   24.298777] CPU: 0 PID: 197 Comm: init Not tainted 
> > 5.11.0-rc2-next-20210111 #333
> > [   24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
> > [   24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
> > [   24.317743] LR is at commit_tail+0xa4/0x1b0
> >
> > Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
> >
> > Cc: 
> > Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display 
> > platform_driver")
> > Suggested-by: Rob Clark 
> > Signed-off-by: Fabio Estevam 
> > ---
> > Changes since v1:
> > - Explain in the commit log that the problem happens after a 'reboot' 
> > command.
> >
> >  drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index 108c405e03dd..c082b72b9e3b 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device 
> > *pdev)
> >  {
> > struct drm_device *drm = platform_get_drvdata(pdev);
> >
> > -   drm_atomic_helper_shutdown(drm);
> > +   if (get_mdp_ver(pdev))
> > +   drm_atomic_helper_shutdown(drm);
> >  }
> >
> >  static const struct of_device_id dt_match[] = {
> > --
> > 2.25.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: ITE66121 HDMI driver

On 15/02/2021 13:01, Paul Cercueil wrote:
> 
> 
> Le lun. 15 févr. 2021 à 10:05, Neil Armstrong  a 
> écrit :
>> Hi,
>>
>> On 14/02/2021 00:54, Paul Cercueil wrote:
>>>  Hi Phong and Neil,
>>>
>>>  I see you sent a patchset to support the ITE66121 HDMI transmitter, last 
>>> version being the V2 back in March 2020.
>>>
>>>  Do you still plan to mainline it?
>>
>> Yes, we still plan to mainline it.
> 
> Ok, great!
> 
>>>
>>>  I do have a device with a ITE66121 chip, so I can help to clean the driver 
>>> and have it mainlined. But right now I cannot get the driver to work, while 
>>> the chip is properly detected and correct DDC data is read,, my PC monitor 
>>> does not detect any signal.
>>
>> Having DDC read working is a good point...
>>
>> Did you check the DPI data setup ? the chip supports dual data rate input, 
>> and the last version only supported it via a DT property.
> 
> If "dual data rate" means two pixels per pixclock tick, then my SoC does not 
> support it. I did try both modes though.
> 
> The other thing is that my SoC has no VDE/HDE pins, so (according to the 
> manual) I have to have the chip recreate these signals from videomode 
> information. Which I did, and I get the "video stable" status bit, but I 
> still cannot get anything on screen.

What is the mode you're trying to achieve ?

let me send a v3 with all the comments from v2 fixed and re-start a discussion 
from this patchset.

Neil

> 
> Cheers,
> -Paul
> 
> 

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

Re: [PATCH v7 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

On Mon, Feb 15, 2021 at 01:40:29PM +0200, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.

Reviewed-by: Andy Shevchenko 
See also below.

> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++-
>  1 file changed, 21 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 31d1342e61e8..31662c3a8c9e 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool 
> write_only)
>  {
>   const struct v4l2_fmtdesc *p = arg;
>  
> - pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, 
> mbus_code=0x%04x, description='%.*s'\n",
> + pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, 
> mbus_code=0x%04x, description='%.*s'\n",
>   p->index, prt_names(p->type, v4l2_type_names),
> - p->flags, (p->pixelformat & 0xff),
> - (p->pixelformat >>  8) & 0xff,
> - (p->pixelformat >> 16) & 0xff,
> - (p->pixelformat >> 24) & 0xff,
> - p->mbus_code,
> + p->flags, &p->pixelformat, p->mbus_code,
>   (int)sizeof(p->description), p->description);
>  }
>  
> @@ -293,12 +289,8 @@ static void v4l_print_format(const void *arg, bool 
> write_only)
>   case V4L2_BUF_TYPE_VIDEO_CAPTURE:
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT:
>   pix = &p->fmt.pix;
> - pr_cont(", width=%u, height=%u, pixelformat=%c%c%c%c, field=%s, 
> bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, 
> quantization=%u, xfer_func=%u\n",
> - pix->width, pix->height,
> - (pix->pixelformat & 0xff),
> - (pix->pixelformat >>  8) & 0xff,
> - (pix->pixelformat >> 16) & 0xff,
> - (pix->pixelformat >> 24) & 0xff,
> + pr_cont(", width=%u, height=%u, pixelformat=%p4cc, field=%s, 
> bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, 
> quantization=%u, xfer_func=%u\n",
> + pix->width, pix->height, &pix->pixelformat,
>   prt_names(pix->field, v4l2_field_names),
>   pix->bytesperline, pix->sizeimage,
>   pix->colorspace, pix->flags, pix->ycbcr_enc,
> @@ -307,12 +299,8 @@ static void v4l_print_format(const void *arg, bool 
> write_only)
>   case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>   mp = &p->fmt.pix_mp;
> - pr_cont(", width=%u, height=%u, format=%c%c%c%c, field=%s, 
> colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, 
> xfer_func=%u\n",
> - mp->width, mp->height,
> - (mp->pixelformat & 0xff),
> - (mp->pixelformat >>  8) & 0xff,
> - (mp->pixelformat >> 16) & 0xff,
> - (mp->pixelformat >> 24) & 0xff,
> + pr_cont(", width=%u, height=%u, format=%p4cc, field=%s, 
> colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, 
> xfer_func=%u\n",
> + mp->width, mp->height, &mp->pixelformat,
>   prt_names(mp->field, v4l2_field_names),
>   mp->colorspace, mp->num_planes, mp->flags,
>   mp->ycbcr_enc, mp->quantization, mp->xfer_func);
> @@ -337,13 +325,9 @@ static void v4l_print_format(const void *arg, bool 
> write_only)
>   case V4L2_BUF_TYPE_VBI_CAPTURE:
>   case V4L2_BUF_TYPE_VBI_OUTPUT:
>   vbi = &p->fmt.vbi;
> - pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, 
> sample_format=%c%c%c%c, start=%u,%u, count=%u,%u\n",
> + pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, 
> sample_format=%p4cc, start=%u,%u, count=%u,%u\n",
>   vbi->sampling_rate, vbi->offset,
> - vbi->samples_per_line,
> - (vbi->sample_format & 0xff),
> - (vbi->sample_format >>  8) & 0xff,
> - (vbi->sample_format >> 16) & 0xff,
> - (vbi->sample_format >> 24) & 0xff,
> + vbi->samples_per_line, &vbi->sample_format,
>   vbi->start[0], vbi->start[1],
>   vbi->count[0], vbi->count[1]);
>   break;
> @@ -360,21 +344,13 @@ static void v4l_print_format(const void *arg, bool 
> write_only)
>   case V4L2_BUF_TYPE_SDR_CAPTURE:
>   case V4L2_BUF_TYPE_SDR_OUTPUT:
>   sdr = &p->fmt.sdr;
> - pr_cont(", pixelformat=%c%c%c%c\n",
> - (sdr->pixelformat >>  0) & 0xff,
> - (sdr->pixelformat >>  8) & 0xff,
> - (sdr-

Re: [PATCH v7 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

On Mon, Feb 15, 2021 at 01:40:28PM +0200, Sakari Ailus wrote:
> Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by fourccs. The fourcc encoding is the same for both
> so the same implementation can be used.

This version I almost like, feel free to add
Reviewed-by: From: Andy Shevchenko 
after considering addressing below nit-picks.

> Suggested-by: Mauro Carvalho Chehab 
> Signed-off-by: Sakari Ailus 
> Reviewed-by: Petr Mladek 
> Reviewed-by: Sergey Senozhatsky 
> ---
>  Documentation/core-api/printk-formats.rst | 16 ++
>  lib/test_printf.c | 17 ++
>  lib/vsprintf.c| 39 +++
>  scripts/checkpatch.pl |  6 ++--
>  4 files changed, 76 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/core-api/printk-formats.rst 
> b/Documentation/core-api/printk-formats.rst
> index 160e710d992f..da2aa065dc42 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -567,6 +567,22 @@ For printing netdev_features_t.
>  
>  Passed by reference.
>  
> +V4L2 and DRM FourCC code (pixel format)
> +---
> +
> +::
> +
> + %p4cc
> +
> +Print a FourCC code used by V4L2 or DRM, including format endianness and
> +its numerical value as hexadecimal.
> +
> +Passed by reference.
> +
> +Examples::
> +
> + %p4cc   BG12 little-endian (0x32314742)

No examples with spaces / non-printable / non-ascii characters

> +
>  Thanks
>  ==
>  
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 7d60f24240a4..9848510a2786 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> @@ -647,6 +647,22 @@ static void __init fwnode_pointer(void)
>   software_node_unregister_nodes(softnodes);
>  }
>  
> +static void __init fourcc_pointer(void)
> +{
> + struct {
> + u32 code;
> + char *str;
> + } const try[] = {
> + { 0x3231564e, "NV12 little-endian (0x3231564e)", },
> + { 0xb231564e, "NV12 big-endian (0xb231564e)", },
> + { 0x10111213, " little-endian (0x10111213)", },
> + };
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(try); i++)
> + test(try[i].str, "%p4cc", &try[i].code);
> +}
> +
>  static void __init
>  errptr(void)
>  {
> @@ -692,6 +708,7 @@ test_pointer(void)
>   flags();
>   errptr();
>   fwnode_pointer();
> + fourcc_pointer();
>  }
>  
>  static void __init selftest(void)
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 3b53c73580c5..432b5a2d1e90 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1733,6 +1733,42 @@ char *netdev_bits(char *buf, char *end, const void 
> *addr,
>   return special_hex_number(buf, end, num, size);
>  }
>  
> +static noinline_for_stack
> +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> + struct printf_spec spec, const char *fmt)
> +{
> + char output[sizeof("1234 little-endian (0x01234567)")];

1234 -> ABCD ? (Or XY12 to be closer to the reality)

> + char *p = output;
> + unsigned int i;
> + u32 val;
> +
> + if (fmt[1] != 'c' || fmt[2] != 'c')
> + return error_string(buf, end, "(%p4?)", spec);
> +
> + if (check_pointer(&buf, end, fourcc, spec))
> + return buf;
> +
> + val = *fourcc & ~BIT(31);
> +
> + for (i = 0; i < sizeof(*fourcc); i++) {
> + unsigned char c = val >> (i * 8);
> +
> + /* Print non-control ASCII characters as-is, dot otherwise */
> + *p++ = isascii(c) && isprint(c) ? c : '.';
> + }
> +
> + strcpy(p, *fourcc & BIT(31) ? " big-endian" : " little-endian");
> + p += strlen(p);
> +
> + *p++ = ' ';
> + *p++ = '(';
> + p = special_hex_number(p, output + sizeof(output) - 2, *fourcc, 
> sizeof(u32));
> + *p++ = ')';
> + *p = '\0';
> +
> + return string(buf, end, output, spec);
> +}
> +
>  static noinline_for_stack
>  char *address_val(char *buf, char *end, const void *addr,
> struct printf_spec spec, const char *fmt)
> @@ -2162,6 +2198,7 @@ char *fwnode_string(char *buf, char *end, struct 
> fwnode_handle *fwnode,
>   *   correctness of the format string and va_list arguments.
>   * - 'K' For a kernel pointer that should be hidden from unprivileged users
>   * - 'NF' For a netdev_features_t
> + * - '4cc' V4L2 or DRM FourCC code, with endianness and raw numerical value.
>   * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
>   *a certain separator (' ' by default):
>   *  C colon
> @@ -2259,6 +2296,8 @@ char *pointer(const char *fmt, char *buf, char *end, 
> void *ptr,
>   return restricted_pointer(buf, end, ptr, spec);
>   case 'N':
>   return netdev_bits(buf, end, ptr, spec, fmt);
> + case '4':
> + return fourcc_string(buf, end, p

Re: [PATCH 0/5] drm/omap: hdmi: improve hdmi4 CEC, add CEC for hdmi5

2021-02-15 Thread H . Nikolaus Schaller

Hi,

> Am 11.02.2021 um 11:36 schrieb Hans Verkuil :
> 
> This series improves the drm_bridge support for CEC by introducing two
> new bridge ops in the first patch, and using those in the second patch.
> 
> This makes it possible to call cec_s_conn_info() and set
> CEC_CAP_CONNECTOR_INFO for the CEC adapter, so userspace can associate
> the CEC adapter with the corresponding DRM connector.
> 
> The third patch simplifies CEC physical address handling by using the
> cec_s_phys_addr_from_edid helper function that didn't exist when this
> code was originally written.
> 
> The fourth patch adds CEC support to the OMAP5 driver and the last
> patch adds the missing cec clock to the dra7 and omap5 device tree.
> 
> Tested with a Pandaboard and a Beagle X15 board.

Tested to have no adverse effect on Pyra (omap5432).
But I have not tested if CEC itself is working.

> 
> Regards,
> 
>   Hans
> 
> Hans Verkuil (5):
>  drm: drm_bridge: add cec_init/exit bridge ops
>  drm/omap: hdmi4: switch to the cec bridge ops
>  drm/omap: hdmi4: simplify CEC Phys Addr handling
>  drm/omap: hdmi5: add CEC support
>  ARM: dts: dra7/omap5: add cec clock
> 
> arch/arm/boot/dts/dra7.dtsi  |   5 +-
> arch/arm/boot/dts/omap5.dtsi |   5 +-
> drivers/gpu/drm/drm_bridge_connector.c   |  23 +++
> drivers/gpu/drm/omapdrm/dss/Kconfig  |   8 +
> drivers/gpu/drm/omapdrm/dss/Makefile |   1 +

Merging with patch series by Tomi Valkeinen and Sebastian Reichel
for omapdrm/dsi will need to move the Kconfig and Makefile one level
up.

> drivers/gpu/drm/omapdrm/dss/hdmi.h   |   1 +
> drivers/gpu/drm/omapdrm/dss/hdmi4.c  |  41 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c  |  12 +-
> drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h  |  12 +-
> drivers/gpu/drm/omapdrm/dss/hdmi5.c  |  63 +--
> drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c  | 201 +++
> drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h  |  42 +
> drivers/gpu/drm/omapdrm/dss/hdmi5_core.c |  28 +++-
> drivers/gpu/drm/omapdrm/dss/hdmi5_core.h |  33 +++-
> include/drm/drm_bridge.h |  31 
> 15 files changed, 453 insertions(+), 53 deletions(-)
> create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c
> create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h
> 
> -- 
> 2.30.0
> 

BR and thanks,
Nikolaus Schaller

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

Re: [Intel-gfx] [PATCH] drm/i915/gem: Add a check for object size for corner cases

2021-02-15 Thread Chris Wilson

Quoting Ram Moon, AnandX (2021-02-15 12:29:17)
> Hi Chris,
> 
> -Original Message-
> From: dri-devel  On Behalf Of Chris 
> Wilson
> Sent: Wednesday, February 10, 2021 4:15 PM
> To: Ram Moon, AnandX ; Jani Nikula 
> ; Auld, Matthew ; 
> Surendrakumar Upadhyay, TejaskumarX 
> ; Ursulin, Tvrtko 
> ; dri-devel@lists.freedesktop.org; 
> intel-...@lists.freedesktop.org
> Cc: Ram Moon, AnandX 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gem: Add a check for object size 
> for corner cases
> 
> Quoting Anand Moon (2021-02-10 07:59:29)
> > Add check for object size to return appropriate error -E2BIG or 
> > -EINVAL to avoid WARM_ON and successful return for some testcase.
> 
> No. You miss the point of having those warnings. We need to inspect the code 
> to remove the last remaining "int pagenum", and then we can remove the 
> GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX). These are not emitted for users, 
> only for us to motivate us into finally fixing the code.
> -Chris
> 
> Yes, I got your point these check are meant to catch up integer overflow.
> 
> I have check with the IGT testcase case  _gem_create_ and _gem_userptr_blits_ 
>  
> which fails pass size *-1ull << 32*  left shift and *0~* which leads to 
> integer overflow 
> ie  _negative_ size passed to create  i915_gem_create via ioctl  this leads 
> to GM_WARN_ON. 
> 
> Can we drop these testcase so that we don't break the kernel ?

The kernel rejects the ioctl with the expected errno. We leave a warning
purely for the benefit of CI, only when compiled for debugging and not by
default, so that we have a persistent reminder to do the code review.
What's broken?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [Intel-gfx] [PATCH] drm/i915/gem: Add a check for object size for corner cases

2021-02-15 Thread Ram Moon, AnandX

Hi Chris,

-Original Message-
From: dri-devel  On Behalf Of Chris 
Wilson
Sent: Wednesday, February 10, 2021 4:15 PM
To: Ram Moon, AnandX ; Jani Nikula 
; Auld, Matthew ; 
Surendrakumar Upadhyay, TejaskumarX 
; Ursulin, Tvrtko 
; dri-devel@lists.freedesktop.org; 
intel-...@lists.freedesktop.org
Cc: Ram Moon, AnandX 
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gem: Add a check for object size for 
corner cases

Quoting Anand Moon (2021-02-10 07:59:29)
> Add check for object size to return appropriate error -E2BIG or 
> -EINVAL to avoid WARM_ON and successful return for some testcase.

No. You miss the point of having those warnings. We need to inspect the code to 
remove the last remaining "int pagenum", and then we can remove the 
GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX). These are not emitted for users, 
only for us to motivate us into finally fixing the code.
-Chris

Yes, I got your point these check are meant to catch up integer overflow.

I have check with the IGT testcase case  _gem_create_ and _gem_userptr_blits_  
which fails pass size *-1ull << 32*  left shift and *0~* which leads to integer 
overflow 
ie  _negative_ size passed to create  i915_gem_create via ioctl  this leads to 
GM_WARN_ON. 

Can we drop these testcase so that we don't break the kernel ?

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

Re: DMA-buf and uncached system memory


Am 15.02.21 um 13:16 schrieb Lucas Stach:

[SNIP]

Userspace components can then of course tell the exporter what the
importer needs, but validation if that stuff is correct and doesn't
crash the system must happen in the kernel.

What exactly do you mean by "scanout requires non-coherent memory"?
Does the scanout requestor always set the no-snoop PCI flag, so you get
garbage if some writes to memory are still stuck in the caches, or is
it some other requirement?

Snooping the CPU caches introduces some extra latency, so what can
happen is that the response to the PCIe read comes to late for the
scanout. The result is an underflow and flickering whenever something is
in the cache which needs to be flushed first.

Okay, that confirms my theory on why this is needed. So things don't
totally explode if you don't do it, but to in order to guarantee access
latency you need to take the no-snoop path, which means your device
effectively gets dma-noncoherent.


Exactly. My big question at the moment is if this is something AMD 
specific or do we have the same issue on other devices as well?



On the other hand when the don't snoop the CPU caches we at least get
garbage/stale data on the screen. That wouldn't be that worse, but the
big problem is that we have also seen machine check exceptions when
don't snoop and the cache is dirty.

If you attach to the dma-buf with a struct device which is non-coherent
it's the exporters job to flush any dirty caches. Unfortunately the DRM
caching of the dma-buf attachments in the DRM framework will get a bit
in the way here, so a DRM specific flush might be be needed. :/ Maybe
moving the whole buffer to uncached sysmem location on first attach of
a non-coherent importer would be enough?


Could work in theory, but problem is that for this to do I have to tear 
down all CPU mappings and attachments of other devices.


Apart from the problem that we don't have the infrastructure for that we 
don't know at import time that a buffer might be used for scan out. I 
would need to re-import it during fb creation or something like this.


Our current concept for AMD GPUs is rather that we try to use uncached 
memory as much as possible. So for the specific use case just checking 
if the exporter is AMDGPU and has the flag set should be enough for not.



So this should better be coherent or you can crash the box. ARM seems to
be really susceptible for this, x86 is fortunately much more graceful
and I'm not sure about other architectures.

ARM really dislikes pagetable setups with different attributes pointing
to the same physical page, however you should be fine as long as all
cached aliases are properly flushed from the cache before access via a
different alias.


Yeah, can totally confirm that and had to learn it the hard way.

Regards,
Christian.



Regards,
Lucas



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

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for Chipone ICN6211

2021-02-15 Thread Laurent Pinchart

Hi Jagan,

Thank you for the patch.

On Sun, Feb 14, 2021 at 11:22:10PM +0530, Jagan Teki wrote:
> ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.
> 
> It has a flexible configuration of MIPI DSI signal input and
> produce RGB565, RGB666, RGB888 output format.
> 
> Add dt-bingings for it.
> 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - updated to new dt-bindings style
> 
>  .../display/bridge/chipone,icn6211.yaml   | 90 +++
>  1 file changed, 90 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml 
> b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> new file mode 100644
> index ..13764f13fe46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge
> +
> +maintainers:
> +  - Jagan Teki 
> +
> +description: |
> +  ICN6211 is MIPI-DSI to RGB Convertor bridge from chipone.
> +
> +  It has a flexible configuration of MIPI DSI signal input and
> +  produce RGB565, RGB666, RGB888 output format.

How does one select between the output formats ? Should the output
connection option be described in the device tree ?

> +
> +properties:
> +  compatible:
> +enum:
> +  - chipone,icn6211
> +
> +  reg:
> +maxItems: 1
> +description: virtual channel number of a DSI peripheral
> +
> +  reset-gpios:
> +description: GPIO connected for the reset pin
> +
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Video port for MIPI DSI input
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Video port for MIPI DPI output (panel or connector).
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - reset-gpios
> +  - ports

How about regulators ?

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +dsi {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  bridge@0 {
> +compatible = "chipone,icn6211";
> +reg = <0>;
> +reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  bridge_in: port@0 {

You can drop this label.

> +reg = <0>;
> +
> +bridge_out_dsi: endpoint {

This label should be bridge_in_dsi.

> +  remote-endpoint = <&dsi_out_bridge>;
> +};
> +  };
> +
> +  bridge_out: port@1 {

You can drop this label too.

> +reg = <1>;
> +
> +bridge_out_panel: endpoint {
> +  remote-endpoint = <&panel_out_bridge>;
> +};
> +  };
> +};
> +  };
> +};

-- 
Regards,

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

Re: [PATCH v3 2/2] drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB bridge

2021-02-15 Thread Robert Foss

Hey Jagan,

Thanks for submitting this driver, it looks really nice, but
checkpatch.pl has some minor issues with it. Again I'd suggest
deferring to the convertor->converter spelling change even though both
seem to be perfectly valid English.

With the below fixed, feel free to add my r-b.
Reviewed-by: Robert Foss 

On Sun, 14 Feb 2021 at 18:55, Jagan Teki  wrote:
>
> ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.

WARNING: 'Convertor' may be misspelled - perhaps 'Converter'?
#6:
ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.
   ^


>
> It has a flexible configuration of MIPI DSI signal input and
> produce RGB565, RGB666, RGB888 output format.
>
> Add bridge driver for it.

Currently this driver only supports MIPI_DSI_FMT_RGB888, maybe this
should be noted in the commit msg.

>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - updated the driver to inline with new drm bridge style
>
>  MAINTAINERS  |   6 +
>  drivers/gpu/drm/bridge/Kconfig   |  11 ++
>  drivers/gpu/drm/bridge/Makefile  |   1 +
>  drivers/gpu/drm/bridge/chipone-icn6211.c | 222 +++
>  4 files changed, 240 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/chipone-icn6211.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9d241b832aae..4f1084aae50d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5529,6 +5529,12 @@ S:   Maintained
>  F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
>  F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
>
> +DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTOR BRIDGE

WARNING: 'CONVERTOR' may be misspelled - perhaps 'CONVERTER'?
#30: FILE: MAINTAINERS:5533:
+DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTOR BRIDGE
^


> +M: Jagan Teki 
> +S: Maintained
> +F: drivers/gpu/drm/bridge/chipone-icn6211.c
> +F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml

WARNING: Misordered MAINTAINERS entry - list file patterns in alphabetic order
#34: FILE: MAINTAINERS:5537:
+F: drivers/gpu/drm/bridge/chipone-icn6211.c
+F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml


> +
>  DRM DRIVER FOR FARADAY TVE200 TV ENCODER
>  M: Linus Walleij 
>  S: Maintained
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e4110d6ca7b3..49d1565b7f25 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -27,6 +27,17 @@ config DRM_CDNS_DSI
>   Support Cadence DPI to DSI bridge. This is an internal
>   bridge and is meant to be directly embedded in a SoC.
>
> +config DRM_CHIPONE_ICN6211
> +   tristate "Chipone ICN6211 MIPI-DSI/RGB Convertor bridge"

WARNING: 'Convertor' may be misspelled - perhaps 'Converter'?
#48: FILE: drivers/gpu/drm/bridge/Kconfig:31:
+   tristate "Chipone ICN6211 MIPI-DSI/RGB Convertor bridge"
   ^


> +   depends on OF
> +   select DRM_MIPI_DSI
> +   select DRM_PANEL_BRIDGE
> +   help
> + ICN6211 is MIPI-DSI/RGB Convertor bridge from chipone.

WARNING: 'Convertor' may be misspelled - perhaps 'Converter'?
#53: FILE: drivers/gpu/drm/bridge/Kconfig:36:
+ ICN6211 is MIPI-DSI/RGB Convertor bridge from chipone.
  ^

> +
> + It has a flexible configuration of MIPI DSI signal input
> + and produce RGB565, RGB666, RGB888 output format.
> +

WARNING: please write a paragraph that describes the config symbol fully
#47: FILE: drivers/gpu/drm/bridge/Kconfig:30:
+config DRM_CHIPONE_ICN6211


>  config DRM_CHRONTEL_CH7033
> tristate "Chrontel CH7033 Video Encoder"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 86e7acc76f8d..3eb84b638988 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> +obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
>  obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>  obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
>  obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c 
> b/drivers/gpu/drm/bridge/chipone-icn6211.c
> new file mode 100644
> index ..3f478f21a4a5
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
> @@ -0,0 +1,222 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Amarula Solutions(India)

2020-2021?

> + * Author: Jagan Teki 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct chipone {
> +   struct device *dev;
> +   struct drm_bridge bridg

Re: DMA-buf and uncached system memory

2021-02-15 Thread Lucas Stach

Am Montag, dem 15.02.2021 um 13:04 +0100 schrieb Christian König:
> Am 15.02.21 um 12:53 schrieb Lucas Stach:
> > Am Montag, dem 15.02.2021 um 10:34 +0100 schrieb Christian König:
> > > Am 15.02.21 um 10:06 schrieb Simon Ser:
> > > > On Monday, February 15th, 2021 at 9:58 AM, Christian König 
> > > >  wrote:
> > > > 
> > > > > we are currently working an Freesync and direct scan out from system
> > > > > memory on AMD APUs in A+A laptops.
> > > > > 
> > > > > On problem we stumbled over is that our display hardware needs to scan
> > > > > out from uncached system memory and we currently don't have a way to
> > > > > communicate that through DMA-buf.
> > > > > 
> > > > > For our specific use case at hand we are going to implement something
> > > > > driver specific, but the question is should we have something more
> > > > > generic for this?
> > > > > 
> > > > > After all the system memory access pattern is a PCIe extension and as
> > > > > such something generic.
> > > > Intel also needs uncached system memory if I'm not mistaken?
> > > No idea, that's why I'm asking. Could be that this is also interesting
> > > for I+A systems.
> > > 
> > > > Where are the buffers allocated? If GBM, then it needs to allocate 
> > > > memory that
> > > > can be scanned out if the USE_SCANOUT flag is set or if a 
> > > > scanout-capable
> > > > modifier is picked.
> > > > 
> > > > If this is about communicating buffer constraints between different 
> > > > components
> > > > of the stack, there were a few proposals about it. The most recent one 
> > > > is [1].
> > > Well the problem here is on a different level of the stack.
> > > 
> > > See resolution, pitch etc:.. can easily communicated in userspace
> > > without involvement of the kernel. The worst thing which can happen is
> > > that you draw garbage into your own application window.
> > > 
> > > But if you get the caching attributes in the page tables (both CPU as
> > > well as IOMMU, device etc...) wrong then ARM for example has the
> > > tendency to just spontaneously reboot
> > > 
> > > X86 is fortunately a bit more gracefully and you only end up with random
> > > data corruption, but that is only marginally better.
> > > 
> > > So to sum it up that is not something which we can leave in the hands of
> > > userspace.
> > > 
> > > I think that exporters in the DMA-buf framework should have the ability
> > > to tell importers if the system memory snooping is necessary or not.
> > There is already a coarse-grained way to do so: the dma_coherent
> > property in struct device, which you can check at dmabuf attach time.
> > 
> > However it may not be enough for the requirements of a GPU where the
> > engines could differ in their dma coherency requirements. For that you
> > need to either have fake struct devices for the individual engines or
> > come up with a more fine-grained way to communicate those requirements.
> 
> Yeah, that won't work. We need this on a per buffer level.
> 
> > > Userspace components can then of course tell the exporter what the
> > > importer needs, but validation if that stuff is correct and doesn't
> > > crash the system must happen in the kernel.
> > What exactly do you mean by "scanout requires non-coherent memory"?
> > Does the scanout requestor always set the no-snoop PCI flag, so you get
> > garbage if some writes to memory are still stuck in the caches, or is
> > it some other requirement?
> 
> Snooping the CPU caches introduces some extra latency, so what can 
> happen is that the response to the PCIe read comes to late for the 
> scanout. The result is an underflow and flickering whenever something is 
> in the cache which needs to be flushed first.

Okay, that confirms my theory on why this is needed. So things don't
totally explode if you don't do it, but to in order to guarantee access
latency you need to take the no-snoop path, which means your device
effectively gets dma-noncoherent.

> On the other hand when the don't snoop the CPU caches we at least get 
> garbage/stale data on the screen. That wouldn't be that worse, but the 
> big problem is that we have also seen machine check exceptions when 
> don't snoop and the cache is dirty.

If you attach to the dma-buf with a struct device which is non-coherent
it's the exporters job to flush any dirty caches. Unfortunately the DRM
caching of the dma-buf attachments in the DRM framework will get a bit
in the way here, so a DRM specific flush might be be needed. :/ Maybe
moving the whole buffer to uncached sysmem location on first attach of
a non-coherent importer would be enough?

> So this should better be coherent or you can crash the box. ARM seems to 
> be really susceptible for this, x86 is fortunately much more graceful 
> and I'm not sure about other architectures.

ARM really dislikes pagetable setups with different attributes pointing
to the same physical page, however you should be fine as long as all
cached aliases are properly flushed from the cache before access via a

Re: DMA-buf and uncached system memory




Am 15.02.21 um 13:00 schrieb Thomas Zimmermann:

Hi

Am 15.02.21 um 10:49 schrieb Thomas Zimmermann:

Hi

Am 15.02.21 um 09:58 schrieb Christian König:

Hi guys,

we are currently working an Freesync and direct scan out from system 
memory on AMD APUs in A+A laptops.


On problem we stumbled over is that our display hardware needs to 
scan out from uncached system memory and we currently don't have a 
way to communicate that through DMA-buf.


Re-reading this paragrah, it sounds more as if you want to let the 
exporter know where to move the buffer. Is this another case of the 
missing-pin-flag problem?


No, your original interpretation was correct. Maybe my writing is a bit 
unspecific.


The real underlying issue is that our display hardware has a problem 
with latency when accessing system memory.


So the question is if that also applies to for example Intel hardware or 
other devices as well or if it is just something AMD specific?


Regards,
Christian.



Best regards
Thomas



For our specific use case at hand we are going to implement 
something driver specific, but the question is should we have 
something more generic for this?


For vmap operations, we return the address as struct dma_buf_map, 
which contains additional information about the memory buffer. In 
vram helpers, we have the interface drm_gem_vram_offset() that 
returns the offset of the GPU device memory.


Would it be feasible to combine both concepts into a dma-buf 
interface that returns the device-memory offset plus the additional 
caching flag?


There'd be a structure and a getter function returning the structure.

struct dma_buf_offset {
 bool cached;
 u64 address;
};

// return offset in *off
int dma_buf_offset(struct dma_buf *buf, struct dma_buf_off *off);

Whatever settings are returned by dma_buf_offset() are valid while 
the dma_buf is pinned.


Best regards
Thomas



After all the system memory access pattern is a PCIe extension and 
as such something generic.


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

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for Chipone ICN6211

2021-02-15 Thread Jagan Teki

On Mon, Feb 15, 2021 at 5:28 PM Robert Foss  wrote:
>
> Hey Jagan,
>
> Thanks for submitting this.
>
> checkpatch.pl threw some typ-o warnings, and I listed them below. I
> think either spelling is correct, but 'spelling.txt' does list this as
> a typ-o explicitly, so I would suggest conforming to that just to
> silence the checkpatch warning.
>
> This patch also passes 'dt_binding_check' and 'dtbs_check', but I
> think I'd like to defer to Rob Herring for an actual r-b.
>
> On Sun, 14 Feb 2021 at 18:55, Jagan Teki  wrote:
> >
> > ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.
> >
> > It has a flexible configuration of MIPI DSI signal input and
> > produce RGB565, RGB666, RGB888 output format.
> >
> > Add dt-bingings for it.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> > Changes for v3:
> > - updated to new dt-bindings style
> >
> >  .../display/bridge/chipone,icn6211.yaml   | 90 +++
> >  1 file changed, 90 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> > new file mode 100644
> > index ..13764f13fe46
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> > @@ -0,0 +1,90 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge
>
> $ scripts/checkpatch.pl --git HEAD~0
> WARNING: 'Convertor' may be misspelled - perhaps 'Converter'?

Thanks for pointing it.

I was aware of it before sending it and need to understand whether we
need to use vendor naming conversion or not. Chipone call these
devices are Convertor [1], So I have used the vendor notation for
better understanding.

Any comments are this would be welcome?

[1] http://en.chiponeic.com/content/details45_123.html

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

Re: [PATCH v5 3/3] drm: Add Generic USB Display driver

2021-02-15 Thread Peter Stuge

Hi Noralf,

I was happy to see v4 - thanks for accepting so much of my feedback -
and I have to say that the new recursive acronym makes me smile! :)

Noralf Trønnes wrote:
> +++ b/drivers/gpu/drm/gud/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +config DRM_GUD
> + tristate "GUD USB Display"
> + depends on DRM && USB
> + select LZ4_COMPRESS

Just a thought: Maybe LZ4_COMPRESS should be optional also on the host?

Ie. not select it here and make lz4 code conditional on CONFIG_LZ4_COMPRESS?

> +++ b/drivers/gpu/drm/gud/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +gud-objs := gud_drv.o gud_pipe.o gud_connector.o

Should this be gud-y instead, like in other drm/*/Makefile ?

> +++ b/drivers/gpu/drm/gud/gud_connector.c
..
> +static int gud_connector_atomic_check(struct drm_connector *connector,
> +   struct drm_atomic_state *state)
> +{

This always returns 0, so could be void?

> +int gud_connector_create(struct gud_device *gdrm, unsigned int index)
> +{
> + struct gud_connector_descriptor_req desc;
> + struct drm_device *drm = &gdrm->drm;
> + struct gud_connector *gconn;
> + struct drm_connector *connector;
> + struct drm_encoder *encoder;
> + int ret, connector_type;
> + u32 flags;
> +
> + ret = gud_usb_get(gdrm, GUD_REQ_GET_CONNECTOR, index, &desc, 
> sizeof(desc));

Watch out for endianness bugs.

I'd suggest to stay with the pattern "little-endian on wire" and add
complexity on the host to deserialize/convert transfered data to native,
but perhaps with some generic method that scales better than explicitly
converting values on every use.

> +++ b/drivers/gpu/drm/gud/gud_drv.c
..
> +static int gud_usb_control_msg(struct usb_device *usb, u8 ifnum, bool in,
> +u8 request, u16 value, void *buf, size_t len)
> +{
> + u8 requesttype = USB_TYPE_VENDOR | USB_RECIP_INTERFACE;
> + unsigned int pipe;
> + int ret;
> +
> + if (in) {
> + pipe = usb_rcvctrlpipe(usb, 0);
> + requesttype |= USB_DIR_IN;
> + } else {
> + pipe = usb_sndctrlpipe(usb, 0);
> + requesttype |= USB_DIR_OUT;

The above line seems unneccessary since USB_DIR_OUT is 0 by spec.

> +static int gud_get_display_descriptor(struct usb_interface *interface,
> +   struct gud_display_descriptor_req *desc)
> +{
> + u8 ifnum = interface->cur_altsetting->desc.bInterfaceNumber;
> + struct usb_device *usb = interface_to_usbdev(interface);
> + void *buf;
> + int ret;
> +
> + buf = kmalloc(sizeof(*desc), GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + ret = gud_usb_control_msg(usb, ifnum, true, GUD_REQ_GET_DESCRIPTOR, 0, 
> buf, sizeof(*desc));
> + memcpy(desc, buf, sizeof(*desc));
> + kfree(buf);

Is buf neccessary here? This isn't the hot path, but less dynamic memory
and copying is always nicer.

> + if (desc->magic != GUD_DISPLAY_MAGIC)
> + return -ENODATA;

It seems like this checks overlooks endianness, which happens very easily.

Maybe it's a good idea to create a function to fix endianness directly
after data transfers?

Such a function could take a pointer to memory and a kind of format
string made up of 'b', 'w', 'l' and 'q' or '1', '2', '4' and '8' to
describe field sizes, and would then convert wlq fields to native
endianness in-place.

Or are there some parts of the code that could really benefit from
keeping wire-endian values in host memory?

> +static int gud_usb_get_status(struct usb_device *usb, u8 ifnum, u8 *status)
> +{
> + u8 *buf;
> + int ret;
> +
> + buf = kmalloc(sizeof(*buf), GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + ret = gud_usb_control_msg(usb, ifnum, true, GUD_REQ_GET_STATUS, 0, buf, 
> sizeof(*buf));
> + *status = *buf;
> + kfree(buf);

Ouch, kmalloc for a single byte here, this is the extreme case! :)

If it's not cool to transfer data directly through to the provided pointer
then how about bouncing onto a stack variable rather than kmalloc memory?

Ie:

u8 val;

gud_usb_control_msg(.. GUD_REQ_GET_STATUS, 0, &val, sizeof val)

> +static int gud_usb_transfer(struct gud_device *gdrm, bool in, u8 request, 
> u16 index,
> + void *buf, size_t len)
> +{
> + struct usb_device *usb = gud_to_usb_device(gdrm);
> + void *trbuf = NULL;
> + int idx, ret;
> +
> + drm_dbg(&gdrm->drm, "%s: request=0x%x index=%u len=%zu\n",
> + in ? "get" : "set", request, index, len);
> +
> + if (!drm_dev_enter(&gdrm->drm, &idx))
> + return -ENODEV;
> +
> + mutex_lock(&gdrm->ctrl_lock);
> +
> + if (buf) {
> + if (in)
> + trbuf = kmalloc(len, GFP_KERNEL);
> + else
> + trbuf = kmemdup(buf, len, GFP_KERNEL);

Also not the hot path, b

Re: DMA-buf and uncached system memory


Am 15.02.21 um 12:53 schrieb Lucas Stach:

Am Montag, dem 15.02.2021 um 10:34 +0100 schrieb Christian König:

Am 15.02.21 um 10:06 schrieb Simon Ser:

On Monday, February 15th, 2021 at 9:58 AM, Christian König 
 wrote:


we are currently working an Freesync and direct scan out from system
memory on AMD APUs in A+A laptops.

On problem we stumbled over is that our display hardware needs to scan
out from uncached system memory and we currently don't have a way to
communicate that through DMA-buf.

For our specific use case at hand we are going to implement something
driver specific, but the question is should we have something more
generic for this?

After all the system memory access pattern is a PCIe extension and as
such something generic.

Intel also needs uncached system memory if I'm not mistaken?

No idea, that's why I'm asking. Could be that this is also interesting
for I+A systems.


Where are the buffers allocated? If GBM, then it needs to allocate memory that
can be scanned out if the USE_SCANOUT flag is set or if a scanout-capable
modifier is picked.

If this is about communicating buffer constraints between different components
of the stack, there were a few proposals about it. The most recent one is [1].

Well the problem here is on a different level of the stack.

See resolution, pitch etc:.. can easily communicated in userspace
without involvement of the kernel. The worst thing which can happen is
that you draw garbage into your own application window.

But if you get the caching attributes in the page tables (both CPU as
well as IOMMU, device etc...) wrong then ARM for example has the
tendency to just spontaneously reboot

X86 is fortunately a bit more gracefully and you only end up with random
data corruption, but that is only marginally better.

So to sum it up that is not something which we can leave in the hands of
userspace.

I think that exporters in the DMA-buf framework should have the ability
to tell importers if the system memory snooping is necessary or not.

There is already a coarse-grained way to do so: the dma_coherent
property in struct device, which you can check at dmabuf attach time.

However it may not be enough for the requirements of a GPU where the
engines could differ in their dma coherency requirements. For that you
need to either have fake struct devices for the individual engines or
come up with a more fine-grained way to communicate those requirements.


Yeah, that won't work. We need this on a per buffer level.


Userspace components can then of course tell the exporter what the
importer needs, but validation if that stuff is correct and doesn't
crash the system must happen in the kernel.

What exactly do you mean by "scanout requires non-coherent memory"?
Does the scanout requestor always set the no-snoop PCI flag, so you get
garbage if some writes to memory are still stuck in the caches, or is
it some other requirement?


Snooping the CPU caches introduces some extra latency, so what can 
happen is that the response to the PCIe read comes to late for the 
scanout. The result is an underflow and flickering whenever something is 
in the cache which needs to be flushed first.


On the other hand when the don't snoop the CPU caches we at least get 
garbage/stale data on the screen. That wouldn't be that worse, but the 
big problem is that we have also seen machine check exceptions when 
don't snoop and the cache is dirty.


So this should better be coherent or you can crash the box. ARM seems to 
be really susceptible for this, x86 is fortunately much more graceful 
and I'm not sure about other architectures.


Regards,
Christian.



Regards,
Lucas



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

Re: ITE66121 HDMI driver

2021-02-15 Thread Paul Cercueil





Le lun. 15 févr. 2021 à 10:05, Neil Armstrong 
 a écrit :

Hi,

On 14/02/2021 00:54, Paul Cercueil wrote:

 Hi Phong and Neil,

 I see you sent a patchset to support the ITE66121 HDMI transmitter, 
last version being the V2 back in March 2020.


 Do you still plan to mainline it?


Yes, we still plan to mainline it.


Ok, great!



 I do have a device with a ITE66121 chip, so I can help to clean the 
driver and have it mainlined. But right now I cannot get the driver 
to work, while the chip is properly detected and correct DDC data is 
read,, my PC monitor does not detect any signal.


Having DDC read working is a good point...

Did you check the DPI data setup ? the chip supports dual data rate 
input, and the last version only supported it via a DT property.


If "dual data rate" means two pixels per pixclock tick, then my SoC 
does not support it. I did try both modes though.


The other thing is that my SoC has no VDE/HDE pins, so (according to 
the manual) I have to have the chip recreate these signals from 
videomode information. Which I did, and I get the "video stable" status 
bit, but I still cannot get anything on screen.


Cheers,
-Paul


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

Re: DMA-buf and uncached system memory


Hi

Am 15.02.21 um 10:49 schrieb Thomas Zimmermann:

Hi

Am 15.02.21 um 09:58 schrieb Christian König:

Hi guys,

we are currently working an Freesync and direct scan out from system 
memory on AMD APUs in A+A laptops.


On problem we stumbled over is that our display hardware needs to scan 
out from uncached system memory and we currently don't have a way to 
communicate that through DMA-buf.


Re-reading this paragrah, it sounds more as if you want to let the 
exporter know where to move the buffer. Is this another case of the 
missing-pin-flag problem?


Best regards
Thomas



For our specific use case at hand we are going to implement something 
driver specific, but the question is should we have something more 
generic for this?


For vmap operations, we return the address as struct dma_buf_map, which 
contains additional information about the memory buffer. In vram 
helpers, we have the interface drm_gem_vram_offset() that returns the 
offset of the GPU device memory.


Would it be feasible to combine both concepts into a dma-buf interface 
that returns the device-memory offset plus the additional caching flag?


There'd be a structure and a getter function returning the structure.

struct dma_buf_offset {
 bool cached;
 u64 address;
};

// return offset in *off
int dma_buf_offset(struct dma_buf *buf, struct dma_buf_off *off);

Whatever settings are returned by dma_buf_offset() are valid while the 
dma_buf is pinned.


Best regards
Thomas



After all the system memory access pattern is a PCIe extension and as 
such something generic.


Regards,
Christian.
___
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: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for Chipone ICN6211

2021-02-15 Thread Robert Foss

Hey Jagan,

Thanks for submitting this.

checkpatch.pl threw some typ-o warnings, and I listed them below. I
think either spelling is correct, but 'spelling.txt' does list this as
a typ-o explicitly, so I would suggest conforming to that just to
silence the checkpatch warning.

This patch also passes 'dt_binding_check' and 'dtbs_check', but I
think I'd like to defer to Rob Herring for an actual r-b.

On Sun, 14 Feb 2021 at 18:55, Jagan Teki  wrote:
>
> ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.
>
> It has a flexible configuration of MIPI DSI signal input and
> produce RGB565, RGB666, RGB888 output format.
>
> Add dt-bingings for it.
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - updated to new dt-bindings style
>
>  .../display/bridge/chipone,icn6211.yaml   | 90 +++
>  1 file changed, 90 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
>
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml 
> b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> new file mode 100644
> index ..13764f13fe46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge

$ scripts/checkpatch.pl --git HEAD~0
WARNING: 'Convertor' may be misspelled - perhaps 'Converter'?
#7:
ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.
   ^

> +
> +maintainers:
> +  - Jagan Teki 
> +
> +description: |
> +  ICN6211 is MIPI-DSI to RGB Convertor bridge from chipone.

WARNING: 'Convertor' may be misspelled - perhaps 'Converter'?
#38: FILE: 
Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml:13:
+  ICN6211 is MIPI-DSI to RGB Convertor bridge from chipone.
  ^


> +
> +  It has a flexible configuration of MIPI DSI signal input and
> +  produce RGB565, RGB666, RGB888 output format.
> +
> +properties:
> +  compatible:
> +enum:
> +  - chipone,icn6211
> +
> +  reg:
> +maxItems: 1
> +description: virtual channel number of a DSI peripheral
> +
> +  reset-gpios:
> +description: GPIO connected for the reset pin
> +
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Video port for MIPI DSI input
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Video port for MIPI DPI output (panel or connector).
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - reset-gpios
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +dsi {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  bridge@0 {
> +compatible = "chipone,icn6211";
> +reg = <0>;
> +reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  bridge_in: port@0 {
> +reg = <0>;
> +
> +bridge_out_dsi: endpoint {
> +  remote-endpoint = <&dsi_out_bridge>;
> +};
> +  };
> +
> +  bridge_out: port@1 {
> +reg = <1>;
> +
> +bridge_out_panel: endpoint {
> +  remote-endpoint = <&panel_out_bridge>;
> +};
> +  };
> +};
> +  };
> +};
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DMA-buf and uncached system memory

2021-02-15 Thread Lucas Stach

Am Montag, dem 15.02.2021 um 10:34 +0100 schrieb Christian König:
> 
> Am 15.02.21 um 10:06 schrieb Simon Ser:
> > On Monday, February 15th, 2021 at 9:58 AM, Christian König 
> >  wrote:
> > 
> > > we are currently working an Freesync and direct scan out from system
> > > memory on AMD APUs in A+A laptops.
> > > 
> > > On problem we stumbled over is that our display hardware needs to scan
> > > out from uncached system memory and we currently don't have a way to
> > > communicate that through DMA-buf.
> > > 
> > > For our specific use case at hand we are going to implement something
> > > driver specific, but the question is should we have something more
> > > generic for this?
> > > 
> > > After all the system memory access pattern is a PCIe extension and as
> > > such something generic.
> > Intel also needs uncached system memory if I'm not mistaken?
> 
> No idea, that's why I'm asking. Could be that this is also interesting 
> for I+A systems.
> 
> > Where are the buffers allocated? If GBM, then it needs to allocate memory 
> > that
> > can be scanned out if the USE_SCANOUT flag is set or if a scanout-capable
> > modifier is picked.
> > 
> > If this is about communicating buffer constraints between different 
> > components
> > of the stack, there were a few proposals about it. The most recent one is 
> > [1].
> 
> Well the problem here is on a different level of the stack.
> 
> See resolution, pitch etc:.. can easily communicated in userspace 
> without involvement of the kernel. The worst thing which can happen is 
> that you draw garbage into your own application window.
> 
> But if you get the caching attributes in the page tables (both CPU as 
> well as IOMMU, device etc...) wrong then ARM for example has the 
> tendency to just spontaneously reboot
> 
> X86 is fortunately a bit more gracefully and you only end up with random 
> data corruption, but that is only marginally better.
> 
> So to sum it up that is not something which we can leave in the hands of 
> userspace.
> 
> I think that exporters in the DMA-buf framework should have the ability 
> to tell importers if the system memory snooping is necessary or not.

There is already a coarse-grained way to do so: the dma_coherent
property in struct device, which you can check at dmabuf attach time.

However it may not be enough for the requirements of a GPU where the 
engines could differ in their dma coherency requirements. For that you
need to either have fake struct devices for the individual engines or
come up with a more fine-grained way to communicate those requirements.

> Userspace components can then of course tell the exporter what the 
> importer needs, but validation if that stuff is correct and doesn't 
> crash the system must happen in the kernel.

What exactly do you mean by "scanout requires non-coherent memory"?
Does the scanout requestor always set the no-snoop PCI flag, so you get
garbage if some writes to memory are still stuck in the caches, or is
it some other requirement?

Regards,
Lucas

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

[PATCH v7 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes

Now that we can print FourCC codes directly using printk, make use of the
feature in V4L2 core.

Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++-
 1 file changed, 21 insertions(+), 64 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 31d1342e61e8..31662c3a8c9e 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool 
write_only)
 {
const struct v4l2_fmtdesc *p = arg;
 
-   pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c, 
mbus_code=0x%04x, description='%.*s'\n",
+   pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc, 
mbus_code=0x%04x, description='%.*s'\n",
p->index, prt_names(p->type, v4l2_type_names),
-   p->flags, (p->pixelformat & 0xff),
-   (p->pixelformat >>  8) & 0xff,
-   (p->pixelformat >> 16) & 0xff,
-   (p->pixelformat >> 24) & 0xff,
-   p->mbus_code,
+   p->flags, &p->pixelformat, p->mbus_code,
(int)sizeof(p->description), p->description);
 }
 
@@ -293,12 +289,8 @@ static void v4l_print_format(const void *arg, bool 
write_only)
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
pix = &p->fmt.pix;
-   pr_cont(", width=%u, height=%u, pixelformat=%c%c%c%c, field=%s, 
bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, 
quantization=%u, xfer_func=%u\n",
-   pix->width, pix->height,
-   (pix->pixelformat & 0xff),
-   (pix->pixelformat >>  8) & 0xff,
-   (pix->pixelformat >> 16) & 0xff,
-   (pix->pixelformat >> 24) & 0xff,
+   pr_cont(", width=%u, height=%u, pixelformat=%p4cc, field=%s, 
bytesperline=%u, sizeimage=%u, colorspace=%d, flags=0x%x, ycbcr_enc=%u, 
quantization=%u, xfer_func=%u\n",
+   pix->width, pix->height, &pix->pixelformat,
prt_names(pix->field, v4l2_field_names),
pix->bytesperline, pix->sizeimage,
pix->colorspace, pix->flags, pix->ycbcr_enc,
@@ -307,12 +299,8 @@ static void v4l_print_format(const void *arg, bool 
write_only)
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
mp = &p->fmt.pix_mp;
-   pr_cont(", width=%u, height=%u, format=%c%c%c%c, field=%s, 
colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, 
xfer_func=%u\n",
-   mp->width, mp->height,
-   (mp->pixelformat & 0xff),
-   (mp->pixelformat >>  8) & 0xff,
-   (mp->pixelformat >> 16) & 0xff,
-   (mp->pixelformat >> 24) & 0xff,
+   pr_cont(", width=%u, height=%u, format=%p4cc, field=%s, 
colorspace=%d, num_planes=%u, flags=0x%x, ycbcr_enc=%u, quantization=%u, 
xfer_func=%u\n",
+   mp->width, mp->height, &mp->pixelformat,
prt_names(mp->field, v4l2_field_names),
mp->colorspace, mp->num_planes, mp->flags,
mp->ycbcr_enc, mp->quantization, mp->xfer_func);
@@ -337,13 +325,9 @@ static void v4l_print_format(const void *arg, bool 
write_only)
case V4L2_BUF_TYPE_VBI_CAPTURE:
case V4L2_BUF_TYPE_VBI_OUTPUT:
vbi = &p->fmt.vbi;
-   pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, 
sample_format=%c%c%c%c, start=%u,%u, count=%u,%u\n",
+   pr_cont(", sampling_rate=%u, offset=%u, samples_per_line=%u, 
sample_format=%p4cc, start=%u,%u, count=%u,%u\n",
vbi->sampling_rate, vbi->offset,
-   vbi->samples_per_line,
-   (vbi->sample_format & 0xff),
-   (vbi->sample_format >>  8) & 0xff,
-   (vbi->sample_format >> 16) & 0xff,
-   (vbi->sample_format >> 24) & 0xff,
+   vbi->samples_per_line, &vbi->sample_format,
vbi->start[0], vbi->start[1],
vbi->count[0], vbi->count[1]);
break;
@@ -360,21 +344,13 @@ static void v4l_print_format(const void *arg, bool 
write_only)
case V4L2_BUF_TYPE_SDR_CAPTURE:
case V4L2_BUF_TYPE_SDR_OUTPUT:
sdr = &p->fmt.sdr;
-   pr_cont(", pixelformat=%c%c%c%c\n",
-   (sdr->pixelformat >>  0) & 0xff,
-   (sdr->pixelformat >>  8) & 0xff,
-   (sdr->pixelformat >> 16) & 0xff,
-   (sdr->pixelformat >> 24) & 0xff);
+   pr_cont(", pixelformat=%p4cc\n", &sdr->pixelformat);
break;

[PATCH v7 3/3] drm: Switch to %p4cc format modifier

Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
large number of temporary variables at the same time.

Signed-off-by: Sakari Ailus 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  5 ++--
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  5 ++--
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  5 ++--
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  5 ++--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  5 ++--
 .../arm/display/komeda/komeda_format_caps.h   | 11 
 .../arm/display/komeda/komeda_framebuffer.c   |  4 +--
 .../gpu/drm/arm/display/komeda/komeda_plane.c |  6 ++---
 drivers/gpu/drm/arm/malidp_mw.c   |  7 ++
 drivers/gpu/drm/drm_atomic.c  |  8 ++
 drivers/gpu/drm/drm_crtc.c|  7 ++
 drivers/gpu/drm/drm_fourcc.c  | 25 ---
 drivers/gpu/drm/drm_framebuffer.c | 11 +++-
 drivers/gpu/drm/drm_mipi_dbi.c|  5 ++--
 drivers/gpu/drm/drm_plane.c   |  8 ++
 .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c   |  5 ++--
 drivers/gpu/drm/i915/display/intel_display.c  | 14 +++
 .../drm/i915/display/intel_display_debugfs.c  | 19 ++
 drivers/gpu/drm/i915/display/intel_sprite.c   |  6 ++---
 drivers/gpu/drm/mcde/mcde_display.c   |  6 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  6 ++---
 drivers/gpu/drm/nouveau/nouveau_display.c |  9 +++
 drivers/gpu/drm/radeon/atombios_crtc.c| 10 +++-
 drivers/gpu/drm/sun4i/sun4i_backend.c |  6 ++---
 drivers/gpu/drm/vkms/vkms_writeback.c |  7 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 15 +--
 include/drm/drm_fourcc.h  |  1 -
 27 files changed, 64 insertions(+), 157 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 7944781e1086..ea825b4f8ee8 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1862,7 +1862,6 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   struct drm_format_name_buf format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -1981,8 +1980,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
 #endif
break;
default:
-   DRM_ERROR("Unsupported screen format %s\n",
- drm_get_format_name(target_fb->format->format, 
&format_name));
+   DRM_ERROR("Unsupported screen format %p4cc\n",
+ &target_fb->format->format);
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 1b6ff0470011..a360a6dec198 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1904,7 +1904,6 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   struct drm_format_name_buf format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -2023,8 +2022,8 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
*crtc,
 #endif
break;
default:
-   DRM_ERROR("Unsupported screen format %s\n",
- drm_get_format_name(target_fb->format->format, 
&format_name));
+   DRM_ERROR("Unsupported screen format %p4cc\n",
+ &target_fb->format->format);
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index 83a88385b762..ef124ac853b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -1820,7 +1820,6 @@ static int dce_v6_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   struct drm_format_name_buf format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -1929,8 +1928,8 @@ static int dce_v6_0_crtc_do_set_base(struct drm_crtc 
*crtc,
 #endif
break;
default:
-   DRM_ERROR("Unsupported screen format %s\n",
- drm_get_format_name(target_fb->format->format, 
&format_name));
+   DRM_ERROR("Unsupported screen format %p4cc\n",
+ &target_fb->format->format);
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 224b30214427..c98650183828 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1791,7 +1791,6 @@ static int dce_v8_0_crtc_do_set_base(struct drm_crtc 
*crtc,

[PATCH v7 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
pixel formats denoted by fourccs. The fourcc encoding is the same for both
so the same implementation can be used.

Suggested-by: Mauro Carvalho Chehab 
Signed-off-by: Sakari Ailus 
Reviewed-by: Petr Mladek 
Reviewed-by: Sergey Senozhatsky 
---
 Documentation/core-api/printk-formats.rst | 16 ++
 lib/test_printf.c | 17 ++
 lib/vsprintf.c| 39 +++
 scripts/checkpatch.pl |  6 ++--
 4 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst 
b/Documentation/core-api/printk-formats.rst
index 160e710d992f..da2aa065dc42 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -567,6 +567,22 @@ For printing netdev_features_t.
 
 Passed by reference.
 
+V4L2 and DRM FourCC code (pixel format)
+---
+
+::
+
+   %p4cc
+
+Print a FourCC code used by V4L2 or DRM, including format endianness and
+its numerical value as hexadecimal.
+
+Passed by reference.
+
+Examples::
+
+   %p4cc   BG12 little-endian (0x32314742)
+
 Thanks
 ==
 
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 7d60f24240a4..9848510a2786 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -647,6 +647,22 @@ static void __init fwnode_pointer(void)
software_node_unregister_nodes(softnodes);
 }
 
+static void __init fourcc_pointer(void)
+{
+   struct {
+   u32 code;
+   char *str;
+   } const try[] = {
+   { 0x3231564e, "NV12 little-endian (0x3231564e)", },
+   { 0xb231564e, "NV12 big-endian (0xb231564e)", },
+   { 0x10111213, " little-endian (0x10111213)", },
+   };
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(try); i++)
+   test(try[i].str, "%p4cc", &try[i].code);
+}
+
 static void __init
 errptr(void)
 {
@@ -692,6 +708,7 @@ test_pointer(void)
flags();
errptr();
fwnode_pointer();
+   fourcc_pointer();
 }
 
 static void __init selftest(void)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3b53c73580c5..432b5a2d1e90 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1733,6 +1733,42 @@ char *netdev_bits(char *buf, char *end, const void *addr,
return special_hex_number(buf, end, num, size);
 }
 
+static noinline_for_stack
+char *fourcc_string(char *buf, char *end, const u32 *fourcc,
+   struct printf_spec spec, const char *fmt)
+{
+   char output[sizeof("1234 little-endian (0x01234567)")];
+   char *p = output;
+   unsigned int i;
+   u32 val;
+
+   if (fmt[1] != 'c' || fmt[2] != 'c')
+   return error_string(buf, end, "(%p4?)", spec);
+
+   if (check_pointer(&buf, end, fourcc, spec))
+   return buf;
+
+   val = *fourcc & ~BIT(31);
+
+   for (i = 0; i < sizeof(*fourcc); i++) {
+   unsigned char c = val >> (i * 8);
+
+   /* Print non-control ASCII characters as-is, dot otherwise */
+   *p++ = isascii(c) && isprint(c) ? c : '.';
+   }
+
+   strcpy(p, *fourcc & BIT(31) ? " big-endian" : " little-endian");
+   p += strlen(p);
+
+   *p++ = ' ';
+   *p++ = '(';
+   p = special_hex_number(p, output + sizeof(output) - 2, *fourcc, 
sizeof(u32));
+   *p++ = ')';
+   *p = '\0';
+
+   return string(buf, end, output, spec);
+}
+
 static noinline_for_stack
 char *address_val(char *buf, char *end, const void *addr,
  struct printf_spec spec, const char *fmt)
@@ -2162,6 +2198,7 @@ char *fwnode_string(char *buf, char *end, struct 
fwnode_handle *fwnode,
  *   correctness of the format string and va_list arguments.
  * - 'K' For a kernel pointer that should be hidden from unprivileged users
  * - 'NF' For a netdev_features_t
+ * - '4cc' V4L2 or DRM FourCC code, with endianness and raw numerical value.
  * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
  *a certain separator (' ' by default):
  *  C colon
@@ -2259,6 +2296,8 @@ char *pointer(const char *fmt, char *buf, char *end, void 
*ptr,
return restricted_pointer(buf, end, ptr, spec);
case 'N':
return netdev_bits(buf, end, ptr, spec, fmt);
+   case '4':
+   return fourcc_string(buf, end, ptr, spec, fmt);
case 'a':
return address_val(buf, end, ptr, spec, fmt);
case 'd':
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 92e888ed939f..79858e07d023 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6557,9 +6557,11 @@ sub process {
$specifier = $1;
$extension = $2;
$qualifier = $3;
-

[PATCH v7 0/3] Add %p4cc printk modifier for V4L2 and DRM fourcc codes

Hi all,

This set adds support for %p4cc printk modifier for printing V4L2 and DRM
fourcc codes. The codes are cumbersome to print manually and by adding the
modifier, this task is saved from the V4L2 and DRM frameworks as well as
related drivers. DRM actually had it handled in a way (see 3rd patch) but
the printk modifier makes printing the format easier even there. On V4L2
side it saves quite a few lines of repeating different implementations of
printing the 4cc codes.

Further work will include converting the V4L2 drivers doing the same, as
well as converting DRM drivers from drm_get_format_name() to plain %p4cc.
I left these out from this version since individual drivers are easier
changed without dealing with multiple trees.

If DRM folks would prefer to convert drivers to %p4cc directly instead I
have no problem dropping the 3rd patch. Nearly all uses in DRM are in
printk family of functions that can readily use %p4cc instead of the
current arrangement that relies on caller-allocated temporary buffer.

Since v6:

- Don't drop spaces in fourcc codes.

- Print unprintable characters as dot ('.') instead of hexadecimal number
  in parentheses.

- Convert DRM from drm_get_format_name() to %p4cc. I wonder if this should
  be merged through the DRM tree, albeit it's probably unlikely to
  conflict with other changes. Further use of the function could be a
  problem.

- Make tests more realistic.

Since v5:

- Added V4L2 core conversion to %p4cc, as well as change the DRM
  fourcc printing function to use %p4cc.

- Add missing checkpatch.pl checks for %p4cc modifier.

Sakari Ailus (3):
  lib/vsprintf: Add support for printing V4L2 and DRM fourccs
  v4l: ioctl: Use %p4cc printk modifier to print FourCC codes
  drm: Switch to %p4cc format modifier

 Documentation/core-api/printk-formats.rst | 16 
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  5 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  5 +-
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  5 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  5 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  5 +-
 .../arm/display/komeda/komeda_format_caps.h   | 11 ---
 .../arm/display/komeda/komeda_framebuffer.c   |  4 +-
 .../gpu/drm/arm/display/komeda/komeda_plane.c |  6 +-
 drivers/gpu/drm/arm/malidp_mw.c   |  7 +-
 drivers/gpu/drm/drm_atomic.c  |  8 +-
 drivers/gpu/drm/drm_crtc.c|  7 +-
 drivers/gpu/drm/drm_fourcc.c  | 25 --
 drivers/gpu/drm/drm_framebuffer.c | 11 +--
 drivers/gpu/drm/drm_mipi_dbi.c|  5 +-
 drivers/gpu/drm/drm_plane.c   |  8 +-
 .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c   |  5 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 14 +--
 .../drm/i915/display/intel_display_debugfs.c  | 19 ++---
 drivers/gpu/drm/i915/display/intel_sprite.c   |  6 +-
 drivers/gpu/drm/mcde/mcde_display.c   |  6 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  6 +-
 drivers/gpu/drm/nouveau/nouveau_display.c |  9 +-
 drivers/gpu/drm/radeon/atombios_crtc.c| 10 +--
 drivers/gpu/drm/sun4i/sun4i_backend.c |  6 +-
 drivers/gpu/drm/vkms/vkms_writeback.c |  7 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 15 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c  | 85 +--
 include/drm/drm_fourcc.h  |  1 -
 lib/test_printf.c | 17 
 lib/vsprintf.c| 39 +
 scripts/checkpatch.pl |  6 +-
 32 files changed, 161 insertions(+), 223 deletions(-)

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

Re: [PATCH] drm/bridge: dw-mipi-dsi: Move drm_bridge_add into probe

2021-02-15 Thread Laurent Pinchart

Hi Heiko,

On Wed, Feb 03, 2021 at 01:05:43PM +0100, Heiko Stübner wrote:
> Am Mittwoch, 3. Februar 2021, 10:13:06 CET schrieb Jagan Teki:
> > Usual I2C configured DSI bridge drivers have drm_bridge_add
> > in probe and mipi_dsi_attach in bridge attach functions.
> > 
> > With, this approach the drm pipeline is unable to find the
> > dsi bridge in stm drm drivers since the dw-mipi-dsi bridge is
> > adding drm bridge during bridge attach operations instead of
> > the probe.
> 
> Shouldn't the STM drm driver not simply defer if it's missing
> a bridge that is referenced in the devicetree or somewhere?
> 
> > This specific issue may not encounter for rockchip drm dsi
> > drivers, since rockchip drm uses component binding operations,
> > unlike stm drm drivers.
> > 
> > So, possible solutions are
> > 1. Move drm_bridge_add into the dw-mipi-dsi probe.
> > 2. Add mipi_dsi_attach in the bridge drivers probe.
> > 3. Add component binding operations for stm drm drivers.
> 
> personally I'd like number (3) a lot ;-) .

We have different opinions on this topic :-) The component framework
adds a layer of complexity that can be avoided with probe deferral in
most cases. The main reason why probe deferral isn't always enough is
circular dependencies, which unless I'm mistaken isn't an issue here.

> With your approach, at least the component-based variants would
> end up with multiple probe cycles, getting clocks etc until at some point
> the panel has probed, where in the current way of things, the probe is
> done once and we continue bringup once the panel has probed and called
> dsi-attach to signal it is present.
> 
> Which was actually what Andrzej wished for, when I moved the Rockchip
> dsi to the common driver.
> 
> Or at least make it configurable via a param to the common dw-dsi probe
> function. Especially as I also need the dsi bridge-less when used as a
> simple means for the configuring the internal dphy to rx-mode, see [0]
> 
> Heiko
> 
> [0] 
> https://lore.kernel.org/dri-devel/20210202145632.1263136-1-he...@sntech.de/
> 
> > Option 1 is a relatively possible solution as most of the
> > mainline drm dsi with bridge drivers have a similar approach
> > to their dsi host vs bridge registration.
> > 
> > Signed-off-by: Jagan Teki 
> > ---
> >  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 35 +--
> >  1 file changed, 17 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> > b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > index 6b268f9445b3..8a535041f071 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > @@ -314,8 +314,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
> > *host,
> >  {
> > struct dw_mipi_dsi *dsi = host_to_dsi(host);
> > const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
> > -   struct drm_bridge *bridge;
> > -   struct drm_panel *panel;
> > int ret;
> >  
> > if (device->lanes > dsi->plat_data->max_data_lanes) {
> > @@ -329,22 +327,6 @@ static int dw_mipi_dsi_host_attach(struct 
> > mipi_dsi_host *host,
> > dsi->format = device->format;
> > dsi->mode_flags = device->mode_flags;
> >  
> > -   ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
> > - &panel, &bridge);
> > -   if (ret)
> > -   return ret;
> > -
> > -   if (panel) {
> > -   bridge = drm_panel_bridge_add_typed(panel,
> > -   DRM_MODE_CONNECTOR_DSI);
> > -   if (IS_ERR(bridge))
> > -   return PTR_ERR(bridge);
> > -   }
> > -
> > -   dsi->panel_bridge = bridge;
> > -
> > -   drm_bridge_add(&dsi->bridge);
> > -
> > if (pdata->host_ops && pdata->host_ops->attach) {
> > ret = pdata->host_ops->attach(pdata->priv_data, device);
> > if (ret < 0)
> > @@ -1105,6 +1087,8 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > struct device *dev = &pdev->dev;
> > struct reset_control *apb_rst;
> > struct dw_mipi_dsi *dsi;
> > +   struct drm_bridge *bridge;
> > +   struct drm_panel *panel;
> > int ret;
> >  
> > dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> > @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > dw_mipi_dsi_debugfs_init(dsi);
> > pm_runtime_enable(dev);
> >  
> > +   ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> > + &panel, &bridge);
> > +   if (ret)
> > +   return ERR_PTR(ret);
> > +
> > +   if (panel) {
> > +   bridge = drm_panel_bridge_add_typed(panel,
> > +   DRM_MODE_CONNECTOR_DSI);
> > +   if (IS_ERR(bridge))
> > +   return ERR_PTR(-ENODEV);
> > +   }
> > +
> > +   dsi->panel_bridge = bridge;
> > +
> > dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
> > dsi->dsi_host.dev = dev;
> > ret = mipi

[PATCH] drm/i915: Remove unused function pointer typedef long_pulse_detect_func

2021-02-15 Thread Chen Lin

From: Chen Lin 

Remove the 'long_pulse_detect_func' typedef as it is not used.

Signed-off-by: Chen Lin 
---
 drivers/gpu/drm/i915/i915_irq.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6cdb052..c294ac6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -78,7 +78,6 @@ static inline void pmu_irq_stats(struct drm_i915_private 
*i915,
WRITE_ONCE(i915->pmu.irq_count, i915->pmu.irq_count + 1);
 }
 
-typedef bool (*long_pulse_detect_func)(enum hpd_pin pin, u32 val);
 typedef u32 (*hotplug_enables_func)(struct drm_i915_private *i915,
enum hpd_pin pin);
 
-- 
1.7.9.5


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

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for SN65DSI83/84/85

2021-02-15 Thread Jagan Teki

On Mon, Feb 15, 2021 at 2:32 PM Neil Armstrong  wrote:
>
> Hi,
>
> On 14/02/2021 18:44, Jagan Teki wrote:
> > SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge
> > controller IC's from Texas Instruments.
> >
> > SN65DSI83 - Single Channel DSI to Single-link LVDS bridge
> > SN65DSI84 - Single Channel DSI to Dual-link LVDS bridge
> > SN65DSI85 - Dual Channel DSI to Dual-link LVDS bridge
> >
> > Right now the bridge driver is supporting Channel A with single
> > link, so dt-bindings documented according to it.
>
> Shouldn't it describe Dual-link LVDS already for SN65DSI84/85 and Dual 
> Channel DSI for SN65DSI85 even if not implemented in the driver ?

Patch documented only Single link LVDS as it only supported by driver.
Single link LVDS with Channel A configuration is common across all 3
variant chips. I have SN65DSI84 with Single link LVDS which is routed
in Channel A. Idea is to go with Single link and add double link later
and document the same.

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

[PATCH] drm/radeon: Remove unused function pointer typedef radeon_packet3_check_t

2021-02-15 Thread Chen Lin

From: Chen Lin 

Remove the 'radeon_packet3_check_t' typedef as it is not used.

Signed-off-by: Chen Lin 
---
 drivers/gpu/drm/radeon/radeon.h |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5f3adba..a1c38b5 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -,9 +,6 @@ struct radeon_cs_packet {
 typedef int (*radeon_packet0_check_t)(struct radeon_cs_parser *p,
  struct radeon_cs_packet *pkt,
  unsigned idx, unsigned reg);
-typedef int (*radeon_packet3_check_t)(struct radeon_cs_parser *p,
- struct radeon_cs_packet *pkt);
-
 
 /*
  * AGP
-- 
1.7.9.5

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

Re: [PATCH 0/3] NVIDIA Tegra NVDEC support

2021-02-15 Thread Thierry Reding

On Mon, Feb 15, 2021 at 11:21:27AM +0100, Neil Armstrong wrote:
> Hi Thierry,
> 
> 
> On 15/02/2021 10:50, Thierry Reding wrote:
> > On Mon, Feb 15, 2021 at 10:10:26AM +0100, Neil Armstrong wrote:
> >> Hi,
> >>
> >> On 13/02/2021 11:15, Mikko Perttunen wrote:
> >>> Hi all,
> >>>
> >>> with the release of documentation headers for Tegra multimedia engines
> >>> (NVDEC, NVENC, NVJPG) [1], I have started working on the corresponding
> >>> implementations. Here's the first one, NVDEC.
> >>>
> >>> The kernel driver is a simple Falcon boot driver based on the VIC
> >>> driver. Some code sharing should be considered there in the future.
> >>> The userspace driver to accompany this is a bit more complicated -
> >>> I have expanded vaapi-tegra-driver[2] to support MPEG2 decoding.
> >>> It should be noted that the implementation is still very clunky
> >>> and has poor performance, but it's a start.
> >>
> >> Funny how all this tries to avoid all the DRM, remoteproc, V4L2-M2M 
> >> stateless & co
> >> all the other vendors tries to make usage of...
> > 
> > Care to elaborate why you think this is trying to avoid anything? Mikko
> > pointed you at the documentation for these engines, provided a link to
> > an open-source (albeit work in progress) userspace driver and posts an
> > extension to an existing DRM driver to add the required kernel
> > functionality. That's a standard approach for submitting this kind of
> > driver.
> 
> Thanks for the reply, I didn't look extensively at all the documents & 
> userspace
> libraries, but I wonder why this couldn't fit in the V4L2-M2M approach and 
> avoid
> having userspace drivers and specific libraries to handle this.

Ah, I see. Without going too much into the details, the reason for this
is that the multimedia engines on Tegra use host1x for command
submission. host1x is roughly a command stream parser with built-in
capability for synchronization and (in newer generations) process
isolation, etc. This same engine is used for things like 2D and 3D
acceleration on older chips and there are other hardware blocks that use
it, such as the video image compositor (used for some post-processing
tasks). The GPU can also interoperate with host1x for synchronization
with these multimedia engines.

The userspace interfaces for 2D and 3D have existed for a long time, and
the fundamental programming sequences are largely the same, so we chose
to use the same interface for simplicity rather that duplicating most of
this into the kernel.

Constructing these command streams can be fairly complicated and a
number of extra data structures are needed for each command. Putting all
of that into userspace reduces the potential for bugs and crashes in the
kernel that may take down the whole system.

As for the userspace drivers argument, this isn't adding anything new
but rather provides a driver for the existing VAAPI library that's
already widely supported in multimedia applications.

Thierry

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

Re: [PATCH] drm/radeon: Remove unused function pointer typedef radeon_packet3_check_t




Am 15.02.21 um 11:21 schrieb Chen Lin:

From: Chen Lin 

Remove the 'radeon_packet3_check_t' typedef as it is not used.

Signed-off-by: Chen Lin 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon.h |3 ---
  1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5f3adba..a1c38b5 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -,9 +,6 @@ struct radeon_cs_packet {
  typedef int (*radeon_packet0_check_t)(struct radeon_cs_parser *p,
  struct radeon_cs_packet *pkt,
  unsigned idx, unsigned reg);
-typedef int (*radeon_packet3_check_t)(struct radeon_cs_parser *p,
- struct radeon_cs_packet *pkt);
-
  
  /*

   * AGP


___
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 pm tree

+Cc: Patrik (JFYI).

On Mon, Feb 15, 2021 at 12:23 PM Andy Shevchenko
 wrote:
>
> On Mon, Feb 15, 2021 at 2:45 AM Stephen Rothwell  
> wrote:
> >
> > Hi all,
> >
> > After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> >
> > In file included from drivers/gpu/drm/gma500/mdfld_output.c:28:
> > arch/x86/include/asm/intel_scu_ipc.h:23:12: warning: 'struct module' 
> > declared inside parameter list will not be visible outside of this 
> > definition or declaration
> >23 | struct module *owner);
> >   |^~
> > arch/x86/include/asm/intel_scu_ipc.h:33:17: warning: 'struct module' 
> > declared inside parameter list will not be visible outside of this 
> > definition or declaration
> >33 |  struct module *owner);
> >   | ^~
> >
> > Introduced by commit
> >
> >   bfc838f8598e ("drm/gma500: Convert to use new SCU IPC API")
> >
> > OK, these will go away when the drm-misc tree removes this file in commit
> >
> >   e1da811218d2 ("drm/gma500: Remove Medfield support")
> >
> > So, if you don't want to see these warnings in Linus' build testing,
> > you need to make sure that the drm-misc tree is merged before the pm
> > tree (or the drivers-x86 tree).  Or you need to include module.h in
> > mdfld_output.c before intel_scu_ipc.h (or in intel_scu_ipc.h itself).
>
> Thanks for the report.
> I guess the DRM tree should carry this burden, or they can merge the
> immutable tag themselves.
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
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: build warning after merge of the pm tree

On Mon, Feb 15, 2021 at 2:45 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> In file included from drivers/gpu/drm/gma500/mdfld_output.c:28:
> arch/x86/include/asm/intel_scu_ipc.h:23:12: warning: 'struct module' declared 
> inside parameter list will not be visible outside of this definition or 
> declaration
>23 | struct module *owner);
>   |^~
> arch/x86/include/asm/intel_scu_ipc.h:33:17: warning: 'struct module' declared 
> inside parameter list will not be visible outside of this definition or 
> declaration
>33 |  struct module *owner);
>   | ^~
>
> Introduced by commit
>
>   bfc838f8598e ("drm/gma500: Convert to use new SCU IPC API")
>
> OK, these will go away when the drm-misc tree removes this file in commit
>
>   e1da811218d2 ("drm/gma500: Remove Medfield support")
>
> So, if you don't want to see these warnings in Linus' build testing,
> you need to make sure that the drm-misc tree is merged before the pm
> tree (or the drivers-x86 tree).  Or you need to include module.h in
> mdfld_output.c before intel_scu_ipc.h (or in intel_scu_ipc.h itself).

Thanks for the report.
I guess the DRM tree should carry this burden, or they can merge the
immutable tag themselves.

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] kernel: Expose SYS_kcmp by default

2021-02-15 Thread Lucas Stach

Am Samstag, dem 13.02.2021 um 18:40 +0100 schrieb Pavel Machek:
> Hi!
> 
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description() in order to identify when two fd (e.g. device
> > or dmabuf) point to the same struct file. Since they depend on it for
> > core functionality, lift SYS_kcmp out of the non-default
> > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
> 
> Is it good idea to enable everything because Mesa uses it for file
> descriptors?
> 
> This is really interesting syscall...

As Debian/Ubuntu and Fedora are already shipping with
CONFIG_CHECKPOINT_RESTORE=y in their kernel configs, I don't really see
the need to add further restrictions here. Or this discussion should
have happened a while ago...

Regards,
Lucas

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

Re: [PATCH 0/3] NVIDIA Tegra NVDEC support

Hi Thierry,


On 15/02/2021 10:50, Thierry Reding wrote:
> On Mon, Feb 15, 2021 at 10:10:26AM +0100, Neil Armstrong wrote:
>> Hi,
>>
>> On 13/02/2021 11:15, Mikko Perttunen wrote:
>>> Hi all,
>>>
>>> with the release of documentation headers for Tegra multimedia engines
>>> (NVDEC, NVENC, NVJPG) [1], I have started working on the corresponding
>>> implementations. Here's the first one, NVDEC.
>>>
>>> The kernel driver is a simple Falcon boot driver based on the VIC
>>> driver. Some code sharing should be considered there in the future.
>>> The userspace driver to accompany this is a bit more complicated -
>>> I have expanded vaapi-tegra-driver[2] to support MPEG2 decoding.
>>> It should be noted that the implementation is still very clunky
>>> and has poor performance, but it's a start.
>>
>> Funny how all this tries to avoid all the DRM, remoteproc, V4L2-M2M 
>> stateless & co
>> all the other vendors tries to make usage of...
> 
> Care to elaborate why you think this is trying to avoid anything? Mikko
> pointed you at the documentation for these engines, provided a link to
> an open-source (albeit work in progress) userspace driver and posts an
> extension to an existing DRM driver to add the required kernel
> functionality. That's a standard approach for submitting this kind of
> driver.

Thanks for the reply, I didn't look extensively at all the documents & userspace
libraries, but I wonder why this couldn't fit in the V4L2-M2M approach and avoid
having userspace drivers and specific libraries to handle this.

Neil

> 
> Thierry
> 




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

Re: [PATCH 0/3] NVIDIA Tegra NVDEC support

2021-02-15 Thread Thierry Reding

On Mon, Feb 15, 2021 at 10:10:26AM +0100, Neil Armstrong wrote:
> Hi,
> 
> On 13/02/2021 11:15, Mikko Perttunen wrote:
> > Hi all,
> > 
> > with the release of documentation headers for Tegra multimedia engines
> > (NVDEC, NVENC, NVJPG) [1], I have started working on the corresponding
> > implementations. Here's the first one, NVDEC.
> > 
> > The kernel driver is a simple Falcon boot driver based on the VIC
> > driver. Some code sharing should be considered there in the future.
> > The userspace driver to accompany this is a bit more complicated -
> > I have expanded vaapi-tegra-driver[2] to support MPEG2 decoding.
> > It should be noted that the implementation is still very clunky
> > and has poor performance, but it's a start.
> 
> Funny how all this tries to avoid all the DRM, remoteproc, V4L2-M2M stateless 
> & co
> all the other vendors tries to make usage of...

Care to elaborate why you think this is trying to avoid anything? Mikko
pointed you at the documentation for these engines, provided a link to
an open-source (albeit work in progress) userspace driver and posts an
extension to an existing DRM driver to add the required kernel
functionality. That's a standard approach for submitting this kind of
driver.

Thierry


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

Re: DMA-buf and uncached system memory


Hi

Am 15.02.21 um 09:58 schrieb Christian König:

Hi guys,

we are currently working an Freesync and direct scan out from system 
memory on AMD APUs in A+A laptops.


On problem we stumbled over is that our display hardware needs to scan 
out from uncached system memory and we currently don't have a way to 
communicate that through DMA-buf.


For our specific use case at hand we are going to implement something 
driver specific, but the question is should we have something more 
generic for this?


For vmap operations, we return the address as struct dma_buf_map, which 
contains additional information about the memory buffer. In vram 
helpers, we have the interface drm_gem_vram_offset() that returns the 
offset of the GPU device memory.


Would it be feasible to combine both concepts into a dma-buf interface 
that returns the device-memory offset plus the additional caching flag?


There'd be a structure and a getter function returning the structure.

struct dma_buf_offset {
bool cached;
u64 address;
};

// return offset in *off
int dma_buf_offset(struct dma_buf *buf, struct dma_buf_off *off);

Whatever settings are returned by dma_buf_offset() are valid while the 
dma_buf is pinned.


Best regards
Thomas



After all the system memory access pattern is a PCIe extension and as 
such something generic.


Regards,
Christian.
___
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: DMA-buf and uncached system memory

Am 15.02.21 um 10:06 schrieb Simon Ser:

On Monday, February 15th, 2021 at 9:58 AM, Christian König
wrote:

we are currently working an Freesync and direct scan out from system
memory on AMD APUs in A+A laptops.

On problem we stumbled over is that our display hardware needs to scan
out from uncached system memory and we currently don't have a way to
communicate that through DMA-buf.

For our specific use case at hand we are going to implement something
driver specific, but the question is should we have something more
generic for this?

After all the system memory access pattern is a PCIe extension and as
such something generic.

Intel also needs uncached system memory if I'm not mistaken?

No idea, that's why I'm asking. Could be that this is also interesting
for I+A systems.

Where are the buffers allocated? If GBM, then it needs to allocate memory that
can be scanned out if the USE_SCANOUT flag is set or if a scanout-capable
modifier is picked.

If this is about communicating buffer constraints between different components
of the stack, there were a few proposals about it. The most recent one is [1].

Well the problem here is on a different level of the stack.

See resolution, pitch etc:.. can easily communicated in userspace
without involvement of the kernel. The worst thing which can happen is
that you draw garbage into your own application window.

But if you get the caching attributes in the page tables (both CPU as
well as IOMMU, device etc...) wrong then ARM for example has the
tendency to just spontaneously reboot

X86 is fortunately a bit more gracefully and you only end up with random
data corruption, but that is only marginally better.

So to sum it up that is not something which we can leave in the hands of
userspace.

I think that exporters in the DMA-buf framework should have the ability
to tell importers if the system memory snooping is necessary or not.

Userspace components can then of course tell the exporter what the
importer needs, but validation if that stuff is correct and doesn't
crash the system must happen in the kernel.

Regards,
Christian.

Simon

[1]:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxdc2020.x.org%2Fevent%2F9%2Fcontributions%2F615%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7Cb2824bd79bd44862b38e08d8d190f344%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637489767796900783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hIptfin5Xx6XlYBtGFYAAbfuNsnD6kmQEiggq9k10E8%3D&reserved=0

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

Re: [PATCH 0/3] NVIDIA Tegra NVDEC support

Hi,

On 13/02/2021 11:15, Mikko Perttunen wrote:
> Hi all,
> 
> with the release of documentation headers for Tegra multimedia engines
> (NVDEC, NVENC, NVJPG) [1], I have started working on the corresponding
> implementations. Here's the first one, NVDEC.
> 
> The kernel driver is a simple Falcon boot driver based on the VIC
> driver. Some code sharing should be considered there in the future.
> The userspace driver to accompany this is a bit more complicated -
> I have expanded vaapi-tegra-driver[2] to support MPEG2 decoding.
> It should be noted that the implementation is still very clunky
> and has poor performance, but it's a start.

Funny how all this tries to avoid all the DRM, remoteproc, V4L2-M2M stateless & 
co
all the other vendors tries to make usage of...

Neil

> 
> This series is based on top of the "Host1x/TegraDRM UAPI" series.
> For testing, appropriate firmware should be obtained from a
> Linux for Tegra distribution for now; the GPU should also be
> enabled in the device tree.
> 
> Series was tested on Tegra186.
> 
> Thanks!
> 
> Mikko
> 
> [1] https://github.com/NVIDIA/open-gpu-doc/tree/master/classes/video
> [2] https://github.com/cyndis/vaapi-tegra-driver
> 
> Mikko Perttunen (3):
>   dt-bindings: Add YAML bindings for Host1x and NVDEC
>   arm64: tegra: Add NVDEC to Tegra186 device tree
>   drm/tegra: Add NVDEC driver
> 
>  .../gpu/host1x/nvidia,tegra20-host1x.yaml | 129 +
>  .../gpu/host1x/nvidia,tegra210-nvdec.yaml |  90 
>  MAINTAINERS   |   1 +
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi  |  15 +
>  drivers/gpu/drm/tegra/Makefile|   3 +-
>  drivers/gpu/drm/tegra/drm.c   |   4 +
>  drivers/gpu/drm/tegra/drm.h   |   1 +
>  drivers/gpu/drm/tegra/nvdec.c | 497 ++
>  drivers/gpu/host1x/dev.c  |  12 +
>  include/linux/host1x.h|   1 +
>  10 files changed, 752 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
>  create mode 100644 drivers/gpu/drm/tegra/nvdec.c
> 

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

Re: [PATCH 1/3] dt-bindings: Add YAML bindings for Host1x and NVDEC