Re: [PATCH v2 00/12] accel/ivpu: Changes for 6.10

[Jacek Lawrynowicz]

Applied to drm-misc-next

On 13.05.2024 14:04, Jacek Lawrynowicz wrote:
> There are couple of major new features in this patchset:
>   * Hardware scheduler support (disabled by default)
>   * Profiling support
>   * Expose NPU busy time in sysfs
> 
> Other then that, there are two small random fixes.
> 
> v2: Included Jeffrey's v1 comments
> 
> v1: 
> https://lore.kernel.org/dri-devel/20240508132106.2387464-1-jacek.lawrynow...@linux.intel.com
> 
> Jacek Lawrynowicz (2):
>   accel/ivpu: Update VPU FW API headers
>   accel/ivpu: Increase reset counter when warm boot fails
> 
> Tomasz Rusinowicz (3):
>   accel/ivpu: Add NPU profiling support
>   accel/ivpu: Configure fw logging using debugfs
>   accel/ivpu: Share NPU busy time in sysfs
> 
> Wachowski, Karol (7):
>   accel/ivpu: Add sched_mode module param
>   accel/ivpu: Create priority based command queues
>   accel/ivpu: Implement support for preemption buffers
>   accel/ivpu: Add HWS JSM messages
>   accel/ivpu: Implement support for hardware scheduler
>   accel/ivpu: Add resume engine support
>   accel/ivpu: Add force snoop module parameter
> 
>  drivers/accel/ivpu/Makefile   |   6 +-
>  drivers/accel/ivpu/ivpu_debugfs.c |  50 +
>  drivers/accel/ivpu/ivpu_drv.c |  44 -
>  drivers/accel/ivpu/ivpu_drv.h |  23 ++-
>  drivers/accel/ivpu/ivpu_fw.c  |  10 +
>  drivers/accel/ivpu/ivpu_fw.h  |   2 +
>  drivers/accel/ivpu/ivpu_gem.h |  11 +-
>  drivers/accel/ivpu/ivpu_hw.h  |   3 +-
>  drivers/accel/ivpu/ivpu_hw_37xx.c |   7 +-
>  drivers/accel/ivpu/ivpu_hw_40xx.c |   9 +-
>  drivers/accel/ivpu/ivpu_job.c | 295 ++--
>  drivers/accel/ivpu/ivpu_job.h |   2 +
>  drivers/accel/ivpu/ivpu_jsm_msg.c | 259 -
>  drivers/accel/ivpu/ivpu_jsm_msg.h |  20 +-
>  drivers/accel/ivpu/ivpu_mmu.c |  12 +-
>  drivers/accel/ivpu/ivpu_ms.c  | 309 ++
>  drivers/accel/ivpu/ivpu_ms.h  |  36 
>  drivers/accel/ivpu/ivpu_pm.c  |   5 +
>  drivers/accel/ivpu/ivpu_sysfs.c   |  58 ++
>  drivers/accel/ivpu/ivpu_sysfs.h   |  13 ++
>  drivers/accel/ivpu/vpu_jsm_api.h  |  14 +-
>  include/uapi/drm/ivpu_accel.h |  69 ++-
>  22 files changed, 1173 insertions(+), 84 deletions(-)
>  create mode 100644 drivers/accel/ivpu/ivpu_ms.c
>  create mode 100644 drivers/accel/ivpu/ivpu_ms.h
>  create mode 100644 drivers/accel/ivpu/ivpu_sysfs.c
>  create mode 100644 drivers/accel/ivpu/ivpu_sysfs.h
> 
> --
> 2.43.2

Re: [PATCH v4 3/7] dma-buf: heaps: restricted_heap: Add private heap ops

[吴勇]

Hi Joakim,

Sorry for reply so late.

On Wed, 2024-01-31 at 14:53 +0100, Joakim Bech wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On Fri, Jan 12, 2024 at 05:20:10PM +0800, Yong Wu wrote:
> > Add "struct restricted_heap_ops". For the restricted memory,
> totally there
> > are two steps:
> > a) memory_alloc: Allocate the buffer in kernel;
> > b) memory_restrict: Restrict/Protect/Secure that buffer.
> > The memory_alloc is mandatory while memory_restrict is optinal
> since it may
> >
> s/optinal/optional/

Will Fix.

> 
> > be part of memory_alloc.
> > 
> > Signed-off-by: Yong Wu 
> > ---
> >  drivers/dma-buf/heaps/restricted_heap.c | 41
> -
> >  drivers/dma-buf/heaps/restricted_heap.h | 12 
> >  2 files changed, 52 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma-buf/heaps/restricted_heap.c b/drivers/dma-
> buf/heaps/restricted_heap.c
> > index fd7c82abd42e..8c266a0f6192 100644
> > --- a/drivers/dma-buf/heaps/restricted_heap.c
> > +++ b/drivers/dma-buf/heaps/restricted_heap.c
> > @@ -12,10 +12,44 @@
> >  
> >  #include "restricted_heap.h"
> >  
> > +static int
> > +restricted_heap_memory_allocate(struct restricted_heap *heap,
> struct restricted_buffer *buf)
> > +{
> > +const struct restricted_heap_ops *ops = heap->ops;
> > +int ret;
> > +
> > +ret = ops->memory_alloc(heap, buf);
> > +if (ret)
> > +return ret;
> > +
> > +if (ops->memory_restrict) {
> > +ret = ops->memory_restrict(heap, buf);
> > +if (ret)
> > +goto memory_free;
> > +}
> > +return 0;
> > +
> > +memory_free:
> > +ops->memory_free(heap, buf);
> > +return ret;
> > +}
> > +
> > +static void
> > +restricted_heap_memory_free(struct restricted_heap *heap, struct
> restricted_buffer *buf)
> > +{
> > +const struct restricted_heap_ops *ops = heap->ops;
> > +
> > +if (ops->memory_unrestrict)
> > +ops->memory_unrestrict(heap, buf);
> > +
> > +ops->memory_free(heap, buf);
> > +}
> > +
> >  static struct dma_buf *
> >  restricted_heap_allocate(struct dma_heap *heap, unsigned long
> size,
> >   unsigned long fd_flags, unsigned long heap_flags)
> >  {
> > +struct restricted_heap *restricted_heap =
> dma_heap_get_drvdata(heap);
> >  struct restricted_buffer *restricted_buf;
> >  DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> >  struct dma_buf *dmabuf;
> > @@ -28,6 +62,9 @@ restricted_heap_allocate(struct dma_heap *heap,
> unsigned long size,
> >  restricted_buf->size = ALIGN(size, PAGE_SIZE);
> >  restricted_buf->heap = heap;
> >  
> > +ret = restricted_heap_memory_allocate(restricted_heap,
> restricted_buf);
> >
> Can we guarantee that "restricted_heap" here isn't NULL (i.e., heap-
> >priv). If
> not perhaps we should consider adding a check for NULL in the
> restricted_heap_memory_allocate() function?

heap->priv always is set when dma_heap_add is called. Suppose heap-
>priv is NULL, the KE would have already been occurred in
restricted_heap_add. I don't think it can be NULL. is it right?

> 
> > +if (ret)
> > +goto err_free_buf;
> >  exp_info.exp_name = dma_heap_get_name(heap);
> >  exp_info.size = restricted_buf->size;
> >  exp_info.flags = fd_flags;
> > @@ -36,11 +73,13 @@ restricted_heap_allocate(struct dma_heap *heap,
> unsigned long size,
> >  dmabuf = dma_buf_export(_info);
> >  if (IS_ERR(dmabuf)) {
> >  ret = PTR_ERR(dmabuf);
> > -goto err_free_buf;
> > +goto err_free_restricted_mem;
> >  }
> >  
> >  return dmabuf;
> >  
> > +err_free_restricted_mem:
> > +restricted_heap_memory_free(restricted_heap, restricted_buf);
> >  err_free_buf:
> >  kfree(restricted_buf);
> >  return ERR_PTR(ret);
> > diff --git a/drivers/dma-buf/heaps/restricted_heap.h b/drivers/dma-
> buf/heaps/restricted_heap.h
> > index 443028f6ba3b..ddeaf9805708 100644
> > --- a/drivers/dma-buf/heaps/restricted_heap.h
> > +++ b/drivers/dma-buf/heaps/restricted_heap.h
> > @@ -15,6 +15,18 @@ struct restricted_buffer {
> >  
> >  struct restricted_heap {
> >  const char*name;
> > +
> > +const struct restricted_heap_ops *ops;
> > +};
> > +
> > +struct restricted_heap_ops {
> >
> This have the same name as used for the dma_heap_ops in the file
> restricted_heap.c, this might be a little bit confusing, or?

Thanks very much. I really didn't notice this. I will rename it.

> 
> > +int(*heap_init)(struct restricted_heap *heap);
> > +
> > +int(*memory_alloc)(struct restricted_heap *heap, struct
> restricted_buffer *buf);
> > +void(*memory_free)(struct restricted_heap *heap, struct
> restricted_buffer *buf);
> > +
> > +int(*memory_restrict)(struct restricted_heap *heap, struct
> restricted_buffer *buf);
> > +void(*memory_unrestrict)(struct restricted_heap *heap, struct
> restricted_buffer *buf);
> >
> Is the prefix "memory_" superfluous here in these ops?

I will remove "memory_".  But it looks like the "restrict" is a
keyword, I can't use it or it will build fail. Therefore I plan to use
alloc/free/restrict_buf/unrestrict_buf in next version.

> 
> Also related to 

Re: [PATCH v4 4/7] dma-buf: heaps: restricted_heap: Add dma_ops

[吴勇]

On Fri, 2024-01-12 at 10:49 +0100, Daniel Vetter wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On Fri, Jan 12, 2024 at 10:41:14AM +0100, Daniel Vetter wrote:
> > On Fri, Jan 12, 2024 at 05:20:11PM +0800, Yong Wu wrote:
> > > Add the dma_ops for this restricted heap. For restricted buffer,
> > > cache_ops/mmap are not allowed, thus return EPERM for them.
> > > 
> > > Signed-off-by: Yong Wu 
> > > ---
> > >  drivers/dma-buf/heaps/restricted_heap.c | 103
> 
> > >  1 file changed, 103 insertions(+)
> > > 
> > > diff --git a/drivers/dma-buf/heaps/restricted_heap.c
> b/drivers/dma-buf/heaps/restricted_heap.c
> > > index 8c266a0f6192..ec4c63d2112d 100644
> > > --- a/drivers/dma-buf/heaps/restricted_heap.c
> > > +++ b/drivers/dma-buf/heaps/restricted_heap.c
> > > @@ -12,6 +12,10 @@
> > >  
> > >  #include "restricted_heap.h"
> > >  
> > > +struct restricted_heap_attachment {
> > > +struct sg_table*table;
> > > +};
> > > +
> > >  static int
> > >  restricted_heap_memory_allocate(struct restricted_heap *heap,
> struct restricted_buffer *buf)
> > >  {
> > > @@ -45,6 +49,104 @@ restricted_heap_memory_free(struct
> restricted_heap *heap, struct restricted_buff
> > >  ops->memory_free(heap, buf);
> > >  }
> > >  
> > > +static int restricted_heap_attach(struct dma_buf *dmabuf, struct
> dma_buf_attachment *attachment)
> > > +{
> > > +struct restricted_buffer *restricted_buf = dmabuf->priv;
> > > +struct restricted_heap_attachment *a;
> > > +struct sg_table *table;
> > > +int ret;
> > > +
> > > +a = kzalloc(sizeof(*a), GFP_KERNEL);
> > > +if (!a)
> > > +return -ENOMEM;
> > > +
> > > +table = kzalloc(sizeof(*table), GFP_KERNEL);
> > > +if (!table) {
> > > +ret = -ENOMEM;
> > > +goto err_free_attach;
> > > +}
> > > +
> > > +ret = sg_alloc_table(table, 1, GFP_KERNEL);
> > > +if (ret)
> > > +goto err_free_sgt;
> > > +sg_set_page(table->sgl, NULL, restricted_buf->size, 0);
> > 
> > So this is definitely broken and violating the dma-buf api rules.
> You
> > cannot let attach succed and supply a dummy/invalid sg table.
> > 
> > Two options:
> > 
> > - Reject ->attach for all this buffers with -EBUSY and provide
> instead a
> >   private api for these secure buffers, similar to how
> virtio_dma_buf has
> >   private virto-specific apis. This interface would need to be
> >   standardized across all arm TEE users, so that we don't have a
> >   disastrous proliferation of apis.
> > 
> > - Allow ->attach, but _only_ for drivers/devices which can access
> the
> >   secure buffer correctly, and only if you can put the right secure
> buffer
> >   address into the sg table directly. If dma to a secure buffer for
> a
> >   given struct device * will not work correctly (i.e. without data
> >   corruption), you _must_ reject the attach attempt with -EBUSY.
> > 
> > The 2nd approach would be my preferred one, if it's technically
> possible.
> > 
> > Also my understanding is that arm TEE is standardized, so I think
> we'll at
> > least want some acks from other soc people whether this will work
> for them
> > too.
> > 
> > Finally the usual drill:
> > - this also needs the driver side support, if there's any changes
> needed.
> >   Just the new heap isn't enough.
> 
> Ok I quickly scrolled through your drm patches and that confirms that
> the
> current dma-buf interface you're implementing is just completely
> breaking
> the api. And you need to paper over that will all kinds of very icky
> special-casing.
> 
> So definitely need to rethink the overall design between dma-buf
> heaps and
> drivers here.

Hi,

Thanks very much for the review, and sorry for reply so late.  We
reconstructed our TEE commands so that the kernel can obtain the valid
PA/pages, then the sg operations can run normally. 

I will send the next version.
Thanks.

> -Sima
> 
> > - and for drm you need open userspace for this. Doesn't have to be
> the
> >   full content protection decode pipeline, the drivers in drm that
> landed
> >   secure buffer support thus far enabled it using the
> >   EGL_EXT_protected_content extension using gl, which side steps
> all the
> >   complications around content decryption keys and support
> > 
> > Cheers, Sima
> > 
> > > +
> > > +a->table = table;
> > > +attachment->priv = a;
> > > +
> > > +return 0;
> > > +
> > > +err_free_sgt:
> > > +kfree(table);
> > > +err_free_attach:
> > > +kfree(a);
> > > +return ret;
> > > +}
> > > +
> > > +static void restricted_heap_detach(struct dma_buf *dmabuf,
> struct dma_buf_attachment *attachment)
> > > +{
> > > +struct restricted_heap_attachment *a = attachment->priv;
> > > +
> > > +sg_free_table(a->table);
> > > +kfree(a->table);
> > > +kfree(a);
> > > +}
> > > +
> > > +static struct sg_table *
> > > +restricted_heap_map_dma_buf(struct dma_buf_attachment
> *attachment, enum dma_data_direction direct)
> > > +{
> > > +struct restricted_heap_attachment *a = attachment->priv;
> > > +struct 

Re: [PATCH v7 7/8] media: imagination: Round to closest multiple for cropping region

[Devarsh Thakkar]

Hi Nicolas,

Thanks for the review.

On 15/05/24 01:52, Nicolas Dufresne wrote:
> Le samedi 11 mai 2024 à 22:38 +0530, Devarsh Thakkar a écrit :
>> Hi Andy,
>>
>> Thanks for the quick review.
>> On 10/05/24 20:40, Andy Shevchenko wrote:
>>> On Fri, May 10, 2024 at 12:10:01AM +0530, Devarsh Thakkar wrote:
 If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
 (V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
 multiple of requested value while updating the crop rectangle coordinates.

 Use the rounding macro which gives preference to rounding down in case two
 nearest values (high and low) are possible to raise the probability of
 cropping rectangle falling inside the bound region.
>>>
>>> This is arguable. How do we know that the bigger range is supported?
>>> The safest side is to go smaller than bigger.
>>>
>>
>> Yes and that's what the driver does when do when application passes
>>  while doing the selection. If application does not
>> specify explicitly whether to round down or round up the cropping
>> parameters requested by it (i.e app is neither passing V4L2_SEL_FLAG_LE
>> nor V4L2_SEL_FLAG_GE flags), then it is preferred by driver to round the
>> cropping parameters to nearest possible value by either rounding down or
>> rounding up to align with hardware requirements.
>>
>> For e.g. If requested width for cropping region is 127 and HW requires
>> width to be multiple of 64 then we would prefer to round it up to 128
>> rather than rounding down to a more distant value (i.e. 64), but if
>> requested cropping width is 129 then we would prefer to instead round it
>> down to 128. But if requested cropping width is 160 then there are two
>> nearest possible values 160 - 32 = 128 and 160 + 32 = 192 and in which
>> case we prefer the smaller value as you suggested and that's why the
>> driver uses round_closest_down.
>>
>> For any reason, if still the cropping rectangle falls beyond the bound
>> region, then driver will return out of range error (-ERANGE) to
>> application.
> 
> I would appreciate if this change was based on specification text, meaning
> improving the next if that behaviour is undefined. We might not be able to fix
> it everywhere, but we can recommend something.
> 

Yes, this change is based on specification text. This complies with the
VIDIOC_G_SELECTION, VIDIOC_S_SELECTION ioctl description as documented in
v4l uapi [1] which means driver should choose crop rectangle as close as
possible if no flags are passed by user-space, as quoted below :

"``0`` - The driver can adjust the rectangle size freely and shall
 choose a crop/compose rectangle as close as possible to the requested
 one."

If the user-space has specific requirement to either round down, round up or
honor exact values, it should pass V4L2_SEL_FLAG_LE, V4L2_SEL_FLAG_GE or
V4L2_SEL_FLAG_LE | V4L2_SEL_FLAG_GE flags respectively.

[1]
https://www.kernel.org/doc/Documentation/userspace-api/media/v4l/vidioc-g-selection.rst#:~:text=compose%20rectangle%20as-,close,-as%20possible%20to

Regards
Devarsh

Re: [PATCH] dt-bindings: display: synopsys,dw-hdmi: Document ddc-i2c-bus in core

[Liu Ying]

On 5/15/24 06:04, Marek Vasut wrote:
> The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' property,
> move the property description into the DW HDMI common DT schema too, so this
> property can be used on all devices integrating the DW HDMI core.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Andrzej Hajda 
> Cc: Conor Dooley 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Fabio Estevam 
> Cc: Jernej Skrabec 
> Cc: Jonas Karlman 
> Cc: Krzysztof Kozlowski 
> Cc: Laurent Pinchart 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Neil Armstrong 
> Cc: Pengutronix Kernel Team 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Robert Foss 
> Cc: Sascha Hauer 
> Cc: Shawn Guo 
> Cc: Thomas Zimmermann 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: i...@lists.linux.dev
> Cc: ker...@dh-electronics.com
> Cc: linux-arm-ker...@lists.infradead.org
> ---
>  .../bindings/display/bridge/synopsys,dw-hdmi.yaml | 8 
>  .../devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml| 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)

Cc'ed Mark Yao.

rockchip,dw-hdmi.yaml documents ddc-i2c-bus too. Drop it?

Regards,
Liu Ying

> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
> index 4b7e54a8f037f..828709a8ded26 100644
> --- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
> @@ -45,6 +45,14 @@ properties:
>- const: isfr
>  additionalItems: true
>  
> +  ddc-i2c-bus:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> +  The HDMI DDC bus can be connected to either a system I2C master or the
> +  functionally-reduced I2C master contained in the DWC HDMI. When 
> connected
> +  to a system I2C master this property contains a phandle to that I2C
> +  master controller.
> +
>interrupts:
>  maxItems: 1
>  
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> index 7979cf07f1199..180c4b510fb12 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> @@ -31,14 +31,6 @@ properties:
>clock-names:
>  maxItems: 2
>  
> -  ddc-i2c-bus:
> -$ref: /schemas/types.yaml#/definitions/phandle
> -description:
> -  The HDMI DDC bus can be connected to either a system I2C master or the
> -  functionally-reduced I2C master contained in the DWC HDMI. When 
> connected
> -  to a system I2C master this property contains a phandle to that I2C
> -  master controller.
> -
>gpr:
>  $ref: /schemas/types.yaml#/definitions/phandle
>  description:

[PATCH] nouveau: set placement to original placement on uvmm validate.

[Dave Airlie]

From: Dave Airlie 

When a buffer is evicted for memory pressure or TTM evict all,
the placement is set to the eviction domain, this means the
buffer never gets revalidated on the next exec to the correct domain.

I think this should be fine to use the initial domain from the
object creation, as least with VM_BIND this won't change after
init so this should be the correct answer.

Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Cc: Danilo Krummrich 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_uvmm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c 
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index ee02cd833c5e..84a36fe7c37d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1803,6 +1803,7 @@ nouveau_uvmm_bo_validate(struct drm_gpuvm_bo *vm_bo, 
struct drm_exec *exec)
 {
struct nouveau_bo *nvbo = nouveau_gem_object(vm_bo->obj);
 
+   nouveau_bo_placement_set(nvbo, nvbo->valid_domains, 0);
return nouveau_bo_validate(nvbo, true, false);
 }
 
-- 
2.45.0

[v7 7/7] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel

[Cong Yang]

The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
Reviewed-by: Linus Walleij 
---
Chage since V7:

- Fine tune HFP/HBP/CLK to increase the frame rate to 60.01Hz.

V6: 
https://lore.kernel.org/all/20240511021326.288728-8-yangco...@huaqin.corp-partner.google.com

Chage since V6:

- Add hx83102_enable_extended_cmds(_ctx, false) at end of inital cmds.

V5: 
https://lore.kernel.org/all/20240509015207.3271370-8-yangco...@huaqin.corp-partner.google.com

Chage since V5:

- Adjust inital cmds indentation and check accum_err before calling mdelay in 
init().
- Adjust somes inital cmds to Optimize gamma.

V4: 
https://lore.kernel.org/all/20240507135234.1356855-8-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- inital cmds use lowercasehex.

V3: 
https://lore.kernel.org/all/20240424023010.2099949-8-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- Depend Dous'series [1].
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org

V2: 
https://lore.kernel.org/all/20240422090310.3311429-8-yangco...@huaqin.corp-partner.google.com

---
 drivers/gpu/drm/panel/panel-himax-hx83102.c | 132 
 1 file changed, 132 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c 
b/drivers/gpu/drm/panel/panel-himax-hx83102.c
index 9464996e4ebd..fd3a5a132e72 100644
--- a/drivers/gpu/drm/panel/panel-himax-hx83102.c
+++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c
@@ -293,6 +293,113 @@ static int boe_nv110wum_init(struct hx83102 *ctx)
return 0;
 };
 
+static int ivo_t109nw41_init(struct hx83102 *ctx)
+{
+   struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
+
+   msleep(60);
+
+   hx83102_enable_extended_cmds(_ctx, true);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPOWER, 0x2c, 0xed, 
0xed, 0x0f, 0xcf, 0x42,
+0xf5, 0x39, 0x36, 0x36, 0x36, 0x36, 0x32, 
0x8b, 0x11, 0x65, 0x00, 0x88,
+0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 0xd6, 
0x33);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETDISP, 0x00, 0x47, 
0xb0, 0x80, 0x00, 0x12,
+0x71, 0x3c, 0xa3, 0x22, 0x20, 0x00, 0x00, 
0x88, 0x01);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCYC, 0x35, 0x35, 
0x43, 0x43, 0x35, 0x35,
+0x30, 0x7a, 0x30, 0x7a, 0x01, 0x9d);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcd);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETMIPI, 0x84);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETVDC, 0x1b, 0x04);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_UNKNOWN_BE, 0x20);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPTBA, 0xfc, 0xc4);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSTBA, 0x34, 0x34, 
0x22, 0x11, 0x22, 0xa0,
+0x31, 0x08, 0xf5, 0x03);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcc);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTCON, 0x80);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xd3);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTCON, 0x22);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc6);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETRAMDMY, 0x97);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPWM, 0x00, 0x1e, 
0x13, 0x88, 0x01);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCLOCK, 0x08, 0x13, 
0x07, 0x00, 0x0f, 0x34);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPANEL, 0x02, 0x03, 
0x44);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc4);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCASCADE, 0x03);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPCTRL, 0x07, 0x06, 
0x00, 0x02, 0x04, 0x2c,
+0xff);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP0, 0x06, 0x00, 
0x00, 0x00, 0x00, 0x08,
+0x08, 0x08, 0x08, 0x37, 0x07, 0x64, 0x7c, 
0x11, 0x11, 0x03, 0x03, 0x32,
+0x10, 0x0e, 0x00, 0x0e, 0x32, 0x17, 0x97, 
0x07, 0x97, 0x32, 0x00, 0x02,
+0x00, 0x02, 0x00, 0x00);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP1, 0x25, 0x24, 
0x25, 0x24, 0x18, 0x18,
+0x18, 0x18, 0x07, 0x06, 0x07, 0x06, 0x05, 
0x04, 0x05, 0x04, 0x03, 0x02,
+ 

[v7 6/7] dt-bindings: display: panel: Add compatible for IVO t109nw41

[Cong Yang]

The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
Acked-by: Conor Dooley 
---
Chage since V7:

- No change.

V6: 
https://lore.kernel.org/all/20240511021326.288728-7-yangco...@huaqin.corp-partner.google.com

Chage since V6:

- No change.

V5: 
https://lore.kernel.org/all/20240509015207.3271370-7-yangco...@huaqin.corp-partner.google.com

Chage since V5:

- No change.

V4: 
https://lore.kernel.org/all/20240507135234.1356855-7-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- No change.

V3: 
https://lore.kernel.org/all/20240424023010.2099949-7-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- Update commit message.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-7-yangco...@huaqin.corp-partner.google.com/

---
 .../devicetree/bindings/display/panel/himax,hx83102.yaml| 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml 
b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
index baf8b053e375..c649fb085833 100644
--- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
@@ -18,6 +18,8 @@ properties:
   - enum:
   # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel
   - boe,nv110wum-l60
+  # IVO t109nw41 11.0" WUXGA TFT LCD panel
+  - ivo,t109nw41
   # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
   - starry,himax83102-j02
   - const: himax,hx83102
-- 
2.25.1

[v7 5/7] drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel

[Cong Yang]

The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
Reviewed-by: Linus Walleij 
---
Chage since V7:

- Fine tune HFP/HBP/CLK to increase the frame rate to 60.01Hz.

V6: 
https://lore.kernel.org/all/20240511021326.288728-6-yangco...@huaqin.corp-partner.google.com

Chage since V6:

- No change.

V5: 
https://lore.kernel.org/all/20240509015207.3271370-6-yangco...@huaqin.corp-partner.google.com

Chage since V5:

- Adjust inital cmds indentation and check accum_err before calling mdelay in 
init()..

V4: 
https://lore.kernel.org/all/20240507135234.1356855-6-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- Depend Dous'series [1].
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org

V3: 
https://lore.kernel.org/all/20240424023010.2099949-6-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- inital cmds use lowercasehex.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-6-yangco...@huaqin.corp-partner.google.com

---
 drivers/gpu/drm/panel/panel-himax-hx83102.c | 133 
 1 file changed, 133 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c 
b/drivers/gpu/drm/panel/panel-himax-hx83102.c
index 8eb5864d8d26..9464996e4ebd 100644
--- a/drivers/gpu/drm/panel/panel-himax-hx83102.c
+++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c
@@ -44,6 +44,7 @@
 #define HX83102_SETGIP20xd6
 #define HX83102_SETGIP30xd8
 #define HX83102_SETGMA 0xe0
+#define HX83102_UNKNOWN_E1 0xe1
 #define HX83102_SETTP1 0xe7
 #define HX83102_SETSPCCMD  0xe9
 
@@ -185,6 +186,113 @@ static int starry_himax83102_j02_init(struct hx83102 *ctx)
return dsi_ctx.accum_err;
 };
 
+static int boe_nv110wum_init(struct hx83102 *ctx)
+{
+   struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
+
+   msleep(60);
+
+   hx83102_enable_extended_cmds(_ctx, true);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPOWER, 0x2c, 0xaf, 
0xaf, 0x2b, 0xeb, 0x42,
+0xe1, 0x4d, 0x36, 0x36, 0x36, 0x36, 0x1a, 
0x8b, 0x11, 0x65, 0x00,
+0x88, 0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 
0x9a, 0x33);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETDISP, 0x00, 0x47, 
0xb0, 0x80, 0x00, 0x12,
+0x71, 0x3c, 0xa3, 0x11, 0x00, 0x00, 0x00, 
0x88, 0xf5, 0x22, 0x8f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCYC, 0x49, 0x49, 
0x32, 0x32, 0x14, 0x32,
+0x84, 0x6e, 0x84, 0x6e, 0x01, 0x9c);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcd);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETMIPI, 0x84);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETVDC, 0x1b, 0x04);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_UNKNOWN_BE, 0x20);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPTBA, 0xfc, 0x84);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSTBA, 0x36, 0x36, 
0x22, 0x00, 0x00, 0xa0,
+0x61, 0x08, 0xf5, 0x03);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcc);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTCON, 0x80);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc6);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETRAMDMY, 0x97);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPWM, 0x00, 0x1e, 
0x30, 0xd4, 0x01);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCLOCK, 0x08, 0x13, 
0x07, 0x00, 0x0f, 0x34);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPANEL, 0x02, 0x03, 
0x44);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc4);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCASCADE, 0x03);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPCTRL, 0x37, 0x06, 
0x00, 0x02, 0x04, 0x0c, 0xff);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_UNKNOWN_D2, 0x1f, 0x11, 
0x1f, 0x11);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP0, 0x06, 0x00, 
0x00, 0x00, 0x00, 0x04,
+0x08, 0x04, 0x08, 0x37, 0x37, 0x64, 0x4b, 
0x11, 0x11, 0x03, 0x03, 0x32,
+0x10, 0x0e, 0x00, 0x0e, 0x32, 0x10, 0x0a, 
0x00, 0x0a, 0x32, 0x17, 0x98,
+0x07, 0x98, 0x00, 0x00);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP1, 0x18, 0x18, 
0x18, 0x18, 0x1e, 0x1e,
+0x1e, 0x1e, 0x1f, 0x1f, 0x1f, 0x1f, 

[v7 4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60

[Cong Yang]

The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
Acked-by: Conor Dooley 
---
Chage since V7:

- No change.

V6: 
https://lore.kernel.org/all/20240511021326.288728-5-yangco...@huaqin.corp-partner.google.com

Chage since V6:

- No change.

V5: 
https://lore.kernel.org/all/20240509015207.3271370-5-yangco...@huaqin.corp-partner.google.com

Chage since V5:

- No change.

V4: 
https://lore.kernel.org/all/20240507135234.1356855-5-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- No change.

V3: 
https://lore.kernel.org/all/20240424023010.2099949-5-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- Update commit message.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-5-yangco...@huaqin.corp-partner.google.com

---
 .../devicetree/bindings/display/panel/himax,hx83102.yaml| 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml 
b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
index fc584b5088ff..baf8b053e375 100644
--- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
@@ -16,6 +16,8 @@ properties:
   compatible:
 items:
   - enum:
+  # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel
+  - boe,nv110wum-l60
   # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
   - starry,himax83102-j02
   - const: himax,hx83102
-- 
2.25.1

[v7 2/7] drm/panel: himax-hx83102: Break out as separate driver

[Cong Yang]

The Starry HX83102 based mipi panel should never have been part of the boe
tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a
separate driver to enable the hx83102 controller.

In hx83102 driver, add DSI commands as macros. So it can add some panels
with same control model in the future.

In the old boe-tv101wum-nl6 driver inital cmds was invoked at the end of
prepare() function , and call 0x11 and 0x29 at end of inital. For
himax-hx83102 driver, we move 0x11 and 0x29 cmds invoked at prepare()
function.

Note:0x11 is mipi_dsi_dcs_exit_sleep_mode
 0x29 is mipi_dsi_dcs_set_display_on

[1]: 
https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
Reviewed-by: Linus Walleij 
---
Chage since V7:

-  Fix Doug comment "return ret" change to "goto poweroff".

V6: 
https://lore.kernel.org/all/20240511021326.288728-3-yangco...@huaqin.corp-partner.google.com

Chage since V6:

-  Modify Move mipi_dsi_dcs_exit_sleep_mode and  mipi_dsi_dcs_set_display_on 
from enable() to prepare().

V5: 
https://lore.kernel.org/all/20240509015207.3271370-3-yangco...@huaqin.corp-partner.google.com

Chage since V5:

-  Modify hx83102_enable_extended_cmds function and adjust inital cmds 
indentation.update commit message.
-  Move the ->init() call to be made at the end of prepare() instead of the 
beginning of enable().

V4: 
https://lore.kernel.org/all/20240507135234.1356855-3-yangco...@huaqin.corp-partner.google.com

Chage since V4:

-  Add hx83102_enable_extended_cmds function, rename UNKNOWN CMDS and depend 
Dous'series [1].
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org

V3: 
https://lore.kernel.org/all/20240424023010.2099949-3-yangco...@huaqin.corp-partner.google.com

Chage since V3:

-  Drop excess flags and function, inital cmds use lowercasehex.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-3-yangco...@huaqin.corp-partner.google.com

---
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 133 -
 drivers/gpu/drm/panel/panel-himax-hx83102.c   | 473 ++
 4 files changed, 483 insertions(+), 133 deletions(-)
 create mode 100644 drivers/gpu/drm/panel/panel-himax-hx83102.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d037b3b8b999..acd3d09b5a05 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -145,6 +145,15 @@ config DRM_PANEL_LVDS
  handling of power supplies or control signals. It implements automatic
  backlight handling if the panel is attached to a backlight controller.
 
+config DRM_PANEL_HIMAX_HX83102
+   tristate "Himax HX83102-based panels"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Himax HX83102 controller.
+
 config DRM_PANEL_HIMAX_HX83112A
tristate "Himax HX83112A-based DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f156d7fa0bcc..8fa9e38382f6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
 obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
 obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
 obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX83102) += panel-himax-hx83102.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index aab60cec0603..4b4b125a6c6b 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1399,108 +1399,6 @@ static int starry_qfh032011_53g_init(struct boe_panel 
*boe)
return 0;
 };
 
-static int starry_himax83102_j02_init(struct boe_panel *boe)
-{
-   struct mipi_dsi_multi_context ctx = { .dsi = boe->dsi };
-
-   mipi_dsi_dcs_write_seq_multi(, 0xb9, 0x83, 0x10, 0x21, 0x55, 0x00);
-   mipi_dsi_dcs_write_seq_multi(, 0xb1, 0x2c, 0xb5, 0xb5, 0x31, 0xf1, 
0x31, 0xd7, 0x2f,
-0x36, 0x36, 0x36, 0x36, 0x1a, 0x8b, 0x11, 
0x65, 0x00, 0x88,
-0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 0x74, 
0x33);
-   mipi_dsi_dcs_write_seq_multi(, 0xb2, 0x00, 0x47, 0xb0, 0x80, 0x00, 
0x12, 0x72, 0x3c,
-0xa3, 0x03, 0x03, 0x00, 0x00, 0x88, 0xf5);
-   mipi_dsi_dcs_write_seq_multi(, 0xb4, 0x76, 

[v7 3/7] arm64: defconfig: Enable HIMAX_HX83102 panel

[Cong Yang]

DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
Since the arm64 defconfig had the BOE panel driver enabled, let's also
enable the himax driver.

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2c30d617e180..687c86ddaece 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -864,6 +864,7 @@ CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
 CONFIG_DRM_PANEL_LVDS=m
 CONFIG_DRM_PANEL_SIMPLE=m
 CONFIG_DRM_PANEL_EDP=m
+CONFIG_DRM_PANEL_HIMAX_HX83102=m
 CONFIG_DRM_PANEL_ILITEK_ILI9882T=m
 CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m
 CONFIG_DRM_PANEL_RAYDIUM_RM67191=m
-- 
2.25.1

[v7 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings

[Cong Yang]

In V1, discussed with Doug and Linus [1], we need break out as separate
driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02"
and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same
controller, they have some common CMDS. So add new documentation for
this panels.

For himax83102-j02 controller, no need 3v3 supply, so remove it.

[1]: 
https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com

Signed-off-by: Cong Yang 
Reviewed-by: Conor Dooley 
---
Chage since V7:

- No change.

V6: 
https://lore.kernel.org/all/20240511021326.288728-2-yangco...@huaqin.corp-partner.google.com

Chage since V6:

- No change.

V5: 
https://lore.kernel.org/all/20240509015207.3271370-2-yangco...@huaqin.corp-partner.google.com

Chage since V5:

- Modify compatible format.

V4: 
https://lore.kernel.org/all/20240507135234.1356855-2-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- Update commit message and add fallback compatible.

V3: 
https://lore.kernel.org/all/20240424023010.2099949-2-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- Update commit message.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-2-yangco...@huaqin.corp-partner.google.com
---
 .../display/panel/boe,tv101wum-nl6.yaml   |  2 -
 .../bindings/display/panel/himax,hx83102.yaml | 73 +++
 2 files changed, 73 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml 
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
index 906ef62709b8..53fb35f5c9de 100644
--- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -32,8 +32,6 @@ properties:
   - innolux,hj110iz-01a
 # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
   - starry,2081101qfh032011-53g
-# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
-  - starry,himax83102-j02
 # STARRY ili9882t 10.51" WUXGA TFT LCD panel
   - starry,ili9882t
 
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml 
b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
new file mode 100644
index ..fc584b5088ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83102.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83102 MIPI-DSI LCD panel controller
+
+maintainers:
+  - Cong Yang 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+items:
+  - enum:
+  # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
+  - starry,himax83102-j02
+  - const: himax,hx83102
+
+  reg:
+description: the virtual channel number of a DSI peripheral
+
+  enable-gpios:
+description: a GPIO spec for the enable pin
+
+  pp1800-supply:
+description: core voltage supply
+
+  avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+  avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+  backlight: true
+  port: true
+  rotation: true
+
+required:
+  - compatible
+  - reg
+  - enable-gpios
+  - pp1800-supply
+  - avdd-supply
+  - avee-supply
+
+additionalProperties: false
+
+examples:
+  - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "starry,himax83102-j02", "himax,hx83102";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
-- 
2.25.1

[PATCH v7 0/7] Break out as separate driver and add BOE nv110wum-l60 IVO t109nw41 MIPI-DSI panel

[Cong Yang]

Discussion with Doug and Linus in V1, we need a
separate driver to enable the hx83102 controller.

So this series this series mainly Break out as separate driver
for Starry-himax83102-j02 panels from boe tv101wum driver.

Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver.

Add compatible for BOE nv110wum-l60 and IVO t109nw41
in dt-bindings

Note:this series depend Dous'series [1]
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org/

Changes in v7:
- PATCH 1/7: No change.
- PATCH 2/7: Fix Doug comment "return ret" change to "goto poweroff".
- PATCH 3/7: No change.
- PATCH 4/7: No change.
- PATCH 5/7: Fine tune HFP/HBP/CLK to increase the frame rate to 60.01Hz.
- PATCH 6/7: No change.
- PATCH 7/7: Fine tune HFP/HBP/CLK to increase the frame rate to 60.01Hz.
- Link to 
v6:https://lore.kernel.org/all/20240511021326.288728-1-yangco...@huaqin.corp-partner.google.com/

Changes in v6:
- PATCH 1/7: No change.
- PATCH 2/7: Modify Move mipi_dsi_dcs_exit_sleep_mode and  
mipi_dsi_dcs_set_display_on from enable() to prepare().
- PATCH 3/7: No change.
- PATCH 4/7: No change.
- PATCH 5/7: No change.
- PATCH 6/7: No change.
- PATCH 7/7: - Adjust inital cmds indentation and check accum_err before 
calling mdelay in init().
-Adjust somes inital cmds to Optimize gamma.
- Link to 
v5:https://lore.kernel.org/all/20240509015207.3271370-1-yangco...@huaqin.corp-partner.google.com/

Changes in v5:
- PATCH 1/7: Modify compatible format.
- PATCH 2/7: Modify hx83102_enable_extended_cmds function and adjust inital 
cmds indentation.update commit message.
- PATCH 3/7: No change.
- PATCH 4/7: No change.
- PATCH 5/7: Adjust inital cmds indentation and check accum_err before calling 
mdelay in init().
- PATCH 6/7: No change.
- PATCH 7/7: Adjust inital cmds indentation and check accum_err before calling 
mdelay in init().
- Link to 
v4:https://lore.kernel.org/all/20240507135234.1356855-1-yangco...@huaqin.corp-partner.google.com

Changes in v4:
- PATCH 1/7: Update commit message and add fallback compatible.
- PATCH 2/7: Add hx83102_enable_extended_cmds function, rename UNKNOWN CMDS and 
depend Dous'series [1].
- PATCH 3/7: No change.
- PATCH 4/7: No change.
- PATCH 5/7: Depend Dous'series [1].
- PATCH 6/7: No change.
- PATCH 7/7: Depend Dous'series [1].
- Link to 
v3:https://lore.kernel.org/all/20240424023010.2099949-1-yangco...@huaqin.corp-partner.google.com/

Changes in v3:
- PATCH 1/7: Update commit message.
- PATCH 2/7: Drop excess flags and function, inital cmds use lowercasehex.
- PATCH 4/7: Update commit message.
- PATCH 5/7: inital cmds use lowercasehex.
- PATCH 6/7: Update commit message.
- PATCH 7/7: inital cmds use lowercasehex..
- Link to v2: 
https://lore.kernel.org/all/20240422090310.3311429-1-yangco...@huaqin.corp-partner.google.com/

Changes in v2:
- PATCH 1/7: Delete Starry-himax83102-j02 from boe,tv101wum-nl6.yaml, add a new 
bindings file.
- PATCH 2/7: Break out as separate driver with Starry-himax83102-j02 panels.
- PATCH 3/7: Enable HIMAX_HX83102 panel.
- PATCH 4/7: Add compatible for BOE nv110wum-l60 in dt-bindings.
- PATCH 5/7: Support for BOE nv110wum-l60 MIPI-DSI panel.
- PATCH 6/7: Add compatible for IVO t109nw41 in dt-bindings..
- PATCH 7/7: Support for IVO t109nw41 MIPI-DSI panel.
- Link to v1: 
https://lore.kernel.org/all/20240410071439.2152588-1-yangco...@huaqin.corp-partner.google.com/

Cong Yang (7):
  dt-bindings: display: panel: Add himax hx83102 panel bindings
  drm/panel: himax-hx83102: Break out as separate driver
  arm64: defconfig: Enable HIMAX_HX83102 panel
  dt-bindings: display: panel: Add compatible for BOE nv110wum-l60
  drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel
  dt-bindings: display: panel: Add compatible for IVO t109nw41
  drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel

 .../display/panel/boe,tv101wum-nl6.yaml   |   2 -
 .../bindings/display/panel/himax,hx83102.yaml |  77 ++
 arch/arm64/configs/defconfig  |   1 +
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 133 
 drivers/gpu/drm/panel/panel-himax-hx83102.c   | 738 ++
 7 files changed, 826 insertions(+), 135 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-himax-hx83102.c

-- 
2.25.1

Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs

[Matthew Brost]

On Tue, May 14, 2024 at 11:15:55PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 14.05.2024 22:31, Matthew Brost wrote:
> > On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:
> >> On 5/14/2024 07:58, Michal Wajdeczko wrote:
> >>> On 13.05.2024 18:53, John Harrison wrote:
>  On 5/12/2024 08:36, Michal Wajdeczko wrote:
> > We already provide the content of the GuC log in debugsfs, but it
> > is in a text format where each log dword is printed as hexadecimal
> > number, which does not scale well with large GuC log buffers.
> >
> > To allow more efficient access to the GuC log, which could benefit
> > our CI systems, expose raw binary log data.  In addition to less
> > overhead in preparing text based GuC log file, the new GuC log file
> > in binary format is also almost 3x smaller.
> >
> > Any existing script that expects the GuC log buffer in text format
> > can use command like below to convert from new binary format:
> >
> >  hexdump -e '4/4 "0x%08x " "\n"'
> >
> > but this shouldn't be the case as most decoders expect GuC log data
> > in binary format.
>  I strongly disagree with this.
> 
>  Efficiency and file size is not an issue when accessing the GuC log via
>  debugfs on actual hardware.
> >>> to some extend it is as CI team used to refuse to collect GuC logs after
> >>> each executed test just because of it's size
> >> I've never heard that argument. I've heard many different arguments but not
> >> one about file size. The default GuC log size is pretty tiny. So size 
> >> really
> >> is not an issue.
> >>
> >>>
>  It is an issue when dumping via dmesg but
>  you definitely should not be dumping binary data to dmesg. Whereas,
> >>> not following here - this is debugfs specific, not a dmesg printer
> >> Except that it is preferable to have common code for both if at all
> >> possible.
> >>
> >>>
>  dumping in binary data is much more dangerous and liable to corruption
>  because some tool along the way tries to convert to ASCII, or truncates
>  at the first zero, etc. We request GuC logs be sent by end users,
>  customer bug reports, etc. all doing things that we have no control over.
> >>> hmm, how "cp gt0/uc/guc_log_raw FILE" could end with a corrupted file ?
> >> Because someone then tries to email it, or attach it or copy it via Windows
> >> or any number of other ways in which a file can get munged.
> >>
> >>>
>  Converting the hexdump back to binary is trivial for those tools which
>  require it. If you follow the acquisition and decoding instructions on
>  the wiki page then it is all done for you automatically.
> >>> I'm afraid I don't know where this wiki page is, but I do know that hex
> >>> conversion dance is not needed for me to get decoded GuC log the way I
> >>> used to do
> >> Look for the 'GuC Debug Logs' page on the developer wiki. It's pretty easy
> >> to find.
> >>
>  These patches are trying to solve a problem which does not exist and are
>  going to make working with GuC logs harder and more error prone.
> >>> it at least solves the problem of currently super inefficient way of
> >>> generating the GuC log in text format.
> >>>
> >>> it also opens other opportunities to develop tools that could monitor or
> >>> capture GuC log independently on  top of what driver is able to offer
> >>> today (on i915 there was guc-log-relay, but it was broken for long time,
> >>> not sure what are the plans for Xe)
> >>>
> >>> also still not sure how it can be more error prone.
> >> As already explained, the plan is move to LFD - an extensible, streamable,
> >> logging format. Any non-trivial effort that is not helping to move to LFD 
> >> is
> >> not worth the effort.
> >>
> >>>
>  On the other hand, there are many other issues with GuC logs that it
>  would be useful to solves - including extra meta data, reliable output
>  via dmesg, continuous streaming, pre-sizing the debugfs file to not have
>  to generate it ~12 times for a single read, etc.
> >>> this series actually solves last issue but in a bit different way (we
> >>> even don't need to generate full GuC log dump at all if we would like to
> >>> capture only part of the log if we know where to look)
> >> No, it doesn't solve it. Your comment below suggests it will be read in 4KB
> >> chunks. Which means your 16MB buffer now requires 4096 separate reads! And
> >> you only doing partial reads of the section you think you need is never
> >> going to be reliable on live system. Not sure why you would want to anyway.
> >> It is just making things much more complex. You now need an intelligent 
> >> user
> >> land program to read the log out and decode at least the header section to
> >> know what data section to read. You can't just dump the whole thing with
> >> 'cat' or 'dd'.
> >>
> > 
> > Briefly have read this thread but seconding John's opinion that anything
> > which breaks GuC 

Re: [PATCH] drm/msm: Add obj flags to gpu devcoredump

[Konrad Dybcio]

On 5/13/24 17:51, Rob Clark wrote:

From: Rob Clark 

When debugging faults, it is useful to know how the BO is mapped (cached
vs WC, gpu readonly, etc).

Signed-off-by: Rob Clark 
---


Acked-by: Konrad Dybcio 

Konrad

Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs

[John Harrison]

On 5/14/2024 13:41, Michal Wajdeczko wrote:

On 14.05.2024 20:13, John Harrison wrote:

On 5/14/2024 07:58, Michal Wajdeczko wrote:

On 13.05.2024 18:53, John Harrison wrote:

On 5/12/2024 08:36, Michal Wajdeczko wrote:

We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale well with large GuC log buffers.

To allow more efficient access to the GuC log, which could benefit
our CI systems, expose raw binary log data.  In addition to less
overhead in preparing text based GuC log file, the new GuC log file
in binary format is also almost 3x smaller.

Any existing script that expects the GuC log buffer in text format
can use command like below to convert from new binary format:

  hexdump -e '4/4 "0x%08x " "\n"'

but this shouldn't be the case as most decoders expect GuC log data
in binary format.

I strongly disagree with this.

Efficiency and file size is not an issue when accessing the GuC log via
debugfs on actual hardware.

to some extend it is as CI team used to refuse to collect GuC logs after
each executed test just because of it's size

I've never heard that argument. I've heard many different arguments but
not one about file size. The default GuC log size is pretty tiny. So
size really is not an issue.

so it's tiny or 16MB as you mention below ?
The default size is tiny. The maximum allowed is 16MB. By default, you 
get tiny logs. When a developer is debugging a specific issue and needs 
larger logs, they can bump the size up to 16MB.





It is an issue when dumping via dmesg but
you definitely should not be dumping binary data to dmesg. Whereas,

not following here - this is debugfs specific, not a dmesg printer

Except that it is preferable to have common code for both if at all
possible.

but here, for debugfs, it's almost no code, it's 1-liner thanks to using
generic helpers, so there is really nothing to share as common code

note that with this separate raw access to guc log over debugfs, you can
further customize xe_guc_log_dump() function for dmesg output [2]
without worrying about impact in generating output to debugfs

[2] https://patchwork.freedesktop.org/series/133349/
Or, we could put all this extra effort into doing something with 
tangible benefit. I've probably already spent more time arguing about 
this patch than it took to implement it. Time I would much rather be 
doing something useful with.


And my point was that the dump size is only relevant for dmesg. For 
debugfs, the size simply does not matter. So trying to optimise the 
debugfs dump size but with a downside of making it more difficult to use 
and more susceptible to issues is a bad trade off that we should not be 
making.





dumping in binary data is much more dangerous and liable to corruption
because some tool along the way tries to convert to ASCII, or truncates
at the first zero, etc. We request GuC logs be sent by end users,
customer bug reports, etc. all doing things that we have no control
over.

hmm, how "cp gt0/uc/guc_log_raw FILE" could end with a corrupted file ?

Because someone then tries to email it, or attach it or copy it via
Windows or any number of other ways in which a file can get munged.

no comment


Converting the hexdump back to binary is trivial for those tools which
require it. If you follow the acquisition and decoding instructions on
the wiki page then it is all done for you automatically.

I'm afraid I don't know where this wiki page is, but I do know that hex
conversion dance is not needed for me to get decoded GuC log the way I
used to do

Look for the 'GuC Debug Logs' page on the developer wiki. It's pretty
easy to find.

ok, found it

btw, it says "Actual log size will be significantly more (about 50MB) as
there are multiple sections."
16MB debug log, 1MB crash dump, 1MB register capture -> 18MB actual data 
size, expands to about 50MB as an ASCII hexdump.





These patches are trying to solve a problem which does not exist and are
going to make working with GuC logs harder and more error prone.

it at least solves the problem of currently super inefficient way of
generating the GuC log in text format.

it also opens other opportunities to develop tools that could monitor or
capture GuC log independently on  top of what driver is able to offer
today (on i915 there was guc-log-relay, but it was broken for long time,
not sure what are the plans for Xe)

also still not sure how it can be more error prone.

As already explained, the plan is move to LFD - an extensible,
streamable, logging format. Any non-trivial effort that is not helping
to move to LFD is not worth the effort.

which part from my series was non-trivial ?

The doing it properly part.

If you want a functional streaming interface then you will need a lot 
more than a backdoor access to the GuC log memory buffer. You will need 
all the user land code to interpret it, do the streaming, cope with 
wrap-arounds, 

[PATCH] dt-bindings: display: synopsys, dw-hdmi: Document ddc-i2c-bus in core

[Marek Vasut]

The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' property,
move the property description into the DW HDMI common DT schema too, so this
property can be used on all devices integrating the DW HDMI core.

Signed-off-by: Marek Vasut 
---
Cc: Andrzej Hajda 
Cc: Conor Dooley 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Fabio Estevam 
Cc: Jernej Skrabec 
Cc: Jonas Karlman 
Cc: Krzysztof Kozlowski 
Cc: Laurent Pinchart 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Pengutronix Kernel Team 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Robert Foss 
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: Thomas Zimmermann 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: i...@lists.linux.dev
Cc: ker...@dh-electronics.com
Cc: linux-arm-ker...@lists.infradead.org
---
 .../bindings/display/bridge/synopsys,dw-hdmi.yaml | 8 
 .../devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml| 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
index 4b7e54a8f037f..828709a8ded26 100644
--- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
@@ -45,6 +45,14 @@ properties:
   - const: isfr
 additionalItems: true
 
+  ddc-i2c-bus:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  The HDMI DDC bus can be connected to either a system I2C master or the
+  functionally-reduced I2C master contained in the DWC HDMI. When connected
+  to a system I2C master this property contains a phandle to that I2C
+  master controller.
+
   interrupts:
 maxItems: 1
 
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
index 7979cf07f1199..180c4b510fb12 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
@@ -31,14 +31,6 @@ properties:
   clock-names:
 maxItems: 2
 
-  ddc-i2c-bus:
-$ref: /schemas/types.yaml#/definitions/phandle
-description:
-  The HDMI DDC bus can be connected to either a system I2C master or the
-  functionally-reduced I2C master contained in the DWC HDMI. When connected
-  to a system I2C master this property contains a phandle to that I2C
-  master controller.
-
   gpr:
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
-- 
2.43.0

Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs

[John Harrison]

On 5/14/2024 14:15, Michal Wajdeczko wrote:

On 14.05.2024 22:31, Matthew Brost wrote:

On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:

On 5/14/2024 07:58, Michal Wajdeczko wrote:

On 13.05.2024 18:53, John Harrison wrote:

On 5/12/2024 08:36, Michal Wajdeczko wrote:

We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale well with large GuC log buffers.

To allow more efficient access to the GuC log, which could benefit
our CI systems, expose raw binary log data.  In addition to less
overhead in preparing text based GuC log file, the new GuC log file
in binary format is also almost 3x smaller.

Any existing script that expects the GuC log buffer in text format
can use command like below to convert from new binary format:

  hexdump -e '4/4 "0x%08x " "\n"'

but this shouldn't be the case as most decoders expect GuC log data
in binary format.

I strongly disagree with this.

Efficiency and file size is not an issue when accessing the GuC log via
debugfs on actual hardware.

to some extend it is as CI team used to refuse to collect GuC logs after
each executed test just because of it's size

I've never heard that argument. I've heard many different arguments but not
one about file size. The default GuC log size is pretty tiny. So size really
is not an issue.


It is an issue when dumping via dmesg but
you definitely should not be dumping binary data to dmesg. Whereas,

not following here - this is debugfs specific, not a dmesg printer

Except that it is preferable to have common code for both if at all
possible.


dumping in binary data is much more dangerous and liable to corruption
because some tool along the way tries to convert to ASCII, or truncates
at the first zero, etc. We request GuC logs be sent by end users,
customer bug reports, etc. all doing things that we have no control over.

hmm, how "cp gt0/uc/guc_log_raw FILE" could end with a corrupted file ?

Because someone then tries to email it, or attach it or copy it via Windows
or any number of other ways in which a file can get munged.


Converting the hexdump back to binary is trivial for those tools which
require it. If you follow the acquisition and decoding instructions on
the wiki page then it is all done for you automatically.

I'm afraid I don't know where this wiki page is, but I do know that hex
conversion dance is not needed for me to get decoded GuC log the way I
used to do

Look for the 'GuC Debug Logs' page on the developer wiki. It's pretty easy
to find.


These patches are trying to solve a problem which does not exist and are
going to make working with GuC logs harder and more error prone.

it at least solves the problem of currently super inefficient way of
generating the GuC log in text format.

it also opens other opportunities to develop tools that could monitor or
capture GuC log independently on  top of what driver is able to offer
today (on i915 there was guc-log-relay, but it was broken for long time,
not sure what are the plans for Xe)

also still not sure how it can be more error prone.

As already explained, the plan is move to LFD - an extensible, streamable,
logging format. Any non-trivial effort that is not helping to move to LFD is
not worth the effort.


On the other hand, there are many other issues with GuC logs that it
would be useful to solves - including extra meta data, reliable output
via dmesg, continuous streaming, pre-sizing the debugfs file to not have
to generate it ~12 times for a single read, etc.

this series actually solves last issue but in a bit different way (we
even don't need to generate full GuC log dump at all if we would like to
capture only part of the log if we know where to look)

No, it doesn't solve it. Your comment below suggests it will be read in 4KB
chunks. Which means your 16MB buffer now requires 4096 separate reads! And
you only doing partial reads of the section you think you need is never
going to be reliable on live system. Not sure why you would want to anyway.
It is just making things much more complex. You now need an intelligent user
land program to read the log out and decode at least the header section to
know what data section to read. You can't just dump the whole thing with
'cat' or 'dd'.


Briefly have read this thread but seconding John's opinion that anything
which breaks GuC log collection via a simple command like cat is a no

hexdump or cp is also a simple command and likely we can assume that
either user will know what command to use or will just type the command
that we say.


go. Also anything that can allow windows to mangle the output would be
less than idle too. Lastly, GuC log collection is not a critical path
operation so it likely does not need to optimized for speed.

but please remember that this patch does not change anything to the
existing debugfs files, the guc_log stays as is, this new raw access is
defined as another 

RE: dma-buf sg mangling

[Kasireddy, Vivek]

Hi Rob,

> 
> On Mon, May 13, 2024 at 11:27 AM Christian König
>  wrote:
> >
> > Am 10.05.24 um 18:34 schrieb Zack Rusin:
> > > Hey,
> > >
> > > so this is a bit of a silly problem but I'd still like to solve it
> > > properly. The tldr is that virtualized drivers abuse
> > > drm_driver::gem_prime_import_sg_table (at least vmwgfx and xen do,
> > > virtgpu and xen punt on it) because there doesn't seem to be a
> > > universally supported way of converting the sg_table back to a list of
> > > pages without some form of gart to do it.
> >
> > Well the whole point is that you should never touch the pages in the
> > sg_table in the first place.
> >
> > The long term plan is actually to completely remove the pages from that
> > interface.
> >
> > > drm_prime_sg_to_page_array is deprecated (for all the right reasons on
> > > actual hardware) but in our cooky virtualized world we don't have
> > > gart's so what are we supposed to do with the dma_addr_t from the
> > > imported sg_table? What makes it worse (and definitely breaks xen) is
> > > that with CONFIG_DMABUF_DEBUG the sg page_link is mangled via
> > > mangle_sg_table so drm_prime_sg_to_page_array won't even work.
> >
> > XEN and KVM were actually adjusted to not touch the struct pages any
> more.
> >
> > I'm not sure if that work is already upstream or not but I had to
> > explain it over and over again why their approach doesn't work.
> >
> > > The reason why I'm saying it's a bit of a silly problem is that afaik
> > > currently it only affects IGT testing with vgem (because the rest of
> > > external gem objects will be from the virtualized gpu itself which is
> > > different). But do you have any ideas on what we'd like to do with
> > > this long term? i.e. we have a virtualized gpus without iommu, we have
> > > sg_table with some memory and we'd like to import it. Do we just
> > > assume that the sg_table on those configs will always reference cpu
> > > accessible memory (i.e. if it's external it only comes through
> > > drm_gem_shmem_object) and just do some horrific abomination like:
> > > for (i = 0; i < bo->ttm->num_pages; ++i) {
> > >  phys_addr_t pa = dma_to_phys(vmw->drm.dev, bo->ttm-
> >dma_address[i]);
> > >  pages[i] = pfn_to_page(PHYS_PFN(pa));
> > > }
> > > or add a "i know this is cpu accessible, please demangle" flag to
> > > drm_prime_sg_to_page_array or try to have some kind of more
> permanent
> > > solution?
> >
> > Well there is no solution for that. Accessing the underlying struct page
> > through the sg_table is illegal in the first place.
> >
> > So the question is not how to access the struct page, but rather why do
> > you want to do this?
> 
> It _think_ Zack is trying to map guest paged back buffers to the host
> GPU?  Which would require sending the pfn's in some form to the host
> vmm..
> 
> virtgpu goes the other direction with mapping host page backed GEM
> buffers to guest as "vram" (although for various reasons I kinda want
> to go in the other direction)
I just want to mention that I proposed a way for virtio-gpu to import buffers
from other GPU drivers here:
https://lore.kernel.org/dri-devel/20240328083615.2662516-1-vivek.kasire...@intel.com/

For now, this is only being used for importing scanout buffers, considering the
Mutter and Weston (additional_devices feature) use-cases.

Thanks,
Vivek

> 
> BR,
> -R
> 
> > Regards,
> > Christian.
> >
> > >
> > > z
> >

Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs

[Michal Wajdeczko]

On 14.05.2024 22:31, Matthew Brost wrote:
> On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:
>> On 5/14/2024 07:58, Michal Wajdeczko wrote:
>>> On 13.05.2024 18:53, John Harrison wrote:
 On 5/12/2024 08:36, Michal Wajdeczko wrote:
> We already provide the content of the GuC log in debugsfs, but it
> is in a text format where each log dword is printed as hexadecimal
> number, which does not scale well with large GuC log buffers.
>
> To allow more efficient access to the GuC log, which could benefit
> our CI systems, expose raw binary log data.  In addition to less
> overhead in preparing text based GuC log file, the new GuC log file
> in binary format is also almost 3x smaller.
>
> Any existing script that expects the GuC log buffer in text format
> can use command like below to convert from new binary format:
>
>  hexdump -e '4/4 "0x%08x " "\n"'
>
> but this shouldn't be the case as most decoders expect GuC log data
> in binary format.
 I strongly disagree with this.

 Efficiency and file size is not an issue when accessing the GuC log via
 debugfs on actual hardware.
>>> to some extend it is as CI team used to refuse to collect GuC logs after
>>> each executed test just because of it's size
>> I've never heard that argument. I've heard many different arguments but not
>> one about file size. The default GuC log size is pretty tiny. So size really
>> is not an issue.
>>
>>>
 It is an issue when dumping via dmesg but
 you definitely should not be dumping binary data to dmesg. Whereas,
>>> not following here - this is debugfs specific, not a dmesg printer
>> Except that it is preferable to have common code for both if at all
>> possible.
>>
>>>
 dumping in binary data is much more dangerous and liable to corruption
 because some tool along the way tries to convert to ASCII, or truncates
 at the first zero, etc. We request GuC logs be sent by end users,
 customer bug reports, etc. all doing things that we have no control over.
>>> hmm, how "cp gt0/uc/guc_log_raw FILE" could end with a corrupted file ?
>> Because someone then tries to email it, or attach it or copy it via Windows
>> or any number of other ways in which a file can get munged.
>>
>>>
 Converting the hexdump back to binary is trivial for those tools which
 require it. If you follow the acquisition and decoding instructions on
 the wiki page then it is all done for you automatically.
>>> I'm afraid I don't know where this wiki page is, but I do know that hex
>>> conversion dance is not needed for me to get decoded GuC log the way I
>>> used to do
>> Look for the 'GuC Debug Logs' page on the developer wiki. It's pretty easy
>> to find.
>>
 These patches are trying to solve a problem which does not exist and are
 going to make working with GuC logs harder and more error prone.
>>> it at least solves the problem of currently super inefficient way of
>>> generating the GuC log in text format.
>>>
>>> it also opens other opportunities to develop tools that could monitor or
>>> capture GuC log independently on  top of what driver is able to offer
>>> today (on i915 there was guc-log-relay, but it was broken for long time,
>>> not sure what are the plans for Xe)
>>>
>>> also still not sure how it can be more error prone.
>> As already explained, the plan is move to LFD - an extensible, streamable,
>> logging format. Any non-trivial effort that is not helping to move to LFD is
>> not worth the effort.
>>
>>>
 On the other hand, there are many other issues with GuC logs that it
 would be useful to solves - including extra meta data, reliable output
 via dmesg, continuous streaming, pre-sizing the debugfs file to not have
 to generate it ~12 times for a single read, etc.
>>> this series actually solves last issue but in a bit different way (we
>>> even don't need to generate full GuC log dump at all if we would like to
>>> capture only part of the log if we know where to look)
>> No, it doesn't solve it. Your comment below suggests it will be read in 4KB
>> chunks. Which means your 16MB buffer now requires 4096 separate reads! And
>> you only doing partial reads of the section you think you need is never
>> going to be reliable on live system. Not sure why you would want to anyway.
>> It is just making things much more complex. You now need an intelligent user
>> land program to read the log out and decode at least the header section to
>> know what data section to read. You can't just dump the whole thing with
>> 'cat' or 'dd'.
>>
> 
> Briefly have read this thread but seconding John's opinion that anything
> which breaks GuC log collection via a simple command like cat is a no

hexdump or cp is also a simple command and likely we can assume that
either user will know what command to use or will just type the command
that we say.

> go. Also anything that can allow windows to mangle the output 

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

[Nicolas Dufresne]

Hi,

Le mardi 14 mai 2024 à 23:45 +0300, Laurent Pinchart a écrit :
> > And finally, none of this fixes the issue that the heap allocation are not 
> > being
> > accounted properly and allow of an easy memory DoS. So uaccess should be 
> > granted
> > with care, meaning that defaulting a "desktop" library to that, means it 
> > will
> > most of the time not work at all.
> 
> I think that issue should be fixed, regardless of whether or not we end
> up using dma heaps for libcamera. If we do use them, maybe there will be
> a higher incentive for somebody involved in this conversation to tackle
> that problem first :-) And maybe, as a result, the rest of the Linux
> community will consider with a more open mind usage of dma heaps on
> desktop systems.

The strict reality is that if libcamera offer no alternatives, some OS will
enable it and reduce their security. I totally agree this issue needs to be
fixed regardless of libcamera, or even dma heaps. DMABuf allocation should be
accounted and limited to quotas whether it comes from a GPU, Display, V4L2 or
other type of supported devices. I would also not recommend dropping your heap
support (or preventing it from being merged) in libcamera.

Nicolas

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

[Laurent Pinchart]

On Mon, May 13, 2024 at 11:06:24AM -0400, Nicolas Dufresne wrote:
> Le lundi 13 mai 2024 à 15:51 +0200, Maxime Ripard a écrit :
> > On Mon, May 13, 2024 at 09:42:00AM -0400, Nicolas Dufresne wrote:
> > > Le lundi 13 mai 2024 à 10:29 +0200, Maxime Ripard a écrit :
> > > > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > > > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > > > > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit :
> > > > > > > Shorter term, we have a problem to solve, and the best option we 
> > > > > > > have
> > > > > > > found so far is to rely on dma-buf heaps as a backend for the 
> > > > > > > frame
> > > > > > > buffer allocatro helper in libcamera for the use case described 
> > > > > > > above.
> > > > > > > This won't work in 100% of the cases, clearly. It's a stop-gap 
> > > > > > > measure
> > > > > > > until we can do better.
> > > > > > 
> > > > > > Considering the security concerned raised on this thread with 
> > > > > > dmabuf heap
> > > > > > allocation not be restricted by quotas, you'd get what you want 
> > > > > > quickly with
> > > > > > memfd + udmabuf instead (which is accounted already).
> > > > > > 
> > > > > > It was raised that distro don't enable udmabuf, but as stated there 
> > > > > > by Hans, in
> > > > > > any cases distro needs to take action to make the softISP works. 
> > > > > > This
> > > > > > alternative is easy and does not interfere in anyway with your 
> > > > > > future plan or
> > > > > > the libcamera API. You could even have both dmabuf heap (for 
> > > > > > Raspbian) and the
> > > > > > safer memfd+udmabuf for the distro with security concerns.
> > > > > > 
> > > > > > And for the long term plan, we can certainly get closer by fixing 
> > > > > > that issue
> > > > > > with accounting. This issue also applied to v4l2 io-ops, so it 
> > > > > > would be nice to
> > > > > > find common set of helpers to fix these exporters.
> > > > > 
> > > > > Yeah if this is just for softisp, then memfd + udmabuf is also what I 
> > > > > was
> > > > > about to suggest. Not just as a stopgap, but as the real official 
> > > > > thing.
> > > > > 
> > > > > udmabuf does kinda allow you to pin memory, but we can easily fix 
> > > > > that by
> > > > > adding the right accounting and then either let mlock rlimits or 
> > > > > cgroups
> > > > > kernel memory limits enforce good behavior.
> > > > 
> > > > I think the main drawback with memfd is that it'll be broken for devices
> > > > without an IOMMU, and while you said that it's uncommon for GPUs, it's
> > > > definitely not for codecs and display engines.
> > > 
> > > In the context of libcamera, the allocation and the alignment done to the 
> > > video
> > > frame is done completely blindly. In that context, there is a lot more 
> > > then just
> > > the allocation type that can go wrong and will lead to a memory copy. The 
> > > upside
> > > of memfd, is that the read cache will help speeding up the copies if they 
> > > are
> > > needed.
> > 
> > dma-heaps provide cacheable buffers too...
> 
> Yes, and why we have cache hints in V4L2 now. There is no clue that softISP 
> code
> can read to make the right call. The required cache management in undefined
> until all the importer are known. I also don't think heaps currently care to
> adapt the dmabuf sync behaviour based on the different importers, or the
> addition of a new importer. On top of which, there is insufficient information
> on the device to really deduce what is needed.
> 
> > > Another important point is that this is only used if the application 
> > > haven't
> > > provided frames. If your embedded application is non-generic, and you have
> > > permissions to access the right heap, the application can solve your 
> > > specific
> > > issue. But in the generic Linux space, Linux kernel API are just 
> > > insufficient
> > > for the "just work" scenario.
> > 
> > ... but they also provide semantics around the memory buffers that no
> > other allocation API do. There's at least the mediatek secure playback
> > series and another one that I've started to work on to allocate ECC
> > protected or unprotected buffers that are just the right use case for
> > the heaps, and the target frameworks aren't.
> 
> Let's agree we are both off topic now. The libcamera softISP is currently 
> purely
> software, and cannot write to any form of protected memory. As for ECC, I 
> would
> hope this usage will be coded in the application and that this application has
> been authorized to access the appropriate heaps.
> 
> And finally, none of this fixes the issue that the heap allocation are not 
> being
> accounted properly and allow of an easy memory DoS. So uaccess should be 
> granted
> with care, meaning that defaulting a "desktop" library to that, means it will
> most of the time not work at all.

I think that issue should be fixed, regardless of whether or not we end
up using dma heaps for libcamera. If we 

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

[Laurent Pinchart]

On Mon, May 13, 2024 at 11:10:00AM -0400, Nicolas Dufresne wrote:
> Le lundi 13 mai 2024 à 11:34 +0300, Laurent Pinchart a écrit :
> > On Mon, May 13, 2024 at 10:29:22AM +0200, Maxime Ripard wrote:
> > > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > > > > Hi,
> > > > > 
> > > > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit :
> > > > > > Shorter term, we have a problem to solve, and the best option we 
> > > > > > have
> > > > > > found so far is to rely on dma-buf heaps as a backend for the frame
> > > > > > buffer allocatro helper in libcamera for the use case described 
> > > > > > above.
> > > > > > This won't work in 100% of the cases, clearly. It's a stop-gap 
> > > > > > measure
> > > > > > until we can do better.
> > > > > 
> > > > > Considering the security concerned raised on this thread with dmabuf 
> > > > > heap
> > > > > allocation not be restricted by quotas, you'd get what you want 
> > > > > quickly with
> > > > > memfd + udmabuf instead (which is accounted already).
> > > > > 
> > > > > It was raised that distro don't enable udmabuf, but as stated there 
> > > > > by Hans, in
> > > > > any cases distro needs to take action to make the softISP works. This
> > > > > alternative is easy and does not interfere in anyway with your future 
> > > > > plan or
> > > > > the libcamera API. You could even have both dmabuf heap (for 
> > > > > Raspbian) and the
> > > > > safer memfd+udmabuf for the distro with security concerns.
> > > > > 
> > > > > And for the long term plan, we can certainly get closer by fixing 
> > > > > that issue
> > > > > with accounting. This issue also applied to v4l2 io-ops, so it would 
> > > > > be nice to
> > > > > find common set of helpers to fix these exporters.
> > > > 
> > > > Yeah if this is just for softisp, then memfd + udmabuf is also what I 
> > > > was
> > > > about to suggest. Not just as a stopgap, but as the real official thing.
> > > > 
> > > > udmabuf does kinda allow you to pin memory, but we can easily fix that 
> > > > by
> > > > adding the right accounting and then either let mlock rlimits or cgroups
> > > > kernel memory limits enforce good behavior.
> > > 
> > > I think the main drawback with memfd is that it'll be broken for devices
> > > without an IOMMU, and while you said that it's uncommon for GPUs, it's
> > > definitely not for codecs and display engines.
> > 
> > If the application wants to share buffers between the camera and a
> > display engine or codec, it should arguably not use the libcamera
> > FrameBufferAllocator, but allocate the buffers from the display or the
> > encoder. memfd wouldn't be used in that case.
> > 
> > We need to eat our own dogfood though. If we want to push the
> > responsibility for buffer allocation in the buffer sharing case to the
> > application, we need to modify the cam application to do so when using
> > the KMS backend.
> 
> Agreed, and the new dmabuf feedback on wayland can also be used on top of 
> this.
> 
> You'll hit the same limitation as we hit in GStreamer, which is that KMS 
> driver
> only offer allocation for render buffers and most of them are missing 
> allocators
> for YUV buffers, even though they can import in these formats. (kms 
> allocators,
> except dumb, which has other issues, are format aware).

My experience on Arm platforms is that the KMS drivers offer allocation
for scanout buffers, not render buffers, and mostly using the dumb
allocator API. If the KMS device can scan out YUV natively, YUV buffer
allocation should be supported. Am I missing something here ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs

[Michal Wajdeczko]

On 14.05.2024 20:13, John Harrison wrote:
> On 5/14/2024 07:58, Michal Wajdeczko wrote:
>> On 13.05.2024 18:53, John Harrison wrote:
>>> On 5/12/2024 08:36, Michal Wajdeczko wrote:
 We already provide the content of the GuC log in debugsfs, but it
 is in a text format where each log dword is printed as hexadecimal
 number, which does not scale well with large GuC log buffers.

 To allow more efficient access to the GuC log, which could benefit
 our CI systems, expose raw binary log data.  In addition to less
 overhead in preparing text based GuC log file, the new GuC log file
 in binary format is also almost 3x smaller.

 Any existing script that expects the GuC log buffer in text format
 can use command like below to convert from new binary format:

  hexdump -e '4/4 "0x%08x " "\n"'

 but this shouldn't be the case as most decoders expect GuC log data
 in binary format.
>>> I strongly disagree with this.
>>>
>>> Efficiency and file size is not an issue when accessing the GuC log via
>>> debugfs on actual hardware.
>> to some extend it is as CI team used to refuse to collect GuC logs after
>> each executed test just because of it's size
> I've never heard that argument. I've heard many different arguments but
> not one about file size. The default GuC log size is pretty tiny. So
> size really is not an issue.

so it's tiny or 16MB as you mention below ?

> 
>>
>>> It is an issue when dumping via dmesg but
>>> you definitely should not be dumping binary data to dmesg. Whereas,
>> not following here - this is debugfs specific, not a dmesg printer
> Except that it is preferable to have common code for both if at all
> possible.

but here, for debugfs, it's almost no code, it's 1-liner thanks to using
generic helpers, so there is really nothing to share as common code

note that with this separate raw access to guc log over debugfs, you can
further customize xe_guc_log_dump() function for dmesg output [2]
without worrying about impact in generating output to debugfs

[2] https://patchwork.freedesktop.org/series/133349/

> 
>>
>>> dumping in binary data is much more dangerous and liable to corruption
>>> because some tool along the way tries to convert to ASCII, or truncates
>>> at the first zero, etc. We request GuC logs be sent by end users,
>>> customer bug reports, etc. all doing things that we have no control
>>> over.
>> hmm, how "cp gt0/uc/guc_log_raw FILE" could end with a corrupted file ?
> Because someone then tries to email it, or attach it or copy it via
> Windows or any number of other ways in which a file can get munged.

no comment

> 
>>
>>> Converting the hexdump back to binary is trivial for those tools which
>>> require it. If you follow the acquisition and decoding instructions on
>>> the wiki page then it is all done for you automatically.
>> I'm afraid I don't know where this wiki page is, but I do know that hex
>> conversion dance is not needed for me to get decoded GuC log the way I
>> used to do
> Look for the 'GuC Debug Logs' page on the developer wiki. It's pretty
> easy to find.

ok, found it

btw, it says "Actual log size will be significantly more (about 50MB) as
there are multiple sections."

> 
>>> These patches are trying to solve a problem which does not exist and are
>>> going to make working with GuC logs harder and more error prone.
>> it at least solves the problem of currently super inefficient way of
>> generating the GuC log in text format.
>>
>> it also opens other opportunities to develop tools that could monitor or
>> capture GuC log independently on  top of what driver is able to offer
>> today (on i915 there was guc-log-relay, but it was broken for long time,
>> not sure what are the plans for Xe)
>>
>> also still not sure how it can be more error prone.
> As already explained, the plan is move to LFD - an extensible,
> streamable, logging format. Any non-trivial effort that is not helping
> to move to LFD is not worth the effort.

which part from my series was non-trivial ?

> 
>>
>>> On the other hand, there are many other issues with GuC logs that it
>>> would be useful to solves - including extra meta data, reliable output
>>> via dmesg, continuous streaming, pre-sizing the debugfs file to not have
>>> to generate it ~12 times for a single read, etc.
>> this series actually solves last issue but in a bit different way (we
>> even don't need to generate full GuC log dump at all if we would like to
>> capture only part of the log if we know where to look)
> No, it doesn't solve it. Your comment below suggests it will be read in
> 4KB chunks. 

chunks will be 4K if we stick to proposed here simple_read_from_iomem()
that initially uses hardcoded 4K chunks, but we could either modify it
to use larger chunks by default or extend it to take additional param,
or promote more powerful copy_to_user_fromio() from SOUND

> Which means your 16MB buffer now requires 4096 separate
> reads! And you only 

Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs

[Matthew Brost]

On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:
> On 5/14/2024 07:58, Michal Wajdeczko wrote:
> > On 13.05.2024 18:53, John Harrison wrote:
> > > On 5/12/2024 08:36, Michal Wajdeczko wrote:
> > > > We already provide the content of the GuC log in debugsfs, but it
> > > > is in a text format where each log dword is printed as hexadecimal
> > > > number, which does not scale well with large GuC log buffers.
> > > > 
> > > > To allow more efficient access to the GuC log, which could benefit
> > > > our CI systems, expose raw binary log data.  In addition to less
> > > > overhead in preparing text based GuC log file, the new GuC log file
> > > > in binary format is also almost 3x smaller.
> > > > 
> > > > Any existing script that expects the GuC log buffer in text format
> > > > can use command like below to convert from new binary format:
> > > > 
> > > >  hexdump -e '4/4 "0x%08x " "\n"'
> > > > 
> > > > but this shouldn't be the case as most decoders expect GuC log data
> > > > in binary format.
> > > I strongly disagree with this.
> > > 
> > > Efficiency and file size is not an issue when accessing the GuC log via
> > > debugfs on actual hardware.
> > to some extend it is as CI team used to refuse to collect GuC logs after
> > each executed test just because of it's size
> I've never heard that argument. I've heard many different arguments but not
> one about file size. The default GuC log size is pretty tiny. So size really
> is not an issue.
> 
> > 
> > > It is an issue when dumping via dmesg but
> > > you definitely should not be dumping binary data to dmesg. Whereas,
> > not following here - this is debugfs specific, not a dmesg printer
> Except that it is preferable to have common code for both if at all
> possible.
> 
> > 
> > > dumping in binary data is much more dangerous and liable to corruption
> > > because some tool along the way tries to convert to ASCII, or truncates
> > > at the first zero, etc. We request GuC logs be sent by end users,
> > > customer bug reports, etc. all doing things that we have no control over.
> > hmm, how "cp gt0/uc/guc_log_raw FILE" could end with a corrupted file ?
> Because someone then tries to email it, or attach it or copy it via Windows
> or any number of other ways in which a file can get munged.
> 
> > 
> > > Converting the hexdump back to binary is trivial for those tools which
> > > require it. If you follow the acquisition and decoding instructions on
> > > the wiki page then it is all done for you automatically.
> > I'm afraid I don't know where this wiki page is, but I do know that hex
> > conversion dance is not needed for me to get decoded GuC log the way I
> > used to do
> Look for the 'GuC Debug Logs' page on the developer wiki. It's pretty easy
> to find.
> 
> > > These patches are trying to solve a problem which does not exist and are
> > > going to make working with GuC logs harder and more error prone.
> > it at least solves the problem of currently super inefficient way of
> > generating the GuC log in text format.
> > 
> > it also opens other opportunities to develop tools that could monitor or
> > capture GuC log independently on  top of what driver is able to offer
> > today (on i915 there was guc-log-relay, but it was broken for long time,
> > not sure what are the plans for Xe)
> > 
> > also still not sure how it can be more error prone.
> As already explained, the plan is move to LFD - an extensible, streamable,
> logging format. Any non-trivial effort that is not helping to move to LFD is
> not worth the effort.
> 
> > 
> > > On the other hand, there are many other issues with GuC logs that it
> > > would be useful to solves - including extra meta data, reliable output
> > > via dmesg, continuous streaming, pre-sizing the debugfs file to not have
> > > to generate it ~12 times for a single read, etc.
> > this series actually solves last issue but in a bit different way (we
> > even don't need to generate full GuC log dump at all if we would like to
> > capture only part of the log if we know where to look)
> No, it doesn't solve it. Your comment below suggests it will be read in 4KB
> chunks. Which means your 16MB buffer now requires 4096 separate reads! And
> you only doing partial reads of the section you think you need is never
> going to be reliable on live system. Not sure why you would want to anyway.
> It is just making things much more complex. You now need an intelligent user
> land program to read the log out and decode at least the header section to
> know what data section to read. You can't just dump the whole thing with
> 'cat' or 'dd'.
> 

Briefly have read this thread but seconding John's opinion that anything
which breaks GuC log collection via a simple command like cat is a no
go. Also anything that can allow windows to mangle the output would be
less than idle too. Lastly, GuC log collection is not a critical path
operation so it likely does not need to optimized for speed.

Matt

> > 
> > for reliable 

Re: [PATCH v7 7/8] media: imagination: Round to closest multiple for cropping region

[Nicolas Dufresne]

Le samedi 11 mai 2024 à 22:38 +0530, Devarsh Thakkar a écrit :
> Hi Andy,
> 
> Thanks for the quick review.
> On 10/05/24 20:40, Andy Shevchenko wrote:
> > On Fri, May 10, 2024 at 12:10:01AM +0530, Devarsh Thakkar wrote:
> > > If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
> > > (V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
> > > multiple of requested value while updating the crop rectangle coordinates.
> > > 
> > > Use the rounding macro which gives preference to rounding down in case two
> > > nearest values (high and low) are possible to raise the probability of
> > > cropping rectangle falling inside the bound region.
> > 
> > This is arguable. How do we know that the bigger range is supported?
> > The safest side is to go smaller than bigger.
> > 
> 
> Yes and that's what the driver does when do when application passes
> V4L2_SEL_FLAG_LE while doing the selection. If application does not
> specify explicitly whether to round down or round up the cropping
> parameters requested by it (i.e app is neither passing V4L2_SEL_FLAG_LE
> nor V4L2_SEL_FLAG_GE flags), then it is preferred by driver to round the
> cropping parameters to nearest possible value by either rounding down or
> rounding up to align with hardware requirements.
> 
> For e.g. If requested width for cropping region is 127 and HW requires
> width to be multiple of 64 then we would prefer to round it up to 128
> rather than rounding down to a more distant value (i.e. 64), but if
> requested cropping width is 129 then we would prefer to instead round it
> down to 128. But if requested cropping width is 160 then there are two
> nearest possible values 160 - 32 = 128 and 160 + 32 = 192 and in which
> case we prefer the smaller value as you suggested and that's why the
> driver uses round_closest_down.
> 
> For any reason, if still the cropping rectangle falls beyond the bound
> region, then driver will return out of range error (-ERANGE) to
> application.

I would appreciate if this change was based on specification text, meaning
improving the next if that behaviour is undefined. We might not be able to fix
it everywhere, but we can recommend something.

Nicolas

> 
> Regards
> Devarsh
> 
> 

Re: linux-next: build warning after merge of the amdgpu tree

[Alex Deucher]

On Tue, May 14, 2024 at 2:20 PM Nirujogi, Pratap
 wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Stephen,
>
> Thank you for reporting this warning, I will address this in the next amdgpu 
> patchset I will be submitting in this week.

Should be fixed with this patch:
https://patchwork.freedesktop.org/patch/593995/
Sorry, I forgot to CC you.

Alex

>
> Thanks,
> Pratap
>
> -Original Message-
> From: Stephen Rothwell 
> Sent: Tuesday, May 14, 2024 3:14 AM
> To: Alex Deucher 
> Cc: Deucher, Alexander ; Nirujogi, Pratap 
> ; Dave Airlie ; DRI 
> ; Linux Kernel Mailing List 
> ; Linux Next Mailing List 
> 
> Subject: linux-next: build warning after merge of the amdgpu tree
>
> Hi all,
>
> After merging the amdgpu tree, today's linux-next build (htmldocs) produced 
> this warning:
>
> drivers/gpu/drm/amd/include/amd_shared.h:110: warning: Enum value 
> 'AMD_IP_BLOCK_TYPE_ISP' not described in enum 'amd_ip_block_type'
>
> Introduced by commit
>
>   a83048bfa402 ("drm/amd/amdgpu: Add ISP support to amdgpu_discovery")
>
> --
> Cheers,
> Stephen Rothwell

Re: [PATCH] drm/msm: Add obj flags to gpu devcoredump

[Akhil P Oommen]

On Mon, May 13, 2024 at 08:51:47AM -0700, Rob Clark wrote:
> From: Rob Clark 
> 
> When debugging faults, it is useful to know how the BO is mapped (cached
> vs WC, gpu readonly, etc).
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Akhil P Oommen 

-Akhil

> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 +
>  drivers/gpu/drm/msm/msm_gpu.c   | 6 --
>  drivers/gpu/drm/msm/msm_gpu.h   | 1 +
>  3 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index b7bbef2eeff4..d9ea15994ae9 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -887,6 +887,7 @@ void adreno_show(struct msm_gpu *gpu, struct 
> msm_gpu_state *state,
>   drm_printf(p, "  - iova: 0x%016llx\n",
>   state->bos[i].iova);
>   drm_printf(p, "size: %zd\n", state->bos[i].size);
> + drm_printf(p, "flags: 0x%x\n", state->bos[i].flags);
>   drm_printf(p, "name: %-32s\n", state->bos[i].name);
>  
>   adreno_show_object(p, >bos[i].data,
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index d14ec058906f..ceaee23a4d22 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -222,14 +222,16 @@ static void msm_gpu_crashstate_get_bo(struct 
> msm_gpu_state *state,
>   struct drm_gem_object *obj, u64 iova, bool full)
>  {
>   struct msm_gpu_state_bo *state_bo = >bos[state->nr_bos];
> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
>  
>   /* Don't record write only objects */
>   state_bo->size = obj->size;
> + state_bo->flags = msm_obj->flags;
>   state_bo->iova = iova;
>  
> - BUILD_BUG_ON(sizeof(state_bo->name) != sizeof(to_msm_bo(obj)->name));
> + BUILD_BUG_ON(sizeof(state_bo->name) != sizeof(msm_obj->name));
>  
> - memcpy(state_bo->name, to_msm_bo(obj)->name, sizeof(state_bo->name));
> + memcpy(state_bo->name, msm_obj->name, sizeof(state_bo->name));
>  
>   if (full) {
>   void *ptr;
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 685470b84708..05bb247e7210 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -527,6 +527,7 @@ struct msm_gpu_submitqueue {
>  struct msm_gpu_state_bo {
>   u64 iova;
>   size_t size;
> + u32 flags;
>   void *data;
>   bool encoded;
>   char name[32];
> -- 
> 2.45.0
> 

Re: [PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers

[Akhil P Oommen]

On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
> Memory barriers help ensure instruction ordering, NOT time and order
> of actual write arrival at other observers (e.g. memory-mapped IP).
> On architectures employing weak memory ordering, the latter can be a
> giant pain point, and it has been as part of this driver.
> 
> Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
> readl/writel, which include r/w (respectively) barriers.
> 
> Replace the barriers with a readback that ensures the previous writes
> have exited the write buffer (as the CPU must flush the write to the
> register it's trying to read back) and subsequently remove the hack
> introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
> status in hw_init").
> 
> Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
> Signed-off-by: Konrad Dybcio 
> ---
>  drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  5 ++---
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 --
>  2 files changed, 6 insertions(+), 13 deletions(-)

I prefer this version compared to the v2. A helper routine is
unnecessary here because:
1. there are very few scenarios where we have to read back the same
register.
2. we may accidently readback a write only register.

> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 0e3dfd4c2bc8..4135a53b55a7 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
>   int ret;
>   u32 val;
>  
> - gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
> - /* Wait for the register to finish posting */
> - wmb();
> + gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
> + gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ);

This is unnecessary because we are polling on a register on the same port 
below. But I think we
can replace "wmb()" above with "mb()" to avoid reordering between read
and write IO instructions.

>  
>   ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
>   val & (1 << 1), 100, 1);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 973872ad0474..0acbc38b8e70 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu)
>   }
>  
>   /* Clear GBIF halt in case GX domain was not collapsed */
> + gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);

We need a full barrier here to avoid reordering. Also, lets add a
comment about why we are doing this odd looking sequence.

> + gpu_read(gpu, REG_A6XX_GBIF_HALT);
>   if (adreno_is_a619_holi(adreno_gpu)) {
> - gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
>   gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
> - /* Let's make extra sure that the GPU can access the memory.. */
> - mb();

We need a full barrier here.

> + gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL);
>   } else if (a6xx_has_gbif(adreno_gpu)) {
> - gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
>   gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
> - /* Let's make extra sure that the GPU can access the memory.. */
> - mb();

We need a full barrier here.

> + gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
>   }
>  
> - /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
> - if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
> - spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
> -

Why is this removed?

-Akhil

>   gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
>  
>   if (adreno_is_a619_holi(adreno_gpu))
> 
> ---
> base-commit: 93a39e4766083050ca0ecd6a3548093a3b9eb60c
> change-id: 20240508-topic-adreno-a2d199cd4152
> 
> Best regards,
> -- 
> Konrad Dybcio 
> 

[Bug 210467] amdgpu Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

Jothi Prasath (jothiprasa...@gmail.com) changed:

   What|Removed |Added

 CC||jothiprasa...@gmail.com

--- Comment #12 from Jothi Prasath (jothiprasa...@gmail.com) ---
I face this same issue.
I am using ryzen 5 5500u with vega7 
kernel version: 6.8.9

cat /sys/class/drm/card1/device/pp_dpm_mclk
0: 400Mhz
1: 800Mhz
2: 1200Mhz *
3: 1333Mhz

the mclk is always sticking to 1200Mhz

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

RE: linux-next: build warning after merge of the amdgpu tree

[Nirujogi, Pratap]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Stephen,

Thank you for reporting this warning, I will address this in the next amdgpu 
patchset I will be submitting in this week.

Thanks,
Pratap

-Original Message-
From: Stephen Rothwell 
Sent: Tuesday, May 14, 2024 3:14 AM
To: Alex Deucher 
Cc: Deucher, Alexander ; Nirujogi, Pratap 
; Dave Airlie ; DRI 
; Linux Kernel Mailing List 
; Linux Next Mailing List 

Subject: linux-next: build warning after merge of the amdgpu tree

Hi all,

After merging the amdgpu tree, today's linux-next build (htmldocs) produced 
this warning:

drivers/gpu/drm/amd/include/amd_shared.h:110: warning: Enum value 
'AMD_IP_BLOCK_TYPE_ISP' not described in enum 'amd_ip_block_type'

Introduced by commit

  a83048bfa402 ("drm/amd/amdgpu: Add ISP support to amdgpu_discovery")

--
Cheers,
Stephen Rothwell

Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs

[John Harrison]

On 5/14/2024 07:58, Michal Wajdeczko wrote:

On 13.05.2024 18:53, John Harrison wrote:

On 5/12/2024 08:36, Michal Wajdeczko wrote:

We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale well with large GuC log buffers.

To allow more efficient access to the GuC log, which could benefit
our CI systems, expose raw binary log data.  In addition to less
overhead in preparing text based GuC log file, the new GuC log file
in binary format is also almost 3x smaller.

Any existing script that expects the GuC log buffer in text format
can use command like below to convert from new binary format:

 hexdump -e '4/4 "0x%08x " "\n"'

but this shouldn't be the case as most decoders expect GuC log data
in binary format.

I strongly disagree with this.

Efficiency and file size is not an issue when accessing the GuC log via
debugfs on actual hardware.

to some extend it is as CI team used to refuse to collect GuC logs after
each executed test just because of it's size
I've never heard that argument. I've heard many different arguments but 
not one about file size. The default GuC log size is pretty tiny. So 
size really is not an issue.





It is an issue when dumping via dmesg but
you definitely should not be dumping binary data to dmesg. Whereas,

not following here - this is debugfs specific, not a dmesg printer
Except that it is preferable to have common code for both if at all 
possible.





dumping in binary data is much more dangerous and liable to corruption
because some tool along the way tries to convert to ASCII, or truncates
at the first zero, etc. We request GuC logs be sent by end users,
customer bug reports, etc. all doing things that we have no control over.

hmm, how "cp gt0/uc/guc_log_raw FILE" could end with a corrupted file ?
Because someone then tries to email it, or attach it or copy it via 
Windows or any number of other ways in which a file can get munged.





Converting the hexdump back to binary is trivial for those tools which
require it. If you follow the acquisition and decoding instructions on
the wiki page then it is all done for you automatically.

I'm afraid I don't know where this wiki page is, but I do know that hex
conversion dance is not needed for me to get decoded GuC log the way I
used to do
Look for the 'GuC Debug Logs' page on the developer wiki. It's pretty 
easy to find.



These patches are trying to solve a problem which does not exist and are
going to make working with GuC logs harder and more error prone.

it at least solves the problem of currently super inefficient way of
generating the GuC log in text format.

it also opens other opportunities to develop tools that could monitor or
capture GuC log independently on  top of what driver is able to offer
today (on i915 there was guc-log-relay, but it was broken for long time,
not sure what are the plans for Xe)

also still not sure how it can be more error prone.
As already explained, the plan is move to LFD - an extensible, 
streamable, logging format. Any non-trivial effort that is not helping 
to move to LFD is not worth the effort.





On the other hand, there are many other issues with GuC logs that it
would be useful to solves - including extra meta data, reliable output
via dmesg, continuous streaming, pre-sizing the debugfs file to not have
to generate it ~12 times for a single read, etc.

this series actually solves last issue but in a bit different way (we
even don't need to generate full GuC log dump at all if we would like to
capture only part of the log if we know where to look)
No, it doesn't solve it. Your comment below suggests it will be read in 
4KB chunks. Which means your 16MB buffer now requires 4096 separate 
reads! And you only doing partial reads of the section you think you 
need is never going to be reliable on live system. Not sure why you 
would want to anyway. It is just making things much more complex. You 
now need an intelligent user land program to read the log out and decode 
at least the header section to know what data section to read. You can't 
just dump the whole thing with 'cat' or 'dd'.




for reliable output via dmesg - see my proposal at [1]

[1] https://patchwork.freedesktop.org/series/133613/





Hmm. Actually, is this interface allowing the filesystem layers to issue
multiple read calls to read the buffer out in small chunks? That is also
going to break things. If the GuC is still writing to the log as the
user is reading from it, there is the opportunity for each chunk to not
follow on from the previous chunk because the data has just been
overwritten. This is already a problem at the moment that causes issues
when decoding the logs, even with an almost atomic copy of the log into
a temporary buffer before reading it out. Doing the read in separate
chunks is only going to make that problem even worse.

current solution, that converts data into hex numbers, 

[PATCH v5 7/9] drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels

[Douglas Anderson]

Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:

$ scripts/bloat-o-meter \
  .../before/panel-boe-tv101wum-nl6.ko \
  .../after/panel-boe-tv101wum-nl6.ko
add/remove: 14/8 grow/shrink: 0/1 up/down: 27062/-31433 (-4371)
Function old new   delta
inx_hj110iz_init   -7040   +7040
boe_tv110c9m_init  -6440   +6440
boe_init   -5916   +5916
starry_qfh032011_53g_init  -1944   +1944
starry_himax83102_j02_init -1228   +1228
inx_hj110iz_init.d -1040   +1040
boe_tv110c9m_init.d- 982+982
auo_b101uan08_3_init   - 944+944
boe_init.d - 580+580
starry_himax83102_j02_init.d   - 512+512
starry_qfh032011_53g_init.d- 180+180
auo_kd101n80_45na_init - 172+172
auo_b101uan08_3_init.d -  82 +82
auo_kd101n80_45na_init.d   -   2  +2
auo_kd101n80_45na_init_cmd   144   --144
boe_panel_prepare592 440-152
auo_b101uan08_3_init_cmd1056   -   -1056
starry_himax83102_j02_init_cmd  1392   -   -1392
starry_qfh032011_53g_init_cmd   2256   -   -2256
.compoundliteral3393   -   -3393
boe_init_cmd7008   -   -7008
boe_tv110c9m_init_cmd   7656   -   -7656
inx_hj110iz_init_cmd8376   -   -8376
Total: Before=37297, After=32926, chg -11.72%

Let's do the conversion.

Since we're touching all the tables, let's also convert hex numbers to
lower case as per kernel conventions.

Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- Fix spacing of init function.
- Remove an unneeded error print.
- Squash boe-tv101wum-nl6 lowercase patch into main patch

Changes in v2:
- New

 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 2792 +
 1 file changed, 1442 insertions(+), 1350 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 0ffe8f8c01de..aab60cec0603 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -17,6 +17,8 @@
 
 #include 
 
+struct boe_panel;
+
 struct panel_desc {
const struct drm_display_mode *modes;
unsigned int bpc;
@@ -32,7 +34,7 @@ struct panel_desc {
 
unsigned long mode_flags;
enum mipi_dsi_pixel_format format;
-   const struct panel_init_cmd *init_cmds;
+   int (*init)(struct boe_panel *boe);
unsigned int lanes;
bool discharge_on_disable;
bool lp11_before_reset;
@@ -54,1318 +56,1449 @@ struct boe_panel {
bool prepared;
 };
 
-enum dsi_cmd_type {
-   INIT_DCS_CMD,
-   DELAY_CMD,
-};
+static int boe_tv110c9m_init(struct boe_panel *boe)
+{
+   struct mipi_dsi_multi_context ctx = { .dsi = boe->dsi };
+
+   mipi_dsi_dcs_write_seq_multi(, 0xff, 0x20);
+   mipi_dsi_dcs_write_seq_multi(, 0xfb, 0x01);
+   mipi_dsi_dcs_write_seq_multi(, 0x05, 0xd9);
+   mipi_dsi_dcs_write_seq_multi(, 0x07, 0x78);
+   mipi_dsi_dcs_write_seq_multi(, 0x08, 0x5a);
+   mipi_dsi_dcs_write_seq_multi(, 0x0d, 0x63);
+   mipi_dsi_dcs_write_seq_multi(, 0x0e, 0x91);
+   mipi_dsi_dcs_write_seq_multi(, 0x0f, 0x73);
+   mipi_dsi_dcs_write_seq_multi(, 0x95, 0xe6);
+   mipi_dsi_dcs_write_seq_multi(, 0x96, 0xf0);
+   mipi_dsi_dcs_write_seq_multi(, 0x30, 0x00);
+   mipi_dsi_dcs_write_seq_multi(, 0x6d, 0x66);
+   mipi_dsi_dcs_write_seq_multi(, 0x75, 0xa2);
+   mipi_dsi_dcs_write_seq_multi(, 0x77, 0x3b);
+
+   mipi_dsi_dcs_write_seq_multi(, 0xb0, 0x00, 0x08, 0x00, 0x23, 0x00, 
0x4d, 0x00, 0x6d,
+0x00, 0x89, 0x00, 0xa1, 0x00, 0xb6, 0x00, 
0xc9);
+   mipi_dsi_dcs_write_seq_multi(, 0xb1, 0x00, 0xda, 0x01, 0x13, 0x01, 
0x3c, 0x01, 0x7e,
+0x01, 0xab, 0x01, 0xf7, 0x02, 0x2f, 0x02, 
0x31);
+   mipi_dsi_dcs_write_seq_multi(, 0xb2, 0x02, 0x67, 0x02, 0xa6, 0x02, 
0xd1, 0x03, 0x08,
+0x03, 0x2e, 0x03, 0x5b, 0x03, 0x6b, 0x03, 
0x7b);
+   mipi_dsi_dcs_write_seq_multi(, 0xb3, 0x03, 0x8e, 0x03, 0xa2, 0x03, 
0xb7, 0x03, 0xe7,
+0x03, 0xfd, 0x03, 0xff);
+
+   

[PATCH v5 9/9] drm/panel: innolux-p079zca: Don't use a table for initting panels

[Douglas Anderson]

Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. We'll use the
same concepts as the recently introduced
mipi_dsi_generic_write_seq_multi() to make this clean/easy and also
not bloat the driver too much. Measuring before/after this change:

$ scripts/bloat-o-meter \
  .../before/panel-innolux-p079zca.ko \
  .../after/panel-innolux-p079zca.ko
add/remove: 3/2 grow/shrink: 0/1 up/down: 2356/-1944 (412)
Function old new   delta
innolux_p097pfg_init   -1772   +1772
innolux_p097pfg_init.d - 480+480
innolux_panel_write_multi  - 104+104
innolux_panel_prepare412 308-104
.compoundliteral 480   --480
innolux_p097pfg_init_cmds   1360   -   -1360
Total: Before=5802, After=6214, chg +7.10%

Note that, unlike some other drivers, we actually make this panel
driver _bigger_ by using the new functions. This is because the
innolux-p079zca panel driver didn't have as complex of a table and
thus the old table was more efficient than the code. The bloat is
still not giant (only 412 bytes).

Also note that we can't direclty use
mipi_dsi_generic_write_seq_multi() here because we need to deal with
the crazy "nop" that this driver sends after all commands. This means
that we have to write code that is "inspired" by the new macros.

Since we're touching all the tables, let's also convert hex numbers to
lower case as per kernel conventions.

Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v4)

Changes in v4:
- Test to see if init is non-NULL before using it.

Changes in v3:
- New

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 284 +-
 1 file changed, 140 insertions(+), 144 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 485178a99910..ade8bf7491ee 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -17,14 +17,7 @@
 #include 
 #include 
 
-struct panel_init_cmd {
-   size_t len;
-   const char *data;
-};
-
-#define _INIT_CMD(...) { \
-   .len = sizeof((char[]){__VA_ARGS__}), \
-   .data = (char[]){__VA_ARGS__} }
+struct innolux_panel;
 
 struct panel_desc {
const struct drm_display_mode *mode;
@@ -36,7 +29,7 @@ struct panel_desc {
 
unsigned long flags;
enum mipi_dsi_pixel_format format;
-   const struct panel_init_cmd *init_cmds;
+   int (*init)(struct innolux_panel *innolux);
unsigned int lanes;
const char * const *supply_names;
unsigned int num_supplies;
@@ -132,32 +125,10 @@ static int innolux_panel_prepare(struct drm_panel *panel)
/* p079zca: t4, p097pfg: t5 */
usleep_range(2, 21000);
 
-   if (innolux->desc->init_cmds) {
-   const struct panel_init_cmd *cmds =
-   innolux->desc->init_cmds;
-   unsigned int i;
-
-   for (i = 0; cmds[i].len != 0; i++) {
-   const struct panel_init_cmd *cmd = [i];
-
-   err = mipi_dsi_generic_write(innolux->link, cmd->data,
-cmd->len);
-   if (err < 0) {
-   dev_err(panel->dev, "failed to write command 
%u\n", i);
-   goto poweroff;
-   }
-
-   /*
-* Included by random guessing, because without this
-* (or at least, some delay), the panel sometimes
-* didn't appear to pick up the command sequence.
-*/
-   err = mipi_dsi_dcs_nop(innolux->link);
-   if (err < 0) {
-   dev_err(panel->dev, "failed to send DCS nop: 
%d\n", err);
-   goto poweroff;
-   }
-   }
+   if (innolux->desc->init) {
+   err = innolux->desc->init(innolux);
+   if (err < 0)
+   goto poweroff;
}
 
err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
@@ -250,119 +221,144 @@ static const struct drm_display_mode 
innolux_p097pfg_mode = {
.vtotal = 2048 + 100 + 2 + 18,
 };
 
+static void innolux_panel_write_multi(struct mipi_dsi_multi_context *ctx,
+ const void *payload, size_t size)
+{
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   struct device *dev = >dev;
+
+   mipi_dsi_generic_write_multi(ctx, payload, size);
+   if (ctx->accum_err)
+   return;
+
+   /*
+* Included by random guessing, because without this
+* (or at 

[PATCH v5 8/9] drm/panel: ili9882t: Don't use a table for initting panels

[Douglas Anderson]

Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:

$ scripts/bloat-o-meter \
  .../before/panel-ilitek-ili9882t.ko \
  .../after/panel-ilitek-ili9882t.ko
add/remove: 3/2 grow/shrink: 0/2 up/down: 6834/-8177 (-1343)
Function old new   delta
starry_ili9882t_init   -6152   +6152
starry_ili9882t_init.d - 678+678
ili9882t_disable.d -   4  +4
ili9882t_disable 260 228 -32
ili9882t_prepare 540 396-144
.compoundliteral 681   --681
starry_ili9882t_init_cmd7320   -   -7320
Total: Before=11928, After=10585, chg -11.26%

Let's do the conversion.

Since we're touching all the tables, let's also convert hex numbers to
lower case as per kernel conventions.

Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- New

 drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 794 --
 1 file changed, 368 insertions(+), 426 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
index 267a5307041c..58fc1d799371 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
@@ -15,6 +15,8 @@
 
 #include 
 
+struct ili9882t;
+
 /*
  * Use this descriptor struct to describe different panels using the
  * Ilitek ILI9882T display controller.
@@ -34,7 +36,7 @@ struct panel_desc {
 
unsigned long mode_flags;
enum mipi_dsi_pixel_format format;
-   const struct panel_init_cmd *init_cmds;
+   int (*init)(struct ili9882t *boe);
unsigned int lanes;
 };
 
@@ -52,433 +54,372 @@ struct ili9882t {
struct gpio_desc *enable_gpio;
 };
 
-enum dsi_cmd_type {
-   INIT_DCS_CMD,
-   DELAY_CMD,
-};
-
-struct panel_init_cmd {
-   enum dsi_cmd_type type;
-   size_t len;
-   const char *data;
-};
-
-#define _INIT_DCS_CMD(...) { \
-   .type = INIT_DCS_CMD, \
-   .len = sizeof((char[]){__VA_ARGS__}), \
-   .data = (char[]){__VA_ARGS__} }
-
-#define _INIT_DELAY_CMD(...) { \
-   .type = DELAY_CMD,\
-   .len = sizeof((char[]){__VA_ARGS__}), \
-   .data = (char[]){__VA_ARGS__} }
-
 /* ILI9882-specific commands, add new commands as you decode them */
 #define ILI9882T_DCS_SWITCH_PAGE   0xFF
 
-#define _INIT_SWITCH_PAGE_CMD(page) \
-   _INIT_DCS_CMD(ILI9882T_DCS_SWITCH_PAGE, 0x98, 0x82, (page))
-
-static const struct panel_init_cmd starry_ili9882t_init_cmd[] = {
-   _INIT_DELAY_CMD(5),
-   _INIT_SWITCH_PAGE_CMD(0x01),
-   _INIT_DCS_CMD(0x00, 0x42),
-   _INIT_DCS_CMD(0x01, 0x11),
-   _INIT_DCS_CMD(0x02, 0x00),
-   _INIT_DCS_CMD(0x03, 0x00),
-
-   _INIT_DCS_CMD(0x04, 0x01),
-   _INIT_DCS_CMD(0x05, 0x11),
-   _INIT_DCS_CMD(0x06, 0x00),
-   _INIT_DCS_CMD(0x07, 0x00),
-
-   _INIT_DCS_CMD(0x08, 0x80),
-   _INIT_DCS_CMD(0x09, 0x81),
-   _INIT_DCS_CMD(0x0A, 0x71),
-   _INIT_DCS_CMD(0x0B, 0x00),
-
-   _INIT_DCS_CMD(0x0C, 0x00),
-   _INIT_DCS_CMD(0x0E, 0x1A),
-
-   _INIT_DCS_CMD(0x24, 0x00),
-   _INIT_DCS_CMD(0x25, 0x00),
-   _INIT_DCS_CMD(0x26, 0x00),
-   _INIT_DCS_CMD(0x27, 0x00),
-
-   _INIT_DCS_CMD(0x2C, 0xD4),
-   _INIT_DCS_CMD(0xB9, 0x40),
-
-   _INIT_DCS_CMD(0xB0, 0x11),
-
-   _INIT_DCS_CMD(0xE6, 0x32),
-   _INIT_DCS_CMD(0xD1, 0x30),
-
-   _INIT_DCS_CMD(0xD6, 0x55),
-
-   _INIT_DCS_CMD(0xD0, 0x01),
-   _INIT_DCS_CMD(0xE3, 0x93),
-   _INIT_DCS_CMD(0xE4, 0x00),
-   _INIT_DCS_CMD(0xE5, 0x80),
-
-   _INIT_DCS_CMD(0x31, 0x07),
-   _INIT_DCS_CMD(0x32, 0x07),
-   _INIT_DCS_CMD(0x33, 0x07),
-   _INIT_DCS_CMD(0x34, 0x07),
-   _INIT_DCS_CMD(0x35, 0x07),
-   _INIT_DCS_CMD(0x36, 0x01),
-   _INIT_DCS_CMD(0x37, 0x00),
-   _INIT_DCS_CMD(0x38, 0x28),
-   _INIT_DCS_CMD(0x39, 0x29),
-   _INIT_DCS_CMD(0x3A, 0x11),
-   _INIT_DCS_CMD(0x3B, 0x13),
-   _INIT_DCS_CMD(0x3C, 0x15),
-   _INIT_DCS_CMD(0x3D, 0x17),
-   _INIT_DCS_CMD(0x3E, 0x09),
-   _INIT_DCS_CMD(0x3F, 0x0D),
-   _INIT_DCS_CMD(0x40, 0x02),
-   _INIT_DCS_CMD(0x41, 0x02),
-   _INIT_DCS_CMD(0x42, 0x02),
-   _INIT_DCS_CMD(0x43, 0x02),
-   _INIT_DCS_CMD(0x44, 0x02),
-   _INIT_DCS_CMD(0x45, 0x02),
-   _INIT_DCS_CMD(0x46, 0x02),
-
-   _INIT_DCS_CMD(0x47, 0x07),
-   _INIT_DCS_CMD(0x48, 0x07),
-   _INIT_DCS_CMD(0x49, 0x07),
-   _INIT_DCS_CMD(0x4A, 0x07),
-   _INIT_DCS_CMD(0x4B, 0x07),
-   _INIT_DCS_CMD(0x4C, 0x01),
-   _INIT_DCS_CMD(0x4D, 0x00),
-   

[PATCH v5 6/9] drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()

[Douglas Anderson]

This is a mechanical conversion of the novatek-nt36672e driver to use
the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for
clients to understand and using it also causes smaller code to be
generated. Specifically:

$ scripts/bloat-o-meter \
  ...after/panel-novatek-nt36672e.ko \
  ...ctx/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988)
Function old new   delta
nt36672e_1080x2408_60hz_init62365248-988
Total: Before=10651, After=9663, chg -9.28%

Cc: Ritesh Kumar 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---
This change is only compile tested. I don't use this panel myself but
arbitrarily picked it as an example to look at when working on the
MIPI DSI macros.

(no changes since v3)

Changes in v3:
- Fix spacing of init function.

Changes in v2:
- New

 .../gpu/drm/panel/panel-novatek-nt36672e.c| 576 +-
 1 file changed, 289 insertions(+), 287 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c 
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
index 20b7bfe4aa12..9ce8df455232 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -51,293 +51,295 @@ static inline struct nt36672e_panel 
*to_nt36672e_panel(struct drm_panel *panel)
 
 static int nt36672e_1080x2408_60hz_init(struct mipi_dsi_device *dsi)
 {
-   mipi_dsi_dcs_write_seq(dsi, 0xff, 0x10);
-   mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
-   mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
-   mipi_dsi_dcs_write_seq(dsi, 0xc0, 0x00);
-   mipi_dsi_dcs_write_seq(dsi, 0xc1, 0x89, 0x28, 0x00, 0x08, 0x00, 0xaa, 
0x02,
-   0x0e, 0x00, 0x2b, 0x00, 0x07, 0x0d, 0xb7, 0x0c, 
0xb7);
-
-   mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x1b, 0xa0);
-   mipi_dsi_dcs_write_seq(dsi, 0xff, 0x20);
-   mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
-   mipi_dsi_dcs_write_seq(dsi, 0x01, 0x66);
-   mipi_dsi_dcs_write_seq(dsi, 0x06, 0x40);
-   mipi_dsi_dcs_write_seq(dsi, 0x07, 0x38);
-   mipi_dsi_dcs_write_seq(dsi, 0x2f, 0x83);
-   mipi_dsi_dcs_write_seq(dsi, 0x69, 0x91);
-   mipi_dsi_dcs_write_seq(dsi, 0x95, 0xd1);
-   mipi_dsi_dcs_write_seq(dsi, 0x96, 0xd1);
-   mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x64);
-   mipi_dsi_dcs_write_seq(dsi, 0xf3, 0x54);
-   mipi_dsi_dcs_write_seq(dsi, 0xf4, 0x64);
-   mipi_dsi_dcs_write_seq(dsi, 0xf5, 0x54);
-   mipi_dsi_dcs_write_seq(dsi, 0xf6, 0x64);
-   mipi_dsi_dcs_write_seq(dsi, 0xf7, 0x54);
-   mipi_dsi_dcs_write_seq(dsi, 0xf8, 0x64);
-   mipi_dsi_dcs_write_seq(dsi, 0xf9, 0x54);
-   mipi_dsi_dcs_write_seq(dsi, 0xff, 0x24);
-   mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
-   mipi_dsi_dcs_write_seq(dsi, 0x01, 0x0f);
-   mipi_dsi_dcs_write_seq(dsi, 0x03, 0x0c);
-   mipi_dsi_dcs_write_seq(dsi, 0x05, 0x1d);
-   mipi_dsi_dcs_write_seq(dsi, 0x08, 0x2f);
-   mipi_dsi_dcs_write_seq(dsi, 0x09, 0x2e);
-   mipi_dsi_dcs_write_seq(dsi, 0x0a, 0x2d);
-   mipi_dsi_dcs_write_seq(dsi, 0x0b, 0x2c);
-   mipi_dsi_dcs_write_seq(dsi, 0x11, 0x17);
-   mipi_dsi_dcs_write_seq(dsi, 0x12, 0x13);
-   mipi_dsi_dcs_write_seq(dsi, 0x13, 0x15);
-   mipi_dsi_dcs_write_seq(dsi, 0x15, 0x14);
-   mipi_dsi_dcs_write_seq(dsi, 0x16, 0x16);
-   mipi_dsi_dcs_write_seq(dsi, 0x17, 0x18);
-   mipi_dsi_dcs_write_seq(dsi, 0x1b, 0x01);
-   mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1d);
-   mipi_dsi_dcs_write_seq(dsi, 0x20, 0x2f);
-   mipi_dsi_dcs_write_seq(dsi, 0x21, 0x2e);
-   mipi_dsi_dcs_write_seq(dsi, 0x22, 0x2d);
-   mipi_dsi_dcs_write_seq(dsi, 0x23, 0x2c);
-   mipi_dsi_dcs_write_seq(dsi, 0x29, 0x17);
-   mipi_dsi_dcs_write_seq(dsi, 0x2a, 0x13);
-   mipi_dsi_dcs_write_seq(dsi, 0x2b, 0x15);
-   mipi_dsi_dcs_write_seq(dsi, 0x2f, 0x14);
-   mipi_dsi_dcs_write_seq(dsi, 0x30, 0x16);
-   mipi_dsi_dcs_write_seq(dsi, 0x31, 0x18);
-   mipi_dsi_dcs_write_seq(dsi, 0x32, 0x04);
-   mipi_dsi_dcs_write_seq(dsi, 0x34, 0x10);
-   mipi_dsi_dcs_write_seq(dsi, 0x35, 0x1f);
-   mipi_dsi_dcs_write_seq(dsi, 0x36, 0x1f);
-   mipi_dsi_dcs_write_seq(dsi, 0x4d, 0x14);
-   mipi_dsi_dcs_write_seq(dsi, 0x4e, 0x36);
-   mipi_dsi_dcs_write_seq(dsi, 0x4f, 0x36);
-   mipi_dsi_dcs_write_seq(dsi, 0x53, 0x36);
-   mipi_dsi_dcs_write_seq(dsi, 0x71, 0x30);
-   mipi_dsi_dcs_write_seq(dsi, 0x79, 0x11);
-   mipi_dsi_dcs_write_seq(dsi, 0x7a, 0x82);
-   mipi_dsi_dcs_write_seq(dsi, 0x7b, 0x8f);
-   mipi_dsi_dcs_write_seq(dsi, 0x7d, 0x04);
-   mipi_dsi_dcs_write_seq(dsi, 0x80, 0x04);
-   mipi_dsi_dcs_write_seq(dsi, 0x81, 0x04);
-   mipi_dsi_dcs_write_seq(dsi, 0x82, 0x13);
-   mipi_dsi_dcs_write_seq(dsi, 0x84, 0x31);
-   mipi_dsi_dcs_write_seq(dsi, 0x85, 0x00);
-   mipi_dsi_dcs_write_seq(dsi, 0x86, 0x00);

[PATCH v5 5/9] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()

[Douglas Anderson]

The current mipi_dsi_*_write_seq() macros are non-intutitive because
they contain a hidden "return" statement that will return out of the
_caller_ of the macro. Let's mark them as deprecated and instead
introduce some new macros that are more intuitive.

These new macros are less optimal when an error occurs but should
behave more optimally when there is no error. Specifically these new
macros cause smaller code to get generated and the code size savings
(less to fetch from RAM, less cache space used, less RAM used) are
important. Since the error case isn't something we need to optimize
for and these new macros are easier to understand and more flexible,
they should be used.

After converting to use these new functions, one example shows some
nice savings while also being easier to understand.

$ scripts/bloat-o-meter \
  ...after/panel-novatek-nt36672e.ko \
  ...ctx/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988)
Function old new   delta
nt36672e_1080x2408_60hz_init62365248-988
Total: Before=10651, After=9663, chg -9.28%

Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---
Right now this patch introduces two new functions in drm_mipi_dsi.c.
Alternatively we could have changed the prototype of the "chatty"
functions and made the deprecated macros adapt to the new prototype.
While this sounds nice, it bloated callers of the deprecated functioin
a bit because it caused the compiler to emit less optimal code. It
doesn't seem terrible to add two more functions, so I went that
way. There may be cases where callers who aren't writing many
sequences prefer to use the "chatty" versions anyway.

(no changes since v3)

Changes in v3:
- Add a TODO item for cleaning up the deprecated macros/functions.
- Inline kerneldoc comments for struct mipi_dsi_multi_context.

Changes in v2:
- New

 Documentation/gpu/todo.rst | 18 ++
 drivers/gpu/drm/drm_mipi_dsi.c | 56 ++
 include/drm/drm_mipi_dsi.h | 62 ++
 3 files changed, 136 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index e2a0585915b3..2734b8a34541 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -494,6 +494,24 @@ Contact: Douglas Anderson 
 
 Level: Starter/Intermediate
 
+Transition away from using mipi_dsi_*_write_seq()
+-
+
+The macros mipi_dsi_generic_write_seq() and mipi_dsi_dcs_write_seq() are
+non-intuitive because, if there are errors, they return out of the *caller's*
+function. We should move all callers to use mipi_dsi_generic_write_seq_multi()
+and mipi_dsi_dcs_write_seq_multi() macros instead.
+
+Once all callers are transitioned, the macros and the functions that they call,
+mipi_dsi_generic_write_chatty() and mipi_dsi_dcs_write_buffer_chatty(), can
+probably be removed. Alternatively, if people feel like the _multi() variants
+are overkill for some use cases, we could keep the mipi_dsi_*_write_seq()
+variants but change them not to return out of the caller.
+
+Contact: Douglas Anderson 
+
+Level: Starter
+
 
 Core refactorings
 =
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 4d2685d5a6e0..26c7383406c1 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -792,6 +792,34 @@ int mipi_dsi_generic_write_chatty(struct mipi_dsi_device 
*dsi,
 }
 EXPORT_SYMBOL(mipi_dsi_generic_write_chatty);
 
+/**
+ * mipi_dsi_generic_write_multi() - mipi_dsi_generic_write_chatty() w/ 
accum_err
+ * @ctx: Context for multiple DSI transactions
+ * @payload: buffer containing the payload
+ * @size: size of payload buffer
+ *
+ * Like mipi_dsi_generic_write_chatty() but deals with errors in a way that
+ * makes it convenient to make several calls in a row.
+ */
+void mipi_dsi_generic_write_multi(struct mipi_dsi_multi_context *ctx,
+ const void *payload, size_t size)
+{
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   struct device *dev = >dev;
+   ssize_t ret;
+
+   if (ctx->accum_err)
+   return;
+
+   ret = mipi_dsi_generic_write(dsi, payload, size);
+   if (ret < 0) {
+   ctx->accum_err = ret;
+   dev_err(dev, "sending generic data %*ph failed: %d\n",
+   (int)size, payload, ctx->accum_err);
+   }
+}
+EXPORT_SYMBOL(mipi_dsi_generic_write_multi);
+
 /**
  * mipi_dsi_generic_read() - receive data using a generic read packet
  * @dsi: DSI peripheral device
@@ -908,6 +936,34 @@ int mipi_dsi_dcs_write_buffer_chatty(struct 
mipi_dsi_device *dsi,
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer_chatty);
 
+/**
+ * mipi_dsi_dcs_write_buffer_multi - mipi_dsi_dcs_write_buffer_chatty() w/ 
accum_err
+ * @ctx: Context for multiple DSI transactions
+ * @data: buffer containing 

[PATCH v5 3/9] drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints

[Douglas Anderson]

We really don't expect these errors to be printed over and over
again. When a driver hits the error it should bail out. Just use a
normal error print.

This gives a nice space savings for users of these functions:

$ scripts/bloat-o-meter \
  .../before/panel-novatek-nt36672e.ko \
  .../after/panel-novatek-nt36672e.ko
add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-16760 (-16760)
Function old new   delta
nt36672e_1080x2408_60hz_init   17080   10640   -6440
nt36672e_1080x2408_60hz_init._rs   10320   -  -10320
Total: Before=31815, After=15055, chg -52.68%

Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier.

Changes in v2:
- New

 include/drm/drm_mipi_dsi.h | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index e0f56564bf97..67967be48dbd 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -314,17 +314,16 @@ int mipi_dsi_dcs_get_display_brightness_large(struct 
mipi_dsi_device *dsi,
  * @dsi: DSI peripheral device
  * @seq: buffer containing the payload
  */
-#define mipi_dsi_generic_write_seq(dsi, seq...)
 \
-   do {
\
-   static const u8 d[] = { seq };  
\
-   struct device *dev = >dev; 
\
-   ssize_t ret;
\
-   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));
\
-   if (ret < 0) {  
\
-   dev_err_ratelimited(dev, "transmit data failed: %zd\n", 
\
-   ret);   
\
-   return ret; 
\
-   }   
\
+#define mipi_dsi_generic_write_seq(dsi, seq...)   \
+   do {  \
+   static const u8 d[] = { seq };\
+   struct device *dev = >dev;   \
+   ssize_t ret;  \
+   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));  \
+   if (ret < 0) {\
+   dev_err(dev, "transmit data failed: %zd\n", ret); \
+   return ret;   \
+   } \
} while (0)
 
 /**
@@ -340,8 +339,7 @@ int mipi_dsi_dcs_get_display_brightness_large(struct 
mipi_dsi_device *dsi,
ssize_t ret;\
ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
if (ret < 0) {  \
-   dev_err_ratelimited(\
-   dev, "sending command %#02x failed: %zd\n", \
+   dev_err(dev, "sending command %#02x failed: %zd\n", \
cmd, ret);  \
return ret; \
}   \
-- 
2.45.0.rc1.225.g2a3ae87e7f-goog

[PATCH v5 4/9] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()

[Douglas Anderson]

Through a cooperative effort between Hsin-Yi Wang and Dmitry
Baryshkov, we have realized the dev_err() in the
mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty"
version of the functions that includes the print. While doing this,
add a bit more comments to these macros making it clear that they
print errors and also that they return out of _the caller's_ function.

Without any changes to clients this gives a nice savings. Specifically
the macro was inlined and thus the error report call was inlined into
every call to mipi_dsi_dcs_write_seq() and
mipi_dsi_generic_write_seq(). By using a call to a "chatty" function,
the usage is reduced to one call in the chatty function and a function
call at the invoking site.

Building with my build system shows one example:

$ scripts/bloat-o-meter \
  .../before/panel-novatek-nt36672e.ko \
  .../after/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-4404 (-4404)
Function old new   delta
nt36672e_1080x2408_60hz_init   106406236   -4404
Total: Before=15055, After=10651, chg -29.25%

Note that given the change in location of the print it's harder to
include the "cmd" in the printout for mipi_dsi_dcs_write_seq() since,
theoretically, someone could call the new chatty function with a
zero-size array and it would be illegal to dereference data[0].
There's a printk format to print the whole buffer and this is probably
more useful for debugging anyway. Given that we're doing this for
mipi_dsi_dcs_write_seq(), let's also print the buffer for
mipi_dsi_generic_write_seq() in the error case.

It should be noted that the current consensus of DRM folks is that the
mipi_dsi_*_write_seq() should be deprecated due to the non-intuitive
return behavior. A future patch will formally mark them as deprecated
and provide an alternative.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

Changes in v5:
- Fix comment dev_err_ratelimited() => dev_err().

Changes in v4:
- Update wording as per Linus W.

Changes in v3:
- Rebased upon patch to remove ratelimit of prints.

Changes in v2:
- Add some comments to the macros about printing and returning.
- Change the way err value is handled in prep for next patch.
- Modify commit message now that this is part of a series.
- Rebased upon patches to avoid theoretical int overflow.

 drivers/gpu/drm/drm_mipi_dsi.c | 56 ++
 include/drm/drm_mipi_dsi.h | 47 +++-
 2 files changed, 82 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 795001bb7ff1..4d2685d5a6e0 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -764,6 +764,34 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device 
*dsi, const void *payload,
 }
 EXPORT_SYMBOL(mipi_dsi_generic_write);
 
+/**
+ * mipi_dsi_generic_write_chatty() - mipi_dsi_generic_write() w/ an error log
+ * @dsi: DSI peripheral device
+ * @payload: buffer containing the payload
+ * @size: size of payload buffer
+ *
+ * Like mipi_dsi_generic_write() but includes a dev_err()
+ * call for you and returns 0 upon success, not the number of bytes sent.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi,
+ const void *payload, size_t size)
+{
+   struct device *dev = >dev;
+   ssize_t ret;
+
+   ret = mipi_dsi_generic_write(dsi, payload, size);
+   if (ret < 0) {
+   dev_err(dev, "sending generic data %*ph failed: %zd\n",
+   (int)size, payload, ret);
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_generic_write_chatty);
+
 /**
  * mipi_dsi_generic_read() - receive data using a generic read packet
  * @dsi: DSI peripheral device
@@ -852,6 +880,34 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device 
*dsi,
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer);
 
+/**
+ * mipi_dsi_dcs_write_buffer_chatty - mipi_dsi_dcs_write_buffer() w/ an error 
log
+ * @dsi: DSI peripheral device
+ * @data: buffer containing data to be transmitted
+ * @len: size of transmission buffer
+ *
+ * Like mipi_dsi_dcs_write_buffer() but includes a dev_err()
+ * call for you and returns 0 upon success, not the number of bytes sent.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi,
+const void *data, size_t len)
+{
+   struct device *dev = >dev;
+   ssize_t ret;
+
+   ret = mipi_dsi_dcs_write_buffer(dsi, data, len);
+   if (ret < 0) {
+   dev_err(dev, "sending dcs data %*ph failed: %zd\n",
+   (int)len, 

[PATCH v5 2/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()

[Douglas Anderson]

The mipi_dsi_generic_write_seq() macro makes a call to
mipi_dsi_generic_write() which returns a type ssize_t. The macro then
stores it in an int and checks to see if it's negative. This could
theoretically be a problem if "ssize_t" is larger than "int".

To see the issue, imagine that "ssize_t" is 32-bits and "int" is
16-bits, you could see a problem if there was some code out there that
looked like:

  mipi_dsi_generic_write_seq(dsi, <32768 bytes as arguments>);

...since we'd get back that 32768 bytes were transferred and 32768
stored in a 16-bit int would look negative.

Though there are no callsites where we'd actually hit this (even if
"int" was only 16-bit), it's cleaner to make the types match so let's
fix it.

Fixes: a9015ce59320 ("drm/mipi-dsi: Add a mipi_dsi_dcs_write_seq() macro")
Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- Use %zd in print instead of casting errors to int.

Changes in v2:
- New

 include/drm/drm_mipi_dsi.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 70ce0b8cbc68..e0f56564bf97 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -314,17 +314,17 @@ int mipi_dsi_dcs_get_display_brightness_large(struct 
mipi_dsi_device *dsi,
  * @dsi: DSI peripheral device
  * @seq: buffer containing the payload
  */
-#define mipi_dsi_generic_write_seq(dsi, seq...)
\
-   do {   \
-   static const u8 d[] = { seq }; \
-   struct device *dev = >dev;\
-   int ret;   \
-   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));   \
-   if (ret < 0) { \
-   dev_err_ratelimited(dev, "transmit data failed: %d\n", \
-   ret);  \
-   return ret;\
-   }  \
+#define mipi_dsi_generic_write_seq(dsi, seq...)
 \
+   do {
\
+   static const u8 d[] = { seq };  
\
+   struct device *dev = >dev; 
\
+   ssize_t ret;
\
+   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));
\
+   if (ret < 0) {  
\
+   dev_err_ratelimited(dev, "transmit data failed: %zd\n", 
\
+   ret);   
\
+   return ret; 
\
+   }   
\
} while (0)
 
 /**
-- 
2.45.0.rc1.225.g2a3ae87e7f-goog

[PATCH v5 1/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()

[Douglas Anderson]

The mipi_dsi_dcs_write_seq() macro makes a call to
mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro
then stores it in an int and checks to see if it's negative. This
could theoretically be a problem if "ssize_t" is larger than "int".

To see the issue, imagine that "ssize_t" is 32-bits and "int" is
16-bits, you could see a problem if there was some code out there that
looked like:

  mipi_dsi_dcs_write_seq(dsi, cmd, <32767 bytes as arguments>);

...since we'd get back that 32768 bytes were transferred and 32768
stored in a 16-bit int would look negative.

Though there are no callsites where we'd actually hit this (even if
"int" was only 16-bit), it's cleaner to make the types match so let's
fix it.

Fixes: 2a9e9daf7523 ("drm/mipi-dsi: Introduce mipi_dsi_dcs_write_seq macro")
Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- Use %zd in print instead of casting errors to int.

Changes in v2:
- New

 include/drm/drm_mipi_dsi.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 82b1cc434ea3..70ce0b8cbc68 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -333,18 +333,18 @@ int mipi_dsi_dcs_get_display_brightness_large(struct 
mipi_dsi_device *dsi,
  * @cmd: Command
  * @seq: buffer containing data to be transmitted
  */
-#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)   \
-   do {   \
-   static const u8 d[] = { cmd, seq };\
-   struct device *dev = >dev;\
-   int ret;   \
-   ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d));\
-   if (ret < 0) { \
-   dev_err_ratelimited(   \
-   dev, "sending command %#02x failed: %d\n", \
-   cmd, ret); \
-   return ret;\
-   }  \
+#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)\
+   do {\
+   static const u8 d[] = { cmd, seq }; \
+   struct device *dev = >dev; \
+   ssize_t ret;\
+   ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
+   if (ret < 0) {  \
+   dev_err_ratelimited(\
+   dev, "sending command %#02x failed: %zd\n", \
+   cmd, ret);  \
+   return ret; \
+   }   \
} while (0)
 
 /**
-- 
2.45.0.rc1.225.g2a3ae87e7f-goog

[PATCH v5 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs

[Douglas Anderson]

The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
init functions that can use common DRM functions. The issue thus far
has been that using the macros mipi_dsi_generic_write_seq() and
mipi_dsi_dcs_write_seq() bloats the driver using them.

While trying to solve bloat, we realized that the majority of the it
was easy to solve. This series solves the bloat for existing drivers
by moving the printout outside of the macro.

During discussion of my v1 patch to fix the bloat [1], we also decided
that we really want to change the way that drivers deal with init
sequences to make it clearer. In addition to being cleaner, a side
effect of moving drivers to the new style reduces bloat _even more_.

This series also contains a few minor fixes / cleanups that I found
along the way.

This series converts four drivers over to the new
mipi_dsi_dcs_write_seq_multi() function. Not all conversions have been
tested, but hopefully they are straightforward enough. I'd appreciate
testing.

NOTE: In v3 I tried to incorporate the feedback from v2. I also
converted the other two panels I could find that used table-based
initialization.

v4 just has a tiny bugfix and collects tags. v5 has another tiny
bugfix. Assuming no other problems are found the plan is to land this
series sometime roughly around May 16 [2].

[1] 
https://lore.kernel.org/r/20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid
[2] https://lore.kernel.org/r/35b899d2-fb47-403a-83d2-204c0800d...@linaro.org

Changes in v5:
- Fix comment dev_err_ratelimited() => dev_err().

Changes in v4:
- Test to see if init is non-NULL before using it.
- Update wording as per Linus W.

Changes in v3:
- ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier.
- Add a TODO item for cleaning up the deprecated macros/functions.
- Fix spacing of init function.
- Inline kerneldoc comments for struct mipi_dsi_multi_context.
- Rebased upon patch to remove ratelimit of prints.
- Remove an unneeded error print.
- Squash boe-tv101wum-nl6 lowercase patch into main patch
- Use %zd in print instead of casting errors to int.
- drm/panel: ili9882t: Don't use a table for initting panels
- drm/panel: innolux-p079zca: Don't use a table for initting panels

Changes in v2:
- Add some comments to the macros about printing and returning.
- Change the way err value is handled in prep for next patch.
- Modify commit message now that this is part of a series.
- Rebased upon patches to avoid theoretical int overflow.
- drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
- drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()
- drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
- drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints
- drm/panel: boe-tv101wum-nl6: Convert hex to lowercase
- drm/panel: boe-tv101wum-nl6: Don't use a table for initting commands
- drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()

Douglas Anderson (9):
  drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
  drm/mipi-dsi: Fix theoretical int overflow in
mipi_dsi_generic_write_seq()
  drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit
prints
  drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
  drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
  drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
  drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels
  drm/panel: ili9882t: Don't use a table for initting panels
  drm/panel: innolux-p079zca: Don't use a table for initting panels

 Documentation/gpu/todo.rst|   18 +
 drivers/gpu/drm/drm_mipi_dsi.c|  112 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 2792 +
 drivers/gpu/drm/panel/panel-ilitek-ili9882t.c |  794 +++--
 drivers/gpu/drm/panel/panel-innolux-p079zca.c |  284 +-
 .../gpu/drm/panel/panel-novatek-nt36672e.c|  576 ++--
 include/drm/drm_mipi_dsi.h|  101 +-
 7 files changed, 2452 insertions(+), 2225 deletions(-)

-- 
2.45.0.rc1.225.g2a3ae87e7f-goog

Re: [PATCH net-next v9 00/14] Device Memory TCP

[Mina Almasry]

On Mon, May 13, 2024 at 4:31 PM Jakub Kicinski  wrote:
>
> On Fri, 10 May 2024 16:21:11 -0700 Mina Almasry wrote:
> > Device Memory TCP
>
> Sorry Mina, this is too big to apply during the merge window :(

No worries at all. I'll repost once it re-opens with any feedback I
get in the meantime.

-- 
Thanks,
Mina

Re: [PATCH v2 0/5] Add support for GE SUNH hot-pluggable connector (was: "drm: add support for hot-pluggable bridges")

[Luca Ceresoli]

Hello Rob,

On Fri, 10 May 2024 11:44:49 -0500
Rob Herring  wrote:

> On Fri, May 10, 2024 at 09:10:36AM +0200, Luca Ceresoli wrote:

[...]

> > Overall approach
> > 
> > 
> > Device tree overlays appear as the most natural solution to support the
> > addition and removal of devices from a running system.
> > 
> > Several features are missing from the mainline Linux kernel in order to
> > support this use case:
> > 
> >  1. runtime (un)loading of device tree overlays is not supported  
> 
> Not true. Device specific applying of overlays has been supported 
> since we merged DT overlay support. What's not supported is a general 
> purpose interface to userspace to change any part of the DT at any point 
> in time.

I think I should replace "supported" with "exposed [to user space]". In
other words, there is no user of of_overlay_fdt_apply() /
of_overlay_remove*() in mainline Linux, except in unittest. Would it be
a correct rewording?

> >  2. if enabled, overlay (un)loading exposes several bugs  
> 
> Hence why there is no general purpose interface.

Absolutely.

Best regards,
Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure

[Sui Jingfeng]

Hi,

On 2024/5/15 00:22, Maxime Ripard wrote:

Hi,

On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:

Because a lot of implementations has already added it into their drived
class, promote it into drm_bridge core may benifits a lot. drm bridge is
a driver, it should know the underlying hardware entity.

Is there some actual benefits, or is it theoretical at this point?



I think, DRM bridge drivers could remove the 'struct device *dev'
member from their derived structure. Rely on the drm bridge core
when they need the 'struct device *' pointer.


Maxime


--
Best regards,
Sui

Re: [PATCH v2 1/5] dt-bindings: connector: add GE SUNH hotplug addon connector

[Luca Ceresoli]

Hello Rob,

+cc Srinivas and Miquèl for the NVMEM cell discussion below

On Fri, 10 May 2024 11:36:25 -0500
Rob Herring  wrote:

> On Fri, May 10, 2024 at 09:10:37AM +0200, Luca Ceresoli wrote:
> > Add bindings for the GE SUNH add-on connector. This is a physical,
> > hot-pluggable connector that allows to attach and detach at runtime an
> > add-on adding peripherals on non-discoverable busses.
> > 
> > Signed-off-by: Luca Ceresoli 

[...]

> > +++ 
> > b/Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.yaml
> > @@ -0,0 +1,197 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/connector/ge,sunh-addon-connector.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GE SUNH hotplug add-on connector
> > +
> > +maintainers:
> > +  - Luca Ceresoli 
> > +
> > +description:
> > +  Represent the physical connector present on GE SUNH devices that allows
> > +  to attach and detach at runtime an add-on adding peripherals on
> > +  non-discoverable busses.
> > +
> > +  This connector has status GPIOs to notify the connection status to the
> > +  CPU and a reset GPIO to allow the CPU to reset all the peripherals on the
> > +  add-on. It also has a 4-lane MIPI DSI bus.
> > +
> > +  Add-on removal can happen at any moment under user control and without
> > +  prior notice to the CPU, making all of its components not usable
> > +  anymore. Later on, the same or a different add-on model can be 
> > connected.  
> 
> Is there any documentation for this connector?
> 
> Is the connector supposed to be generic in that any board with any SoC 
> could have it? If so, the connector needs to be able to remap things so 
> overlays aren't tied to the base dts, but only the connector. If not, 
> then doing that isn't required, but still a good idea IMO.

It is not generic. The connector pinout is very specific to this
product, and there is no public documentation.

> > +examples:
> > +  # Main DTS describing the "main" board up to the connector
> > +  - |
> > +/ {
> > +#include 
> > +
> > +addon_connector: addon-connector {  
> 
> Just 'connector' for the node name.

OK

> > +compatible = "ge,sunh-addon-connector";
> > +reset-gpios = < 1 GPIO_ACTIVE_LOW>;
> > +plugged-gpios = < 2 GPIO_ACTIVE_LOW>;
> > +powergood-gpios = < 3 GPIO_ACTIVE_HIGH>;
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +reg = <0>;
> > +
> > +hotplug_conn_dsi_in: endpoint {
> > +remote-endpoint = <_bridge_out>;
> > +};
> > +};
> > +
> > +port@1 {
> > +reg = <1>;
> > +
> > +hotplug_conn_dsi_out: endpoint {
> > +// remote-endpoint to be added by overlay
> > +};
> > +};
> > +};
> > +};
> > +};
> > +
> > +  # "base" overlay describing the common components on every add-on that
> > +  # are required to read the model ID  
> 
> This is located on the add-on board, right?

Exactly. Each add-on has an EEPROM with the add-on model ID stored
along with other data.

> Is it really any better to have this as a separate overlay rather than 
> just making it an include? Better to have just 1 overlay per board 
> applied atomically than splitting it up.

(see below)

> > +  - |
> > + {  
> 
> Generally, I think everything on an add-on board should be underneath 
> the connector node. For starters, that makes controlling probing and 
> removal of devices easier. For example, you'll want to handle 
> reset-gpios and powergood-gpios before any devices 'appear'. Otherwise, 
> you add devices on i2c1, start probing them, and then reset them at some 
> async time?

This is not a problem because the code is asserting reset before
loading the first overlay. From patch 5/5:

static int sunh_conn_attach(struct sunh_conn *conn)
{
int err;

/* Reset the plugged board in order to start from a stable state */
sunh_conn_reset(conn, false);

err = sunh_conn_load_base_overlay(conn);
...
}

> For i2c, it could look something like this:
> 
> connector {
>   i2c {
>   i2c-parent = <>;
> 
>   eeprom@50 {...};
>   };
> };

I think this can be done, but I need to evaluate what is needed in the
driver code to support it.

> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +eeprom@50 {
> > +compatible = "atmel,24c64";
> > +reg = <0x50>;
> > +
> > +nvmem-layout {
> > +compatible = "fixed-layout";
> > +#address-cells = <1>;
> > +#size-cells = <1>;
> > +
> > +addon_model_id: 

Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure

[Maxime Ripard]

Hi,

On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:
> Because a lot of implementations has already added it into their drived
> class, promote it into drm_bridge core may benifits a lot. drm bridge is
> a driver, it should know the underlying hardware entity.

Is there some actual benefits, or is it theoretical at this point?

Maxime


signature.asc
Description: PGP signature

Re: [RFC 0/5] Discussion around eviction improvements

[Christian König]

Am 14.05.24 um 17:14 schrieb Tvrtko Ursulin:


On 13/05/2024 14:49, Tvrtko Ursulin wrote:


On 09/05/2024 13:40, Tvrtko Ursulin wrote:


On 08/05/2024 19:09, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Last few days I was looking at the situation with VRAM over 
subscription, what
happens versus what perhaps should happen. Browsing through the 
driver and

running some simple experiments.

I ended up with this patch series which, as a disclaimer, may be 
completely
wrong but as I found some suspicious things, to me at least, I 
thought it was a

good point to stop and request some comments.

To perhaps summarise what are the main issues I think I found:

  * Migration rate limiting does not bother knowing if actual 
migration happened

    and so can over-account and unfairly penalise.

  * Migration rate limiting does not even work, at least not for 
the common case
    where userspace configures VRAM+GTT. It thinks it can stop 
migration attempts
    by playing with bo->allowed_domains vs bo->preferred domains 
but, both from
    the code, and from empirical experiments, I see that not 
working at all. Both

    masks are identical so fiddling with them achieves nothing.

  * Idea of the fallback placement only works when VRAM has free 
space. As soon
    as it does not, ttm_resource_compatible is happy to leave the 
buffers in the

    secondary placement forever.

  * Driver thinks it will be re-validating evicted buffers on the 
next submission
    but it does not for the very common case of VRAM+GTT because it 
only checks

    if current placement is *none* of the preferred placements.

All those problems are addressed in individual patches.

End result of this series appears to be driver which will try 
harder to move
buffers back into VRAM, but will be (more) correctly throttled in 
doing so by

the existing rate limiting logic.

I have run a quick benchmark of Cyberpunk 2077 and cannot say that 
I saw a
change but that could be a good thing too. At least I did not break 
anything,
perhaps.. On one occassion I did see the rate limiting logic get 
confused while
for a period of few minutes it went to a mode where it was 
constantly giving a
high migration budget. But that recovered itself when I switched 
clients and did
not come back so I don't know. If there is something wrong there I 
don't think

it would be caused by any patches in this series.


Since yesterday I also briefly tested with Far Cry New Dawn. One run 
each so possibly doesn't mean anything apart that there isn't a 
regression aka migration throttling is keeping things at bay even 
with increased requests to migrate things back to VRAM:


  before after
min/avg/max fps    36/44/54    37/45/55

Cyberpunk 2077 from yesterday was similarly close:

 26.96/29.59/30.40    29.70/30.00/30.32

I guess the real story is proper DGPU where misplaced buffers have a 
real cost.


I found one game which regresses spectacularly badly with this series 
- Assasin's Creed Valhalla. The built-in benchmark at least. The game 
appears to have a working set much larger than the other games I 
tested, around 5GiB total during the benchmark. And for some reason 
migration throttling totally fails to put it in check. I will be 
investigating this shortly.


I think that the conclusion is everything I attempted to add relating 
to TTM_PL_PREFERRED does not really work as I initially thought it 
did. Therefore please imagine this series as only containing patches 
1, 2 and 5.


Noted (and I had just started to wrap my head around that idea).



(And FWIW it was quite annoying to get to the bottom of since for some 
reason the system exibits some sort of a latching behaviour, where on 
some boots and/or some minutes of runtime things were fine, and then 
it would latch onto a mode where the TTM_PL_PREFERRED induced breakage 
would show. And sometimes this breakage would appear straight away. Odd.)


Welcome to my world. You improve one use case and four other get a 
penalty. Even when you know the code and potential use cases inside out 
it's really hard to predict how some applications and the core memory 
management behave sometimes.




I still need to test though if the subset of patches manage to achieve 
some positive improvement on their own. It is possible, as patch 5 
marks more buffers for re-validation so once overcommit subsides they 
would get promoted to preferred placement straight away. And 1&2 are 
notionally fixes for migration throttling so at least in broad sense 
should be still valid as discussion points.


Yeah, especially 5 kind of makes sense but could potentially lead to 
higher overhead. Need to see how we can better handle that.


Regards,
Christian.



Regards,

Tvrtko

Series is probably rough but should be good enough for dicsussion. 
I am curious
to hear if I identified at least something correctly as a real 
problem.


It would also be good to hear what are the suggested games to check 

[PATCH 1/2] drm/bridge: Support finding bridge with struct device

[Sui Jingfeng]

The pointer of 'struct device' can also be used as a key to search drm
bridge instance from the global bridge list, traditionally, fwnode and
'OF' based APIs requires the system has decent fwnode/OF Graph support.
While the drm_find_bridge_by_dev() function introduced in this series
don't has such a restriction. It only require you has a pointer to the
backing device. Hence, it may suitable for some small and/or limited
display subsystems.

Also add the drm_bridge_add_with_dev() as a helper, which automatically
set the .of_node field of drm_bridge instances if you call it. But it
suitable for simple bridge drivers which one device backing one drm_bridge
instance.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/drm_bridge.c | 39 
 include/drm/drm_bridge.h |  5 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 584d109330ab..1928d9d0dd3c 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -213,6 +213,23 @@ void drm_bridge_add(struct drm_bridge *bridge)
 }
 EXPORT_SYMBOL(drm_bridge_add);
 
+/**
+ * drm_bridge_add_with_dev - add the given bridge to the global bridge list
+ *
+ * @bridge: bridge control structure
+ * @dev: pointer to the kernel device that this bridge is backed.
+ */
+void drm_bridge_add_with_dev(struct drm_bridge *bridge, struct device *dev)
+{
+   if (dev) {
+   bridge->kdev = dev;
+   bridge->of_node = dev->of_node;
+   }
+
+   drm_bridge_add(bridge);
+}
+EXPORT_SYMBOL_GPL(drm_bridge_add_with_dev);
+
 static void drm_bridge_remove_void(void *bridge)
 {
drm_bridge_remove(bridge);
@@ -1334,6 +1351,27 @@ void drm_bridge_hpd_notify(struct drm_bridge *bridge,
 }
 EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
 
+struct drm_bridge *drm_find_bridge_by_dev(struct device *kdev)
+{
+   struct drm_bridge *bridge;
+
+   if (!kdev)
+   return NULL;
+
+   mutex_lock(_lock);
+
+   list_for_each_entry(bridge, _list, list) {
+   if (bridge->kdev == kdev) {
+   mutex_unlock(_lock);
+   return bridge;
+   }
+   }
+
+   mutex_unlock(_lock);
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(drm_find_bridge_by_dev);
+
 #ifdef CONFIG_OF
 /**
  * of_drm_find_bridge - find the bridge corresponding to the device node in
@@ -1361,6 +1399,7 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
*np)
return NULL;
 }
 EXPORT_SYMBOL(of_drm_find_bridge);
+
 #endif
 
 MODULE_AUTHOR("Ajay Kumar ");
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 4baca0d9107b..70d8393bbd9c 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -715,6 +715,8 @@ struct drm_bridge {
struct drm_private_obj base;
/** @dev: DRM device this bridge belongs to */
struct drm_device *dev;
+   /** @kdev: pointer to the kernel device backing this bridge */
+   struct device *kdev;
/** @encoder: encoder to which this bridge is connected */
struct drm_encoder *encoder;
/** @chain_node: used to form a bridge chain */
@@ -782,12 +784,15 @@ drm_priv_to_bridge(struct drm_private_obj *priv)
 }
 
 void drm_bridge_add(struct drm_bridge *bridge);
+void drm_bridge_add_with_dev(struct drm_bridge *bridge, struct device *dev);
 int devm_drm_bridge_add(struct device *dev, struct drm_bridge *bridge);
 void drm_bridge_remove(struct drm_bridge *bridge);
 int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
  struct drm_bridge *previous,
  enum drm_bridge_attach_flags flags);
 
+struct drm_bridge *drm_find_bridge_by_dev(struct device *kdev);
+
 #ifdef CONFIG_OF
 struct drm_bridge *of_drm_find_bridge(struct device_node *np);
 #else
-- 
2.43.0

[PATCH 2/2] drm/bridge: Switch to use drm_bridge_add_with_dev()

[Sui Jingfeng]

Normally, the drm_bridge::of_node member won't be used by drm bridge driver
instances, as display driver instances will use the device node fetched
from its backing device directly. The drm_bridge::of_node is mainly for
finding the drm bridge instance associated. Hence, display bridge drivers
don't have to set it manually for the canonical cases.

Let's reduce the boilerplates by using drm_bridge_add_with_dev().

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 +--
 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c   | 4 +---
 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c   | 4 +---
 drivers/gpu/drm/bridge/analogix/anx7625.c| 3 +--
 drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c   | 3 +--
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c  | 3 +--
 drivers/gpu/drm/bridge/chipone-icn6211.c | 5 ++---
 drivers/gpu/drm/bridge/chrontel-ch7033.c | 3 +--
 drivers/gpu/drm/bridge/cros-ec-anx7688.c | 4 +---
 drivers/gpu/drm/bridge/display-connector.c   | 3 +--
 drivers/gpu/drm/bridge/fsl-ldb.c | 3 +--
 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 3 +--
 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c  | 3 +--
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 3 +--
 drivers/gpu/drm/bridge/ite-it6505.c  | 3 +--
 drivers/gpu/drm/bridge/ite-it66121.c | 3 +--
 drivers/gpu/drm/bridge/lontium-lt8912b.c | 3 +--
 drivers/gpu/drm/bridge/lontium-lt9211.c  | 3 +--
 drivers/gpu/drm/bridge/lontium-lt9611.c  | 3 +--
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c   | 3 +--
 drivers/gpu/drm/bridge/lvds-codec.c  | 3 +--
 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 3 +--
 drivers/gpu/drm/bridge/microchip-lvds.c  | 3 +--
 drivers/gpu/drm/bridge/nwl-dsi.c | 3 +--
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 3 +--
 drivers/gpu/drm/bridge/panel.c   | 3 +--
 drivers/gpu/drm/bridge/parade-ps8622.c   | 3 +--
 drivers/gpu/drm/bridge/parade-ps8640.c   | 1 -
 drivers/gpu/drm/bridge/samsung-dsim.c| 3 +--
 drivers/gpu/drm/bridge/sii902x.c | 3 +--
 drivers/gpu/drm/bridge/sii9234.c | 3 +--
 drivers/gpu/drm/bridge/sil-sii8620.c | 3 +--
 drivers/gpu/drm/bridge/simple-bridge.c   | 3 +--
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 3 +--
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c| 3 +--
 drivers/gpu/drm/bridge/tc358762.c| 3 +--
 drivers/gpu/drm/bridge/tc358764.c| 3 +--
 drivers/gpu/drm/bridge/tc358767.c| 3 +--
 drivers/gpu/drm/bridge/tc358768.c| 3 +--
 drivers/gpu/drm/bridge/tc358775.c| 3 +--
 drivers/gpu/drm/bridge/thc63lvd1024.c| 3 +--
 drivers/gpu/drm/bridge/ti-dlpc3433.c | 3 +--
 drivers/gpu/drm/bridge/ti-sn65dsi83.c| 3 +--
 drivers/gpu/drm/bridge/ti-sn65dsi86.c| 3 +--
 drivers/gpu/drm/bridge/ti-tfp410.c   | 3 +--
 drivers/gpu/drm/bridge/ti-tpd12s015.c| 3 +--
 drivers/gpu/drm/i2c/tda998x_drv.c| 5 +
 47 files changed, 47 insertions(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 6089b0bb9321..8e4a95584ad8 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1318,10 +1318,9 @@ static int adv7511_probe(struct i2c_client *i2c)
if (adv7511->i2c_main->irq)
adv7511->bridge.ops |= DRM_BRIDGE_OP_HPD;
 
-   adv7511->bridge.of_node = dev->of_node;
adv7511->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
 
-   drm_bridge_add(>bridge);
+   drm_bridge_add_with_dev(>bridge, dev);
 
adv7511_audio_init(dev, adv7511);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index b754947e3e00..f4f3298404d2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -697,8 +697,6 @@ static int anx6345_i2c_probe(struct i2c_client *client)
 
mutex_init(>lock);
 
-   anx6345->bridge.of_node = client->dev.of_node;
-
anx6345->client = client;
i2c_set_clientdata(client, anx6345);
 
@@ -766,7 +764,7 @@ static int anx6345_i2c_probe(struct i2c_client *client)
anx6345_poweron(anx6345);
if (anx6345_get_chip_id(anx6345)) {
anx6345->bridge.funcs = _bridge_funcs;
-

[PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure

[Sui Jingfeng]

Because a lot of implementations has already added it into their drived
class, promote it into drm_bridge core may benifits a lot. drm bridge is
a driver, it should know the underlying hardware entity.

Sui Jingfeng (2):
  drm/bridge: Support finding bridge with struct device
  drm/bridge: Switch to use drm_bridge_add_with_dev()

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c  |  3 +-
 .../drm/bridge/analogix/analogix-anx6345.c|  4 +-
 .../drm/bridge/analogix/analogix-anx78xx.c|  4 +-
 drivers/gpu/drm/bridge/analogix/anx7625.c |  3 +-
 .../gpu/drm/bridge/cadence/cdns-dsi-core.c|  3 +-
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   |  3 +-
 drivers/gpu/drm/bridge/chipone-icn6211.c  |  5 +--
 drivers/gpu/drm/bridge/chrontel-ch7033.c  |  3 +-
 drivers/gpu/drm/bridge/cros-ec-anx7688.c  |  4 +-
 drivers/gpu/drm/bridge/display-connector.c|  3 +-
 drivers/gpu/drm/bridge/fsl-ldb.c  |  3 +-
 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c  |  3 +-
 .../gpu/drm/bridge/imx/imx8qxp-pixel-link.c   |  3 +-
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c  |  3 +-
 drivers/gpu/drm/bridge/ite-it6505.c   |  3 +-
 drivers/gpu/drm/bridge/ite-it66121.c  |  3 +-
 drivers/gpu/drm/bridge/lontium-lt8912b.c  |  3 +-
 drivers/gpu/drm/bridge/lontium-lt9211.c   |  3 +-
 drivers/gpu/drm/bridge/lontium-lt9611.c   |  3 +-
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c|  3 +-
 drivers/gpu/drm/bridge/lvds-codec.c   |  3 +-
 .../bridge/megachips-stdp-ge-b850v3-fw.c  |  3 +-
 drivers/gpu/drm/bridge/microchip-lvds.c   |  3 +-
 drivers/gpu/drm/bridge/nwl-dsi.c  |  3 +-
 drivers/gpu/drm/bridge/nxp-ptn3460.c  |  3 +-
 drivers/gpu/drm/bridge/panel.c|  3 +-
 drivers/gpu/drm/bridge/parade-ps8622.c|  3 +-
 drivers/gpu/drm/bridge/parade-ps8640.c|  1 -
 drivers/gpu/drm/bridge/samsung-dsim.c |  3 +-
 drivers/gpu/drm/bridge/sii902x.c  |  3 +-
 drivers/gpu/drm/bridge/sii9234.c  |  3 +-
 drivers/gpu/drm/bridge/sil-sii8620.c  |  3 +-
 drivers/gpu/drm/bridge/simple-bridge.c|  3 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  3 +-
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c |  3 +-
 drivers/gpu/drm/bridge/tc358762.c |  3 +-
 drivers/gpu/drm/bridge/tc358764.c |  3 +-
 drivers/gpu/drm/bridge/tc358767.c |  3 +-
 drivers/gpu/drm/bridge/tc358768.c |  3 +-
 drivers/gpu/drm/bridge/tc358775.c |  3 +-
 drivers/gpu/drm/bridge/thc63lvd1024.c |  3 +-
 drivers/gpu/drm/bridge/ti-dlpc3433.c  |  3 +-
 drivers/gpu/drm/bridge/ti-sn65dsi83.c |  3 +-
 drivers/gpu/drm/bridge/ti-sn65dsi86.c |  3 +-
 drivers/gpu/drm/bridge/ti-tfp410.c|  3 +-
 drivers/gpu/drm/bridge/ti-tpd12s015.c |  3 +-
 drivers/gpu/drm/drm_bridge.c  | 39 +++
 drivers/gpu/drm/i2c/tda998x_drv.c |  5 +--
 include/drm/drm_bridge.h  |  5 +++
 49 files changed, 91 insertions(+), 99 deletions(-)

-- 
2.43.0

[PATCH 3/3] dt-bindings: display: vop2: Add VP clock resets

[Detlev Casanova]

Add the documentation for VOP2 video ports reset clocks.
One reset can be set per video port.

Signed-off-by: Detlev Casanova 
---
 .../display/rockchip/rockchip-vop2.yaml   | 27 +++
 1 file changed, 27 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
index 2531726af306b..941fd059498d4 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
@@ -65,6 +65,22 @@ properties:
   - const: dclk_vp3
   - const: pclk_vop
 
+  resets:
+minItems: 3
+items:
+  - description: Pixel clock reset for video port 0.
+  - description: Pixel clock reset for video port 1.
+  - description: Pixel clock reset for video port 2.
+  - description: Pixel clock reset for video port 3.
+
+  reset-names:
+minItems: 3
+items:
+  - const: dclk_vp0
+  - const: dclk_vp1
+  - const: dclk_vp2
+  - const: dclk_vp3
+
   rockchip,grf:
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
@@ -128,6 +144,11 @@ allOf:
 clock-names:
   minItems: 7
 
+resets:
+  minItems: 4
+reset-names:
+  minItems: 4
+
 ports:
   required:
 - port@0
@@ -183,6 +204,12 @@ examples:
   "dclk_vp0",
   "dclk_vp1",
   "dclk_vp2";
+resets = < SRST_VOP0>,
+ < SRST_VOP1>,
+ < SRST_VOP2>;
+reset-names = "dclk_vp0",
+  "dclk_vp1",
+  "dclk_vp2";
 power-domains = < RK3568_PD_VO>;
 iommus = <_mmu>;
 vop_out: ports {
-- 
2.43.2

[PATCH 2/3] arm64: dts: rockchip: Add VOP clock resets for rk3588s

[Detlev Casanova]

This adds the needed clock resets for all rk3588(s) based SOCs.

Signed-off-by: Detlev Casanova 
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 6ac5ac8b48abb..8560c92cd406c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -1193,6 +1193,14 @@ vop: vop@fdd9 {
  "pclk_vop";
iommus = <_mmu>;
power-domains = < RK3588_PD_VOP>;
+   resets = < SRST_D_VOP0>,
+< SRST_D_VOP1>,
+< SRST_D_VOP2>,
+< SRST_D_VOP3>;
+   reset-names = "dclk_vp0",
+ "dclk_vp1",
+ "dclk_vp2",
+ "dclk_vp3";
rockchip,grf = <_grf>;
rockchip,vop-grf = <_grf>;
rockchip,vo1-grf = <_grf>;
-- 
2.43.2

[PATCH 1/3] drm/rockchip: vop2: Add clock resets support

[Detlev Casanova]

At the end of initialization, each VP clock needs to be reset before
they can be used.

Failing to do so can put the VOP in an undefined state where the
generated HDMI signal is either lost or not matching the selected mode.

Signed-off-by: Detlev Casanova 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 30 
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index fdd768bbd487c..e81a67161d29a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -157,6 +158,7 @@ struct vop2_win {
 struct vop2_video_port {
struct drm_crtc crtc;
struct vop2 *vop2;
+   struct reset_control *dclk_rst;
struct clk *dclk;
unsigned int id;
const struct vop2_video_port_data *data;
@@ -1915,6 +1917,26 @@ static int us_to_vertical_line(struct drm_display_mode 
*mode, int us)
return us * mode->clock / mode->htotal / 1000;
 }
 
+static int vop2_clk_reset(struct vop2_video_port *vp)
+{
+   struct reset_control *rstc = vp->dclk_rst;
+   struct vop2 *vop2 = vp->vop2;
+   int ret;
+
+   if (!rstc)
+   return 0;
+
+   ret = reset_control_assert(rstc);
+   if (ret < 0)
+   drm_warn(vop2->drm, "failed to assert reset\n");
+   udelay(10);
+   ret = reset_control_deassert(rstc);
+   if (ret < 0)
+   drm_warn(vop2->drm, "failed to deassert reset\n");
+
+   return ret;
+}
+
 static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
 {
@@ -2055,6 +2077,8 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
 
vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
 
+   vop2_clk_reset(vp);
+
drm_crtc_vblank_on(crtc);
 
vop2_unlock(vop2);
@@ -2706,6 +2730,12 @@ static int vop2_create_crtcs(struct vop2 *vop2)
vp->data = vp_data;
 
snprintf(dclk_name, sizeof(dclk_name), "dclk_vp%d", vp->id);
+   vp->dclk_rst = devm_reset_control_get_optional(vop2->dev, 
dclk_name);
+   if (IS_ERR(vp->dclk_rst)) {
+   drm_err(vop2->drm, "failed to get %s reset\n", 
dclk_name);
+   return PTR_ERR(vp->dclk_rst);
+   }
+
vp->dclk = devm_clk_get(vop2->dev, dclk_name);
if (IS_ERR(vp->dclk)) {
drm_err(vop2->drm, "failed to get %s\n", dclk_name);
-- 
2.43.2

[PATCH 0/3] drm/rockchip: vop2: Add VP clock resets support

[Detlev Casanova]

The clock reset must be used when the VOP is configured. Skipping it can
put the VOP in an unknown state where the HDMI signal is either lost or
not matching the selected mode.

This adds support for rk3588(s) based SoCs.

Detlev Casanova (3):
  drm/rockchip: vop2: Add clock resets support
  arm64: dts: rockchip: Add VOP clock resets for rk3588s
  dt-bindings: display: vop2: Add VP clock resets

 .../display/rockchip/rockchip-vop2.yaml   | 27 +
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi |  8 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c  | 30 +++
 3 files changed, 65 insertions(+)

-- 
2.43.2

Re: [RFC 0/5] Discussion around eviction improvements

[Tvrtko Ursulin]

On 13/05/2024 14:49, Tvrtko Ursulin wrote:


On 09/05/2024 13:40, Tvrtko Ursulin wrote:


On 08/05/2024 19:09, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Last few days I was looking at the situation with VRAM over 
subscription, what
happens versus what perhaps should happen. Browsing through the 
driver and

running some simple experiments.

I ended up with this patch series which, as a disclaimer, may be 
completely
wrong but as I found some suspicious things, to me at least, I 
thought it was a

good point to stop and request some comments.

To perhaps summarise what are the main issues I think I found:

  * Migration rate limiting does not bother knowing if actual 
migration happened

    and so can over-account and unfairly penalise.

  * Migration rate limiting does not even work, at least not for the 
common case
    where userspace configures VRAM+GTT. It thinks it can stop 
migration attempts
    by playing with bo->allowed_domains vs bo->preferred domains but, 
both from
    the code, and from empirical experiments, I see that not working 
at all. Both

    masks are identical so fiddling with them achieves nothing.

  * Idea of the fallback placement only works when VRAM has free 
space. As soon
    as it does not, ttm_resource_compatible is happy to leave the 
buffers in the

    secondary placement forever.

  * Driver thinks it will be re-validating evicted buffers on the 
next submission
    but it does not for the very common case of VRAM+GTT because it 
only checks

    if current placement is *none* of the preferred placements.

All those problems are addressed in individual patches.

End result of this series appears to be driver which will try harder 
to move
buffers back into VRAM, but will be (more) correctly throttled in 
doing so by

the existing rate limiting logic.

I have run a quick benchmark of Cyberpunk 2077 and cannot say that I 
saw a
change but that could be a good thing too. At least I did not break 
anything,
perhaps.. On one occassion I did see the rate limiting logic get 
confused while
for a period of few minutes it went to a mode where it was constantly 
giving a
high migration budget. But that recovered itself when I switched 
clients and did
not come back so I don't know. If there is something wrong there I 
don't think

it would be caused by any patches in this series.


Since yesterday I also briefly tested with Far Cry New Dawn. One run 
each so possibly doesn't mean anything apart that there isn't a 
regression aka migration throttling is keeping things at bay even with 
increased requests to migrate things back to VRAM:


  before after
min/avg/max fps    36/44/54    37/45/55

Cyberpunk 2077 from yesterday was similarly close:

 26.96/29.59/30.40    29.70/30.00/30.32

I guess the real story is proper DGPU where misplaced buffers have a 
real cost.


I found one game which regresses spectacularly badly with this series - 
Assasin's Creed Valhalla. The built-in benchmark at least. The game 
appears to have a working set much larger than the other games I tested, 
around 5GiB total during the benchmark. And for some reason migration 
throttling totally fails to put it in check. I will be investigating 
this shortly.


I think that the conclusion is everything I attempted to add relating to 
TTM_PL_PREFERRED does not really work as I initially thought it did. 
Therefore please imagine this series as only containing patches 1, 2 and 5.


(And FWIW it was quite annoying to get to the bottom of since for some 
reason the system exibits some sort of a latching behaviour, where on 
some boots and/or some minutes of runtime things were fine, and then it 
would latch onto a mode where the TTM_PL_PREFERRED induced breakage 
would show. And sometimes this breakage would appear straight away. Odd.)


I still need to test though if the subset of patches manage to achieve 
some positive improvement on their own. It is possible, as patch 5 marks 
more buffers for re-validation so once overcommit subsides they would 
get promoted to preferred placement straight away. And 1&2 are 
notionally fixes for migration throttling so at least in broad sense 
should be still valid as discussion points.


Regards,

Tvrtko

Series is probably rough but should be good enough for dicsussion. I 
am curious

to hear if I identified at least something correctly as a real problem.

It would also be good to hear what are the suggested games to check 
and see

whether there is any improvement.

Cc: Christian König 
Cc: Friedrich Vock 

Tvrtko Ursulin (5):
   drm/amdgpu: Fix migration rate limiting accounting
   drm/amdgpu: Actually respect buffer migration budget
   drm/ttm: Add preferred placement flag
   drm/amdgpu: Use preferred placement for VRAM+GTT
   drm/amdgpu: Re-validate evicted buffers

  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 38 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  8 +++--
  

Re: drm/bridge: adv7511: Attach next bridge without creating connector

[Laurent Pinchart]

Hello,

On Tue, May 14, 2024 at 12:26:15AM +0800, Sui Jingfeng wrote:
> On 5/13/24 16:02, Liu Ying wrote:
> > The connector is created by either this ADV7511 bridge driver or
> > any DRM device driver/previous bridge driver, so this ADV7511
> > bridge driver should not let the next bridge driver create connector.
> > 
> > If the next bridge is a HDMI connector, the next bridge driver
> > would fail to attach bridge from display_connector_attach() without
> > the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.

In theory we could have another HDMI-to-something bridge connected to
the ADV7511 output, and that bridge could create a connector. However,
before commit 14b3cdbd0e5b the adv7511 driver didn't try to attach to
the next bridge, so it's clear that no platform support in mainline had
such a setup. It should be safe to set DRM_BRIDGE_ATTACH_NO_CONNECTOR
unconditionally here.

Reviewed-by: Laurent Pinchart 

> > 
> > Add that flag to drm_bridge_attach() function call in
> > adv7511_bridge_attach() to fix the issue.
> > 
> > This fixes the issue where the HDMI connector bridge fails to attach
> > to the previous ADV7535 bridge on i.MX8MP EVK platform:
> > 
> > [2.216442] [drm:drm_bridge_attach] *ERROR* failed to attach bridge 
> > /hdmi-connector to encoder None-37: -22
> > [2.220675] mmc1: SDHCI controller on 30b5.mmc [30b5.mmc] using 
> > ADMA
> > [2.226262] [drm:drm_bridge_attach] *ERROR* failed to attach bridge 
> > /soc@0/bus@3080/i2c@30a3/hdmi@3d to encoder None-37: -22
> > [2.245204] [drm:drm_bridge_attach] *ERROR* failed to attach bridge 
> > /soc@0/bus@32c0/dsi@32e6 to encoder None-37: -22
> > [2.256445] imx-lcdif 32e8.display-controller: error -EINVAL: Failed 
> > to attach bridge for endpoint0
> > [2.265850] imx-lcdif 32e8.display-controller: error -EINVAL: Cannot 
> > connect bridge
> > [2.274009] imx-lcdif 32e8.display-controller: probe with driver 
> > imx-lcdif failed with error -22
> > 
> > Fixes: 14b3cdbd0e5b ("drm/bridge: adv7511: make it honour next bridge in 
> > DT")
> > Signed-off-by: Liu Ying 
> > ---
> >   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index dd21b81bd28f..66ccb61e2a66 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -953,7 +953,8 @@ static int adv7511_bridge_attach(struct drm_bridge 
> > *bridge,
> > int ret = 0;
> >   
> > if (adv->next_bridge) {
> > -   ret = drm_bridge_attach(bridge->encoder, adv->next_bridge, 
> > bridge, flags);
> > +   ret = drm_bridge_attach(bridge->encoder, adv->next_bridge, 
> > bridge,
> > +   flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> 
> As a side note, I think, maybe you could do better in the future.
> 
> If we know that the KMS display driver side has the HDMI connector
> already created for us, we should pass DRM_BRIDGE_ATTACH_NO_CONNECTOR
> from the root KMS driver side. Which is to forbidden all potential
> drm bridge drivers to create a connector in the middle.

That's the recommended way for new drivers. Using the
drm_bridge_connector helper handles all this for you.

> The KMS display driver side could parse the DT to know if there is
> a hdmi connector, or merely just hdmi connector device node, or
> something else.

No, that would violate the basic principle of not peeking into the DT of
devices you know nothing about. The display engine driver can't walk the
pipeline in DT and expect to understand all the DT nodes on the path,
and what their properties mean.

What KMS drivers should do is to use the drm_bridge_connector helper.
Calling drm_bridge_connector_init() will create a connector for a chain
of bridges. The KMS driver should then attach to the first bridge with
DRM_BRIDGE_ATTACH_NO_CONNECTOR, unconditionally.

> However, other maintainer and/or reviewer's opinion are of cause
> more valuable. I send a A-b because I thought the bug is urgency
> and it's probably more important to solve this bug first. And
> maybe you can Cc:  if you like.
> 
> > if (ret)
> > return ret;
> > }

-- 
Regards,

Laurent Pinchart

drm: Remove driver dependencies on FB_DEVICE

[Manas Ghandat]

Hi. I recently looked at the todos of drm and found the topic 
interesting. I wanted to get started with this issue but having some 
trouble identifying the devices. What would be the right approach to get 
started?


Thanks,

Manas

[drm-tip:drm-tip 10/10] htmldocs: Warning: integration-manifest references a file that doesn't exist: Documentation/i915

[kernel test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   723adadf19b6bd8a54881b0e7d04ba56c4e8f401
commit: 723adadf19b6bd8a54881b0e7d04ba56c4e8f401 [10/10] drm-tip: 
2024y-05m-14d-12h-21m-31s UTC integration manifest
reproduce: 
(https://download.01.org/0day-ci/archive/20240514/202405142346.oqo7oogu-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202405142346.oqo7oogu-...@intel.com/

All warnings (new ones prefixed by >>):

   Warning: Documentation/devicetree/bindings/power/wakeup-source.txt 
references a file that doesn't exist: 
Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
   Warning: 
Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml 
references a file that doesn't exist: 
Documentation/devicetree/bindings/mfd/siliconmitus,sm5703.yaml
   Warning: Documentation/devicetree/bindings/sound/fsl-asoc-card.txt 
references a file that doesn't exist: 
Documentation/devicetree/bindings/sound/fsl,asrc.txt
   Warning: Documentation/userspace-api/netlink/index.rst references a file 
that doesn't exist: Documentation/networking/netlink_spec/index.rst
   Warning: Documentation/userspace-api/netlink/specs.rst references a file 
that doesn't exist: Documentation/networking/netlink_spec/index.rst
>> Warning: integration-manifest references a file that doesn't exist: 
>> Documentation/i915
   Using alabaster theme

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs

[Michal Wajdeczko]

On 13.05.2024 18:53, John Harrison wrote:
> On 5/12/2024 08:36, Michal Wajdeczko wrote:
>> We already provide the content of the GuC log in debugsfs, but it
>> is in a text format where each log dword is printed as hexadecimal
>> number, which does not scale well with large GuC log buffers.
>>
>> To allow more efficient access to the GuC log, which could benefit
>> our CI systems, expose raw binary log data.  In addition to less
>> overhead in preparing text based GuC log file, the new GuC log file
>> in binary format is also almost 3x smaller.
>>
>> Any existing script that expects the GuC log buffer in text format
>> can use command like below to convert from new binary format:
>>
>> hexdump -e '4/4 "0x%08x " "\n"'
>>
>> but this shouldn't be the case as most decoders expect GuC log data
>> in binary format.
> I strongly disagree with this.
> 
> Efficiency and file size is not an issue when accessing the GuC log via
> debugfs on actual hardware. 

to some extend it is as CI team used to refuse to collect GuC logs after
each executed test just because of it's size

> It is an issue when dumping via dmesg but
> you definitely should not be dumping binary data to dmesg. Whereas,

not following here - this is debugfs specific, not a dmesg printer

> dumping in binary data is much more dangerous and liable to corruption
> because some tool along the way tries to convert to ASCII, or truncates
> at the first zero, etc. We request GuC logs be sent by end users,
> customer bug reports, etc. all doing things that we have no control over.

hmm, how "cp gt0/uc/guc_log_raw FILE" could end with a corrupted file ?

> 
> Converting the hexdump back to binary is trivial for those tools which
> require it. If you follow the acquisition and decoding instructions on
> the wiki page then it is all done for you automatically.

I'm afraid I don't know where this wiki page is, but I do know that hex
conversion dance is not needed for me to get decoded GuC log the way I
used to do

> 
> These patches are trying to solve a problem which does not exist and are
> going to make working with GuC logs harder and more error prone.

it at least solves the problem of currently super inefficient way of
generating the GuC log in text format.

it also opens other opportunities to develop tools that could monitor or
capture GuC log independently on  top of what driver is able to offer
today (on i915 there was guc-log-relay, but it was broken for long time,
not sure what are the plans for Xe)

also still not sure how it can be more error prone.

> 
> On the other hand, there are many other issues with GuC logs that it
> would be useful to solves - including extra meta data, reliable output
> via dmesg, continuous streaming, pre-sizing the debugfs file to not have
> to generate it ~12 times for a single read, etc.

this series actually solves last issue but in a bit different way (we
even don't need to generate full GuC log dump at all if we would like to
capture only part of the log if we know where to look)

for reliable output via dmesg - see my proposal at [1]

[1] https://patchwork.freedesktop.org/series/133613/

> 
> Hmm. Actually, is this interface allowing the filesystem layers to issue
> multiple read calls to read the buffer out in small chunks? That is also
> going to break things. If the GuC is still writing to the log as the
> user is reading from it, there is the opportunity for each chunk to not
> follow on from the previous chunk because the data has just been
> overwritten. This is already a problem at the moment that causes issues
> when decoding the logs, even with an almost atomic copy of the log into
> a temporary buffer before reading it out. Doing the read in separate
> chunks is only going to make that problem even worse.

current solution, that converts data into hex numbers, reads log buffer
in chunks of 128 dwords, how proposed here solution that reads in 4K
chunks could be "even worse" ?

and in case of some smart tool, that would understands the layout of the
GuC log buffer, we can even fully eliminate problem of reading stale
data, so why not to choose a more scalable solution ?

> 
> John.
> 
>> Signed-off-by: Michal Wajdeczko 
>> Cc: Lucas De Marchi 
>> Cc: John Harrison 
>> ---
>> Cc: linux-fsde...@vger.kernel.org
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>>   drivers/gpu/drm/xe/xe_guc_debugfs.c | 26 ++
>>   1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_guc_debugfs.c
>> b/drivers/gpu/drm/xe/xe_guc_debugfs.c
>> index d3822cbea273..53fea952344d 100644
>> --- a/drivers/gpu/drm/xe/xe_guc_debugfs.c
>> +++ b/drivers/gpu/drm/xe/xe_guc_debugfs.c
>> @@ -8,6 +8,7 @@
>>   #include 
>>   #include 
>>   +#include "xe_bo.h"
>>   #include "xe_device.h"
>>   #include "xe_gt.h"
>>   #include "xe_guc.h"
>> @@ -52,6 +53,29 @@ static const struct drm_info_list debugfs_list[] = {
>>   {"guc_log", guc_log, 0},
>>   };
>>   +static ssize_t guc_log_read(struct file 

[PATCH v3 1/2] drm/buddy: Fix the range bias clear memory allocation issue

[Arunpravin Paneer Selvam]

Problem statement: During the system boot time, an application request
for the bulk volume of cleared range bias memory when the clear_avail
is zero, we dont fallback into normal allocation method as we had an
unnecessary clear_avail check which prevents the fallback method leads
to fb allocation failure following system goes into unresponsive state.

Solution: Remove the unnecessary clear_avail check in the range bias
allocation function.

v2: add a kunit for this corner case (Daniel Vetter)

Signed-off-by: Arunpravin Paneer Selvam 
Fixes: 96950929eb23 ("drm/buddy: Implement tracking clear page feature")
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/drm_buddy.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 284ebae71cc4..1daf778cf6fa 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -249,6 +249,7 @@ int drm_buddy_init(struct drm_buddy *mm, u64 size, u64 
chunk_size)
 
mm->size = size;
mm->avail = size;
+   mm->clear_avail = 0;
mm->chunk_size = chunk_size;
mm->max_order = ilog2(size) - ilog2(chunk_size);
 
@@ -574,7 +575,7 @@ __drm_buddy_alloc_range_bias(struct drm_buddy *mm,
 
block = __alloc_range_bias(mm, start, end, order,
   flags, fallback);
-   if (IS_ERR(block) && mm->clear_avail)
+   if (IS_ERR(block))
return __alloc_range_bias(mm, start, end, order,
  flags, !fallback);
 
-- 
2.25.1

[PATCH v3 2/2] drm/tests: Add a unit test for range bias allocation

[Arunpravin Paneer Selvam]

Allocate cleared blocks in the bias range when the DRM
buddy's clear avail is zero. This will validate the bias
range allocation in scenarios like system boot when no
cleared blocks are available and exercise the fallback
path too. The resulting blocks should always be dirty.

v1:(Matthew)
  - move the size to the variable declaration section.
  - move the mm.clear_avail init to allocator init.

Signed-off-by: Arunpravin Paneer Selvam 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/tests/drm_buddy_test.c | 36 +-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c 
b/drivers/gpu/drm/tests/drm_buddy_test.c
index e3b50e240d36..b3be68b03610 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -23,9 +23,11 @@ static inline u64 get_size(int order, u64 chunk_size)
 
 static void drm_test_buddy_alloc_range_bias(struct kunit *test)
 {
-   u32 mm_size, ps, bias_size, bias_start, bias_end, bias_rem;
+   u32 mm_size, size, ps, bias_size, bias_start, bias_end, bias_rem;
DRM_RND_STATE(prng, random_seed);
unsigned int i, count, *order;
+   struct drm_buddy_block *block;
+   unsigned long flags;
struct drm_buddy mm;
LIST_HEAD(allocated);
 
@@ -222,6 +224,38 @@ static void drm_test_buddy_alloc_range_bias(struct kunit 
*test)
 
drm_buddy_free_list(, , 0);
drm_buddy_fini();
+
+   /*
+* Allocate cleared blocks in the bias range when the DRM buddy's clear 
avail is
+* zero. This will validate the bias range allocation in scenarios like 
system boot
+* when no cleared blocks are available and exercise the fallback path 
too. The resulting
+* blocks should always be dirty.
+*/
+
+   KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_init(, mm_size, ps),
+  "buddy_init failed\n");
+
+   bias_start = round_up(prandom_u32_state() % (mm_size - ps), ps);
+   bias_end = round_up(bias_start + prandom_u32_state() % (mm_size - 
bias_start), ps);
+   bias_end = max(bias_end, bias_start + ps);
+   bias_rem = bias_end - bias_start;
+
+   flags = DRM_BUDDY_CLEAR_ALLOCATION | DRM_BUDDY_RANGE_ALLOCATION;
+   size = max(round_up(prandom_u32_state() % bias_rem, ps), ps);
+
+   KUNIT_ASSERT_FALSE_MSG(test,
+  drm_buddy_alloc_blocks(, bias_start,
+ bias_end, size, ps,
+ ,
+ flags),
+  "buddy_alloc failed with bias(%x-%x), size=%u, 
ps=%u\n",
+  bias_start, bias_end, size, ps);
+
+   list_for_each_entry(block, , link)
+   KUNIT_EXPECT_EQ(test, drm_buddy_block_is_clear(block), false);
+
+   drm_buddy_free_list(, , 0);
+   drm_buddy_fini();
 }
 
 static void drm_test_buddy_alloc_clear(struct kunit *test)
-- 
2.25.1

[RFC] drm/print: Introduce drm_line_printer

[Michal Wajdeczko]

This drm printer wrapper can be used to increase the robustness of
the captured output generated by any other drm_printer to make sure
we didn't lost any intermediate lines of the output by adding line
numbers to each output line. Helpful for capturing some crash data.

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/drm_print.c |  9 +
 include/drm/drm_print.h | 37 +
 2 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index cf2efb44722c..d6fb50d3407a 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -214,6 +214,15 @@ void __drm_printfn_err(struct drm_printer *p, struct 
va_format *vaf)
 }
 EXPORT_SYMBOL(__drm_printfn_err);
 
+void __drm_printfn_line(struct drm_printer *p, struct va_format *vaf)
+{
+   unsigned int line = (uintptr_t)(++p->prefix);
+   struct drm_printer *dp = p->arg;
+
+   drm_printf(dp, "%u: %pV", line, vaf);
+}
+EXPORT_SYMBOL(__drm_printfn_line);
+
 /**
  * drm_puts - print a const string to a _printer stream
  * @p: the  printer
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 089950ad8681..58cc73c53853 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -186,6 +186,7 @@ void __drm_puts_seq_file(struct drm_printer *p, const char 
*str);
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_dbg(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf);
+void __drm_printfn_line(struct drm_printer *p, struct va_format *vaf);
 
 __printf(2, 3)
 void drm_printf(struct drm_printer *p, const char *f, ...);
@@ -357,6 +358,42 @@ static inline struct drm_printer drm_err_printer(struct 
drm_device *drm,
return p;
 }
 
+/**
+ * drm_line_printer - construct a _printer that prefixes outputs with line 
numbers
+ * @dp: the  drm_printer which actually generates the output
+ *
+ * This printer can be used to increase the robustness of the captured output
+ * to make sure we didn't lost any intermediate lines of the output. Helpful
+ * while capturing some crash data.
+ *
+ * For example::
+ *
+ * void crash_dump(struct drm_device *drm)
+ * {
+ * struct drm_printer dp = drm_err_printer(drm, "crash");
+ * struct drm_printer lp = drm_line_printer();
+ *
+ * drm_printf(, "foo");
+ * drm_printf(, "bar");
+ * }
+ *
+ * Above code will print into the dmesg something like::
+ *
+ * [ ] :00:00.0: [drm] *ERROR* crash 1: foo
+ * [ ] :00:00.0: [drm] *ERROR* crash 2: bar
+ *
+ * RETURNS:
+ * The _printer object
+ */
+static inline struct drm_printer drm_line_printer(struct drm_printer *dp)
+{
+   struct drm_printer lp = {
+   .printfn = __drm_printfn_line,
+   .arg = dp,
+   };
+   return lp;
+}
+
 /*
  * struct device based logging
  *
-- 
2.43.0

Re: [PATCH] Revert "drm/msm/dpu: drop dpu_encoder_phys_ops.atomic_mode_set"

[Caleb Connolly]

hw_pp->caps->intr_rdptr;
-
dpu_core_irq_register_callback(phys_enc->dpu_kms,
   phys_enc->irq[INTR_IDX_PINGPONG],
   dpu_encoder_phys_cmd_pp_tx_done_irq,
@@ -318,10 +327,6 @@ static void dpu_encoder_phys_cmd_irq_disable(struct 
dpu_encoder_phys *phys_enc)
dpu_core_irq_unregister_callback(phys_enc->dpu_kms, 
phys_enc->irq[INTR_IDX_UNDERRUN]);
dpu_encoder_phys_cmd_control_vblank_irq(phys_enc, false);
dpu_core_irq_unregister_callback(phys_enc->dpu_kms, 
phys_enc->irq[INTR_IDX_PINGPONG]);
-
-   phys_enc->irq[INTR_IDX_CTL_START] = 0;
-   phys_enc->irq[INTR_IDX_PINGPONG] = 0;
-   phys_enc->irq[INTR_IDX_RDPTR] = 0;
  }
  
  static void dpu_encoder_phys_cmd_tearcheck_config(

@@ -698,6 +703,7 @@ static void dpu_encoder_phys_cmd_init_ops(
struct dpu_encoder_phys_ops *ops)
  {
ops->is_master = dpu_encoder_phys_cmd_is_master;
+   ops->atomic_mode_set = dpu_encoder_phys_cmd_atomic_mode_set;
ops->enable = dpu_encoder_phys_cmd_enable;
ops->disable = dpu_encoder_phys_cmd_disable;
ops->control_vblank_irq = dpu_encoder_phys_cmd_control_vblank_irq;
@@ -736,8 +742,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(struct 
drm_device *dev,
  
  	dpu_encoder_phys_cmd_init_ops(_enc->ops);

phys_enc->intf_mode = INTF_MODE_CMD;
-   phys_enc->irq[INTR_IDX_UNDERRUN] = 
phys_enc->hw_intf->cap->intr_underrun;
-
cmd_enc->stream_sel = 0;
  
  	if (!phys_enc->hw_intf) {

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index ef69c2f408c3..636a97432d51 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -356,6 +356,16 @@ static bool dpu_encoder_phys_vid_needs_single_flush(
return phys_enc->split_role != ENC_ROLE_SOLO;
  }
  
+static void dpu_encoder_phys_vid_atomic_mode_set(

+   struct dpu_encoder_phys *phys_enc,
+   struct drm_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+   phys_enc->irq[INTR_IDX_VSYNC] = phys_enc->hw_intf->cap->intr_vsync;
+
+   phys_enc->irq[INTR_IDX_UNDERRUN] = 
phys_enc->hw_intf->cap->intr_underrun;
+}
+
  static int dpu_encoder_phys_vid_control_vblank_irq(
struct dpu_encoder_phys *phys_enc,
bool enable)
@@ -699,6 +709,7 @@ static int dpu_encoder_phys_vid_get_frame_count(
  static void dpu_encoder_phys_vid_init_ops(struct dpu_encoder_phys_ops *ops)
  {
ops->is_master = dpu_encoder_phys_vid_is_master;
+   ops->atomic_mode_set = dpu_encoder_phys_vid_atomic_mode_set;
ops->enable = dpu_encoder_phys_vid_enable;
ops->disable = dpu_encoder_phys_vid_disable;
ops->control_vblank_irq = dpu_encoder_phys_vid_control_vblank_irq;
@@ -737,8 +748,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_vid_init(struct 
drm_device *dev,
  
  	dpu_encoder_phys_vid_init_ops(_enc->ops);

phys_enc->intf_mode = INTF_MODE_VIDEO;
-   phys_enc->irq[INTR_IDX_VSYNC] = phys_enc->hw_intf->cap->intr_vsync;
-   phys_enc->irq[INTR_IDX_UNDERRUN] = 
phys_enc->hw_intf->cap->intr_underrun;
  
  	DPU_DEBUG_VIDENC(phys_enc, "created intf idx:%d\n", p->hw_intf->idx);
  
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c

index d3ea91c1d7d2..356dca5e5ea9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -404,6 +404,15 @@ static void dpu_encoder_phys_wb_irq_disable(struct 
dpu_encoder_phys *phys)
dpu_core_irq_unregister_callback(phys->dpu_kms, 
phys->irq[INTR_IDX_WB_DONE]);
  }
  
+static void dpu_encoder_phys_wb_atomic_mode_set(

+   struct dpu_encoder_phys *phys_enc,
+   struct drm_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+
+   phys_enc->irq[INTR_IDX_WB_DONE] = phys_enc->hw_wb->caps->intr_wb_done;
+}
+
  static void _dpu_encoder_phys_wb_handle_wbdone_timeout(
struct dpu_encoder_phys *phys_enc)
  {
@@ -640,6 +649,7 @@ static bool dpu_encoder_phys_wb_is_valid_for_commit(struct 
dpu_encoder_phys *phy
  static void dpu_encoder_phys_wb_init_ops(struct dpu_encoder_phys_ops *ops)
  {
ops->is_master = dpu_encoder_phys_wb_is_master;
+   ops->atomic_mode_set = dpu_encoder_phys_wb_atomic_mode_set;
ops->enable = dpu_encoder_phys_wb_enable;
ops->disable = dpu_encoder_phys_wb_disable;
ops->wait_for_commit_done = dpu_encoder_phys_wb_wait_for_commit_done;
@@ -685,7 +695,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_wb_init(struct

[PATCH v2 1/1] video: Handle HAS_IOPORT dependencies

[Niklas Schnelle]

In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to #ifdef functions and their callsites which
unconditionally use these I/O accessors. In the include/video/vga.h
these are conveniently all those functions with the vga_io_* prefix.

Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
---
Note: This patch does not depend any not-yet-mainline HAS_IOPORT changes
and may be merged via subsystem specific trees at your earliest
convenience.

v1 -> v2:
- Moved vga_mm_r(), vga_mm_w(), vga_mm_w_fast() above #ifdef CONFIG_HAS_IOPORT
  to use them in with or without I/O port variants.
- Duplicated vga_r(), vga_w(), vga_w_fast() functions as non-I/O port variants
  to get rid of in-code #ifdef (Arnd)
- Got rid of if (regbase) logic inversion needed for in-code #ifdef

 include/video/vga.h | 58 -
 1 file changed, 42 insertions(+), 16 deletions(-)

diff --git a/include/video/vga.h b/include/video/vga.h
index 947c0abd04ef..468764d6727a 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -197,9 +197,26 @@ struct vgastate {
 extern int save_vga(struct vgastate *state);
 extern int restore_vga(struct vgastate *state);
 
+static inline unsigned char vga_mm_r (void __iomem *regbase, unsigned short 
port)
+{
+   return readb (regbase + port);
+}
+
+static inline void vga_mm_w (void __iomem *regbase, unsigned short port, 
unsigned char val)
+{
+   writeb (val, regbase + port);
+}
+
+static inline void vga_mm_w_fast (void __iomem *regbase, unsigned short port,
+ unsigned char reg, unsigned char val)
+{
+   writew (VGA_OUT16VAL (val, reg), regbase + port);
+}
+
 /*
  * generic VGA port read/write
  */
+#ifdef CONFIG_HAS_IOPORT
 
 static inline unsigned char vga_io_r (unsigned short port)
 {
@@ -217,22 +234,6 @@ static inline void vga_io_w_fast (unsigned short port, 
unsigned char reg,
outw(VGA_OUT16VAL (val, reg), port);
 }
 
-static inline unsigned char vga_mm_r (void __iomem *regbase, unsigned short 
port)
-{
-   return readb (regbase + port);
-}
-
-static inline void vga_mm_w (void __iomem *regbase, unsigned short port, 
unsigned char val)
-{
-   writeb (val, regbase + port);
-}
-
-static inline void vga_mm_w_fast (void __iomem *regbase, unsigned short port,
- unsigned char reg, unsigned char val)
-{
-   writew (VGA_OUT16VAL (val, reg), regbase + port);
-}
-
 static inline unsigned char vga_r (void __iomem *regbase, unsigned short port)
 {
if (regbase)
@@ -258,7 +259,24 @@ static inline void vga_w_fast (void __iomem *regbase, 
unsigned short port,
else
vga_io_w_fast (port, reg, val);
 }
+#else /* CONFIG_HAS_IOPORT */
+static inline unsigned char vga_r (void __iomem *regbase, unsigned short port)
+{
+   return vga_mm_r (regbase, port);
+}
 
+static inline void vga_w (void __iomem *regbase, unsigned short port, unsigned 
char val)
+{
+   vga_mm_w (regbase, port, val);
+}
+
+
+static inline void vga_w_fast (void __iomem *regbase, unsigned short port,
+  unsigned char reg, unsigned char val)
+{
+   vga_mm_w_fast (regbase, port, reg, val);
+}
+#endif /* CONFIG_HAS_IOPORT */
 
 /*
  * VGA CRTC register read/write
@@ -280,6 +298,7 @@ static inline void vga_wcrt (void __iomem *regbase, 
unsigned char reg, unsigned
 #endif /* VGA_OUTW_WRITE */
 }
 
+#ifdef CONFIG_HAS_IOPORT
 static inline unsigned char vga_io_rcrt (unsigned char reg)
 {
 vga_io_w (VGA_CRT_IC, reg);
@@ -295,6 +314,7 @@ static inline void vga_io_wcrt (unsigned char reg, unsigned 
char val)
 vga_io_w (VGA_CRT_DC, val);
 #endif /* VGA_OUTW_WRITE */
 }
+#endif /* CONFIG_HAS_IOPORT */
 
 static inline unsigned char vga_mm_rcrt (void __iomem *regbase, unsigned char 
reg)
 {
@@ -333,6 +353,7 @@ static inline void vga_wseq (void __iomem *regbase, 
unsigned char reg, unsigned
 #endif /* VGA_OUTW_WRITE */
 }
 
+#ifdef CONFIG_HAS_IOPORT
 static inline unsigned char vga_io_rseq (unsigned char reg)
 {
 vga_io_w (VGA_SEQ_I, reg);
@@ -348,6 +369,7 @@ static inline void vga_io_wseq (unsigned char reg, unsigned 
char val)
 vga_io_w (VGA_SEQ_D, val);
 #endif /* VGA_OUTW_WRITE */
 }
+#endif /* CONFIG_HAS_IOPORT */
 
 static inline unsigned char vga_mm_rseq (void __iomem *regbase, unsigned char 
reg)
 {
@@ -385,6 +407,7 @@ static inline void vga_wgfx (void __iomem *regbase, 
unsigned char reg, unsigned
 #endif /* VGA_OUTW_WRITE */
 }
 
+#ifdef CONFIG_HAS_IOPORT
 static inline unsigned char vga_io_rgfx (unsigned char reg)
 {
 vga_io_w (VGA_GFX_I, reg);
@@ -400,6 +423,7 @@ static inline void vga_io_wgfx (unsigned char reg, unsigned 
char val)
 vga_io_w (VGA_GFX_D, val);
 #endif /* VGA_OUTW_WRITE */
 }
+#endif /* CONFIG_HAS_IOPORT */
 
 static inline unsigned char vga_mm_rgfx (void __iomem *regbase, unsigned char 
reg)
 {
@@ -434,6 

[PATCH v2 0/1] video: Handle HAS_IOPORT dependencies

[Niklas Schnelle]

Hi,

This is a follow up in my ongoing effort of making inb()/outb() and
similar I/O port accessors compile-time optional. Previously I sent this
as a treewide series titled "treewide: Remove I/O port accessors for
HAS_IOPORT=n" with the latest being its 5th version[0]. With a significant
subset of patches merged I've changed over to per-subsystem series. These
series are stand alone and should be merged via the relevant tree such
that with all subsystems complete we can follow this up with the final
patch that will make the I/O port accessors compile-time optional.

The current state of the full series with changes to the remaining subsystems
and the aforementioned final patch can be found for your convenience on my
git.kernel.org tree in the has_ioport branch[1]. As for compile-time vs runtime
see Linus' reply to my first attempt[2].

Changes since v1:
- Moved vga_mm_r(), vga_mm_w(), vga_mm_w_fast() above #ifdef CONFIG_HAS_IOPORT
  to use them in with or without I/O port variants.
- Duplicated vga_r(), vga_w(), vga_w_fast() functions as non-I/O port variants
  to get rid of in-code #ifdef (Arnd)
- Got rid of if (regbase) logic inversion needed for in-code #ifdef

Thanks,
Niklas

[0] https://lore.kernel.org/all/20230522105049.1467313-1-schne...@linux.ibm.com/
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/niks/linux.git/log/?h=has_ioport
[2] 
https://lore.kernel.org/lkml/CAHk-=wg80je=k7madf4e7wrrnp37e3qh6y10svhdc7o8sz_...@mail.gmail.com/

Niklas Schnelle (1):
  video: Handle HAS_IOPORT dependencies

 include/video/vga.h | 58 -
 1 file changed, 42 insertions(+), 16 deletions(-)

-- 
2.40.1

Re: [PATCH 05/11] drm/hisilicon/hibmc: convert to struct drm_edid

[Thomas Zimmermann]

Hi

Am 14.05.24 um 14:55 schrieb Jani Nikula:

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Signed-off-by: Jani Nikula 

---

Cc: Xinliang Liu 
Cc: Tian Tao 
Cc: Xinwei Kong 
Cc: Sumit Semwal 
Cc: Yongqin Liu 
Cc: John Stultz 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
---
  .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c| 17 ++---
  1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index 94e2c573a7af..409c551c92af 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -24,14 +24,16 @@
  
  static int hibmc_connector_get_modes(struct drm_connector *connector)


Could this function be replaced with a call to 
drm_connector_helper_get_modes()? With the patch, the only difference is 
the call to the _noedid() function, which the DRM core does 
automatically. There will still be a difference in the maximum 
resolution, but standardizing on 1024x768 seems preferable to me.


Best regards
Thomas


  {
-   int count;
-   void *edid;
struct hibmc_connector *hibmc_connector = to_hibmc_connector(connector);
+   const struct drm_edid *drm_edid;
+   int count;
+
+   drm_edid = drm_edid_read_ddc(connector, _connector->adapter);
  
-	edid = drm_get_edid(connector, _connector->adapter);

-   if (edid) {
-   drm_connector_update_edid_property(connector, edid);
-   count = drm_add_edid_modes(connector, edid);
+   drm_edid_connector_update(connector, drm_edid);
+
+   if (drm_edid) {
+   count = drm_edid_connector_add_modes(connector);
if (count)
goto out;
}
@@ -42,7 +44,8 @@ static int hibmc_connector_get_modes(struct drm_connector 
*connector)
drm_set_preferred_mode(connector, 1024, 768);
  
  out:

-   kfree(edid);
+   drm_edid_free(drm_edid);
+
return count;
  }
  


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

[PATCH 11/11] drm/imx/ldb: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Signed-off-by: Jani Nikula 

---

Cc: Philipp Zabel 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: i...@lists.linux.dev
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c 
b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
index 71d70194fcbd..793dfb1a3ed0 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
@@ -72,7 +72,7 @@ struct imx_ldb_channel {
struct device_node *child;
struct i2c_adapter *ddc;
int chno;
-   void *edid;
+   const struct drm_edid *drm_edid;
struct drm_display_mode mode;
int mode_valid;
u32 bus_format;
@@ -142,15 +142,15 @@ static int imx_ldb_connector_get_modes(struct 
drm_connector *connector)
if (num_modes > 0)
return num_modes;
 
-   if (!imx_ldb_ch->edid && imx_ldb_ch->ddc)
-   imx_ldb_ch->edid = drm_get_edid(connector, imx_ldb_ch->ddc);
-
-   if (imx_ldb_ch->edid) {
-   drm_connector_update_edid_property(connector,
-   imx_ldb_ch->edid);
-   num_modes = drm_add_edid_modes(connector, imx_ldb_ch->edid);
+   if (!imx_ldb_ch->drm_edid && imx_ldb_ch->ddc) {
+   imx_ldb_ch->drm_edid = drm_edid_read_ddc(connector,
+imx_ldb_ch->ddc);
+   drm_edid_connector_update(connector, imx_ldb_ch->drm_edid);
}
 
+   if (imx_ldb_ch->drm_edid)
+   num_modes = drm_edid_connector_add_modes(connector);
+
if (imx_ldb_ch->mode_valid) {
struct drm_display_mode *mode;
 
@@ -553,7 +553,6 @@ static int imx_ldb_panel_ddc(struct device *dev,
struct imx_ldb_channel *channel, struct device_node *child)
 {
struct device_node *ddc_node;
-   const u8 *edidp;
int ret;
 
ddc_node = of_parse_phandle(child, "ddc-i2c-bus", 0);
@@ -567,6 +566,7 @@ static int imx_ldb_panel_ddc(struct device *dev,
}
 
if (!channel->ddc) {
+   const void *edidp;
int edid_len;
 
/* if no DDC available, fallback to hardcoded EDID */
@@ -574,8 +574,8 @@ static int imx_ldb_panel_ddc(struct device *dev,
 
edidp = of_get_property(child, "edid", _len);
if (edidp) {
-   channel->edid = kmemdup(edidp, edid_len, GFP_KERNEL);
-   if (!channel->edid)
+   channel->drm_edid = drm_edid_alloc(edidp, edid_len);
+   if (!channel->drm_edid)
return -ENOMEM;
} else if (!channel->panel) {
/* fallback to display-timings node */
@@ -744,7 +744,7 @@ static void imx_ldb_remove(struct platform_device *pdev)
for (i = 0; i < 2; i++) {
struct imx_ldb_channel *channel = _ldb->channel[i];
 
-   kfree(channel->edid);
+   drm_edid_free(channel->drm_edid);
i2c_put_adapter(channel->ddc);
}
 
-- 
2.39.2

[PATCH 10/11] drm/imx/tve: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Signed-off-by: Jani Nikula 

---

Cc: Philipp Zabel 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: i...@lists.linux.dev
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/imx/ipuv3/imx-tve.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3/imx-tve.c 
b/drivers/gpu/drm/imx/ipuv3/imx-tve.c
index b49bddb85535..29f494bfff67 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-tve.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-tve.c
@@ -201,18 +201,16 @@ static int tve_setup_vga(struct imx_tve *tve)
 static int imx_tve_connector_get_modes(struct drm_connector *connector)
 {
struct imx_tve *tve = con_to_tve(connector);
-   struct edid *edid;
-   int ret = 0;
+   const struct drm_edid *drm_edid;
+   int ret;
 
if (!tve->ddc)
return 0;
 
-   edid = drm_get_edid(connector, tve->ddc);
-   if (edid) {
-   drm_connector_update_edid_property(connector, edid);
-   ret = drm_add_edid_modes(connector, edid);
-   kfree(edid);
-   }
+   drm_edid = drm_edid_read_ddc(connector, tve->ddc);
+   drm_edid_connector_update(connector, drm_edid);
+   ret = drm_edid_connector_add_modes(connector);
+   drm_edid_free(drm_edid);
 
return ret;
 }
-- 
2.39.2

[PATCH 09/11] drm/tegra: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Signed-off-by: Jani Nikula 

---

Cc: Thierry Reding 
Cc: Mikko Perttunen 
Cc: Jonathan Hunter 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/drm.h|  2 +-
 drivers/gpu/drm/tegra/output.c | 29 +
 2 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 682011166a8f..2f3781e04b0a 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -133,7 +133,7 @@ struct tegra_output {
struct drm_bridge *bridge;
struct drm_panel *panel;
struct i2c_adapter *ddc;
-   const struct edid *edid;
+   const struct drm_edid *drm_edid;
struct cec_notifier *cec;
unsigned int hpd_irq;
struct gpio_desc *hpd_gpio;
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 4da3c3d1abbc..e6b5863fec71 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -21,7 +21,7 @@
 int tegra_output_connector_get_modes(struct drm_connector *connector)
 {
struct tegra_output *output = connector_to_output(connector);
-   struct edid *edid = NULL;
+   const struct drm_edid *drm_edid;
int err = 0;
 
/*
@@ -34,18 +34,17 @@ int tegra_output_connector_get_modes(struct drm_connector 
*connector)
return err;
}
 
-   if (output->edid)
-   edid = kmemdup(output->edid, sizeof(*edid), GFP_KERNEL);
+   if (output->drm_edid)
+   drm_edid = drm_edid_dup(output->drm_edid);
else if (output->ddc)
-   edid = drm_get_edid(connector, output->ddc);
+   drm_edid = drm_edid_read_ddc(connector, output->ddc);
 
-   cec_notifier_set_phys_addr_from_edid(output->cec, edid);
-   drm_connector_update_edid_property(connector, edid);
+   drm_edid_connector_update(connector, drm_edid);
+   cec_notifier_set_phys_addr(output->cec,
+  
connector->display_info.source_physical_address);
 
-   if (edid) {
-   err = drm_add_edid_modes(connector, edid);
-   kfree(edid);
-   }
+   err = drm_edid_connector_add_modes(connector);
+   drm_edid_free(drm_edid);
 
return err;
 }
@@ -98,6 +97,7 @@ static irqreturn_t hpd_irq(int irq, void *data)
 int tegra_output_probe(struct tegra_output *output)
 {
struct device_node *ddc, *panel;
+   const void *edid;
unsigned long flags;
int err, size;
 
@@ -124,8 +124,6 @@ int tegra_output_probe(struct tegra_output *output)
return PTR_ERR(output->panel);
}
 
-   output->edid = of_get_property(output->of_node, "nvidia,edid", );
-
ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
if (ddc) {
output->ddc = of_get_i2c_adapter_by_node(ddc);
@@ -137,6 +135,9 @@ int tegra_output_probe(struct tegra_output *output)
}
}
 
+   edid = of_get_property(output->of_node, "nvidia,edid", );
+   output->drm_edid = drm_edid_alloc(edid, size);
+
output->hpd_gpio = devm_fwnode_gpiod_get(output->dev,
of_fwnode_handle(output->of_node),
"nvidia,hpd",
@@ -187,6 +188,8 @@ int tegra_output_probe(struct tegra_output *output)
if (output->ddc)
i2c_put_adapter(output->ddc);
 
+   drm_edid_free(output->drm_edid);
+
return err;
 }
 
@@ -197,6 +200,8 @@ void tegra_output_remove(struct tegra_output *output)
 
if (output->ddc)
i2c_put_adapter(output->ddc);
+
+   drm_edid_free(output->drm_edid);
 }
 
 int tegra_output_init(struct drm_device *drm, struct tegra_output *output)
-- 
2.39.2

[PATCH 08/11] drm/msm/dp: switch to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Simplify the flow by updating the EDID property when the EDID is read
instead of at .get_modes.

Signed-off-by: Jani Nikula 

---

Cc: Rob Clark 
Cc: Abhinav Kumar 
Cc: Dmitry Baryshkov 
Cc: Sean Paul 
Cc: Marijn Suijten 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
 drivers/gpu/drm/msm/dp/dp_display.c | 11 +++
 drivers/gpu/drm/msm/dp/dp_panel.c   | 47 +
 drivers/gpu/drm/msm/dp/dp_panel.h   |  2 +-
 3 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 672a7ba52eda..9622e58dce3e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -360,26 +360,25 @@ static int dp_display_send_hpd_notification(struct 
dp_display_private *dp,
 
 static int dp_display_process_hpd_high(struct dp_display_private *dp)
 {
+   struct drm_connector *connector = dp->dp_display.connector;
+   const struct drm_display_info *info = >display_info;
int rc = 0;
-   struct edid *edid;
 
-   rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
+   rc = dp_panel_read_sink_caps(dp->panel, connector);
if (rc)
goto end;
 
dp_link_process_request(dp->link);
 
if (!dp->dp_display.is_edp)
-   drm_dp_set_subconnector_property(dp->dp_display.connector,
+   drm_dp_set_subconnector_property(connector,
 connector_status_connected,
 dp->panel->dpcd,
 dp->panel->downstream_ports);
 
-   edid = dp->panel->edid;
-
dp->dp_display.psr_supported = dp->panel->psr_cap.version && 
psr_enabled;
 
-   dp->audio_supported = drm_detect_monitor_audio(edid);
+   dp->audio_supported = info->has_audio;
dp_panel_handle_sink_request(dp->panel);
 
/*
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 07db8f37cd06..a916b5f3b317 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -108,28 +108,6 @@ static u32 dp_panel_get_supported_bpp(struct dp_panel 
*dp_panel,
return bpp;
 }
 
-static int dp_panel_update_modes(struct drm_connector *connector,
-   struct edid *edid)
-{
-   int rc = 0;
-
-   if (edid) {
-   rc = drm_connector_update_edid_property(connector, edid);
-   if (rc) {
-   DRM_ERROR("failed to update edid property %d\n", rc);
-   return rc;
-   }
-   rc = drm_add_edid_modes(connector, edid);
-   return rc;
-   }
-
-   rc = drm_connector_update_edid_property(connector, NULL);
-   if (rc)
-   DRM_ERROR("failed to update edid property %d\n", rc);
-
-   return rc;
-}
-
 int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
struct drm_connector *connector)
 {
@@ -175,12 +153,13 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
if (rc)
return rc;
 
-   kfree(dp_panel->edid);
-   dp_panel->edid = NULL;
+   drm_edid_free(dp_panel->drm_edid);
+
+   dp_panel->drm_edid = drm_edid_read_ddc(connector, >aux->ddc);
+
+   drm_edid_connector_update(connector, dp_panel->drm_edid);
 
-   dp_panel->edid = drm_get_edid(connector,
- >aux->ddc);
-   if (!dp_panel->edid) {
+   if (!dp_panel->drm_edid) {
DRM_ERROR("panel edid read failed\n");
/* check edid read fail is due to unplug */
if (!dp_catalog_link_is_connected(panel->catalog)) {
@@ -224,13 +203,13 @@ int dp_panel_get_modes(struct dp_panel *dp_panel,
return -EINVAL;
}
 
-   if (dp_panel->edid)
-   return dp_panel_update_modes(connector, dp_panel->edid);
+   if (dp_panel->drm_edid)
+   return drm_edid_connector_add_modes(connector);
 
return 0;
 }
 
-static u8 dp_panel_get_edid_checksum(struct edid *edid)
+static u8 dp_panel_get_edid_checksum(const struct edid *edid)
 {
edid += edid->extensions;
 
@@ -249,10 +228,12 @@ void dp_panel_handle_sink_request(struct dp_panel 
*dp_panel)
panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
 
if (panel->link->sink_request & DP_TEST_LINK_EDID_READ) {
+   /* FIXME: get rid of drm_edid_raw() */
+   const struct edid *edid = drm_edid_raw(dp_panel->drm_edid);
u8 checksum;
 
-   if (dp_panel->edid)
-   checksum = dp_panel_get_edid_checksum(dp_panel->edid);
+   if (edid)
+   checksum = dp_panel_get_edid_checksum(edid);
else
 

[PATCH 07/11] drm/loongson/7a2000: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Signed-off-by: Jani Nikula 

---

Cc: Sui Jingfeng 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
---
 drivers/gpu/drm/loongson/lsdc_output_7a2000.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/loongson/lsdc_output_7a2000.c 
b/drivers/gpu/drm/loongson/lsdc_output_7a2000.c
index ce3dabec887e..2bd797a9b9ff 100644
--- a/drivers/gpu/drm/loongson/lsdc_output_7a2000.c
+++ b/drivers/gpu/drm/loongson/lsdc_output_7a2000.c
@@ -44,16 +44,15 @@
 
 static int ls7a2000_connector_get_modes(struct drm_connector *connector)
 {
-   unsigned int num = 0;
-   struct edid *edid;
+   int num;
 
if (connector->ddc) {
-   edid = drm_get_edid(connector, connector->ddc);
-   if (edid) {
-   drm_connector_update_edid_property(connector, edid);
-   num = drm_add_edid_modes(connector, edid);
-   kfree(edid);
-   }
+   const struct drm_edid *drm_edid;
+
+   drm_edid = drm_edid_read(connector);
+   drm_edid_connector_update(connector, drm_edid);
+   num = drm_edid_connector_add_modes(connector);
+   drm_edid_free(drm_edid);
 
return num;
}
-- 
2.39.2

[PATCH 06/11] drm/loongson/7a1000: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Signed-off-by: Jani Nikula 

---

Cc: Sui Jingfeng 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
---
 drivers/gpu/drm/loongson/lsdc_output_7a1000.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/loongson/lsdc_output_7a1000.c 
b/drivers/gpu/drm/loongson/lsdc_output_7a1000.c
index 6fc8dd1c7d9a..600ed4fb0884 100644
--- a/drivers/gpu/drm/loongson/lsdc_output_7a1000.c
+++ b/drivers/gpu/drm/loongson/lsdc_output_7a1000.c
@@ -40,16 +40,15 @@
 
 static int ls7a1000_dpi_connector_get_modes(struct drm_connector *conn)
 {
-   unsigned int num = 0;
-   struct edid *edid;
+   int num;
 
if (conn->ddc) {
-   edid = drm_get_edid(conn, conn->ddc);
-   if (edid) {
-   drm_connector_update_edid_property(conn, edid);
-   num = drm_add_edid_modes(conn, edid);
-   kfree(edid);
-   }
+   const struct drm_edid *drm_edid;
+
+   drm_edid = drm_edid_read(conn);
+   drm_edid_connector_update(conn, drm_edid);
+   num = drm_edid_connector_add_modes(conn);
+   drm_edid_free(drm_edid);
 
return num;
}
-- 
2.39.2

[PATCH 05/11] drm/hisilicon/hibmc: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Signed-off-by: Jani Nikula 

---

Cc: Xinliang Liu 
Cc: Tian Tao 
Cc: Xinwei Kong 
Cc: Sumit Semwal 
Cc: Yongqin Liu 
Cc: John Stultz 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
---
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c| 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index 94e2c573a7af..409c551c92af 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -24,14 +24,16 @@
 
 static int hibmc_connector_get_modes(struct drm_connector *connector)
 {
-   int count;
-   void *edid;
struct hibmc_connector *hibmc_connector = to_hibmc_connector(connector);
+   const struct drm_edid *drm_edid;
+   int count;
+
+   drm_edid = drm_edid_read_ddc(connector, _connector->adapter);
 
-   edid = drm_get_edid(connector, _connector->adapter);
-   if (edid) {
-   drm_connector_update_edid_property(connector, edid);
-   count = drm_add_edid_modes(connector, edid);
+   drm_edid_connector_update(connector, drm_edid);
+
+   if (drm_edid) {
+   count = drm_edid_connector_add_modes(connector);
if (count)
goto out;
}
@@ -42,7 +44,8 @@ static int hibmc_connector_get_modes(struct drm_connector 
*connector)
drm_set_preferred_mode(connector, 1024, 768);
 
 out:
-   kfree(edid);
+   drm_edid_free(drm_edid);
+
return count;
 }
 
-- 
2.39.2

[PATCH 04/11] drm/exynos: hdmi: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

The functional change is that the CEC physical address gets invalidated
when the EDID could not be read.

Signed-off-by: Jani Nikula 

---

Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Krzysztof Kozlowski 
Cc: Alim Akhtar 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e968824a4c72..9033e8b66816 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -883,27 +883,30 @@ static const struct drm_connector_funcs 
hdmi_connector_funcs = {
 static int hdmi_get_modes(struct drm_connector *connector)
 {
struct hdmi_context *hdata = connector_to_hdmi(connector);
-   struct edid *edid;
+   const struct drm_display_info *info = >display_info;
+   const struct drm_edid *drm_edid;
int ret;
 
if (!hdata->ddc_adpt)
return 0;
 
-   edid = drm_get_edid(connector, hdata->ddc_adpt);
-   if (!edid)
+   drm_edid = drm_edid_read_ddc(connector, hdata->ddc_adpt);
+
+   drm_edid_connector_update(connector, drm_edid);
+
+   cec_notifier_set_phys_addr(hdata->notifier, 
info->source_physical_address);
+
+   if (!drm_edid)
return 0;
 
-   hdata->dvi_mode = !connector->display_info.is_hdmi;
+   hdata->dvi_mode = !info->is_hdmi;
DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",
  (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"),
- edid->width_cm, edid->height_cm);
-
-   drm_connector_update_edid_property(connector, edid);
-   cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid);
+ info->width_mm / 10, info->height_mm / 10);
 
-   ret = drm_add_edid_modes(connector, edid);
+   ret = drm_edid_connector_add_modes(connector);
 
-   kfree(edid);
+   drm_edid_free(drm_edid);
 
return ret;
 }
-- 
2.39.2

[PATCH 03/11] drm/bridge: analogix_dp: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

Signed-off-by: Jani Nikula 

---

Cc: Andrzej Hajda 
Cc: Neil Armstrong 
Cc: Robert Foss 
Cc: Laurent Pinchart 
Cc: Jonas Karlman 
Cc: Jernej Skrabec 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
---
 .../gpu/drm/bridge/analogix/analogix_dp_core.c| 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7b841232321f..9360b63ad37c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1108,7 +1108,7 @@ static int analogix_dp_prepare_panel(struct 
analogix_dp_device *dp,
 static int analogix_dp_get_modes(struct drm_connector *connector)
 {
struct analogix_dp_device *dp = to_dp(connector);
-   struct edid *edid;
+   const struct drm_edid *drm_edid;
int ret, num_modes = 0;
 
if (dp->plat_data->panel) {
@@ -1120,12 +1120,13 @@ static int analogix_dp_get_modes(struct drm_connector 
*connector)
return 0;
}
 
-   edid = drm_get_edid(connector, >aux.ddc);
-   if (edid) {
-   drm_connector_update_edid_property(>connector,
-  edid);
-   num_modes += drm_add_edid_modes(>connector, edid);
-   kfree(edid);
+   drm_edid = drm_edid_read_ddc(connector, >aux.ddc);
+
+   drm_edid_connector_update(>connector, drm_edid);
+
+   if (drm_edid) {
+   num_modes += 
drm_edid_connector_add_modes(>connector);
+   drm_edid_free(drm_edid);
}
 
ret = analogix_dp_prepare_panel(dp, false, false);
-- 
2.39.2

[PATCH 02/11] drm/sti/sti_hdmi: convert to struct drm_edid

[Jani Nikula]

Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.

The functional change is that the CEC physical address gets invalidated
when the EDID could not be read.

Signed-off-by: Jani Nikula 

---

Cc: Alain Volmat 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 500936d5743c..3b62ec2d742f 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -974,28 +974,32 @@ static const struct drm_bridge_funcs 
sti_hdmi_bridge_funcs = {
 
 static int sti_hdmi_connector_get_modes(struct drm_connector *connector)
 {
+   const struct drm_display_info *info = >display_info;
struct sti_hdmi_connector *hdmi_connector
= to_sti_hdmi_connector(connector);
struct sti_hdmi *hdmi = hdmi_connector->hdmi;
-   struct edid *edid;
+   const struct drm_edid *drm_edid;
int count;
 
DRM_DEBUG_DRIVER("\n");
 
-   edid = drm_get_edid(connector, hdmi->ddc_adapt);
-   if (!edid)
-   goto fail;
+   drm_edid = drm_edid_read_ddc(connector, hdmi->ddc_adapt);
+
+   drm_edid_connector_update(connector, drm_edid);
 
-   cec_notifier_set_phys_addr_from_edid(hdmi->notifier, edid);
+   cec_notifier_set_phys_addr(hdmi->notifier,
+  
connector->display_info.source_physical_address);
+
+   if (!drm_edid)
+   goto fail;
 
-   count = drm_add_edid_modes(connector, edid);
-   drm_connector_update_edid_property(connector, edid);
+   count = drm_edid_connector_add_modes(connector);
 
DRM_DEBUG_KMS("%s : %dx%d cm\n",
- (connector->display_info.is_hdmi ? "hdmi monitor" : "dvi 
monitor"),
- edid->width_cm, edid->height_cm);
+ info->is_hdmi ? "hdmi monitor" : "dvi monitor",
+ info->width_mm / 10, info->height_mm / 10);
 
-   kfree(edid);
+   drm_edid_free(drm_edid);
return count;
 
 fail:
-- 
2.39.2

[PATCH 01/11] drm/rockchip: cdn-dp: get rid of drm_edid_raw()

[Jani Nikula]

The dimensions are available in display info, so there's no need for raw
EDID access. While at it, move the debug logging to where the EDID is
actually read.

Signed-off-by: Jani Nikula 

---

Cc: Sandy Huang 
Cc: "Heiko Stübner" 
Cc: Andy Yan 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
---
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index bd7aa891b839..90913fa26aad 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -266,15 +266,6 @@ static int cdn_dp_connector_get_modes(struct drm_connector 
*connector)
 
mutex_lock(>lock);
 
-   if (dp->drm_edid) {
-   /* FIXME: get rid of drm_edid_raw() */
-   const struct edid *edid = drm_edid_raw(dp->drm_edid);
-
-   DRM_DEV_DEBUG_KMS(dp->dev, "got edid: width[%d] x height[%d]\n",
- edid->width_cm, edid->height_cm);
-
-   }
-
ret = drm_edid_connector_add_modes(connector);
 
mutex_unlock(>lock);
@@ -369,6 +360,7 @@ static int cdn_dp_firmware_init(struct cdn_dp_device *dp)
 
 static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp)
 {
+   const struct drm_display_info *info = >connector.display_info;
int ret;
 
if (!cdn_dp_check_sink_connection(dp))
@@ -386,7 +378,11 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device 
*dp)
cdn_dp_get_edid_block, dp);
drm_edid_connector_update(>connector, dp->drm_edid);
 
-   dp->sink_has_audio = dp->connector.display_info.has_audio;
+   dp->sink_has_audio = info->has_audio;
+
+   if (dp->drm_edid)
+   DRM_DEV_DEBUG_KMS(dp->dev, "got edid: width[%d] x height[%d]\n",
+ info->width_mm / 10, info->height_mm / 10);
 
return 0;
 }
-- 
2.39.2

[PATCH 00/11] drm: conversions to struct drm_edid

[Jani Nikula]

Convert more drivers to struct drm_edid.

Compile tested only.

Jani Nikula (11):
  drm/rockchip: cdn-dp: get rid of drm_edid_raw()
  drm/sti/sti_hdmi: convert to struct drm_edid
  drm/bridge: analogix_dp: convert to struct drm_edid
  drm/exynos: hdmi: convert to struct drm_edid
  drm/hisilicon/hibmc: convert to struct drm_edid
  drm/loongson/7a1000: convert to struct drm_edid
  drm/loongson/7a2000: convert to struct drm_edid
  drm/msm/dp: switch to struct drm_edid
  drm/tegra: convert to struct drm_edid
  drm/imx/tve: convert to struct drm_edid
  drm/imx/ldb: convert to struct drm_edid

 .../drm/bridge/analogix/analogix_dp_core.c| 15 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 23 +
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c  | 17 ---
 drivers/gpu/drm/imx/ipuv3/imx-ldb.c   | 24 +-
 drivers/gpu/drm/imx/ipuv3/imx-tve.c   | 14 +++---
 drivers/gpu/drm/loongson/lsdc_output_7a1000.c | 15 +++---
 drivers/gpu/drm/loongson/lsdc_output_7a2000.c | 15 +++---
 drivers/gpu/drm/msm/dp/dp_display.c   | 11 ++---
 drivers/gpu/drm/msm/dp/dp_panel.c | 47 ++-
 drivers/gpu/drm/msm/dp/dp_panel.h |  2 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c| 16 +++
 drivers/gpu/drm/sti/sti_hdmi.c| 24 ++
 drivers/gpu/drm/tegra/drm.h   |  2 +-
 drivers/gpu/drm/tegra/output.c| 29 +++-
 14 files changed, 121 insertions(+), 133 deletions(-)

-- 
2.39.2

Re: [PATCH] drm/i915/gt: Disarm breadcrumbs if engines are already idle

[Andi Shyti]

Hi Janusz,

On Tue, Apr 23, 2024 at 06:23:10PM +0200, Janusz Krzysztofik wrote:
> From: Chris Wilson 
> 
> The breadcrumbs use a GT wakeref for guarding the interrupt, but are
> disarmed during release of the engine wakeref. This leaves a hole where
> we may attach a breadcrumb just as the engine is parking (after it has
> parked its breadcrumbs), execute the irq worker with some signalers still
> attached, but never be woken again.
> 
> That issue manifests itself in CI with IGT runner timeouts while tests
> are waiting indefinitely for release of all GT wakerefs.
> 
> <6> [209.151778] i915: Running live_engine_pm_selftests/live_engine_busy_stats
> <7> [209.231628] i915 :00:02.0: [drm:intel_power_well_disable [i915]] 
> disabling PW_5
> <7> [209.231816] i915 :00:02.0: [drm:intel_power_well_disable [i915]] 
> disabling PW_4
> <7> [209.231944] i915 :00:02.0: [drm:intel_power_well_disable [i915]] 
> disabling PW_3
> <7> [209.232056] i915 :00:02.0: [drm:intel_power_well_disable [i915]] 
> disabling PW_2
> <7> [209.232166] i915 :00:02.0: [drm:intel_power_well_disable [i915]] 
> disabling DC_off
> <7> [209.232270] i915 :00:02.0: [drm:skl_enable_dc6 [i915]] Enabling DC6
> <7> [209.232368] i915 :00:02.0: [drm:gen9_set_dc_state.part.0 [i915]] 
> Setting DC state from 00 to 02
> <4> [299.356116] [IGT] Inactivity timeout exceeded. Killing the current test 
> with SIGQUIT.
> ...
> <6> [299.356526] sysrq: Show State
> ...
> <6> [299.373964] task:i915_selftest   state:D stack:11784 pid:5578  tgid:5578 
>  ppid:873flags:0x4002
> <6> [299.373967] Call Trace:
> <6> [299.373968]  
> <6> [299.373970]  __schedule+0x3bb/0xda0
> <6> [299.373974]  schedule+0x41/0x110
> <6> [299.373976]  intel_wakeref_wait_for_idle+0x82/0x100 [i915]
> <6> [299.374083]  ? __pfx_var_wake_function+0x10/0x10
> <6> [299.374087]  live_engine_busy_stats+0x9b/0x500 [i915]
> <6> [299.374173]  __i915_subtests+0xbe/0x240 [i915]
> <6> [299.374277]  ? __pfx___intel_gt_live_setup+0x10/0x10 [i915]
> <6> [299.374369]  ? __pfx___intel_gt_live_teardown+0x10/0x10 [i915]
> <6> [299.374456]  intel_engine_live_selftests+0x1c/0x30 [i915]
> <6> [299.374547]  __run_selftests+0xbb/0x190 [i915]
> <6> [299.374635]  i915_live_selftests+0x4b/0x90 [i915]
> <6> [299.374717]  i915_pci_probe+0x10d/0x210 [i915]
> 
> At the end of the interrupt worker, if there are no more engines awake,
> disarm the breadcrumb and go to sleep.
> 
> Fixes: 9d5612ca165a ("drm/i915/gt: Defer enabling the breadcrumb interrupt to 
> after submission")
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/10026
> Signed-off-by: Chris Wilson 
> Cc: Andrzej Hajda 
> Cc:  # v5.12+
> Signed-off-by: Janusz Krzysztofik 

Reviewed and applied!

Thanks,
Andi

Re: drm: Remove driver dependencies on FB_DEVICE

[Thomas Zimmermann]

Hi

Am 14.05.24 um 14:34 schrieb Manas Ghandat:
Hi. I recently looked at the todos of drm and found the topic 
interesting. I wanted to get started with this issue but having some 
trouble identifying the devices. What would be the right approach to 
get started?


Sorry, there's already someone working on that topic.

Best regards
Thomas



Thanks,

Manas



--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH v2 0/3] drm/mediatek: Add support for OF graphs

[AngeloGioacchino Del Regno]

Il 14/05/24 11:46, Alexandre Mergnat ha scritto:

Hi Angelo,

Gentle ping because I'm stuck if I rebase my serie on top of yours.



Sorry, I was unable to find time to get back to this... I plan to look at it
between today and tomorrow.

In the meanwhile - does your platform use OVL_ADAPTOR?

If it does, that's the actual issue; otherwise, there may be some mistake on
your side, because the EPs' ports<->ids relationship was verified before sending
this to the lists.

Cheers,
Angelo


On 02/05/2024 18:53, Alexandre Mergnat wrote:



On 30/04/2024 13:33, AngeloGioacchino Del Regno wrote:

Il 30/04/24 12:17, Alexandre Mergnat ha scritto:

Hi Angelo,

On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:

This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths (meaning main display through OF graph and external
display hardcoded, because of OVL_ADAPTOR).


Is that make sense for you to add the DTS changes of these boards into this 
serie ?

I asked because, IMHO, that could help to understand the serie.



Yes and no... but I imagine that you're asking this because you're trying to
prepare something with a different SoC+board(s) combination :-)

In that case, I'm preventively sorry because what follows here is not 100%
perfectly tidy yet as I didn't mean to send the devicetree commits upstream
before this series got picked

... but there you go - I'm sure that you won't mind and that the example will
be more than good enough for you.

Please note that one of the reasons why I didn't want to add this to the series
is that the following changes show only a mere 50% of the reasons why we want OF
graph support on mediatek-drm (but mainly, it's because I didn't have time to
actually rebase etc :-P )


Thanks for the explanations and examples.
Unfortunately, I have 2 display but only one is working (the main: DSI0) when I 
use the dts method.

I've probably missed something but I don't know what.

In my "mmsys" node, if I swap display (the ext endpoint with the main endpoint), 
the DPI0 is working, but not the DSI0. I conclude my both paths are good.


Then, I've put some trace into "mtk_drm_of_ddp_path_build" to check if it parse 
the two endpoint of the node. Both are parsed, but "of_ep.port" is always = 0. 
According to "of_graph_parse_endpoint" function, "port" is the value of the 
parent "reg", whereas "id" is the value of the endpoint "reg".
So I replaced "of_ep.port" by "of_ep.id". Now I've of_ep.id = 0 for main and 
of_ep.id = 1 for EXT.


Now I've the good CRTC path, I get this error:
   mediatek-drm mediatek-drm.1.auto: Invalid display hw pipeline. Last component: 
54 (ret=-2)
   mediatek-drm mediatek-drm.1.auto: probe with driver mediatek-drm failed with 
error -22


After quick look, the "cpath" into "mtk_drm_of_ddp_path_build_one" (or deeper 
functions) seems not be used as it should, due to the previous "of_ep.port" => 
"of_ep.id" change of course.


But I probably have to fix "of_ep.port" because I've mis-coded something. Just in 
case, I share you my diff:


diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts 
b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts

index 1aa3426f561b..f660481d3fe8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
@@ -109,15 +109,51 @@ vsys_lcm_reg: regulator-vsys-lcm {
  };
  };

+ {
+    proc-supply = <_vproc_reg>;
+    sram-supply = <_vsram_proc_reg>;
+};
+
+ {
+    proc-supply = <_vproc_reg>;
+    sram-supply = <_vsram_proc_reg>;
+};
+
+ {
+    proc-supply = <_vproc_reg>;
+    sram-supply = <_vsram_proc_reg>;
+};
+
+ {
+    proc-supply = <_vproc_reg>;
+    sram-supply = <_vsram_proc_reg>;
+};
+
+_out {
+    remote-endpoint = <_in>;
+};
+
   {
  pinctrl-0 = <_default_pins>;
  pinctrl-1 = <_idle_pins>;
  pinctrl-names = "default", "sleep";
  status = "okay";
+    ports {
+    #address-cells = <1>;
+    #size-cells = <0>;

-    port {
-    dpi_out: endpoint {
-    remote-endpoint = <_in>;
+    port@0 {
+    reg = <0>;
+    dpi0_in: endpoint {
+    remote-endpoint = <_out>;
+    };
+    };
+
+    port@1 {
+    reg = <1>;
+    dpi0_out: endpoint {
+    remote-endpoint = <_in>;
+    };
  };
  };
  };
@@ -137,36 +173,28 @@ panel@0 {

  port {
  panel_in: endpoint {
-    remote-endpoint = <_out>;
+    remote-endpoint = <_out>;
  };
  };
  };
+    ports {
+    #address-cells = <1>;
+    #size-cells = <0>;

-    port {
-    dsi_out: endpoint {
-    remote-endpoint = <_in>;
+    port@0 {
+    reg = <0>;
+    dsi0_in: endpoint {
+    remote-endpoint = <_out>;
+    };
  };
-    };
-};

- {
-    proc-supply = <_vproc_reg>;
-    sram-supply = <_vsram_proc_reg>;

[PATCH 5.15 162/168] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1068,7 +1068,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);

[PATCH 5.10 108/111] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

5.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);

[PATCH 5.4 78/84] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

5.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);

[PATCH 4.19 61/63] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1064,7 +1064,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);

[PATCH 6.1 221/236] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);

[PATCH 6.6 271/301] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);

[PATCH 6.6 269/301] drm/ttm: Print the memory decryption status just once

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.

Stop printing the TT memory decryption status info each time tt is created
and instead print it just once.

Reduces the spam in the system logs when running guests with SEV enabled.

Signed-off-by: Zack Rusin 
Fixes: 71ce046327cf ("drm/ttm: Make sure the mapped tt pages are decrypted when 
needed")
Reviewed-by: Christian König 
Cc: Thomas Hellström 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v5.14+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240408155605.1398631-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 578a7c37f00b..d776e3f87064 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -92,7 +92,7 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
 */
if (bdev->pool.use_dma_alloc && 
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
page_flags |= TTM_TT_FLAG_DECRYPTED;
-   drm_info(ddev, "TT memory decryption enabled.");
+   drm_info_once(ddev, "TT memory decryption enabled.");
}
 
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);
-- 
2.45.0

[PATCH] drm/lima: implify the allocation of sync slab caches

[cuitao]

Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
to simplify the creation of SLAB caches.

Signed-off-by: cuitao 
---
 drivers/gpu/drm/lima/lima_sched.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index 00b19adfc888..414a45082b86 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -28,9 +28,7 @@ static int lima_fence_slab_refcnt;
 int lima_sched_slab_init(void)
 {
if (!lima_fence_slab) {
-   lima_fence_slab = kmem_cache_create(
-   "lima_fence", sizeof(struct lima_fence), 0,
-   SLAB_HWCACHE_ALIGN, NULL);
+   lima_fence_slab = KMEM_CACHE(lima_fence, SLAB_HWCACHE_ALIGN);
if (!lima_fence_slab)
return -ENOMEM;
}
-- 
2.25.1

[PATCH] drm/xe: Simplify the allocation of sync slab caches

[cuitao]

Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
to simplify the creation of SLAB caches.

Signed-off-by: cuitao 
---
 drivers/gpu/drm/xe/xe_hw_fence.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_hw_fence.c b/drivers/gpu/drm/xe/xe_hw_fence.c
index a5de3e7b0bd6..0f4eee529c6a 100644
--- a/drivers/gpu/drm/xe/xe_hw_fence.c
+++ b/drivers/gpu/drm/xe/xe_hw_fence.c
@@ -20,9 +20,7 @@ static struct kmem_cache *xe_hw_fence_slab;
 
 int __init xe_hw_fence_module_init(void)
 {
-   xe_hw_fence_slab = kmem_cache_create("xe_hw_fence",
-sizeof(struct xe_hw_fence), 0,
-SLAB_HWCACHE_ALIGN, NULL);
+   xe_hw_fence_slab = KMEM_CACHE(xe_hw_fence, SLAB_HWCACHE_ALIGN);
if (!xe_hw_fence_slab)
return -ENOMEM;
 
-- 
2.25.1

[PATCH] drm/i915: Use for_each_child instead of manual for-loop

[Nirmoy Das]

Simplify child iteration using for_each_child macro
instead of using manual for loop. There is no functional
change.

Cc: John Harrison 
Cc: Tvrtko Ursulin 
Signed-off-by: Nirmoy Das 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 64 ++-
 1 file changed, 33 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0eaa1064242c..7e88d90e935b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1800,14 +1800,37 @@ __unwind_incomplete_requests(struct intel_context *ce)
spin_unlock_irqrestore(_engine->lock, flags);
 }
 
-static void __guc_reset_context(struct intel_context *ce, intel_engine_mask_t 
stalled)
+static void guc_reset_context_state(struct intel_context *ce, 
intel_engine_mask_t stalled)
 {
-   bool guilty;
struct i915_request *rq;
-   unsigned long flags;
+   bool guilty = false;
u32 head;
-   int i, number_children = ce->parallel.number_children;
-   struct intel_context *parent = ce;
+
+   if (!intel_context_is_pinned(ce))
+   return;
+
+   rq = intel_context_get_active_request(ce);
+   if (!rq) {
+   head = ce->ring->tail;
+   goto out_replay;
+   }
+
+   if (i915_request_started(rq))
+   guilty = stalled & ce->engine->mask;
+
+   GEM_BUG_ON(i915_active_is_idle(>active));
+   head = intel_ring_wrap(ce->ring, rq->head);
+
+   __i915_request_reset(rq, guilty);
+   i915_request_put(rq);
+out_replay:
+   guc_reset_state(ce, head, guilty);
+}
+
+static void __guc_reset_context(struct intel_context *ce, intel_engine_mask_t 
stalled)
+{
+   struct intel_context *child;
+   unsigned long flags;
 
GEM_BUG_ON(intel_context_is_child(ce));
 
@@ -1826,34 +1849,13 @@ static void __guc_reset_context(struct intel_context 
*ce, intel_engine_mask_t st
 * For each context in the relationship find the hanging request
 * resetting each context / request as needed
 */
-   for (i = 0; i < number_children + 1; ++i) {
-   if (!intel_context_is_pinned(ce))
-   goto next_context;
-
-   guilty = false;
-   rq = intel_context_get_active_request(ce);
-   if (!rq) {
-   head = ce->ring->tail;
-   goto out_replay;
-   }
-
-   if (i915_request_started(rq))
-   guilty = stalled & ce->engine->mask;
-
-   GEM_BUG_ON(i915_active_is_idle(>active));
-   head = intel_ring_wrap(ce->ring, rq->head);
-
-   __i915_request_reset(rq, guilty);
-   i915_request_put(rq);
-out_replay:
-   guc_reset_state(ce, head, guilty);
-next_context:
-   if (i != number_children)
-   ce = list_next_entry(ce, parallel.child_link);
+   guc_reset_context_state(ce, stalled);
+   for_each_child(ce, child) {
+   guc_reset_context_state(child, stalled);
}
 
-   __unwind_incomplete_requests(parent);
-   intel_context_put(parent);
+   __unwind_incomplete_requests(ce);
+   intel_context_put(ce);
 }
 
 void wake_up_all_tlb_invalidate(struct intel_guc *guc)
-- 
2.42.0

[PATCH 6.8 298/336] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);

[PATCH 6.8 296/336] drm/ttm: Print the memory decryption status just once

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.

Stop printing the TT memory decryption status info each time tt is created
and instead print it just once.

Reduces the spam in the system logs when running guests with SEV enabled.

Signed-off-by: Zack Rusin 
Fixes: 71ce046327cf ("drm/ttm: Make sure the mapped tt pages are decrypted when 
needed")
Reviewed-by: Christian König 
Cc: Thomas Hellström 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v5.14+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240408155605.1398631-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ttm/ttm_tt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -92,7 +92,7 @@ int ttm_tt_create(struct ttm_buffer_obje
 */
if (bdev->pool.use_dma_alloc && 
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
page_flags |= TTM_TT_FLAG_DECRYPTED;
-   drm_info(ddev, "TT memory decryption enabled.");
+   drm_info_once(ddev, "TT memory decryption enabled.");
}
 
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);

Re: [PATCH RESEND v9 3/8] drm: atmel_hlcdc: replace regmap_read with regmap_read_poll_timeout

[Hari.PrasathGE]

On 4/24/24 11:03 AM, Manikandan Muralidharan wrote:
> Replace regmap_read with regmap_read_poll_timeout to neatly handle
> retries
> 

Reviewed-by: Hari Prasath Gujulan Elango 

> Signed-off-by: Manikandan Muralidharan 
> ---
>   .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 44 +++
>   1 file changed, 25 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index cc5cf4c2faf7..b229692a27ca 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -203,19 +203,22 @@ static void atmel_hlcdc_crtc_atomic_disable(struct 
> drm_crtc *c,
>   pm_runtime_get_sync(dev->dev);
>   
>   regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_DISP);
> - while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
> -(status & ATMEL_HLCDC_DISP))
> - cpu_relax();
> + if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
> +  !(status & ATMEL_HLCDC_DISP),
> + 10, 1000))
> + dev_warn(dev->dev, "Atmel LCDC status register DISPSTS 
> timeout\n");
>   
>   regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_SYNC);
> - while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
> -(status & ATMEL_HLCDC_SYNC))
> - cpu_relax();
> + if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
> +  !(status & ATMEL_HLCDC_SYNC),
> + 10, 1000))
> + dev_warn(dev->dev, "Atmel LCDC status register LCDSTS 
> timeout\n");
>   
>   regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_PIXEL_CLK);
> - while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
> -(status & ATMEL_HLCDC_PIXEL_CLK))
> - cpu_relax();
> + if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
> +  !(status & ATMEL_HLCDC_PIXEL_CLK),
> + 10, 1000))
> + dev_warn(dev->dev, "Atmel LCDC status register CLKSTS 
> timeout\n");
>   
>   clk_disable_unprepare(crtc->dc->hlcdc->sys_clk);
>   pinctrl_pm_select_sleep_state(dev->dev);
> @@ -241,20 +244,23 @@ static void atmel_hlcdc_crtc_atomic_enable(struct 
> drm_crtc *c,
>   clk_prepare_enable(crtc->dc->hlcdc->sys_clk);
>   
>   regmap_write(regmap, ATMEL_HLCDC_EN, ATMEL_HLCDC_PIXEL_CLK);
> - while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
> -!(status & ATMEL_HLCDC_PIXEL_CLK))
> - cpu_relax();
> -
> + if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
> +  status & ATMEL_HLCDC_PIXEL_CLK,
> +  10, 1000))
> + dev_warn(dev->dev, "Atmel LCDC status register CLKSTS 
> timeout\n");
>   
>   regmap_write(regmap, ATMEL_HLCDC_EN, ATMEL_HLCDC_SYNC);
> - while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
> -!(status & ATMEL_HLCDC_SYNC))
> - cpu_relax();
> + if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
> +  status & ATMEL_HLCDC_SYNC,
> +  10, 1000))
> + dev_warn(dev->dev, "Atmel LCDC status register LCDSTS 
> timeout\n");
>   
>   regmap_write(regmap, ATMEL_HLCDC_EN, ATMEL_HLCDC_DISP);
> - while (!regmap_read(regmap, ATMEL_HLCDC_SR, ) &&
> -!(status & ATMEL_HLCDC_DISP))
> - cpu_relax();
> + if (regmap_read_poll_timeout(regmap, ATMEL_HLCDC_SR, status,
> +  status & ATMEL_HLCDC_DISP,
> +  10, 1000))
> + dev_warn(dev->dev, "Atmel LCDC status register DISPSTS 
> timeout\n");
> +
>   
>   pm_runtime_put_sync(dev->dev);
>   

Re: [PATCH v2 0/3] drm/mediatek: Add support for OF graphs

[Alexandre Mergnat]

Hi Angelo,

Gentle ping because I'm stuck if I rebase my serie on top of yours.

On 02/05/2024 18:53, Alexandre Mergnat wrote:



On 30/04/2024 13:33, AngeloGioacchino Del Regno wrote:

Il 30/04/24 12:17, Alexandre Mergnat ha scritto:

Hi Angelo,

On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:

This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths (meaning main display through OF graph and external
display hardcoded, because of OVL_ADAPTOR).


Is that make sense for you to add the DTS changes of these boards into this 
serie ?
I asked because, IMHO, that could help to understand the serie.



Yes and no... but I imagine that you're asking this because you're trying to
prepare something with a different SoC+board(s) combination :-)

In that case, I'm preventively sorry because what follows here is not 100%
perfectly tidy yet as I didn't mean to send the devicetree commits upstream
before this series got picked

... but there you go - I'm sure that you won't mind and that the example will
be more than good enough for you.

Please note that one of the reasons why I didn't want to add this to the series
is that the following changes show only a mere 50% of the reasons why we want OF
graph support on mediatek-drm (but mainly, it's because I didn't have time to
actually rebase etc :-P )


Thanks for the explanations and examples.
Unfortunately, I have 2 display but only one is working (the main: DSI0) when I 
use the dts method.
I've probably missed something but I don't know what.

In my "mmsys" node, if I swap display (the ext endpoint with the main endpoint), the DPI0 is 
working, but not the DSI0. I conclude my both paths are good.


Then, I've put some trace into "mtk_drm_of_ddp_path_build" to check if it parse the two endpoint of 
the node. Both are parsed, but "of_ep.port" is always = 0. According to "of_graph_parse_endpoint" 
function, "port" is the value of the parent "reg", whereas "id" is the value of the endpoint "reg".

So I replaced "of_ep.port" by "of_ep.id". Now I've of_ep.id = 0 for main and 
of_ep.id = 1 for EXT.

Now I've the good CRTC path, I get this error:
   mediatek-drm mediatek-drm.1.auto: Invalid display hw pipeline. Last 
component: 54 (ret=-2)
   mediatek-drm mediatek-drm.1.auto: probe with driver mediatek-drm failed with 
error -22

After quick look, the "cpath" into "mtk_drm_of_ddp_path_build_one" (or deeper functions) seems not 
be used as it should, due to the previous "of_ep.port" => "of_ep.id" change of course.


But I probably have to fix "of_ep.port" because I've mis-coded something. Just in case, I share you 
my diff:


diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts 
b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
index 1aa3426f561b..f660481d3fe8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
@@ -109,15 +109,51 @@ vsys_lcm_reg: regulator-vsys-lcm {
  };
  };

+ {
+    proc-supply = <_vproc_reg>;
+    sram-supply = <_vsram_proc_reg>;
+};
+
+ {
+    proc-supply = <_vproc_reg>;
+    sram-supply = <_vsram_proc_reg>;
+};
+
+ {
+    proc-supply = <_vproc_reg>;
+    sram-supply = <_vsram_proc_reg>;
+};
+
+ {
+    proc-supply = <_vproc_reg>;
+    sram-supply = <_vsram_proc_reg>;
+};
+
+_out {
+    remote-endpoint = <_in>;
+};
+
   {
  pinctrl-0 = <_default_pins>;
  pinctrl-1 = <_idle_pins>;
  pinctrl-names = "default", "sleep";
  status = "okay";
+    ports {
+    #address-cells = <1>;
+    #size-cells = <0>;

-    port {
-    dpi_out: endpoint {
-    remote-endpoint = <_in>;
+    port@0 {
+    reg = <0>;
+    dpi0_in: endpoint {
+    remote-endpoint = <_out>;
+    };
+    };
+
+    port@1 {
+    reg = <1>;
+    dpi0_out: endpoint {
+    remote-endpoint = <_in>;
+    };
  };
  };
  };
@@ -137,36 +173,28 @@ panel@0 {

  port {
  panel_in: endpoint {
-    remote-endpoint = <_out>;
+    remote-endpoint = <_out>;
  };
  };
  };
+    ports {
+    #address-cells = <1>;
+    #size-cells = <0>;

-    port {
-    dsi_out: endpoint {
-    remote-endpoint = <_in>;
+    port@0 {
+    reg = <0>;
+    dsi0_in: endpoint {
+    remote-endpoint = <_out>;
+    };
  };
-    };
-};

- {
-    proc-supply = <_vproc_reg>;
-    sram-supply = <_vsram_proc_reg>;
-};
-
- {
-    proc-supply = <_vproc_reg>;
-    sram-supply = <_vsram_proc_reg>;
-};
-
- {
-    proc-supply = <_vproc_reg>;
-    sram-supply = <_vsram_proc_reg>;
-};
-
- {
-    proc-supply = <_vproc_reg>;
-    sram-supply = <_vsram_proc_reg>;
+    port@1 {
+    reg = <1>;
+    dsi0_out: endpoint {
+    remote-endpoint = <_in>;
+    };
+    };
+    };
  };

   {
@@ 

Re: powervr lockdep warnings

[Chen-Yu Tsai]

On Tue, May 14, 2024 at 4:54 PM Matt Coster  wrote:
>
> On 10/05/2024 09:43, Chen-Yu Tsai wrote:
> > Hi,
> >
> > I got the following lockdep warnings while trying to make the powervr
> > driver work on MT8173. This was observed while trying to run vkmark.
> > This was on the next-20240506 kernel running Debian Sid with the
> > Mesa 24.0.6 package rebuilt to include the powervr driver.
>
> Hi,
>
> Thanks for the report! I've got an elm chromebook set up with the same
> versions mentioned above, and spent yesterday trying to make it
> reproduce the issue without success.
>
> I don't really have time at the moment to keep working on this, but I've
> made a note to come back to it when I get a chance.
>
>  From the traces below, it doesn't *seem* like this should be a platform
> specific issue, so I'm definitely interested in getting it fixed.

I broke out the BeaglePlay I got at ELC, grabbed a new image from
beagleboard.org and upgraded the kernel to their v6.9 package, and
used the same packages from my MT8173 run. It seemed to run OK, but
it's possible the kernel doesn't have CONFIG_LOCKDEP enabled.

I'll do some more tests on MT8173 with a release kernel and fewer
stuff on top.


Thanks
ChenYu

> Cheers,
> Matt
>
> > [73602.438144] [ cut here ]
> > [73602.450563] WARNING: CPU: 3 PID: 2244 at
> > drivers/gpu/drm/drm_gpuvm.c:1874 drm_gpuva_unlink+0xec/0x140
> > [drm_gpuvm]
> > [73602.468778] Modules linked in: mtk_vcodec_dec mtk_vcodec_enc
> > v4l2_vp9 v4l2_h264 cdc_ether mtk_vcodec_dbgfs usbnet mtk_vcodec_common
> > mtk_jpeg uvcvideo mtk_scp powervr mtk_jpeg_enc_hw mtk_rpmsg mtk_mdp
> > rpmsg_core cros_ec_sensors mtk_jpeg_dec_hw mtk_scp_ipi
> > cros_ec_sensors_core videobuf2_vmalloc v4l2_mem2mem r8152 uvc
> > videobuf2_dma_contig videobuf2_v4l2 drm_gpuvm videobuf2_memops sha1_ce
> > videobuf2_common mii drm_exec cros_ec_sensorhub mtk_vpu joydev fuse
> > [73602.526113] CPU: 3 PID: 2244 Comm: vkmark Tainted: GW
> > 6.9.0-rc7-next-20240506-11489-g2585d27380e4-dirty #217
> > b57080d80a375eadc1b59c661ce880f5be496816
> > [73602.549750] Hardware name: Google Elm (DT)
> > [73602.562503] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS 
> > BTYPE=--)
> > [73602.578257] pc : drm_gpuva_unlink+0xec/0x140 [drm_gpuvm]
> > [73602.592391] lr : drm_gpuva_unlink+0x12c/0x140 [drm_gpuvm]
> > [73602.606597] sp : ffc086aa7590
> > [73602.618660] x29: ffc086aa7590 x28: 0080 x27: 
> > ffc07ca59b98
> > [73602.634725] x26: ffc086aa7900 x25:  x24: 
> > ff80c14c5980
> > [73602.650776] x23: ff80054cee08 x22: ff80c14c5d00 x21: 
> > ffc082f8a000
> > [73602.666878] x20: ff80d1c3a000 x19: ff80054cee00 x18: 
> > 
> > [73602.682898] x17:  x16:  x15: 
> > 007fc6e28c90
> > [73602.698907] x14: 1ff810d54ea4 x13: 41b58ab3 x12: 
> > ffb019c8f00c
> > [73602.714919] x11: 1ff019c8f00b x10: ffb019c8f00b x9 : 
> > ffc07ca1dff8
> > [73602.730964] x8 : 004fe6370ff5 x7 : ff80ce47805b x6 : 
> > 0001
> > [73602.746942] x5 : ff80ce478058 x4 : ff80ce478058 x3 : 
> > 
> > [73602.762920] x2 :  x1 : ff80d1c3a1a0 x0 : 
> > 
> > [73602.778793] Call trace:
> > [73602.789746]  drm_gpuva_unlink+0xec/0x140 [drm_gpuvm
> > bbf6d948c0b434a2936abb76cd7734fb954b4801]
> > [73602.807036]  pvr_vm_gpuva_unmap+0x88/0xb0 [powervr
> > 3ad437ff1d69ca6bbe76c29aac5b59cf4d3e54e4]
> > [73602.824299]  op_unmap_cb.isra.0+0xbc/0x108 [drm_gpuvm
> > bbf6d948c0b434a2936abb76cd7734fb954b4801]
> > [73602.841559]  __drm_gpuvm_sm_unmap+0x288/0x2c0 [drm_gpuvm
> > bbf6d948c0b434a2936abb76cd7734fb954b4801]
> > [73602.858863]  drm_gpuvm_sm_unmap+0x78/0xb8 [drm_gpuvm
> > bbf6d948c0b434a2936abb76cd7734fb954b4801]
> > [73602.875693]  pvr_vm_bind_op_exec+0x6c/0x118 [powervr
> > 3ad437ff1d69ca6bbe76c29aac5b59cf4d3e54e4]
> > [73602.892483]  pvr_vm_unmap+0x1f8/0x238 [powervr
> > 3ad437ff1d69ca6bbe76c29aac5b59cf4d3e54e4]
> > [73602.908746]  pvr_ioctl_vm_unmap+0x80/0xb8 [powervr
> > 3ad437ff1d69ca6bbe76c29aac5b59cf4d3e54e4]
> > [73602.925386]  drm_ioctl_kernel+0x140/0x1d0
> > [73602.937503]  drm_ioctl+0x3e8/0x7e0
> > [73602.948949]  __arm64_sys_ioctl+0xec/0x118
> > [73602.960993]  invoke_syscall+0x68/0x198
> > [73602.972749]  el0_svc_common.constprop.0+0x80/0x150
> > [73602.985561]  do_el0_svc+0x38/0x50
> > [73602.996856]  el0_svc+0x4c/0xc0
> > [73603.007821]  el0t_64_sync_handler+0x120/0x130
> > [73603.020096]  el0t_64_sync+0x1a8/0x1b0
> > [73603.031606] irq event stamp: 153208
> > [73603.042881] hardirqs last  enabled at (153207):
> > [] _raw_spin_unlock_irqrestore+0x98/0xa8
> > [73603.060595] hardirqs last disabled at (153208):
> > [] el1_dbg+0x28/0x90
> > [73603.076534] softirqs last  enabled at (153032):
> > [] fpsimd_restore_current_state+0x4c/0xf8
> > [73603.094345] softirqs last disabled at (153030):
> > [] 

Re: [PATCH] drm/edid: remove drm_do_get_edid()

[Jani Nikula]

On Tue, 14 May 2024, Thomas Zimmermann  wrote:
> Am 13.05.24 um 22:27 schrieb Jani Nikula:
>> All users of drm_do_get_edid() have been converted to
>> drm_edid_read_custom(). Remove the unused function to prevent new users
>> from creeping in.
>>
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Thomas Zimmermann 

Thanks, pushed to drm-misc-next.

BR,
Jani.


-- 
Jani Nikula, Intel

RE: [PATCH v7 1/1] drm/bridge: it6505: fix hibernate to resume no display issue

[kuro.chung]

-Original Message-
From: Kuro Chung (鐘仕廷) 
Sent: Tuesday, May 14, 2024 11:21 AM
To: 'Robert Foss' 
Cc: Allen Chen ; Pin-yen Lin ; 
Kenneth Hung (洪家倫) ; Kuro Chung 
; Andrzej Hajda 
; Neil Armstrong ; Laurent 
Pinchart ; Jonas Karlman ; 
Jernej Skrabec ; Maarten Lankhorst 
; Maxime Ripard ; Thomas 
Zimmermann ; David Airlie ; Daniel 
Vetter ; open list:DRM DRIVERS 
; open list 
Subject: RE: [PATCH v7 1/1] drm/bridge: it6505: fix hibernate to resume no 
display issue

-Original Message-
From: Robert Foss 
Sent: Tuesday, May 14, 2024 1:45 AM
To: Kuro Chung (鐘仕廷) 
Cc: Allen Chen ; Pin-yen Lin ; 
Kenneth Hung (洪家倫) ; Kuro Chung 
; Andrzej Hajda 
; Neil Armstrong ; Laurent 
Pinchart ; Jonas Karlman ; 
Jernej Skrabec ; Maarten Lankhorst 
; Maxime Ripard ; Thomas 
Zimmermann ; David Airlie ; Daniel 
Vetter ; open list:DRM DRIVERS 
; open list 
Subject: Re: [PATCH v7 1/1] drm/bridge: it6505: fix hibernate to resume no 
display issue

On Mon, May 13, 2024 at 7:42 PM Robert Foss  wrote:
>
> On Mon, May 6, 2024 at 11:36 AM kuro  wrote:
> >
> > From: Kuro 
> >
> > ITE added a FIFO reset bit for input video. When system power 
> > resume, the TTL input of it6505 may get some noise before video 
> > signal stable and the hardware function reset is required.
> > But the input FIFO reset will also trigger error interrupts of output 
> > module rising.
> > Thus, it6505 have to wait a period can clear those expected error 
> > interrupts caused by manual hardware reset in one interrupt handler calling 
> > to avoid interrupt looping.
> >
> > Signed-off-by: Kuro Chung 
> >
> > ---
> >  drivers/gpu/drm/bridge/ite-it6505.c | 73
> > +++--
> >  1 file changed, 49 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
> > b/drivers/gpu/drm/bridge/ite-it6505.c
> > index b53da9bb65a16..64e2706e3d0c3 100644
> > --- a/drivers/gpu/drm/bridge/ite-it6505.c
> > +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> > @@ -1317,9 +1317,15 @@ static void it6505_video_reset(struct it6505 *it6505)
> > it6505_link_reset_step_train(it6505);
> > it6505_set_bits(it6505, REG_DATA_MUTE_CTRL, EN_VID_MUTE, 
> > EN_VID_MUTE);
> > it6505_set_bits(it6505, REG_INFOFRAME_CTRL, EN_VID_CTRL_PKT, 0x00);
> > -   it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
> > +
> > +   it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET, 
> > TX_FIFO_RESET);
> > +   it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET, 
> > + 0x00);
> > +
> > it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO, 
> > RST_501_FIFO);
> > it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO, 
> > 0x00);
> > +
> > +   it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
> > +   usleep_range(1000, 2000);
> > it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, 0x00); 
> > }
> >
> > @@ -2249,12 +2255,11 @@ static void it6505_link_training_work(struct 
> > work_struct *work)
> > if (ret) {
> > it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > it6505_link_train_ok(it6505);
> > -   return;
> > } else {
> > it6505->auto_train_retry--;
> > +   it6505_dump(it6505);
> > }
> >
> > -   it6505_dump(it6505);
> >  }
> >
> >  static void it6505_plugged_status_to_codec(struct it6505 *it6505) 
> > @@ -2475,31 +2480,53 @@ static void it6505_irq_link_train_fail(struct 
> > it6505 *it6505)
> > schedule_work(>link_works);
> >  }
> >
> > -static void it6505_irq_video_fifo_error(struct it6505 *it6505)
> > +static bool it6505_test_bit(unsigned int bit, const unsigned int
> > +*addr)
> >  {
> > -   struct device *dev = >client->dev;
> > -
> > -   DRM_DEV_DEBUG_DRIVER(dev, "video fifo overflow interrupt");
> > -   it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > -   flush_work(>link_works);
> > -   it6505_stop_hdcp(it6505);
> > -   it6505_video_reset(it6505);
> > +   return 1 & (addr[bit / BITS_PER_BYTE] >> (bit % 
> > + BITS_PER_BYTE));
> >  }
> >
> > -static void it6505_irq_io_latch_fifo_overflow(struct it6505
> > *it6505)
> > +static void it6505_irq_video_handler(struct it6505 *it6505, const 
> > +int *int_status)
> >  {
> > struct device *dev = >client->dev;
> > +   int reg_0d, reg_int03;
> >
> > -   DRM_DEV_DEBUG_DRIVER(dev, "IO latch fifo overflow interrupt");
> > -   it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > -   flush_work(>link_works);
> > -   it6505_stop_hdcp(it6505);
> > -   it6505_video_reset(it6505);
> > -}
> > +   /*
> > +* When video SCDT change with video not stable,
> > +* Or video FIFO error, need video reset
> > +*/
> >
> > -static bool it6505_test_bit(unsigned int bit, const unsigned int
> > *addr) -{
> > -   return 1 & (addr[bit / BITS_PER_BYTE] >> (bit % BITS_PER_BYTE));
> > +   if