date:20231218

Abstrace the memory type from the page_pool so we can later add support
for new memory types. Convert the page_pool to use the new netmem type
abstraction, rather than use struct page directly.

As of this patch the netmem type is a no-op abstraction: it's always a
struct page underneath. All the page pool internals are converted to
use struct netmem instead of struct page, and the page pool now exports
2 APIs:

1. The existing struct page API.
2. The new struct netmem API.

Keeping the existing API is transitional; we do not want to refactor all
the curent drivers using the page pool at once.

The netmem abstraction is currently a no-op. The page_pool uses
page_to_netmem() to convert allocated pages to netmem, and uses
netmem_to_page() to convert the netmem back to pages to pass to mm APIs,

Follow up patches to this series add non-paged netmem support to the
page_pool. This change is factored out on its own to limit the code
churn to this 1 patch, for ease of code review.

Signed-off-by: Mina Almasry 

---
 include/linux/skbuff.h   |   4 +-
 include/net/netmem.h |  15 ++
 include/net/page_pool/helpers.h  | 106 
 include/net/page_pool/types.h|  17 +-
 include/trace/events/page_pool.h |  28 +--
 net/bpf/test_run.c   |   5 +-
 net/core/page_pool.c | 286 +--
 net/core/skbuff.c|   7 +-
 8 files changed, 285 insertions(+), 183 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 03ab13072962..1189d8d22da8 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3486,7 +3486,7 @@ static inline void skb_frag_ref(struct sk_buff *skb, int 
f)
__skb_frag_ref(&skb_shinfo(skb)->frags[f]);
 }
 
-bool napi_pp_put_page(struct page *page, bool napi_safe);
+bool napi_pp_put_page(struct netmem *netmem, bool napi_safe);
 
 static inline void
 napi_frag_unref(skb_frag_t *frag, bool recycle, bool napi_safe)
@@ -3494,7 +3494,7 @@ napi_frag_unref(skb_frag_t *frag, bool recycle, bool 
napi_safe)
struct page *page = skb_frag_page(frag);
 
 #ifdef CONFIG_PAGE_POOL
-   if (recycle && napi_pp_put_page(page, napi_safe))
+   if (recycle && napi_pp_put_page(page_to_netmem(page), napi_safe))
return;
 #endif
put_page(page);
diff --git a/include/net/netmem.h b/include/net/netmem.h
index 7fce2efc8707..31f338f19da0 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -68,4 +68,19 @@ static inline struct netmem *page_to_netmem(struct page 
*page)
return container_of(page, struct netmem, page);
 }
 
+static inline int netmem_ref_count(struct netmem *netmem)
+{
+   return page_ref_count(netmem_to_page(netmem));
+}
+
+static inline unsigned long netmem_to_pfn(struct netmem *netmem)
+{
+   return page_to_pfn(netmem_to_page(netmem));
+}
+
+static inline struct netmem *netmem_compound_head(struct netmem *netmem)
+{
+   return page_to_netmem(compound_head(netmem_to_page(netmem)));
+}
+
 #endif /* _NET_NETMEM_H */
diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
index ead2c0d24b2c..c71969279284 100644
--- a/include/net/page_pool/helpers.h
+++ b/include/net/page_pool/helpers.h
@@ -53,6 +53,8 @@
 #define _NET_PAGE_POOL_HELPERS_H
 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_PAGE_POOL_STATS
 /* Deprecated driver-facing API, use netlink instead */
@@ -112,21 +114,21 @@ static inline struct page 
*page_pool_dev_alloc_frag(struct page_pool *pool,
return page_pool_alloc_frag(pool, offset, size, gfp);
 }
 
-static inline struct page *page_pool_alloc(struct page_pool *pool,
-  unsigned int *offset,
-  unsigned int *size, gfp_t gfp)
+static inline struct netmem *page_pool_alloc(struct page_pool *pool,
+unsigned int *offset,
+unsigned int *size, gfp_t gfp)
 {
unsigned int max_size = PAGE_SIZE << pool->p.order;
-   struct page *page;
+   struct netmem *netmem;
 
if ((*size << 1) > max_size) {
*size = max_size;
*offset = 0;
-   return page_pool_alloc_pages(pool, gfp);
+   return page_pool_alloc_netmem(pool, gfp);
}
 
-   page = page_pool_alloc_frag(pool, offset, *size, gfp);
-   if (unlikely(!page))
+   netmem = page_pool_alloc_frag_netmem(pool, offset, *size, gfp);
+   if (unlikely(!netmem))
return NULL;
 
/* There is very likely not enough space for another fragment, so append
@@ -138,7 +140,7 @@ static inline struct page *page_pool_alloc(struct page_pool 
*pool,
pool->frag_offset = max_size;
}
 
-   return page;
+   return netmem;
 }
 
 /**
@@ -160,7 +162,7 @@ static inline struct page *page_pool_dev_alloc(struct 
page_pool *pool,
 {
gfp_t gfp = (GFP_ATOMIC | __GFP_NO

Re: [PATCH v3 08/14] drm/panthor: Add the FW logical block

2023-12-18 Thread Chris Diamand

On 04/12/2023 17:33, Boris Brezillon wrote:
> Contains everything that's FW related, that includes the code dealing
> with the microcontroller unit (MCU) that's running the FW, and anything
> related to allocating memory shared between the FW and the CPU.
> 
> A few global FW events are processed in the IRQ handler, the rest is
> forwarded to the scheduler, since scheduling is the primary reason for
> the FW existence, and also the main source of FW <-> kernel
> interactions.
> 
> v3:
> - Make the FW path more future-proof (Liviu)
> - Use one waitqueue for all FW events
> - Simplify propagation of FW events to the scheduler logic
> - Drop the panthor_fw_mem abstraction and use panthor_kernel_bo instead
> - Account for the panthor_vm changes
> - Replace magic number with 0x7fff with ~0 to better signify that
>   it's the maximum permitted value.
> - More accurate rounding when computing the firmware timeout.
> - Add a 'sub iterator' helper function. This also adds a check that a
>   firmware entry doesn't overflow the firmware image.
> - Drop __packed from FW structures, natural alignment is good enough.
> - Other minor code improvements.
> 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Steven Price 
> ---
>  drivers/gpu/drm/panthor/panthor_fw.c | 1332 ++
>  drivers/gpu/drm/panthor/panthor_fw.h |  504 ++
>  2 files changed, 1836 insertions(+)
>  create mode 100644 drivers/gpu/drm/panthor/panthor_fw.c
>  create mode 100644 drivers/gpu/drm/panthor/panthor_fw.h
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c 
> b/drivers/gpu/drm/panthor/panthor_fw.c
> new file mode 100644
> index ..85afe769f567
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_fw.c

...
> +static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
> +  const struct firmware *fw,
> +  struct panthor_fw_binary_iter *iter,
> +  u32 ehdr)
> +{
> + struct panthor_fw_binary_section_entry_hdr hdr;
> + struct panthor_fw_section *section;
> + u32 section_size;
> + u32 name_len;
> + int ret;
> +
> + ret = panthor_fw_binary_iter_read(ptdev, iter, &hdr, sizeof(hdr));
> + if (ret)
> + return ret;
> +
> + if (hdr.data.end < hdr.data.start) {
> + drm_err(&ptdev->base, "Firmware corrupted, data.end < 
> data.start (0x%x < 0x%x)\n",
> + hdr.data.end, hdr.data.start);
> + return -EINVAL;
> + }
> +
> + if (hdr.va.end < hdr.va.start) {
> + drm_err(&ptdev->base, "Firmware corrupted, hdr.va.end < 
> hdr.va.start (0x%x < 0x%x)\n",
> + hdr.va.end, hdr.va.start);
> + return -EINVAL;
> + }
> +
> + if (hdr.data.end > fw->size) {
> + drm_err(&ptdev->base, "Firmware corrupted, file truncated? 
> data_end=0x%x > fw size=0x%zx\n",
> + hdr.data.end, fw->size);
> + return -EINVAL;
> + }
> +
> + if ((hdr.va.start & ~PAGE_MASK) != 0 ||
> + (hdr.va.end & ~PAGE_MASK) != 0) {
> + drm_err(&ptdev->base, "Firmware corrupted, virtual addresses 
> not page aligned: 0x%x-0x%x\n",
> + hdr.va.start, hdr.va.end);
> + return -EINVAL;
> + }
> +
> + if (hdr.flags & ~CSF_FW_BINARY_IFACE_ENTRY_RD_SUPPORTED_FLAGS) {
> + drm_err(&ptdev->base, "Firmware contains interface with 
> unsupported flags (0x%x)\n",
> + hdr.flags);
> + return -EINVAL;
> + }
> +
> + if (hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_RD_PROT) {
> + drm_warn(&ptdev->base,
> +  "Firmware protected mode entry not be supported, 
> ignoring");
> + return 0;
> + }
> +
> + if (hdr.va.start == CSF_MCU_SHARED_REGION_START &&
> + !(hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_RD_SHARED)) {
> + drm_err(&ptdev->base,
> + "Interface at 0x%llx must be shared", 
> CSF_MCU_SHARED_REGION_START);
> + return -EINVAL;
> + }
> +
> + name_len = iter->size - iter->offset;
> +
> + section = drmm_kzalloc(&ptdev->base, sizeof(*section), GFP_KERNEL);
> + if (!section)
> + return -ENOMEM;
> +
> + list_add_tail(§ion->node, &ptdev->fw->sections);
> + section->flags = hdr.flags;
> + section->data.size = hdr.data.end - hdr.data.start;
> +
> + if (section->data.size > 0) {
> + void *data = drmm_kmalloc(&ptdev->base, section->data.size, 
> GFP_KERNEL);
> +
> + if (!data)
> + return -ENOMEM;
> +
> + memcpy(data, fw->data + hdr.data.start, section->data.size);
> + section->data.buf = data;
> + }
> +
> + if (name_len > 0) {
> + char *name = drmm_kmalloc(&ptdev->base, name_len + 1, 
> GFP_KERNEL);
> +
> + if (!name)
> + retur

[RFC PATCH net-next v5 04/14] netdev: support binding dma-buf to netdevice

Add a netdev_dmabuf_binding struct which represents the
dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
rx queues on the netdevice. On the binding, the dma_buf_attach
& dma_buf_map_attachment will occur. The entries in the sg_table from
mapping will be inserted into a genpool to make it ready
for allocation.

The chunks in the genpool are owned by a dmabuf_chunk_owner struct which
holds the dma-buf offset of the base of the chunk and the dma_addr of
the chunk. Both are needed to use allocations that come from this chunk.

We create a new type that represents an allocation from the genpool:
net_iov. We setup the net_iov allocation size in the
genpool to PAGE_SIZE for simplicity: to match the PAGE_SIZE normally
allocated by the page pool and given to the drivers.

The user can unbind the dmabuf from the netdevice by closing the netlink
socket that established the binding. We do this so that the binding is
automatically unbound even if the userspace process crashes.

The binding and unbinding leaves an indicator in struct netdev_rx_queue
that the given queue is bound, but the binding doesn't take effect until
the driver actually reconfigures its queues, and re-initializes its page
pool.

The netdev_dmabuf_binding struct is refcounted, and releases its
resources only when all the refs are released.

Signed-off-by: Willem de Bruijn 
Signed-off-by: Kaiyuan Zhang 
Signed-off-by: Mina Almasry 

---

RFC v5:
- Renamed page_pool_iov to net_iov, and moved that support to devmem.h
  or netmem.h.

v1:

- Introduce devmem.h instead of bloating netdevice.h (Jakub)
- ENOTSUPP -> EOPNOTSUPP (checkpatch.pl I think)
- Remove unneeded rcu protection for binding->list (rtnl protected)
- Removed extraneous err_binding_put: label.
- Removed dma_addr += len (Paolo).
- Don't override err on netdev_bind_dmabuf_to_queue failure.
- Rename devmem -> dmabuf (David).
- Add id to dmabuf binding (David/Stan).
- Fix missing xa_destroy bound_rq_list.
- Use queue api to reset bound RX queues (Jakub).
- Update netlink API for rx-queue type (tx/re) (Jakub).

RFC v3:
- Support multi rx-queue binding


netmem support

---
 include/net/devmem.h  | 115 ++
 include/net/netdev_rx_queue.h |   1 +
 include/net/netmem.h  |  10 ++
 net/core/dev.c| 273 ++
 net/core/netdev-genl.c| 121 ++-
 5 files changed, 518 insertions(+), 2 deletions(-)
 create mode 100644 include/net/devmem.h

diff --git a/include/net/devmem.h b/include/net/devmem.h
new file mode 100644
index ..85ccbbe84c65
--- /dev/null
+++ b/include/net/devmem.h
@@ -0,0 +1,115 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Device memory TCP support
+ *
+ * Authors:Mina Almasry 
+ * Willem de Bruijn 
+ * Kaiyuan Zhang 
+ *
+ */
+#ifndef _NET_DEVMEM_H
+#define _NET_DEVMEM_H
+
+struct netdev_dmabuf_binding {
+   struct dma_buf *dmabuf;
+   struct dma_buf_attachment *attachment;
+   struct sg_table *sgt;
+   struct net_device *dev;
+   struct gen_pool *chunk_pool;
+
+   /* The user holds a ref (via the netlink API) for as long as they want
+* the binding to remain alive. Each page pool using this binding holds
+* a ref to keep the binding alive. Each allocated net_iov holds a
+* ref.
+*
+* The binding undos itself and unmaps the underlying dmabuf once all
+* those refs are dropped and the binding is no longer desired or in
+* use.
+*/
+   refcount_t ref;
+
+   /* The portid of the user that owns this binding. Used for netlink to
+* notify us of the user dropping the bind.
+*/
+   u32 owner_nlportid;
+
+   /* The list of bindings currently active. Used for netlink to notify us
+* of the user dropping the bind.
+*/
+   struct list_head list;
+
+   /* rxq's this binding is active on. */
+   struct xarray bound_rxq_list;
+
+   /* ID of this binding. Globally unique to all bindings currently
+* active.
+*/
+   u32 id;
+};
+
+/* Owner of the dma-buf chunks inserted into the gen pool. Each scatterlist
+ * entry from the dmabuf is inserted into the genpool as a chunk, and needs
+ * this owner struct to keep track of some metadata necessary to create
+ * allocations from this chunk.
+ */
+struct dmabuf_genpool_chunk_owner {
+   /* Offset into the dma-buf where this chunk starts.  */
+   unsigned long base_virtual;
+
+   /* dma_addr of the start of the chunk.  */
+   dma_addr_t base_dma_addr;
+
+   /* Array of net_iovs for this chunk. */
+   struct net_iov *niovs;
+   size_t num_niovs;
+
+   struct netdev_dmabuf_binding *binding;
+};
+
+#ifdef CONFIG_DMA_SHARED_BUFFER
+void __netdev_dmabuf_binding_free(struct netdev_dmabuf_binding *binding);
+int netdev_bind_dmabuf(struct net_device *dev, unsigned int dmabuf_fd,
+  struct ne

[PATCH v9 0/2] Add displays support for bsh-smm-s2/pro boards

2023-12-18 Thread Dario Binacchi



The series adds drivers for the displays used by bsh-smm-s2/pro boards.
This required applying some patches to the samsung-dsim driver and the
drm_bridge.c module.

Changes in v9:
- Updated commit message
- Drop [3/3] arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup
  because applied.

Changes in v8:
- Move the 'status' property to the end of the list of nodes:
  - pwm1
  - lcdif
  - mipi_dsi
- Add a newline between properties and child node (mipi_dsi_out).
- Sort the iomuxc node alphabetically
- Rename pwm1grp to blgrp

Changes in v7:
- Drop [3/4] dt-bindings: display: panel: Add synaptics r63353 panel controller
  because applied.

Changes in v6:
- Drop patches:
  - [06/10] drm/panel: Add Synaptics R63353 panel driver
  - [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  - [08/10] drm/panel: Add Ilitek ILI9805 panel driver
  - [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  Because applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-next)
  Drop patches:
  - [01/10] drm/bridge: Fix bridge disable logic
  - [02/10] drm/bridge: Fix a use case in the bridge disable logic
  Because they are wrong

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma 
TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Dario Binacchi (2):
  drm: bridge: samsung-dsim: enter display mode in the enable() callback
  drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

 drivers/gpu/drm/bridge/samsung-dsim.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

-- 
2.43.0

[RFC PATCH net-next v5 12/14] net: add SO_DEVMEM_DONTNEED setsockopt to release RX frags

Add an interface for the user to notify the kernel that it is done
reading the devmem dmabuf frags returned as cmsg. The kernel will
drop the reference on the frags to make them available for re-use.

Signed-off-by: Willem de Bruijn 
Signed-off-by: Kaiyuan Zhang 
Signed-off-by: Mina Almasry 

---

Changes in v1:
- devmemtoken -> dmabuf_token (David).
- Use napi_pp_put_page() for refcounting (Yunsheng).
- Fix build error with missing socket options on other asms.

---
 arch/alpha/include/uapi/asm/socket.h  |  8 -
 arch/mips/include/uapi/asm/socket.h   |  6 
 arch/parisc/include/uapi/asm/socket.h |  6 
 arch/sparc/include/uapi/asm/socket.h  |  6 
 include/uapi/asm-generic/socket.h |  1 +
 include/uapi/linux/uio.h  |  4 +++
 net/core/sock.c   | 45 +++
 7 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/include/uapi/asm/socket.h 
b/arch/alpha/include/uapi/asm/socket.h
index e94f621903fe..00146c243037 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -10,7 +10,7 @@
  * Note: we only bother about making the SOL_SOCKET options
  * same as OSF/1, as that's all that "normal" programs are
  * likely to set.  We don't necessarily want to be binary
- * compatible with _everything_. 
+ * compatible with _everything_.
  */
 #define SOL_SOCKET 0x
 
@@ -140,6 +140,12 @@
 #define SO_PASSPIDFD   76
 #define SO_PEERPIDFD   77
 
+#define SO_DEVMEM_DONTNEED 78
+#define SO_DEVMEM_LINEAR   79
+#define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF   80
+#define SCM_DEVMEM_DMABUF  SO_DEVMEM_DMABUF
+
 #if !defined(__KERNEL__)
 
 #if __BITS_PER_LONG == 64
diff --git a/arch/mips/include/uapi/asm/socket.h 
b/arch/mips/include/uapi/asm/socket.h
index 60ebaed28a4c..9a71ee8f36db 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -151,6 +151,12 @@
 #define SO_PASSPIDFD   76
 #define SO_PEERPIDFD   77
 
+#define SO_DEVMEM_DONTNEED 78
+#define SO_DEVMEM_LINEAR   79
+#define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF   80
+#define SCM_DEVMEM_DMABUF  SO_DEVMEM_DMABUF
+
 #if !defined(__KERNEL__)
 
 #if __BITS_PER_LONG == 64
diff --git a/arch/parisc/include/uapi/asm/socket.h 
b/arch/parisc/include/uapi/asm/socket.h
index be264c2b1a11..6b8674399363 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -132,6 +132,12 @@
 #define SO_PASSPIDFD   0x404A
 #define SO_PEERPIDFD   0x404B
 
+#define SO_DEVMEM_DONTNEED 0x404C
+#define SO_DEVMEM_LINEAR   0x404D
+#define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF   0x404E
+#define SCM_DEVMEM_DMABUF  SO_DEVMEM_DMABUF
+
 #if !defined(__KERNEL__)
 
 #if __BITS_PER_LONG == 64
diff --git a/arch/sparc/include/uapi/asm/socket.h 
b/arch/sparc/include/uapi/asm/socket.h
index 682da3714686..ecfc8bfa9fe0 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -133,6 +133,12 @@
 #define SO_PASSPIDFD 0x0055
 #define SO_PEERPIDFD 0x0056
 
+#define SO_DEVMEM_DONTNEED   0x0057
+#define SO_DEVMEM_LINEAR 0x0058
+#define SCM_DEVMEM_LINEARSO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF 0x0059
+#define SCM_DEVMEM_DMABUFSO_DEVMEM_DMABUF
+
 #if !defined(__KERNEL__)
 
 
diff --git a/include/uapi/asm-generic/socket.h 
b/include/uapi/asm-generic/socket.h
index 25a2f5255f52..1acb77780f10 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -135,6 +135,7 @@
 #define SO_PASSPIDFD   76
 #define SO_PEERPIDFD   77
 
+#define SO_DEVMEM_DONTNEED 97
 #define SO_DEVMEM_LINEAR   98
 #define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
 #define SO_DEVMEM_DMABUF   99
diff --git a/include/uapi/linux/uio.h b/include/uapi/linux/uio.h
index ad92e37699da..65f33178a601 100644
--- a/include/uapi/linux/uio.h
+++ b/include/uapi/linux/uio.h
@@ -30,6 +30,10 @@ struct dmabuf_cmsg {
__u32  dmabuf_id;   /* dmabuf id this frag belongs to. */
 };
 
+struct dmabuf_token {
+   __u32 token_start;
+   __u32 token_count;
+};
 /*
  * UIO_MAXIOV shall be at least 16 1003.1g (5.4.1.1)
  */
diff --git a/net/core/sock.c b/net/core/sock.c
index 446e945f736b..77497dbb9022 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1047,6 +1047,46 @@ static int sock_reserve_memory(struct sock *sk, int 
bytes)
return 0;
 }
 
+#ifdef CONFIG_PAGE_POOL
+static noinline_for_stack int
+sock_devmem_dontneed(struct sock *sk, sockptr_t optval, unsigned int optlen)
+{
+   unsigned int num_tokens, i, j;
+   struct dmabuf_token *tokens;
+   int ret;
+
+   if (sk->sk_type != SOCK_STREAM || sk->sk_protocol != IPPROTO_TCP)
+   return -EBADF;
+
+   if (optlen % sizeof(struct dmabuf_toke

[RFC PATCH net-next v5 09/14] net: support non paged skb frags

Make skb_frag_page() fail in the case where the frag is not backed
by a page, and fix its relevant callers to handle this case.

Signed-off-by: Mina Almasry 


---

Changes in v1:
- Fix illegal_highdma() (Yunsheng).
- Rework napi_pp_put_page() slightly to reduce code churn (Willem).

(cherry picked from commit e11c8035ed635e22aab224a89c48d93b5e881278)

also squashed assorted fixes
---
 include/linux/skbuff.h | 47 +-
 net/core/dev.c |  3 ++-
 net/core/gro.c |  2 +-
 net/core/skbuff.c  | 11 ++
 net/ipv4/tcp.c |  3 +++
 5 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 1189d8d22da8..890fc2b94fc7 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3452,17 +3452,53 @@ static inline void skb_frag_off_copy(skb_frag_t *fragto,
fragto->bv_offset = fragfrom->bv_offset;
 }
 
+/* Returns true if the skb_frag contains a net_iov. */
+static inline bool skb_frag_is_net_iov(const skb_frag_t *frag)
+{
+   return netmem_is_net_iov(frag->bv_page);
+}
+
+/**
+ * skb_frag_net_iov - retrieve the net_iov referred to by fragment
+ * @frag: the fragment
+ *
+ * Returns the &struct net_iov associated with @frag. Returns NULL if this
+ * frag has no associated net_iov.
+ */
+static inline struct net_iov *skb_frag_net_iov(const skb_frag_t *frag)
+{
+   if (!skb_frag_is_net_iov(frag))
+   return NULL;
+
+   return netmem_to_net_iov(frag->bv_page);
+}
+
 /**
  * skb_frag_page - retrieve the page referred to by a paged fragment
  * @frag: the paged fragment
  *
- * Returns the &struct page associated with @frag.
+ * Returns the &struct page associated with @frag. Returns NULL if this frag
+ * has no associated page.
  */
 static inline struct page *skb_frag_page(const skb_frag_t *frag)
 {
+   if (skb_frag_is_net_iov(frag))
+   return NULL;
+
return netmem_to_page(frag->bv_page);
 }
 
+/**
+ * skb_frag_netmem - retrieve the netmem referred to by a fragment
+ * @frag: the fragment
+ *
+ * Returns the &struct netmem associated with @frag.
+ */
+static inline struct netmem *skb_frag_netmem(const skb_frag_t *frag)
+{
+   return frag->bv_page;
+}
+
 /**
  * __skb_frag_ref - take an addition reference on a paged fragment.
  * @frag: the paged fragment
@@ -3491,13 +3527,11 @@ bool napi_pp_put_page(struct netmem *netmem, bool 
napi_safe);
 static inline void
 napi_frag_unref(skb_frag_t *frag, bool recycle, bool napi_safe)
 {
-   struct page *page = skb_frag_page(frag);
-
 #ifdef CONFIG_PAGE_POOL
-   if (recycle && napi_pp_put_page(page_to_netmem(page), napi_safe))
+   if (recycle && napi_pp_put_page(skb_frag_netmem(frag), napi_safe))
return;
 #endif
-   put_page(page);
+   put_page(skb_frag_page(frag));
 }
 
 /**
@@ -3537,6 +3571,9 @@ static inline void skb_frag_unref(struct sk_buff *skb, 
int f)
  */
 static inline void *skb_frag_address(const skb_frag_t *frag)
 {
+   if (!skb_frag_page(frag))
+   return NULL;
+
return page_address(skb_frag_page(frag)) + skb_frag_off(frag);
 }
 
diff --git a/net/core/dev.c b/net/core/dev.c
index 20ba528ef426..ad616b3c8e35 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3709,8 +3709,9 @@ static int illegal_highdma(struct net_device *dev, struct 
sk_buff *skb)
if (!(dev->features & NETIF_F_HIGHDMA)) {
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+   struct page *page = skb_frag_page(frag);
 
-   if (PageHighMem(skb_frag_page(frag)))
+   if (page && PageHighMem(page))
return 1;
}
}
diff --git a/net/core/gro.c b/net/core/gro.c
index 0759277dc14e..42d7f6755f32 100644
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -376,7 +376,7 @@ static inline void skb_gro_reset_offset(struct sk_buff 
*skb, u32 nhoff)
NAPI_GRO_CB(skb)->frag0 = NULL;
NAPI_GRO_CB(skb)->frag0_len = 0;
 
-   if (!skb_headlen(skb) && pinfo->nr_frags &&
+   if (!skb_headlen(skb) && pinfo->nr_frags && skb_frag_page(frag0) &&
!PageHighMem(skb_frag_page(frag0)) &&
(!NET_IP_ALIGN || !((skb_frag_off(frag0) + nhoff) & 3))) {
NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 96f85543f1dc..671775bad5f9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1239,6 +1239,14 @@ void skb_dump(const char *level, const struct sk_buff 
*skb, bool full_pkt)
struct page *p;
u8 *vaddr;
 
+   if (skb_frag_is_net_iov(frag)) {
+   printk("%sskb frag %d: not readable\n", level, i);
+   len -= frag->bv_len;
+   if (!len)
+   break;
+

[PATCH v9 2/2] drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

2023-12-18 Thread Dario Binacchi

The patch completes the setting of CLKLANE_STOP for the imx8m{m,n,p}
platforms (i. e. not exynos).

Co-developed-by: Michael Trimarchi 
Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 

---

Changes in v9:
- Updated commit message
- Drop [3/3] arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup
  because applied.

Changes in v8:
- Move the 'status' property to the end of the list of nodes:
  - pwm1
  - lcdif
  - mipi_dsi
- Add a newline between properties and child node (mipi_dsi_out).
- Sort the iomuxc node alphabetically
- Rename pwm1grp to blgrp

Changes in v7:
- Drop [3/4] dt-bindings: display: panel: Add synaptics r63353 panel controller
  because applied.

Changes in v6:
- Drop patches:
  - [06/10] drm/panel: Add Synaptics R63353 panel driver
  - [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  - [08/10] drm/panel: Add Ilitek ILI9805 panel driver
  - [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  Because applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-next)
  Drop patches:
  - [01/10] drm/bridge: Fix bridge disable logic
  - [02/10] drm/bridge: Fix a use case in the bridge disable logic
  Because they are wrong

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma 
TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

 drivers/gpu/drm/bridge/samsung-dsim.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 15bf05b2bbe4..13f181c99d7e 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -96,6 +96,7 @@
 #define DSIM_MFLUSH_VS BIT(29)
 /* This flag is valid only for exynos3250/3472/5260/5430 */
 #define DSIM_CLKLANE_STOP  BIT(30)
+#define DSIM_NON_CONTINUOUS_CLKLANEBIT(31)
 
 /* DSIM_ESCMODE */
 #define DSIM_TX_TRIGGER_RSTBIT(4)
@@ -945,8 +946,12 @@ static int samsung_dsim_init_link(struct samsung_dsim *dsi)
 * power consumption.
 */
if (driver_data->has_clklane_stop &&
-   dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
+   dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
+   if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type))
+   reg |= DSIM_NON_CONTINUOUS_CLKLANE;
+
reg |= DSIM_CLKLANE_STOP;
+   }
samsung_dsim_write(dsi, DSIM_CONFIG_REG, reg);
 
lanes_mask = BIT(dsi->lanes) - 1;
-- 
2.43.0

[RFC PATCH net-next v5 08/14] memory-provider: dmabuf devmem memory provider

Implement a memory provider that allocates dmabuf devmem in the form of
net_iov.

The provider receives a reference to the struct netdev_dmabuf_binding
via the pool->mp_priv pointer. The driver needs to set this pointer for
the provider in the net_iov.

The provider obtains a reference on the netdev_dmabuf_binding which
guarantees the binding and the underlying mapping remains alive until
the provider is destroyed.

Usage of PP_FLAG_DMA_MAP is required for this memory provide such that
the page_pool can provide the driver with the dma-addrs of the devmem.

Support for PP_FLAG_DMA_SYNC_DEV is omitted for simplicity & p.order !=
0.

Signed-off-by: Willem de Bruijn 
Signed-off-by: Kaiyuan Zhang 
Signed-off-by: Mina Almasry 

---

v2:
- Disable devmem for p.order != 0

v1:
- static_branch check in page_is_page_pool_iov() (Willem & Paolo).
- PP_DEVMEM -> PP_IOV (David).
- Require PP_FLAG_DMA_MAP (Jakub).


memory provider

---
 include/net/netmem.h  | 14 ++
 include/net/page_pool/types.h |  2 +
 net/core/page_pool.c  | 93 +++
 3 files changed, 109 insertions(+)

diff --git a/include/net/netmem.h b/include/net/netmem.h
index 7557aecc0f78..ab3824b7b789 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -97,6 +97,20 @@ static inline bool netmem_is_net_iov(const struct netmem 
*netmem)
 #endif
 }
 
+static inline struct net_iov *netmem_to_net_iov(struct netmem *netmem)
+{
+   if (netmem_is_net_iov(netmem))
+   return (struct net_iov *)((unsigned long)netmem & ~NET_IOV);
+
+   DEBUG_NET_WARN_ON_ONCE(true);
+   return NULL;
+}
+
+static inline struct netmem *net_iov_to_netmem(struct net_iov *niov)
+{
+   return (struct netmem *)((unsigned long)niov | NET_IOV);
+}
+
 static inline struct page *netmem_to_page(struct netmem *netmem)
 {
if (WARN_ON_ONCE(netmem_is_net_iov(netmem)))
diff --git a/include/net/page_pool/types.h b/include/net/page_pool/types.h
index 433ae9ae658b..3ddef7d7ba74 100644
--- a/include/net/page_pool/types.h
+++ b/include/net/page_pool/types.h
@@ -134,6 +134,8 @@ struct memory_provider_ops {
bool (*release_page)(struct page_pool *pool, struct netmem *netmem);
 };
 
+extern const struct memory_provider_ops dmabuf_devmem_ops;
+
 struct page_pool {
struct page_pool_params_fast p;
 
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 173158a3dd61..231840112956 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -20,12 +21,15 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
 #include "page_pool_priv.h"
 
 DEFINE_STATIC_KEY_FALSE(page_pool_mem_providers);
+EXPORT_SYMBOL(page_pool_mem_providers);
 
 #define DEFER_TIME (msecs_to_jiffies(1000))
 #define DEFER_WARN_INTERVAL (60 * HZ)
@@ -175,6 +179,7 @@ static void page_pool_producer_unlock(struct page_pool 
*pool,
 static int page_pool_init(struct page_pool *pool,
  const struct page_pool_params *params)
 {
+   struct netdev_dmabuf_binding *binding = NULL;
unsigned int ring_qsize = 1024; /* Default */
int err;
 
@@ -237,6 +242,14 @@ static int page_pool_init(struct page_pool *pool,
/* Driver calling page_pool_create() also call page_pool_destroy() */
refcount_set(&pool->user_cnt, 1);
 
+   if (pool->p.queue)
+   binding = READ_ONCE(pool->p.queue->binding);
+
+   if (binding) {
+   pool->mp_ops = &dmabuf_devmem_ops;
+   pool->mp_priv = binding;
+   }
+
if (pool->mp_ops) {
err = pool->mp_ops->init(pool);
if (err) {
@@ -1055,3 +1068,83 @@ void page_pool_update_nid(struct page_pool *pool, int 
new_nid)
}
 }
 EXPORT_SYMBOL(page_pool_update_nid);
+
+/*** "Dmabuf devmem memory provider" ***/
+
+static int mp_dmabuf_devmem_init(struct page_pool *pool)
+{
+   struct netdev_dmabuf_binding *binding = pool->mp_priv;
+
+   if (!binding)
+   return -EINVAL;
+
+   if (!(pool->p.flags & PP_FLAG_DMA_MAP))
+   return -EOPNOTSUPP;
+
+   if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
+   return -EOPNOTSUPP;
+
+   if (pool->p.order != 0)
+   return -E2BIG;
+
+   netdev_dmabuf_binding_get(binding);
+   return 0;
+}
+
+static struct netmem *mp_dmabuf_devmem_alloc_pages(struct page_pool *pool,
+  gfp_t gfp)
+{
+   struct netdev_dmabuf_binding *binding = pool->mp_priv;
+   struct netmem *netmem;
+   struct net_iov *niov;
+   dma_addr_t dma_addr;
+
+   niov = netdev_alloc_dmabuf(binding);
+   if (!niov)
+   return NULL;
+
+   dma_addr = net_iov_dma_addr(niov);
+
+   netmem = net_iov_to_netmem(niov);
+
+   page_pool_set_pp_info(pool, netmem);
+
+   if (page_pool_set_dma_addr_netmem(netmem, dma_addr))
+   goto err_fre

Re: [PATCH v2 1/2] drm/bridge: Fix improper bridge init order with pre_enable_prev_first

2023-12-18 Thread Jagan Teki

On Sun, Nov 26, 2023 at 9:41 PM Jagan Teki  wrote:
>
> On Mon, Nov 13, 2023 at 6:45 PM Jagan Teki  wrote:
> >
> > On Tue, Aug 1, 2023 at 11:50 AM Dave Stevenson
> >  wrote:
> > >
> > > Hi Jagan
> > >
> > > My apologies for dropping the ball on this one, and thanks to Frieder
> > > for the nudge.
> > >
> > > On Wed, 12 Apr 2023 at 07:25, Jagan Teki  
> > > wrote:
> > > >
> > > > Hi Dave,
> > > >
> > > > Added Maxime, Laurent [which I thought I added before]
> > > >
> > > > On Tue, Mar 28, 2023 at 10:38 PM Jagan Teki 
> > > >  wrote:
> > > > >
> > > > > For a given bridge pipeline if any bridge sets pre_enable_prev_first
> > > > > flag then the pre_enable for the previous bridge will be called before
> > > > > pre_enable of this bridge and opposite is done for post_disable.
> > > > >
> > > > > These are the potential bridge flags to alter bridge init order in 
> > > > > order
> > > > > to satisfy the MIPI DSI host and downstream panel or bridge to 
> > > > > function.
> > > > > However the existing pre_enable_prev_first logic with associated 
> > > > > bridge
> > > > > ordering has broken for both pre_enable and post_disable calls.
> > > > >
> > > > > [pre_enable]
> > > > >
> > > > > The altered bridge ordering has failed if two consecutive bridges on a
> > > > > given pipeline enables the pre_enable_prev_first flag.
> > > > >
> > > > > Example:
> > > > > - Panel
> > > > > - Bridge 1
> > > > > - Bridge 2 pre_enable_prev_first
> > > > > - Bridge 3
> > > > > - Bridge 4 pre_enable_prev_first
> > > > > - Bridge 5 pre_enable_prev_first
> > > > > - Bridge 6
> > > > > - Encoder
> > > > >
> > > > > In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first.
> > > > >
> > > > > The logic looks for a bridge which enabled pre_enable_prev_first flag
> > > > > on each iteration and assigned the previou bridge to limit pointer
> > > > > if the bridge doesn't enable pre_enable_prev_first flags.
> > > > >
> > > > > If control found Bridge 2 is pre_enable_prev_first then the iteration
> > > > > looks for Bridge 3 and found it is not pre_enable_prev_first and 
> > > > > assigns
> > > > > it's previous Bridge 4 to limit pointer and calls pre_enable of 
> > > > > Bridge 3
> > > > > and Bridge 2 and assign iter pointer with limit which is Bridge 4.
> > > > >
> > > > > Here is the actual problem, for the next iteration control look for
> > > > > Bridge 5 instead of Bridge 4 has iter pointer in previous iteration
> > > > > moved to Bridge 4 so this iteration skips the Bridge 4. The iteration
> > > > > found Bridge 6 doesn't pre_enable_prev_first flags so the limit 
> > > > > assigned
> > > > > to Encoder. From next iteration Encoder skips as it is the last bridge
> > > > > for reverse order pipeline.
> > > > >
> > > > > So, the resulting pre_enable bridge order would be,
> > > > > - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5.
> > > > >
> > > > > This patch fixes this by assigning limit to next pointer instead of
> > > > > previous bridge since the iteration always looks for bridge that does
> > > > > NOT request prev so assigning next makes sure the last bridge on a
> > > > > given iteration what exactly the limit bridge is.
> > > > >
> > > > > So, the resulting pre_enable bridge order with fix would be,
> > > > > - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4,
> > > > >   Encoder.
> > > > >
> > > > > [post_disable]
> > > > >
> > > > > The altered bridge ordering has failed if two consecutive bridges on a
> > > > > given pipeline enables the pre_enable_prev_first flag.
> > > > >
> > > > > Example:
> > > > > - Panel
> > > > > - Bridge 1
> > > > > - Bridge 2 pre_enable_prev_first
> > > > > - Bridge 3
> > > > > - Bridge 4 pre_enable_prev_first
> > > > > - Bridge 5 pre_enable_prev_first
> > > > > - Bridge 6
> > > > > - Encoder
> > > > >
> > > > > In this example Bridge 5 and Bridge 4 have pre_enable_prev_first.
> > > > >
> > > > > The logic looks for a bridge which enabled pre_enable_prev_first flags
> > > > > on each iteration and assigned the previou bridge to next and next to
> > > > > limit pointer if the bridge does enable pre_enable_prev_first flag.
> > > > >
> > > > > If control starts from Bridge 6 then it found next Bridge 5 is
> > > > > pre_enable_prev_first and immediately the next assigned to previous
> > > > > Bridge 6 and limit assignments to next Bridge 6 and call post_enable
> > > > > of Bridge 6 even though the next consecutive Bridge 5 is enabled with
> > > > > pre_enable_prev_first. This clearly misses the logic to find the state
> > > > > of next conducive bridge as everytime the next and limit assigns
> > > > > previous bridge if given bridge enabled pre_enable_prev_first.
> > > > >
> > > > > So, the resulting post_disable bridge order would be,
> > > > > - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1,
> > > > >   Panel.
> > > > >
> > > > > This patch fixes this by assigning next with previou bridge only if 
> > > > > the
> > > > > bridge doesn't enab

[RFC PATCH net-next v5 00/14] Device Memory TCP

Major changes in RFC v5:

1. Rebased on top of 'Abstract page from net stack' series and used the
new netmem type to refer to LSB set pointers instead of re-using
struct page.

2. Downgraded this series back to RFC and called it RFC v5. This is
because this series is now dependent on 'Abstract page from net
stack'[1] and the queue API. Both are removed from the series to
pre-requisite work.

3. Reworked the page_pool devmem support to use netmem and for some
more unified handling.

4. Reworked the reference counting of net_iov (renamed from
page_pool_iov) to use pp_ref_count for refcounting.

The full changes including the dependent series and GVE page pool
support is here:

https://github.com/mina/linux/commits/tcpdevmem-rfcv5/

[1] https://patchwork.kernel.org/project/netdevbpf/list/?series=810774

Major changes in v1:

1. Implemented MVP queue API ndos to remove the userspace-visible
driver reset.

2. Fixed issues in the napi_pp_put_page() devmem frag unref path.

3. Removed RFC tag.

Many smaller addressed comments across all the patches (patches have
individual change log).

Full tree including the rest of the GVE driver changes:
https://github.com/mina/linux/commits/tcpdevmem-v1

Changes in RFC v3:
--

1. Pulled in the memory-provider dependency from Jakub's RFC[1] to make the
series reviewable and mergable.

2. Implemented multi-rx-queue binding which was a todo in v2.

3. Fix to cmsg handling.

The sticking point in RFC v2[2] was the device reset required to refill
the device rx-queues after the dmabuf bind/unbind. The solution
suggested as I understand is a subset of the per-queue management ops
Jakub suggested or similar:

https://lore.kernel.org/netdev/20230815171638.4c057...@kernel.org/

This is not addressed in this revision, because:

1. This point was discussed at netconf & netdev and there is openness to
using the current approach of requiring a device reset.

2. Implementing individual queue resetting seems to be difficult for my
test bed with GVE. My prototype to test this ran into issues with the
rx-queues not coming back up properly if reset individually. At the
moment I'm unsure if it's a mistake in the POC or a genuine issue in
the virtualization stack behind GVE, which currently doesn't test
individual rx-queue restart.

3. Our usecases are not bothered by requiring a device reset to refill
the buffer queues, and we'd like to support NICs that run into this
limitation with resetting individual queues.

My thought is that drivers that have trouble with per-queue configs can
use the support in this series, while drivers that support new netdev
ops to reset individual queues can automatically reset the queue as
part of the dma-buf bind/unbind.

The same approach with device resets is presented again for consideration
with other sticking points addressed.

This proposal includes the rx devmem path only proposed for merge. For a
snapshot of my entire tree which includes the GVE POC page pool support &
device memory support:

https://github.com/torvalds/linux/compare/master...mina:linux:tcpdevmem-v3

[1]
https://lore.kernel.org/netdev/f8270765-a27b-6ccf-33ea-cda097168...@redhat.com/T/
[2]
https://lore.kernel.org/netdev/cahs8izovjgjh5wf68osrwfkjid1_huzzuk+hpkblcl4psod...@mail.gmail.com/T/

Changes in RFC v2:
--

The sticking point in RFC v1[1] was the dma-buf pages approach we used to
deliver the device memory to the TCP stack. RFC v2 is a proof-of-concept
that attempts to resolve this by implementing scatterlist support in the
networking stack, such that we can import the dma-buf scatterlist
directly. This is the approach proposed at a high level here[2].

Detailed changes:
1. Replaced dma-buf pages approach with importing scatterlist into the
page pool.
2. Replace the dma-buf pages centric API with a netlink API.
3. Removed the TX path implementation - there is no issue with
implementing the TX path with scatterlist approach, but leaving
out the TX path makes it easier to review.
4. Functionality is tested with this proposal, but I have not conducted
perf testing yet. I'm not sure there are regressions, but I removed
perf claims from the cover letter until they can be re-confirmed.
5. Added Signed-off-by: contributors to the implementation.
6. Fixed some bugs with the RX path since RFC v1.

Any feedback welcome, but specifically the biggest pending questions
needing feedback IMO are:

1. Feedback on the scatterlist-based approach in general.
2. Netlink API (Patch 1 & 2).
3. Approach to handle all the drivers that expect to receive pages from
the page pool (Patch 6).

[1]
https://lore.kernel.org/netdev/dfe4bae7-13a0-3c5d-d671-f61b375cb...@gmail.com/T/
[2]
https://lore.kernel.org/netdev/CAHS8izPm6XRS54LdCDZVd0C75tA1zHSu6jLVO8nzTLXCc=h...@mail.gmail.com/

* TL;DR:

Device memory TCP (devmem TCP) is a proposal for transf

Re: [PATCH v2 1/2] drm/bridge: Fix improper bridge init order with pre_enable_prev_first

2023-12-18 Thread Michael Nazzareno Trimarchi

On Mon, Dec 18, 2023 at 11:28 AM Jagan Teki  wrote:
>
> On Sun, Nov 26, 2023 at 9:41 PM Jagan Teki  wrote:
> >
> > On Mon, Nov 13, 2023 at 6:45 PM Jagan Teki  
> > wrote:
> > >
> > > On Tue, Aug 1, 2023 at 11:50 AM Dave Stevenson
> > >  wrote:
> > > >
> > > > Hi Jagan
> > > >
> > > > My apologies for dropping the ball on this one, and thanks to Frieder
> > > > for the nudge.
> > > >
> > > > On Wed, 12 Apr 2023 at 07:25, Jagan Teki  
> > > > wrote:
> > > > >
> > > > > Hi Dave,
> > > > >
> > > > > Added Maxime, Laurent [which I thought I added before]
> > > > >
> > > > > On Tue, Mar 28, 2023 at 10:38 PM Jagan Teki 
> > > > >  wrote:
> > > > > >
> > > > > > For a given bridge pipeline if any bridge sets pre_enable_prev_first
> > > > > > flag then the pre_enable for the previous bridge will be called 
> > > > > > before
> > > > > > pre_enable of this bridge and opposite is done for post_disable.
> > > > > >
> > > > > > These are the potential bridge flags to alter bridge init order in 
> > > > > > order
> > > > > > to satisfy the MIPI DSI host and downstream panel or bridge to 
> > > > > > function.
> > > > > > However the existing pre_enable_prev_first logic with associated 
> > > > > > bridge
> > > > > > ordering has broken for both pre_enable and post_disable calls.
> > > > > >
> > > > > > [pre_enable]
> > > > > >
> > > > > > The altered bridge ordering has failed if two consecutive bridges 
> > > > > > on a
> > > > > > given pipeline enables the pre_enable_prev_first flag.
> > > > > >
> > > > > > Example:
> > > > > > - Panel
> > > > > > - Bridge 1
> > > > > > - Bridge 2 pre_enable_prev_first
> > > > > > - Bridge 3
> > > > > > - Bridge 4 pre_enable_prev_first
> > > > > > - Bridge 5 pre_enable_prev_first
> > > > > > - Bridge 6
> > > > > > - Encoder
> > > > > >
> > > > > > In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first.
> > > > > >
> > > > > > The logic looks for a bridge which enabled pre_enable_prev_first 
> > > > > > flag
> > > > > > on each iteration and assigned the previou bridge to limit pointer
> > > > > > if the bridge doesn't enable pre_enable_prev_first flags.
> > > > > >
> > > > > > If control found Bridge 2 is pre_enable_prev_first then the 
> > > > > > iteration
> > > > > > looks for Bridge 3 and found it is not pre_enable_prev_first and 
> > > > > > assigns
> > > > > > it's previous Bridge 4 to limit pointer and calls pre_enable of 
> > > > > > Bridge 3
> > > > > > and Bridge 2 and assign iter pointer with limit which is Bridge 4.
> > > > > >
> > > > > > Here is the actual problem, for the next iteration control look for
> > > > > > Bridge 5 instead of Bridge 4 has iter pointer in previous iteration
> > > > > > moved to Bridge 4 so this iteration skips the Bridge 4. The 
> > > > > > iteration
> > > > > > found Bridge 6 doesn't pre_enable_prev_first flags so the limit 
> > > > > > assigned
> > > > > > to Encoder. From next iteration Encoder skips as it is the last 
> > > > > > bridge
> > > > > > for reverse order pipeline.
> > > > > >
> > > > > > So, the resulting pre_enable bridge order would be,
> > > > > > - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5.
> > > > > >
> > > > > > This patch fixes this by assigning limit to next pointer instead of
> > > > > > previous bridge since the iteration always looks for bridge that 
> > > > > > does
> > > > > > NOT request prev so assigning next makes sure the last bridge on a
> > > > > > given iteration what exactly the limit bridge is.
> > > > > >
> > > > > > So, the resulting pre_enable bridge order with fix would be,
> > > > > > - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4,
> > > > > >   Encoder.
> > > > > >
> > > > > > [post_disable]
> > > > > >
> > > > > > The altered bridge ordering has failed if two consecutive bridges 
> > > > > > on a
> > > > > > given pipeline enables the pre_enable_prev_first flag.
> > > > > >
> > > > > > Example:
> > > > > > - Panel
> > > > > > - Bridge 1
> > > > > > - Bridge 2 pre_enable_prev_first
> > > > > > - Bridge 3
> > > > > > - Bridge 4 pre_enable_prev_first
> > > > > > - Bridge 5 pre_enable_prev_first
> > > > > > - Bridge 6
> > > > > > - Encoder
> > > > > >
> > > > > > In this example Bridge 5 and Bridge 4 have pre_enable_prev_first.
> > > > > >
> > > > > > The logic looks for a bridge which enabled pre_enable_prev_first 
> > > > > > flags
> > > > > > on each iteration and assigned the previou bridge to next and next 
> > > > > > to
> > > > > > limit pointer if the bridge does enable pre_enable_prev_first flag.
> > > > > >
> > > > > > If control starts from Bridge 6 then it found next Bridge 5 is
> > > > > > pre_enable_prev_first and immediately the next assigned to previous
> > > > > > Bridge 6 and limit assignments to next Bridge 6 and call post_enable
> > > > > > of Bridge 6 even though the next consecutive Bridge 5 is enabled 
> > > > > > with
> > > > > > pre_enable_prev_first. This clearly misses the logic to find the 
> > > > > > state
> > > > > > of next con

[PATCH 0/5] Pinephone video out fixes (flipping between two frames)

On some pinephones the video output sometimes freezes (flips between two
frames) [1]. It seems to be that the reason for this behaviour is that
PLL-MIPI and PLL-VIDEO0 are operating outside there specified limits.

The changes I propose in this patch series consists of two major parts:
  1. sunxi-ng: Adhere to the following constraints given in the
 Allwinner A64 Manual:
  a. PLL-MIPI:
  * M/N >= 3
  * (PLL_VIDEO0)/M >= 24MHz
  b. PLL-VIDEO0:
  * 8 <= N/M <= 25

  2. Choose a higher clock rate for the ST7703 based XDB599 panel, so
 that the panel functions with the Allwinner A64 SOC. PLL-MIPI
 must run between 500 MHz and 1.4 GHz. As PLL-MIPI runs at 6 times
 the panel's clock rate, we need its clock to be at least 83.333
 MHz.

So far, I've tested the patches only on my pinephone. Before the patches
it would freeze at least every other day. With the patches it has not
shown this behavior in over a week.

I very much appreciate your feedback!

[1] https://gitlab.com/postmarketOS/pmaports/-/issues/805

Signed-off-by: Frank Oltmanns 
---
Frank Oltmanns (5):
  clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate
  clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent 
rate
  clk: sunxi-ng: nm: Support constraints on n/m ratio and parent rate
  clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's n/m ratio
  drm/panel: st7703: Drive XBD599 panel at higher clock rate

 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 ++--
 drivers/clk/sunxi-ng/ccu_nkm.c| 23 ++
 drivers/clk/sunxi-ng/ccu_nkm.h|  8 +++
 drivers/clk/sunxi-ng/ccu_nm.c | 21 +++--
 drivers/clk/sunxi-ng/ccu_nm.h | 34 +--
 drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +--
 6 files changed, 97 insertions(+), 13 deletions(-)
---
base-commit: d0ac5722dae5f4302bb4ef6df10d0afa718df80b
change-id: 20231218-pinephone-pll-fixes-0ccdfde273e4

Best regards,
-- 
Frank Oltmanns

[PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's n/m ratio

The Allwinner A64 manual lists the following constraint for the
PLL-VIDEO0 clock: 8 <= N/M <= 25

Use this constraint.

Signed-off-by: Frank Oltmanns 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index c034ac027d1c..75d839da446c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -68,7 +68,8 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, 
"pll-audio-base",
   BIT(28), /* lock */
   CLK_SET_RATE_UNGATE);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, 
"pll-video0",
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk,
+   "pll-video0",
"osc24M", 0x010,
19200,  /* Minimum rate 
*/
100800, /* Maximum rate 
*/
@@ -80,7 +81,10 @@ static 
SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid
29700,  /* frac rate 1 
*/
BIT(31),/* gate */
BIT(28),/* lock */
-   CLK_SET_RATE_UNGATE);
+   CLK_SET_RATE_UNGATE,
+   CCU_FEATURE_FRACTIONAL |
+   CCU_FEATURE_CLOSEST_RATE,
+   8, 25); /* min/max nm 
ratio */
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
"osc24M", 0x018,

-- 
2.43.0

[PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate

This panel is used in the pinephone that runs on a Allwinner A64 SOC.
Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
than 500 MHz.

Therefore, change [hv]sync_(start|end) so that we reach a clock rate
that is high enough to drive PLL-MIPI within its limits.

Signed-off-by: Frank Oltmanns 
---
 drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b55bafd1a8be..6886fd7f765e 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
 
 static const struct drm_display_mode xbd599_mode = {
.hdisplay= 720,
-   .hsync_start = 720 + 40,
-   .hsync_end   = 720 + 40 + 40,
-   .htotal  = 720 + 40 + 40 + 40,
+   .hsync_start = 720 + 65,
+   .hsync_end   = 720 + 65 + 65,
+   .htotal  = 720 + 65 + 65 + 65,
.vdisplay= 1440,
-   .vsync_start = 1440 + 18,
-   .vsync_end   = 1440 + 18 + 10,
-   .vtotal  = 1440 + 18 + 10 + 17,
-   .clock   = 69000,
+   .vsync_start = 1440 + 30,
+   .vsync_end   = 1440 + 30 + 22,
+   .vtotal  = 1440 + 30 + 22 + 29,
+   .clock   = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
.flags   = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
.width_mm= 68,
.height_mm   = 136,

-- 
2.43.0

[PATCH 3/5] clk: sunxi-ng: nm: Support constraints on n/m ratio and parent rate

The Allwinner A64 manual lists the following constraint for the
PLL-VIDEO0 clock: 8 <= N/M <= 25

The PLL-MIPI clock is implemented as ccu_nm. Therefore, add support for
this constraint.

Signed-off-by: Frank Oltmanns 
---
 drivers/clk/sunxi-ng/ccu_nm.c | 21 +++--
 drivers/clk/sunxi-ng/ccu_nm.h | 34 --
 2 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
index ffac3deb89d6..cfc6981e398b 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.c
+++ b/drivers/clk/sunxi-ng/ccu_nm.c
@@ -27,6 +27,19 @@ static unsigned long ccu_nm_calc_rate(unsigned long parent,
return rate;
 }
 
+static bool ccu_nm_is_valid_rate(struct ccu_common *common, unsigned long n, 
unsigned long m)
+{
+   struct ccu_nm *nm = container_of(common, struct ccu_nm, common);
+
+   if (nm->max_nm_ratio && (n > nm->max_nm_ratio * m))
+   return false;
+
+   if (nm->min_nm_ratio && (n < nm->min_nm_ratio * m))
+   return false;
+
+   return true;
+}
+
 static unsigned long ccu_nm_find_best(struct ccu_common *common, unsigned long 
parent,
  unsigned long rate, struct _ccu_nm *nm)
 {
@@ -36,8 +49,12 @@ static unsigned long ccu_nm_find_best(struct ccu_common 
*common, unsigned long p
 
for (_n = nm->min_n; _n <= nm->max_n; _n++) {
for (_m = nm->min_m; _m <= nm->max_m; _m++) {
-   unsigned long tmp_rate = ccu_nm_calc_rate(parent,
- _n, _m);
+   unsigned long tmp_rate;
+
+   if (!ccu_nm_is_valid_rate(common, _n, _m))
+   continue;
+
+   tmp_rate = ccu_nm_calc_rate(parent, _n, _m);
 
if (ccu_is_better_rate(common, rate, tmp_rate, 
best_rate)) {
best_rate = tmp_rate;
diff --git a/drivers/clk/sunxi-ng/ccu_nm.h b/drivers/clk/sunxi-ng/ccu_nm.h
index 93c11693574f..0075df6d9697 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.h
+++ b/drivers/clk/sunxi-ng/ccu_nm.h
@@ -31,6 +31,8 @@ struct ccu_nm {
unsigned intfixed_post_div;
unsigned intmin_rate;
unsigned intmax_rate;
+   unsigned long   min_nm_ratio; /* minimum value for m/n */
+   unsigned long   max_nm_ratio; /* maximum value for m/n */
 
struct ccu_common   common;
 };
@@ -108,7 +110,8 @@ struct ccu_nm {
},  \
}
 
-#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT(_struct, _name,  \
+#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(
\
+_struct, _name,\
 _parent, _reg, \
 _min_rate, _max_rate,  \
 _nshift, _nwidth,  \
@@ -117,7 +120,9 @@ struct ccu_nm {
 _frac_rate_0,  \
 _frac_rate_1,  \
 _gate, _lock, _flags,  \
-_features) \
+_features, \
+_min_nm_ratio, \
+_max_nm_ratio) \
struct ccu_nm _struct = {   \
.enable = _gate,\
.lock   = _lock,\
@@ -128,6 +133,8 @@ struct ccu_nm {
  _frac_rate_1),\
.min_rate   = _min_rate,\
.max_rate   = _max_rate,\
+   .min_nm_ratio   = _min_nm_ratio,\
+   .max_nm_ratio   = _max_nm_ratio,\
.common = { \
.reg= _reg, \
.features   = _features,\
@@ -138,6 +145,29 @@ struct ccu_nm {
},  \
}
 
+#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT(_struct, _name,  \
+_parent, _reg, \
+_min_rate, _max_rate,  \
+_nshift, _nwidth,  \
+_mshift, _mwidt

[PATCH 2/5] clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent rate

The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
 - M/N >= 3
 - (PLL_VIDEO0)/M >= 24MHz

Use these constraints.

Signed-off-by: Frank Oltmanns 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 8951ffc14ff5..c034ac027d1c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -176,6 +176,8 @@ static struct ccu_nkm pll_mipi_clk = {
.n  = _SUNXI_CCU_MULT(8, 4),
.k  = _SUNXI_CCU_MULT_MIN(4, 2, 2),
.m  = _SUNXI_CCU_DIV(0, 4),
+   .max_mn_ratio   = 3,
+   .parent_wo_nk   = 2400,
.common = {
.reg= 0x040,
.hw.init= CLK_HW_INIT("pll-mipi", "pll-video0",

-- 
2.43.0

[PATCH 1/5] clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate

The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
 - M/N >= 3
 - (PLL_VIDEO0)/M >= 24MHz

The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
these constraints.

Signed-off-by: Frank Oltmanns 
---
 drivers/clk/sunxi-ng/ccu_nkm.c | 23 +++
 drivers/clk/sunxi-ng/ccu_nkm.h |  8 
 2 files changed, 31 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
index eed64547ad42..2af5c1ebd527 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.c
+++ b/drivers/clk/sunxi-ng/ccu_nkm.c
@@ -16,6 +16,20 @@ struct _ccu_nkm {
unsigned long   m, min_m, max_m;
 };
 
+static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long 
parent,
+ unsigned long n, unsigned long m)
+{
+   struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
+
+   if (nkm->max_mn_ratio && (m > nkm->max_mn_ratio * n))
+   return false;
+
+   if (nkm->parent_wo_nk && (parent < nkm->parent_wo_nk * m))
+   return false;
+
+   return true;
+}
+
 static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common 
*common,
   struct clk_hw *parent_hw,
   unsigned long *parent, 
unsigned long rate,
@@ -32,6 +46,9 @@ static unsigned long ccu_nkm_find_best_with_parent_adj(struct 
ccu_common *common
 
tmp_parent = clk_hw_round_rate(parent_hw, rate 
* _m / (_n * _k));
 
+   if (!ccu_nkm_is_valid_rate(common, tmp_parent, 
_n, _m))
+   continue;
+
tmp_rate = tmp_parent * _n * _k / _m;
 
if (ccu_is_better_rate(common, rate, tmp_rate, 
best_rate) ||
@@ -65,6 +82,12 @@ static unsigned long ccu_nkm_find_best(unsigned long parent, 
unsigned long rate,
for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
+   if ((common->reg == 0x040) && (_m > 3 * _n))
+   break;
+
+   if ((common->reg == 0x040) && (parent < 
2400 * _m))
+   continue;
+
unsigned long tmp_rate;
 
tmp_rate = parent * _n * _k / _m;
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
index 6601defb3f38..d3d3eaf55faf 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.h
+++ b/drivers/clk/sunxi-ng/ccu_nkm.h
@@ -16,6 +16,12 @@
  * struct ccu_nkm - Definition of an N-K-M clock
  *
  * Clocks based on the formula parent * N * K / M
+ *
+ * @max_mn_ratio:  Maximum value for M / N.
+ * @parent_wo_nk:  The minimum rate the parent must provide after applying 
the divisor,
+ * but without applying the multipliers, i.e. the 
contstraint
+ *(parent rate)/M >= parent_wo_nk
+ * must be fulfilled.
  */
 struct ccu_nkm {
u32 enable;
@@ -27,6 +33,8 @@ struct ccu_nkm {
struct ccu_mux_internal mux;
 
unsigned intfixed_post_div;
+   unsigned long   max_mn_ratio;
+   unsigned long   parent_wo_nk;
 
struct ccu_common   common;
 };

-- 
2.43.0

Re: [PATCH] drm/vmwgfx: fix all kernel-doc warnings in stdu

2023-12-18 Thread Zack Rusin

On Fri, Dec 15, 2023 at 6:41 PM Randy Dunlap  wrote:
>
> kernel test robot reports one kernel-doc warning in stdu, but
> running scripts/kernel-doc in -Wall mode reports several more,
> so fix all of them at one time:
>
> vmwgfx_stdu.c:76: warning: Excess struct member 'transfer' description in 
> 'vmw_stdu_dirty'
> vmwgfx_stdu.c:103: warning: missing initial short description on line:
>  * struct vmw_screen_target_display_unit
> vmwgfx_stdu.c:215: warning: No description found for return value of 
> 'vmw_stdu_bind_st'
> vmwgfx_stdu.c:320: warning: No description found for return value of 
> 'vmw_stdu_destroy_st'
> vmwgfx_stdu.c:551: warning: No description found for return value of 
> 'vmw_kms_stdu_readback'
> vmwgfx_stdu.c:719: warning: No description found for return value of 
> 'vmw_kms_stdu_surface_dirty'
> vmwgfx_stdu.c:895: warning: No description found for return value of 
> 'vmw_stdu_primary_plane_prepare_fb'
> vmwgfx_stdu.c:1470: warning: No description found for return value of 
> 'vmw_stdu_init'
>
> Signed-off-by: Randy Dunlap 
> Reported-by: kernel test robot 
> Closes: 
> https://lore.kernel.org/oe-kbuild-all/202312150347.5iceznlk-...@intel.com/
> Cc: Zack Rusin 
> Cc: VMware Graphics Reviewers 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> ---

LGTM. Thanks!

Reviewed-by: Zack Rusin 

z

Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers

Conor Dooley  writes:

Hello Connor,

> On Sun, Dec 17, 2023 at 11:00:07PM +0100, Javier Martinez Canillas wrote:
>> Conor Dooley  writes:
>> 
>> Hello Conor,
>> 
>> > On Sun, Dec 17, 2023 at 10:33:24PM +0100, Javier Martinez Canillas wrote:
>> 
>> [...]
>> 
>> >> >> +then:
>> >> >> +  properties:
>> >> >> +width:
>> >> >> +  default: 96
>> >> >> +height:
>> >> >> +  default: 64
>> >> >
>> >> > Do you envisage a rake of devices that are going to end up in this
>> >> > binding? Otherwise, why not unconditionally set the constraints?
>> >> >
>> >> 
>> >> Because these are only for the default width and height, there can be
>> >> panels using the same controller but that have a different resolution.
>> >> 
>> >> For example, there are panels using the SSD1306 controller that have
>> >> 128x32 [0], 64x32 [1] or 128x64 [2] resolutions.
>> >
>> > This, as you know, does not matter here.
>> >
>> 
>> Are you sure? What I tried to say is that the SSD133x are just OLED
>> controllers and manufacturers use those chips to attach a panel that
>> has a certain resolution.
>> 
>> While it makes sense to use all the supported width and height, some
>> manufacturers chose to have a smaller panel instead (I used SSD1306
>> as an example because I knew about these but the same might be true
>> for let's say SSD1331).
>> 
>> Or saying another way, are you sure that every manufacturer selling
>> RGB OLED panels using the SSD1331 chip will use the default resolution
>> and users won't have to set a custom width and height ?
>
> That's not at all what I was saying. I just meant unconditionally set
> the constraints on the property (in this case the default) since you
> only have one compatible. Not unconditionally set the height and width.
>
> Apologies if if that was unclear.
>

Oh, I see that you meant now. Sorry for my confusion!

And yes, I agree with you that doesn't make sense to make it conditional
if there's only a single compatible. I'll drop that if condition on v2.

Thanks a lot for your feedback.

> Thanks,
> Conor.
>
 
-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [RFC PATCH] KVM: Introduce KVM VIRTIO device

2023-12-18 Thread Sean Christopherson

+Yiwei

On Fri, Dec 15, 2023, Kevin Tian wrote:
> > From: Zhao, Yan Y 
> > Sent: Thursday, December 14, 2023 6:35 PM
> > 
> > - For host non-MMIO pages,
> >   * virtio guest frontend and host backend driver should be synced to use
> > the same memory type to map a buffer. Otherwise, there will be
> > potential problem for incorrect memory data. But this will only impact
> > the buggy guest alone.
> >   * for live migration,
> > as QEMU will read all guest memory during live migration, page aliasing
> > could happen.
> > Current thinking is to disable live migration if a virtio device has
> > indicated its noncoherent state.
> > As a follow-up, we can discuss other solutions. e.g.
> > (a) switching back to coherent path before starting live migration.
> 
> both guest/host switching to coherent or host-only?
> 
> host-only certainly is problematic if guest is still using non-coherent.
> 
> on the other hand I'm not sure whether the host/guest gfx stack is
> capable of switching between coherent and non-coherent path in-fly
> when the buffer is right being rendered.
> 
> > (b) read/write of guest memory with clflush during live migration.
> 
> write is irrelevant as it's only done in the resume path where the
> guest is not running.
> 
> > 
> > Implementation Consideration
> > ===
> > There is a previous series [1] from google to serve the same purpose to
> > let KVM be aware of virtio GPU's noncoherent DMA status. That series
> > requires a new memslot flag, and special memslots in user space.
> > 
> > We don't choose to use memslot flag to request honoring guest memory
> > type.
> 
> memslot flag has the potential to restrict the impact e.g. when using
> clflush-before-read in migration?

Yep, exactly.  E.g. if KVM needs to ensure coherency when freeing memory back to
the host kernel, then the memslot flag will allow for a much more targeted
operation.

> Of course the implication is to honor guest type only for the selected slot
> in KVM instead of applying to the entire guest memory as in previous series
> (which selects this way because vmx_get_mt_mask() is in perf-critical path
> hence not good to check memslot flag?)

Checking a memslot flag won't impact performance.  KVM already has the memslot
when creating SPTEs, e.g. the sole caller of vmx_get_mt_mask(), make_spte(), has
access to the memslot.

That isn't coincidental, KVM _must_ have the memslot to construct the SPTE, e.g.
to retrieve the associated PFN, update write-tracking for shadow pages, etc.

I added Yiwei, who I think is planning on posting another RFC for the memslot
idea (I actually completely forgot that the memslot idea had been thought of and
posted a few years back).

> > Instead we hope to make the honoring request to be explicit (not tied to a
> > memslot flag). This is because once guest memory type is honored, not only
> > memory used by guest virtio device, but all guest memory is facing page
> > aliasing issue potentially. KVM needs a generic solution to take care of
> > page aliasing issue rather than counting on memory type of a special
> > memslot being aligned in host and guest.
> > (we can discuss what a generic solution to handle page aliasing issue will
> > look like in later follow-up series).
> > 
> > On the other hand, we choose to introduce a KVM virtio device rather than
> > just provide an ioctl to wrap kvm_arch_[un]register_noncoherent_dma()
> > directly, which is based on considerations that
> 
> I wonder it's over-engineered for the purpose.
> 
> why not just introducing a KVM_CAP and allowing the VMM to enable?
> KVM doesn't need to know the exact source of requiring it...

Agreed.  If we end up needing to grant the whole VM access for some reason, just
give userspace a direct toggle.

[RFC PATCH net-next v5 01/14] net: page_pool: create hooks for custom page providers

From: Jakub Kicinski 

The page providers which try to reuse the same pages will
need to hold onto the ref, even if page gets released from
the pool - as in releasing the page from the pp just transfers
the "ownership" reference from pp to the provider, and provider
will wait for other references to be gone before feeding this
page back into the pool.

Signed-off-by: Jakub Kicinski 
Signed-off-by: Mina Almasry 

---

This is implemented by Jakub in his RFC:
https://lore.kernel.org/netdev/f8270765-a27b-6ccf-33ea-cda097168...@redhat.com/T/

I take no credit for the idea or implementation; I only added minor
edits to make this workable with device memory TCP, and removed some
hacky test code. This is a critical dependency of device memory TCP
and thus I'm pulling it into this series to make it revewable and
mergeable.

RFC v3 -> v1
- Removed unusued mem_provider. (Yunsheng).
- Replaced memory_provider & mp_priv with netdev_rx_queue (Jakub).

---
 include/net/page_pool/types.h | 12 ++
 net/core/page_pool.c  | 43 +++
 2 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/include/net/page_pool/types.h b/include/net/page_pool/types.h
index 76481c465375..4c090e86e550 100644
--- a/include/net/page_pool/types.h
+++ b/include/net/page_pool/types.h
@@ -51,6 +51,7 @@ struct pp_alloc_cache {
  * @dev:   device, for DMA pre-mapping purposes
  * @netdev:netdev this pool will serve (leave as NULL if none or multiple)
  * @napi:  NAPI which is the sole consumer of pages, otherwise NULL
+ * @queue: struct netdev_rx_queue this page_pool is being created for.
  * @dma_dir:   DMA mapping direction
  * @max_len:   max DMA sync memory size for PP_FLAG_DMA_SYNC_DEV
  * @offset:DMA sync address offset for PP_FLAG_DMA_SYNC_DEV
@@ -63,6 +64,7 @@ struct page_pool_params {
int nid;
struct device   *dev;
struct napi_struct *napi;
+   struct netdev_rx_queue *queue;
enum dma_data_direction dma_dir;
unsigned intmax_len;
unsigned intoffset;
@@ -125,6 +127,13 @@ struct page_pool_stats {
 };
 #endif
 
+struct memory_provider_ops {
+   int (*init)(struct page_pool *pool);
+   void (*destroy)(struct page_pool *pool);
+   struct page *(*alloc_pages)(struct page_pool *pool, gfp_t gfp);
+   bool (*release_page)(struct page_pool *pool, struct page *page);
+};
+
 struct page_pool {
struct page_pool_params_fast p;
 
@@ -174,6 +183,9 @@ struct page_pool {
 */
struct ptr_ring ring;
 
+   void *mp_priv;
+   const struct memory_provider_ops *mp_ops;
+
 #ifdef CONFIG_PAGE_POOL_STATS
/* recycle stats are per-cpu to avoid locking */
struct page_pool_recycle_stats __percpu *recycle_stats;
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index dd5a72533f2b..45bb4210412d 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -25,6 +25,8 @@
 
 #include "page_pool_priv.h"
 
+static DEFINE_STATIC_KEY_FALSE(page_pool_mem_providers);
+
 #define DEFER_TIME (msecs_to_jiffies(1000))
 #define DEFER_WARN_INTERVAL (60 * HZ)
 
@@ -174,6 +176,7 @@ static int page_pool_init(struct page_pool *pool,
  const struct page_pool_params *params)
 {
unsigned int ring_qsize = 1024; /* Default */
+   int err;
 
memcpy(&pool->p, ¶ms->fast, sizeof(pool->p));
memcpy(&pool->slow, ¶ms->slow, sizeof(pool->slow));
@@ -234,10 +237,25 @@ static int page_pool_init(struct page_pool *pool,
/* Driver calling page_pool_create() also call page_pool_destroy() */
refcount_set(&pool->user_cnt, 1);
 
+   if (pool->mp_ops) {
+   err = pool->mp_ops->init(pool);
+   if (err) {
+   pr_warn("%s() mem-provider init failed %d\n",
+   __func__, err);
+   goto free_ptr_ring;
+   }
+
+   static_branch_inc(&page_pool_mem_providers);
+   }
+
if (pool->p.flags & PP_FLAG_DMA_MAP)
get_device(pool->p.dev);
 
return 0;
+
+free_ptr_ring:
+   ptr_ring_cleanup(&pool->ring, NULL);
+   return err;
 }
 
 static void page_pool_uninit(struct page_pool *pool)
@@ -519,7 +537,10 @@ struct page *page_pool_alloc_pages(struct page_pool *pool, 
gfp_t gfp)
return page;
 
/* Slow-path: cache empty, do real allocation */
-   page = __page_pool_alloc_pages_slow(pool, gfp);
+   if (static_branch_unlikely(&page_pool_mem_providers) && pool->mp_ops)
+   page = pool->mp_ops->alloc_pages(pool, gfp);
+   else
+   page = __page_pool_alloc_pages_slow(pool, gfp);
return page;
 }
 EXPORT_SYMBOL(page_pool_alloc_pages);
@@ -576,10 +597,13 @@ void __page_pool_release_page_dma(struct page_pool *pool, 
struct page *page)
 void page_pool_return_page(struct page_pool *pool, struct

Re: [PATCH v2] drm/mediatek: dp: Add phy_mtk_dp module as pre-dependency

2023-12-18 Thread Chun-Kuang Hu

Hi, Nicolas:

Nícolas F. R. A. Prado  於 2023年11月21日 週二 下午10:29寫道：
>
> The mtk_dp driver registers a phy device which is handled by the
> phy_mtk_dp driver and assumes that the phy probe will complete
> synchronously, proceeding to make use of functionality exposed by that
> driver right away. This assumption however is false when the phy driver
> is built as a module, causing the mtk_dp driver to fail probe in this
> case.
>
> Add the phy_mtk_dp module as a pre-dependency to the mtk_dp module to
> ensure the phy module has been loaded before the dp, so that the phy
> probe happens synchrounously and the mtk_dp driver can probe
> successfully even with the phy driver built as a module.

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Suggested-by: AngeloGioacchino Del Regno 
> 
> Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
> Signed-off-by: Nícolas F. R. A. Prado 
> Reviewed-by: AngeloGioacchino Del Regno 
> 
>
> ---
>
> Changes in v2:
> - Added missing Suggested-by tag
>
>  drivers/gpu/drm/mediatek/mtk_dp.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
> b/drivers/gpu/drm/mediatek/mtk_dp.c
> index e4c16ba9902d..2136a596efa1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -2818,3 +2818,4 @@ MODULE_AUTHOR("Markus Schneider-Pargmann 
> ");
>  MODULE_AUTHOR("Bo-Chen Chen ");
>  MODULE_DESCRIPTION("MediaTek DisplayPort Driver");
>  MODULE_LICENSE("GPL");
> +MODULE_SOFTDEP("pre: phy_mtk_dp");
> --
> 2.42.1
>

[RFC PATCH net-next v5 07/14] page_pool: devmem support

Convert netmem to be a union of struct page and struct netmem. Overload
the LSB of struct netmem* to indicate that it's a net_iov, otherwise
it's a page.

Currently these entries in struct page are rented by the page_pool and
used exclusively by the net stack:

struct {
unsigned long pp_magic;
struct page_pool *pp;
unsigned long _pp_mapping_pad;
unsigned long dma_addr;
atomic_long_t pp_ref_count;
};

Mirror these (and only these) entries into struct net_iov and implement
netmem helpers that can access these common fields regardless of
whether the underlying type is page or net_iov.

Implement checks for net_iov in netmem helpers which delegate to mm
APIs, to ensure net_iov are never passed to the mm stack.

Signed-off-by: Mina Almasry 

---

RFCv5:
- Use netmem instead of page* with LSB set.
- Use pp_ref_count for refcounting net_iov.
- Removed many of the custom checks for netmem.

v1:
- Disable fragmentation support for iov properly.
- fix napi_pp_put_page() path (Yunsheng).
- Use pp_frag_count for devmem refcounting.

---
 include/net/netmem.h| 145 ++--
 include/net/page_pool/helpers.h |  25 +++---
 net/core/page_pool.c|  26 +++---
 net/core/skbuff.c   |   9 +-
 4 files changed, 164 insertions(+), 41 deletions(-)

diff --git a/include/net/netmem.h b/include/net/netmem.h
index 31f338f19da0..7557aecc0f78 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -12,11 +12,47 @@
 
 /* net_iov */
 
+DECLARE_STATIC_KEY_FALSE(page_pool_mem_providers);
+
+/*  We overload the LSB of the struct page pointer to indicate whether it's
+ *  a page or net_iov.
+ */
+#define NET_IOV 0x01UL
+
 struct net_iov {
+   unsigned long __unused_padding;
+   unsigned long pp_magic;
+   struct page_pool *pp;
struct dmabuf_genpool_chunk_owner *owner;
unsigned long dma_addr;
+   atomic_long_t pp_ref_count;
 };
 
+/* These fields in struct page are used by the page_pool and net stack:
+ *
+ * struct {
+ * unsigned long pp_magic;
+ * struct page_pool *pp;
+ * unsigned long _pp_mapping_pad;
+ * unsigned long dma_addr;
+ * atomic_long_t pp_ref_count;
+ * };
+ *
+ * We mirror the page_pool fields here so the page_pool can access these fields
+ * without worrying whether the underlying fields belong to a page or net_iov.
+ *
+ * The non-net stack fields of struct page are private to the mm stack and must
+ * never be mirrored to net_iov.
+ */
+#define NET_IOV_ASSERT_OFFSET(pg, iov) \
+   static_assert(offsetof(struct page, pg) == \
+ offsetof(struct net_iov, iov))
+NET_IOV_ASSERT_OFFSET(pp_magic, pp_magic);
+NET_IOV_ASSERT_OFFSET(pp, pp);
+NET_IOV_ASSERT_OFFSET(dma_addr, dma_addr);
+NET_IOV_ASSERT_OFFSET(pp_ref_count, pp_ref_count);
+#undef NET_IOV_ASSERT_OFFSET
+
 static inline struct dmabuf_genpool_chunk_owner *
 net_iov_owner(const struct net_iov *niov)
 {
@@ -47,19 +83,25 @@ net_iov_binding(const struct net_iov *niov)
 struct netmem {
union {
struct page page;
-
-   /* Stub to prevent compiler implicitly converting from page*
-* to netmem_t* and vice versa.
-*
-* Other memory type(s) net stack would like to support
-* can be added to this union.
-*/
-   void *addr;
+   struct net_iov niov;
};
 };
 
+static inline bool netmem_is_net_iov(const struct netmem *netmem)
+{
+#ifdef CONFIG_PAGE_POOL
+   return static_branch_unlikely(&page_pool_mem_providers) &&
+  (unsigned long)netmem & NET_IOV;
+#else
+   return false;
+#endif
+}
+
 static inline struct page *netmem_to_page(struct netmem *netmem)
 {
+   if (WARN_ON_ONCE(netmem_is_net_iov(netmem)))
+   return NULL;
+
return &netmem->page;
 }
 
@@ -70,17 +112,104 @@ static inline struct netmem *page_to_netmem(struct page 
*page)
 
 static inline int netmem_ref_count(struct netmem *netmem)
 {
+   /* The non-pp refcount of netmem is always 1. On netmem, we only support
+* pp refcounting.
+*/
+   if (netmem_is_net_iov(netmem))
+   return 1;
+
return page_ref_count(netmem_to_page(netmem));
 }
 
 static inline unsigned long netmem_to_pfn(struct netmem *netmem)
 {
+   if (netmem_is_net_iov(netmem))
+   return 0;
+
return page_to_pfn(netmem_to_page(netmem));
 }
 
+static inline struct net_iov *__netmem_clear_lsb(struct netmem *netmem)
+{
+   return (struct net_iov *)((unsigned long)netmem & ~NET_IOV);
+}
+
+static inline unsigned long netmem_get_pp_magic(struct netmem *netmem)
+{
+   return __netmem_clear_lsb(netmem)->pp_magic;
+}
+
+static inline void netmem_or_pp_magic(struct netmem *netmem,
+ unsigned long pp_magic)
+{
+   __netmem_clear_lsb(netmem)->

Re: [PATCH] drm/bridge: properly refcount DT nodes in aux bridge drivers

2023-12-18 Thread Neil Armstrong


On 17/12/2023 00:59, Dmitry Baryshkov wrote:

The aux-bridge and aux-hpd-bridge drivers didn't call of_node_get() on
the device nodes further used for dev->of_node and platform data. When
bridge devices are released, the reference counts are decreased,
resulting in refcount underflow / use-after-free warnings. Get
corresponding refcounts during AUX bridge allocation.

Reported-by: Luca Weiss 
Fixes: 2a04739139b2 ("drm/bridge: add transparent bridge helper")
Fixes: 26f4bac3d884 ("drm/bridge: aux-hpd: Replace of_device.h with explicit 
include")
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/bridge/aux-bridge.c | 2 +-
  drivers/gpu/drm/bridge/aux-hpd-bridge.c | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/aux-bridge.c 
b/drivers/gpu/drm/bridge/aux-bridge.c
index 49d7c2ab1ecc..54d721db0ea6 100644
--- a/drivers/gpu/drm/bridge/aux-bridge.c
+++ b/drivers/gpu/drm/bridge/aux-bridge.c
@@ -57,7 +57,7 @@ int drm_aux_bridge_register(struct device *parent)
adev->id = ret;
adev->name = "aux_bridge";
adev->dev.parent = parent;
-   adev->dev.of_node = parent->of_node;
+   adev->dev.of_node = of_node_get(parent->of_node);
adev->dev.release = drm_aux_bridge_release;
  
  	ret = auxiliary_device_init(adev);

diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c 
b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
index 1999a053d59b..bb55f697a181 100644
--- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
@@ -68,9 +68,9 @@ struct device *drm_dp_hpd_bridge_register(struct device 
*parent,
adev->id = ret;
adev->name = "dp_hpd_bridge";
adev->dev.parent = parent;
-   adev->dev.of_node = parent->of_node;
+   adev->dev.of_node = of_node_get(parent->of_node);
adev->dev.release = drm_aux_hpd_bridge_release;
-   adev->dev.platform_data = np;
+   adev->dev.platform_data = of_node_get(np);
  
  	ret = auxiliary_device_init(adev);

if (ret) {


Reviewed-by: Neil Armstrong

[PATCH AUTOSEL 4.14 3/6] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc

From: Ziqi Zhao 

[ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]

The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.

Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao 
Reported-and-tested-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Tested-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20230721161446.8602-1-astraj...@yahoo.com
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5af25ce5bf7c2..5ae3adfbc5e80 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -556,8 +556,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
-   int ret;
-   int i;
+   int ret, i, num_connectors;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -672,6 +671,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
 
+   num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned 
long)crtc_req->set_connectors_ptr;
@@ -692,6 +692,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
 
connector_set[i] = connector;
+   num_connectors++;
}
}
 
@@ -700,7 +701,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
-   set.num_connectors = crtc_req->count_connectors;
+   set.num_connectors = num_connectors;
set.fb = fb;
ret = __drm_mode_set_config_internal(&set, &ctx);
 
@@ -709,7 +710,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
 
if (connector_set) {
-   for (i = 0; i < crtc_req->count_connectors; i++) {
+   for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
-- 
2.43.0

[PATCH AUTOSEL 4.19 3/6] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc

From: Ziqi Zhao 

[ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]

The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.

Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao 
Reported-and-tested-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Tested-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20230721161446.8602-1-astraj...@yahoo.com
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6e241a3c31ee3..52a1bfeef0d9c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -573,8 +573,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
-   int ret;
-   int i;
+   int ret, i, num_connectors;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -719,6 +718,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
 
+   num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned 
long)crtc_req->set_connectors_ptr;
@@ -739,6 +739,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
 
connector_set[i] = connector;
+   num_connectors++;
}
}
 
@@ -747,7 +748,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
-   set.num_connectors = crtc_req->count_connectors;
+   set.num_connectors = num_connectors;
set.fb = fb;
 
if (drm_drv_uses_atomic_modeset(dev))
@@ -760,7 +761,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
 
if (connector_set) {
-   for (i = 0; i < crtc_req->count_connectors; i++) {
+   for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
-- 
2.43.0

[PATCH AUTOSEL 5.15 03/13] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc

From: Ziqi Zhao 

[ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]

The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.

Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao 
Reported-and-tested-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Tested-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20230721161446.8602-1-astraj...@yahoo.com
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 26a77a7359056..8b50ab4c55812 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -643,8 +643,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
-   int ret;
-   int i;
+   int ret, i, num_connectors;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -779,6 +778,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
 
+   num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned 
long)crtc_req->set_connectors_ptr;
@@ -799,6 +799,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
 
connector_set[i] = connector;
+   num_connectors++;
}
}
 
@@ -807,7 +808,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
-   set.num_connectors = crtc_req->count_connectors;
+   set.num_connectors = num_connectors;
set.fb = fb;
 
if (drm_drv_uses_atomic_modeset(dev))
@@ -820,7 +821,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
 
if (connector_set) {
-   for (i = 0; i < crtc_req->count_connectors; i++) {
+   for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
-- 
2.43.0

[PATCH AUTOSEL 5.10 3/8] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc

From: Ziqi Zhao 

[ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]

The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.

Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao 
Reported-and-tested-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Tested-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20230721161446.8602-1-astraj...@yahoo.com
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index aecdd7ea26dc8..b3c0a9ea8c6f8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -562,8 +562,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
-   int ret;
-   int i;
+   int ret, i, num_connectors;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -701,6 +700,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
 
+   num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned 
long)crtc_req->set_connectors_ptr;
@@ -721,6 +721,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
 
connector_set[i] = connector;
+   num_connectors++;
}
}
 
@@ -729,7 +730,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
-   set.num_connectors = crtc_req->count_connectors;
+   set.num_connectors = num_connectors;
set.fb = fb;
 
if (drm_drv_uses_atomic_modeset(dev))
@@ -742,7 +743,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
 
if (connector_set) {
-   for (i = 0; i < crtc_req->count_connectors; i++) {
+   for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
-- 
2.43.0

[PATCH] drm/bridge: Fixed a DP link training bug

2023-12-18 Thread xiazhengqiao

To have better compatibility for DP sink, there is a retry mechanism
for the link training process to switch between different training process.
The original driver code doesn't reset the retry counter when training
state is pass. If the system triggers link training over 3 times,
there will be a chance to causes the driver to use the wrong training
method and return a training fail result.

To Fix this, we reset the retry counter when training state is pass
each time.

Signed-off-by: Allen Chen 
Signed-off-by: xiazhengqiao 
---
 drivers/gpu/drm/bridge/ite-it6505.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index 2f300f5ca051..b589136ca6da 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2240,11 +2240,13 @@ static void it6505_link_training_work(struct 
work_struct *work)
ret = it6505_link_start_auto_train(it6505);
DRM_DEV_DEBUG_DRIVER(dev, "auto train %s, auto_train_retry: %d",
 ret ? "pass" : "failed", it6505->auto_train_retry);
-   it6505->auto_train_retry--;
 
if (ret) {
+   it6505->auto_train_retry = AUTO_TRAIN_RETRY;
it6505_link_train_ok(it6505);
return;
+   } else {
+   it6505->auto_train_retry--;
}
 
it6505_dump(it6505);
-- 
2.17.1

Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers

Krzysztof Kozlowski  writes:

Hello Krzysztof,

> On 17/12/2023 11:07, Javier Martinez Canillas wrote:
>>> +  - if:
>> +  properties:
>> +compatible:
>> +  contains:
>> +const: solomon,ssd1331
>> +then:
>> +  properties:
>> +width:
>> +  default: 96
>> +height:
>> +  default: 64
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +i2c {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>
> Use 4 spaces for example indentation.
>

Sure, I'll change it in v2.

> Best regards,
> Krzysztof
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PULL] drm-xe-next

2023-12-18 Thread Oded Gabbay

On Fri, Dec 15, 2023 at 05:28:19PM -0500, Rodrigo Vivi wrote:
> Hi Dave and Sima,
> 
> Here goes the first pull request for the drm/xe driver.
> 
> Our team was focused on putting together a driver that uses most, if not all,
> of the key drm concepts and has a functional display that is shared with i915.
> All the platforms are still protected by the force_probe protection because 
> they
> are either officially supported by i915, or because they are still under
> enablement like Lunar Lake.
> 
> We still have a lot of work ahead of us, but we believe that it will be better
> to work with all of these cross-driver concepts after we are merged to 
> drm-next
> along with the other drivers.
> 
> Besides the cross-driver collaboration and enabling of upcoming hardware, one 
> of
> our key areas will be to improve performance and address reports by users so 
> that
> the driver keeps getting better.
> 
> I’m having the honor to send this first pull request on behalf of the new 
> team of
> maintainers that we are putting together for the xe driver: Lucas, Thomas, and
> Oded. I’m going to assist them to get this through and to set up the drm-tip
> development flow. Then, you should expect future pull requests coming directly
> from them. Likely, with a rotation of duties that they will define by 
> themselves,
> but that should be similar to drm-intel and drm-misc.
> 
> Thanks,
> Rodrigo.
Hi Rodrigo,
You and the team did a great job on bringing the driver to this stage. Congrats!

I reviewed a large part of the driver, mainly focusing on init/fini,
ioctls, memory management, dma-buf.
There were multiple issues raised and all of them were fixed/answered
to my satisfaction.

For the PR:
Acked-by: Oded Gabbay 

Thanks,
Oded

> 
> The following changes since commit a60501d7c2d3e70b3545b9b96576628e369d8e85:
> 
>   Merge tag 'drm-misc-next-2023-12-07' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-12-08 16:27:00 
> +1000)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/drm/xe/kernel.git 
> tags/drm-xe-next-2023-12-15-pr1
> 
> for you to fetch changes up to ac62a6ea9c2030910344723bab3e3f0d04c8a6f4:
> 
>   MAINTAINERS: Updates to Intel DRM (2023-12-15 16:41:56 -0500)
> 
> 
> Introduce a new DRM driver for Intel GPUs
> 
> Xe, is a new driver for Intel GPUs that supports both integrated and
> discrete platforms. The experimental support starts with Tiger Lake.
> i915 will continue be the main production driver for the platforms
> up to Meteor Lake and Alchemist. Then the goal is to make this Intel
> Xe driver the primary driver for Lunar Lake and newer platforms.
> 
> It uses most, if not all, of the key drm concepts, in special: TTM,
> drm-scheduler, drm-exec, drm-gpuvm/gpuva and others.
> 
> It reuses/shares i915 code for display support.
> 
> 
> Alan Previn (1):
>   drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN
> 
> Alexander Usyskin (1):
>   drm/xe/gsc: enable pvc support
> 
> Andrzej Hajda (1):
>   drm/xe: implement driver initiated function-reset
> 
> Animesh Manna (1):
>   drm/xe/dsb: DSB implementation for xe
> 
> Anshuman Gupta (7):
>   drm/xe/pm: Disable PM on unbounded pcie parent bridge
>   drm/xe/pm: Add pci d3cold_capable support
>   drm/xe/pm: Refactor xe_pm_runtime_init
>   drm/xe/pm: Add vram_d3cold_threshold Sysfs
>   drm/xe/pm: Toggle d3cold_allowed using vram_usages
>   drm/xe/pm: Init pcode and restore vram on power lost
>   drm/xe/pm: Add vram_d3cold_threshold for d3cold capable device
> 
> Anusha Srivatsa (10):
>   drm/xe/huc: Support for loading unversiond HuC
>   drm/xe: Load HuC on Alderlake S
>   drm/xe: GuC and HuC loading support for RKL
>   drm/xe: Add Rocketlake device info
>   drm/xe/kunit: Handle fake device creation for all platform/subplatform 
> cases
>   drm/xe: Add missing ADL entries to xe_test_wa
>   drm/xe/rplu: s/ADLP/ALDERLAKE_P
>   drm/xe/rpls: Add RPLS Support
>   drm/xe/rpls: Add Stepping info for RPLS
>   drm/xe: Add missing ADL entries to xe_test_wa
> 
> Aravind Iddamsetty (5):
>   drm/xe: Get GT clock to nanosecs
>   drm/xe: Use spinlock in forcewake instead of mutex
>   drm/xe/pmu: Enable PMU interface
>   drm/xe/pmu: Drop interrupt pmu event
>   drm/xe: Fix lockdep warning in xe_force_wake calls
> 
> Ashutosh Dixit (2):
>   drm/xe/uapi: Use common drm_xe_ext_set_property extension
>   drm/xe/pmu: Remove PMU from Xe till uapi is finalized
> 
> Badal Nilawar (11):
>   drm/xe: Donot apply forcewake while reading actual frequency
>   drm/xe/mtl: Add support to get C6 residency/status of MTL
>   drm/xe/hwmon: Expose power attributes
>   drm/xe/hwmon: Expose card reactive critical power
>   drm/xe/hwmon: Expose input voltage attribute
>   drm/xe/hwmon:

Re: [PULL] drm-xe-next

2023-12-18 Thread Oded Gabbay

On Fri, Dec 15, 2023 at 05:28:19PM -0500, Rodrigo Vivi wrote:
> Hi Dave and Sima,
> 
> Here goes the first pull request for the drm/xe driver.
> 
> Our team was focused on putting together a driver that uses most, if not all,
> of the key drm concepts and has a functional display that is shared with i915.
> All the platforms are still protected by the force_probe protection because 
> they
> are either officially supported by i915, or because they are still under
> enablement like Lunar Lake.
> 
> We still have a lot of work ahead of us, but we believe that it will be better
> to work with all of these cross-driver concepts after we are merged to 
> drm-next
> along with the other drivers.
> 
> Besides the cross-driver collaboration and enabling of upcoming hardware, one 
> of
> our key areas will be to improve performance and address reports by users so 
> that
> the driver keeps getting better.
> 
> I’m having the honor to send this first pull request on behalf of the new 
> team of
> maintainers that we are putting together for the xe driver: Lucas, Thomas, and
> Oded. I’m going to assist them to get this through and to set up the drm-tip
> development flow. Then, you should expect future pull requests coming directly
> from them. Likely, with a rotation of duties that they will define by 
> themselves,
> but that should be similar to drm-intel and drm-misc.
> 
> Thanks,
> Rodrigo.
(Sorry for sending again but my kernel.org smtp definition was wrong and ml 
rejected my email)

Hi Rodrigo,
You and the team did a great job on bringing the driver to this stage. Congrats!

I reviewed a large part of the driver, mainly focusing on init/fini,
ioctls, memory management, dma-buf.
There were multiple issues raised and all of them were fixed/answered
to my satisfaction.

For the PR:
Acked-by: Oded Gabbay 

Thanks,
Oded

> 
> The following changes since commit a60501d7c2d3e70b3545b9b96576628e369d8e85:
> 
>   Merge tag 'drm-misc-next-2023-12-07' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-12-08 16:27:00 
> +1000)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/drm/xe/kernel.git 
> tags/drm-xe-next-2023-12-15-pr1
> 
> for you to fetch changes up to ac62a6ea9c2030910344723bab3e3f0d04c8a6f4:
> 
>   MAINTAINERS: Updates to Intel DRM (2023-12-15 16:41:56 -0500)
> 
> 
> Introduce a new DRM driver for Intel GPUs
> 
> Xe, is a new driver for Intel GPUs that supports both integrated and
> discrete platforms. The experimental support starts with Tiger Lake.
> i915 will continue be the main production driver for the platforms
> up to Meteor Lake and Alchemist. Then the goal is to make this Intel
> Xe driver the primary driver for Lunar Lake and newer platforms.
> 
> It uses most, if not all, of the key drm concepts, in special: TTM,
> drm-scheduler, drm-exec, drm-gpuvm/gpuva and others.
> 
> It reuses/shares i915 code for display support.
> 
> 
> Alan Previn (1):
>   drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN
> 
> Alexander Usyskin (1):
>   drm/xe/gsc: enable pvc support
> 
> Andrzej Hajda (1):
>   drm/xe: implement driver initiated function-reset
> 
> Animesh Manna (1):
>   drm/xe/dsb: DSB implementation for xe
> 
> Anshuman Gupta (7):
>   drm/xe/pm: Disable PM on unbounded pcie parent bridge
>   drm/xe/pm: Add pci d3cold_capable support
>   drm/xe/pm: Refactor xe_pm_runtime_init
>   drm/xe/pm: Add vram_d3cold_threshold Sysfs
>   drm/xe/pm: Toggle d3cold_allowed using vram_usages
>   drm/xe/pm: Init pcode and restore vram on power lost
>   drm/xe/pm: Add vram_d3cold_threshold for d3cold capable device
> 
> Anusha Srivatsa (10):
>   drm/xe/huc: Support for loading unversiond HuC
>   drm/xe: Load HuC on Alderlake S
>   drm/xe: GuC and HuC loading support for RKL
>   drm/xe: Add Rocketlake device info
>   drm/xe/kunit: Handle fake device creation for all platform/subplatform 
> cases
>   drm/xe: Add missing ADL entries to xe_test_wa
>   drm/xe/rplu: s/ADLP/ALDERLAKE_P
>   drm/xe/rpls: Add RPLS Support
>   drm/xe/rpls: Add Stepping info for RPLS
>   drm/xe: Add missing ADL entries to xe_test_wa
> 
> Aravind Iddamsetty (5):
>   drm/xe: Get GT clock to nanosecs
>   drm/xe: Use spinlock in forcewake instead of mutex
>   drm/xe/pmu: Enable PMU interface
>   drm/xe/pmu: Drop interrupt pmu event
>   drm/xe: Fix lockdep warning in xe_force_wake calls
> 
> Ashutosh Dixit (2):
>   drm/xe/uapi: Use common drm_xe_ext_set_property extension
>   drm/xe/pmu: Remove PMU from Xe till uapi is finalized
> 
> Badal Nilawar (11):
>   drm/xe: Donot apply forcewake while reading actual frequency
>   drm/xe/mtl: Add support to get C6 residency/status of MTL
>   drm/xe/hwmon: Expose power attributes
>   drm/xe/hwmon: Expose card r

[Bug 218274] AMD r9 m380, 2015,27 imac - amdgpu wont work

2023-12-18 Thread bugzilla-daemon

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

Artem S. Tashkinov (a...@gmx.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@gmx.com
 Resolution|--- |ANSWERED

--- Comment #2 from Artem S. Tashkinov (a...@gmx.com) ---
Please report here instead:

https://gitlab.freedesktop.org/drm/amd/-/issues

-- 
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: [PATCH 5/6] drm/bridge: dpu-dprc: Use dev_err_probe

Am Montag, 18. Dezember 2023, 11:57:17 CET schrieb Alexander Stein:
> This simplifies the code and gives additional information upon deferral.

Please ignore. I just noticed this file is added in a locally applied series.

Thanks
Alexander

> Signed-off-by: Alexander Stein 
> ---
>  drivers/gpu/drm/imx/dpu/dpu-dprc.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/dpu/dpu-dprc.c
> b/drivers/gpu/drm/imx/dpu/dpu-dprc.c index 261c9566721e..6467ad960080
> 100644
> --- a/drivers/gpu/drm/imx/dpu/dpu-dprc.c
> +++ b/drivers/gpu/drm/imx/dpu/dpu-dprc.c
> @@ -612,7 +612,8 @@ static int dpu_dprc_probe(struct platform_device *pdev)
> 
>   dprc->prgs[i] = dpu_prg_lookup_by_phandle(dev, "fsl,prgs", 
i);
>   if (!dprc->prgs[i])
> - return -EPROBE_DEFER;
> + return dev_err_probe(dev, -EPROBE_DEFER,
> +  "Failed to lookup 
fsl,prgs\n");
> 
>   if (i == 1)
>   dpu_prg_set_auxiliary(dprc->prgs[i]);
> @@ -623,11 +624,10 @@ static int dpu_dprc_probe(struct platform_device
> *pdev)
> 
>   ret = devm_request_irq(dev, wrap_irq, dpu_dprc_wrap_irq_handler,
>  IRQF_SHARED, dev_name(dev), dprc);
> - if (ret < 0) {
> - dev_err(dev, "failed to request dpr_wrap irq(%u): %d\n",
> - wrap_irq, ret);
> - return ret;
> - }
> + if (ret < 0)
> + return dev_err_probe(dev, ret,
> +  "failed to request dpr_wrap 
irq(%u)\n",
> +  wrap_irq);
> 
>   platform_set_drvdata(pdev, dprc);


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH] drm/mgag200: Fix gamma lut not initialized for G200ER, G200EV, G200SE

2023-12-18 Thread Thomas Zimmermann


Hi

Am 14.12.23 um 17:38 schrieb Jocelyn Falempe:

When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads to a black screen, if the bios/uefi doesn't use the same
pixel color depth.
This has been fixed with commit ad81e23426a6 ("drm/mgag200: Fix gamma
lut not initialized.") for most G200, but G200ER, G200EV, G200SE use
their own version of crtc_helper_atomic_enable() and need to be fixed
too.

Fixes: 1baf9127c482 ("drm/mgag200: Replace simple-KMS with regular atomic 
helpers")
Cc:  #v6.1+
Reported-by: Roger Sewell 
Suggested-by: Roger Sewell 
Signed-off-by: Jocelyn Falempe 
---
  drivers/gpu/drm/mgag200/mgag200_drv.h|  4 
  drivers/gpu/drm/mgag200/mgag200_g200er.c |  2 ++
  drivers/gpu/drm/mgag200/mgag200_g200ev.c |  2 ++
  drivers/gpu/drm/mgag200/mgag200_g200se.c |  2 ++
  drivers/gpu/drm/mgag200/mgag200_mode.c   | 26 ++--
  5 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h 
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 57c7edcab602..ed90a92b5fcd 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -392,6 +392,10 @@ void mgag200_primary_plane_helper_atomic_disable(struct 
drm_plane *plane,
.destroy = drm_plane_cleanup, \
DRM_GEM_SHADOW_PLANE_FUNCS
  
+void mgag200_crtc_set_gamma(struct mga_device *mdev,

+   const struct drm_format_info *format,
+   struct drm_property_blob *gamma_lut);
+
  enum drm_mode_status mgag200_crtc_helper_mode_valid(struct drm_crtc *crtc,
const struct 
drm_display_mode *mode);
  int mgag200_crtc_helper_atomic_check(struct drm_crtc *crtc, struct 
drm_atomic_state *new_state);
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200er.c 
b/drivers/gpu/drm/mgag200/mgag200_g200er.c
index bce267e0f7de..38815cb94c61 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200er.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200er.c
@@ -202,6 +202,8 @@ static void mgag200_g200er_crtc_helper_atomic_enable(struct 
drm_crtc *crtc,
  
  	mgag200_g200er_reset_tagfifo(mdev);
  
+	mgag200_crtc_set_gamma(mdev, format, crtc_state->gamma_lut);

+
mgag200_enable_display(mdev);
  
  	if (funcs->enable_vidrst)

diff --git a/drivers/gpu/drm/mgag200/mgag200_g200ev.c 
b/drivers/gpu/drm/mgag200/mgag200_g200ev.c
index ac957f42abe1..e698a3a499bf 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200ev.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200ev.c
@@ -203,6 +203,8 @@ static void mgag200_g200ev_crtc_helper_atomic_enable(struct 
drm_crtc *crtc,
  
  	mgag200_g200ev_set_hiprilvl(mdev);
  
+	mgag200_crtc_set_gamma(mdev, format, crtc_state->gamma_lut);

+
mgag200_enable_display(mdev);
  
  	if (funcs->enable_vidrst)

diff --git a/drivers/gpu/drm/mgag200/mgag200_g200se.c 
b/drivers/gpu/drm/mgag200/mgag200_g200se.c
index bd6e573c9a1a..7e4ea0046a6b 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200se.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200se.c
@@ -334,6 +334,8 @@ static void mgag200_g200se_crtc_helper_atomic_enable(struct 
drm_crtc *crtc,
  
  	mgag200_g200se_set_hiprilvl(mdev, adjusted_mode, format);
  
+	mgag200_crtc_set_gamma(mdev, format, crtc_state->gamma_lut);

+
mgag200_enable_display(mdev);
  
  	if (funcs->enable_vidrst)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index af3ce5a6a636..d2a04b317232 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -65,9 +65,9 @@ static void mgag200_crtc_set_gamma_linear(struct mga_device 
*mdev,
}
  }
  
-static void mgag200_crtc_set_gamma(struct mga_device *mdev,

-  const struct drm_format_info *format,
-  struct drm_color_lut *lut)
+static void mgag200_crtc_set_gamma_table(struct mga_device *mdev,
+const struct drm_format_info *format,
+struct drm_color_lut *lut)
  {
int i;
  
@@ -103,6 +103,16 @@ static void mgag200_crtc_set_gamma(struct mga_device *mdev,

}
  }
  
+void mgag200_crtc_set_gamma(struct mga_device *mdev,

+   const struct drm_format_info *format,
+   struct drm_property_blob *gamma_lut)
+{
+   if (gamma_lut)
+   mgag200_crtc_set_gamma_table(mdev, format, gamma_lut->data);
+   else
+   mgag200_crtc_set_gamma_linear(mdev, format);
+}


Please keep this open-coded its callers. With that changed

Reviewed-by: Thomas Zimmermann 


+
  static inline void mga_wait_vsync(struct mga_device *mdev)
  {
unsigned long timeout = jiffies + HZ/10;
@@ -616,10 +626,7 @@ void mgag200_crtc_helper_atomic_flush(struct drm_crtc 
*crtc, struct drm_atomic_s
if (crtc_state->enable && crtc_state->color_mgmt_change

[PATCH 4/6] drm/bridge: imx8qxp-pixel-link: Use dev_err_probe

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein 
---
 .../gpu/drm/bridge/imx/imx8qxp-pixel-link.c   | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
index ed8b7a4e0e11..b8cc1df3e572 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -338,12 +338,9 @@ static int imx8qxp_pixel_link_bridge_probe(struct 
platform_device *pdev)
return -ENOMEM;
 
ret = imx_scu_get_handle(&pl->ipc_handle);
-   if (ret) {
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev, "failed to get SCU ipc handle: %d\n",
- ret);
-   return ret;
-   }
+   if (ret)
+   return dev_err_probe(dev, ret,
+"failed to get SCU ipc handle\n");
 
ret = of_property_read_u8(np, "fsl,dc-id", &pl->dc_id);
if (ret) {
@@ -379,13 +376,9 @@ static int imx8qxp_pixel_link_bridge_probe(struct 
platform_device *pdev)
return ret;
 
pl->next_bridge = imx8qxp_pixel_link_find_next_bridge(pl);
-   if (IS_ERR(pl->next_bridge)) {
-   ret = PTR_ERR(pl->next_bridge);
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev, "failed to find next bridge: %d\n",
- ret);
-   return ret;
-   }
+   if (IS_ERR(pl->next_bridge))
+   return dev_err_probe(dev, PTR_ERR(pl->next_bridge),
+"failed to find next bridge\n");
 
platform_set_drvdata(pdev, pl);
 
-- 
2.34.1

Re: [PATCH v3 01/14] drm/panthor: Add uAPI

2023-12-18 Thread Chris Diamand

> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> new file mode 100644
> index ..6d815df5e829
> --- /dev/null
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -0,0 +1,892 @@
> +/* SPDX-License-Identifier: MIT */
> +/* Copyright (C) 2023 Collabora ltd. */
> +#ifndef _PANTHOR_DRM_H_
> +#define _PANTHOR_DRM_H_
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +/**
> + * DOC: Introduction

...

> +/**
> + * struct drm_panthor_group_submit - Arguments passed to 
> DRM_IOCTL_PANTHOR_VM_BIND
> + */
> +struct drm_panthor_group_submit {
> + /** @group_handle: Handle of the group to queue jobs to. */
> + __u32 group_handle;
> +
> + /** @pad: MBZ. */
> + __u32 pad;
> +
> + /** @queue_submits: Array of drm_panthor_queue_submit objects. */
> + struct drm_panthor_obj_array queue_submits;
> +};


Hi! Very minor nit - but shouldn't the comment above say 
DRM_IOCTL_PANTHOR_GROUP_SUBMIT, not VM_BIND?

> +
> +/**
> + * enum drm_panthor_group_state_flags - Group state flags
> + */
> +enum drm_panthor_group_state_flags {
> + /**
> +  * @DRM_PANTHOR_GROUP_STATE_TIMEDOUT: Group had unfinished jobs.
> +  *
> +  * When a group ends up with this flag set, no jobs can be submitted to 
> its queues.
> +  */
> + DRM_PANTHOR_GROUP_STATE_TIMEDOUT = 1 << 0,
> +
> + /**
> +  * @DRM_PANTHOR_GROUP_STATE_FATAL_FAULT: Group had fatal faults.
> +  *
> +  * When a group ends up with this flag set, no jobs can be submitted to 
> its queues.
> +  */
> + DRM_PANTHOR_GROUP_STATE_FATAL_FAULT = 1 << 1,
> +};
> +
> +/**
> + * struct drm_panthor_group_get_state - Arguments passed to 
> DRM_IOCTL_PANTHOR_GROUP_GET_STATE
> + *
> + * Used to query the state of a group and decide whether a new group should 
> be created to
> + * replace it.
> + */
> +struct drm_panthor_group_get_state {
> + /** @group_handle: Handle of the group to query state on */
> + __u32 group_handle;
> +
> + /**
> +  * @state: Combination of DRM_PANTHOR_GROUP_STATE_* flags encoding the
> +  * group state.
> +  */
> + __u32 state;
> +
> + /** @fatal_queues: Bitmask of queues that faced fatal faults. */
> + __u32 fatal_queues;
> +
> + /** @pad: MBZ */
> + __u32 pad;
> +};
> +
> +/**
> + * struct drm_panthor_tiler_heap_create - Arguments passed to 
> DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE
> + */
> +struct drm_panthor_tiler_heap_create {
> + /** @vm_id: VM ID the tiler heap should be mapped to */
> + __u32 vm_id;
> +
> + /** @initial_chunk_count: Initial number of chunks to allocate. */
> + __u32 initial_chunk_count;
> +
> + /** @chunk_size: Chunk size. Must be a power of two at least 256KB 
> large. */
> + __u32 chunk_size;
> +
> + /** @max_chunks: Maximum number of chunks that can be allocated. */
> + __u32 max_chunks;
> +
> + /**
> +  * @target_in_flight: Maximum number of in-flight render passes.
> +  *
> +  * If the heap has more than tiler jobs in-flight, the FW will wait for 
> render
> +  * passes to finish before queuing new tiler jobs.
> +  */
> + __u32 target_in_flight;
> +
> + /** @handle: Returned heap handle. Passed back to DESTROY_TILER_HEAP. */
> + __u32 handle;
> +
> + /** @tiler_heap_ctx_gpu_va: Returned heap GPU virtual address returned 
> */
> + __u64 tiler_heap_ctx_gpu_va;
> +
> + /**
> +  * @first_heap_chunk_gpu_va: First heap chunk.
> +  *
> +  * The tiler heap is formed of heap chunks forming a single-link list. 
> This
> +  * is the first element in the list.
> +  */
> + __u64 first_heap_chunk_gpu_va;
> +};
> +
> +/**
> + * struct drm_panthor_tiler_heap_destroy - Arguments passed to 
> DRM_IOCTL_PANTHOR_TILER_HEAP_DESTROY
> + */
> +struct drm_panthor_tiler_heap_destroy {
> + /** @handle: Handle of the tiler heap to destroy */
> + __u32 handle;
> +
> + /** @pad: Padding field, MBZ. */
> + __u32 pad;
> +};
> +
> +#if defined(__cplusplus)
> +}
> +#endif
> +
> +#endif /* _PANTHOR_DRM_H_ */

Cheers,
Chris

Re: [PATCH 6/6] drm/bridge: dpu-core: Don't print error on -EPROBE_DEFER

Am Montag, 18. Dezember 2023, 11:57:18 CET schrieb Alexander Stein:
> -517 errors are just annoying. dev_err_probe can't be used here either
> as this would hide the error message already set in us->init.

Please ignore. I just noticed this file is added in a locally applied series.

Thanks
Alexander

> Signed-off-by: Alexander Stein 
> ---
>  drivers/gpu/drm/imx/dpu/dpu-core.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/dpu/dpu-core.c
> b/drivers/gpu/drm/imx/dpu/dpu-core.c index d6116b3e4ed7..ea2558a14a6c
> 100644
> --- a/drivers/gpu/drm/imx/dpu/dpu-core.c
> +++ b/drivers/gpu/drm/imx/dpu/dpu-core.c
> @@ -592,9 +592,10 @@ static int dpu_submodules_init(struct dpu_soc *dpu,
> unsigned long dpu_base) ret = us->init(dpu, j, us->ids[j], us->types[j],
>  pec_ofs, dpu_base + us-
>ofss[j]);
>   if (ret) {
> - dev_err(dpu->dev,
> - "failed to initialize %s%d: 
%d\n",
> - us->name, us-
>ids[j], ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dpu->dev,
> + "failed to 
initialize %s%d: %d\n",
> + us-
>name, us->ids[j], ret);
>   return ret;
>   }
>   }


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

[PATCH 1/6] drm/bridge: imx8qxp-pxl2dpi: Use dev_err_probe

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein 
---
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 26 ++--
 1 file changed, 7 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
index 4a886cb808ca..3a1d5795d002 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -403,20 +403,12 @@ static int imx8qxp_pxl2dpi_bridge_probe(struct 
platform_device *pdev)
return -ENOMEM;
 
p2d->regmap = syscon_node_to_regmap(np->parent);
-   if (IS_ERR(p2d->regmap)) {
-   ret = PTR_ERR(p2d->regmap);
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev, "failed to get regmap: %d\n", ret);
-   return ret;
-   }
+   if (IS_ERR(p2d->regmap))
+   return dev_err_probe(dev, ret, "failed to get regmap\n");
 
ret = imx_scu_get_handle(&p2d->ipc_handle);
-   if (ret) {
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev, "failed to get SCU ipc handle: %d\n",
- ret);
-   return ret;
-   }
+   if (ret)
+   return dev_err_probe(dev, ret, "failed to get SCU ipc 
handle\n");
 
p2d->dev = dev;
 
@@ -427,13 +419,9 @@ static int imx8qxp_pxl2dpi_bridge_probe(struct 
platform_device *pdev)
}
 
p2d->next_bridge = imx8qxp_pxl2dpi_find_next_bridge(p2d);
-   if (IS_ERR(p2d->next_bridge)) {
-   ret = PTR_ERR(p2d->next_bridge);
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev, "failed to find next bridge: %d\n",
- ret);
-   return ret;
-   }
+   if (IS_ERR(p2d->next_bridge))
+   return dev_err_probe(dev, PTR_ERR(p2d->next_bridge),
+"failed to find next bridge\n");
 
ret = imx8qxp_pxl2dpi_set_pixel_link_sel(p2d);
if (ret)
-- 
2.34.1

[PATCH 6/6] drm/bridge: dpu-core: Don't print error on -EPROBE_DEFER

-517 errors are just annoying. dev_err_probe can't be used here either
as this would hide the error message already set in us->init.

Signed-off-by: Alexander Stein 
---
 drivers/gpu/drm/imx/dpu/dpu-core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/dpu/dpu-core.c 
b/drivers/gpu/drm/imx/dpu/dpu-core.c
index d6116b3e4ed7..ea2558a14a6c 100644
--- a/drivers/gpu/drm/imx/dpu/dpu-core.c
+++ b/drivers/gpu/drm/imx/dpu/dpu-core.c
@@ -592,9 +592,10 @@ static int dpu_submodules_init(struct dpu_soc *dpu, 
unsigned long dpu_base)
ret = us->init(dpu, j, us->ids[j], us->types[j],
   pec_ofs, dpu_base + us->ofss[j]);
if (ret) {
-   dev_err(dpu->dev,
-   "failed to initialize %s%d: %d\n",
-   us->name, us->ids[j], ret);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dpu->dev,
+   "failed to initialize %s%d: 
%d\n",
+   us->name, us->ids[j], 
ret);
return ret;
}
}
-- 
2.34.1

Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

Hi everybody,

Am Montag, 18. Dezember 2023, 09:48:49 CET schrieb Luca Ceresoli:
> Hi,
> 
> On Mon, 18 Dec 2023 04:36:55 +0200
> 
> Laurent Pinchart  wrote:
> > On Fri, Dec 15, 2023 at 05:09:41PM -0300, Fabio Estevam wrote:
> > > On Fri, Dec 15, 2023 at 4:01 PM Adam Ford  wrote:
> > > > Thanks for the list.  I was able to successfully build the stable 6.6
> > > > branch with those patches applied and I have the HDMI working.
> > > > Unfortunately, I get build errors on the linux-next, so it's going to
> > > > take me a little time to sort through all of this.
> > > 
> > > If you need help to figure this problem out, please let me know.
> > > 
> > > I haven't tried it against linux-next.
> > > 
> > > > I am thinking that it would be better to consolidate all these
> > > > together into one series instead of piecemealing it.  However, there
> > > > are some items that can be submitted right away without significantly
> > > > reworking them against linux-next.  Do people have a preference?
> > > 
> > > I think it makes sense to re-submit the "easy ones" right away.
> > 
> > Agreed. The more we can merge quickly, the easier it will become to
> > rebase and upstream the rest.
> 
> I agree as well, "release early, release often". These patches are
> around since a long time and lots of people are using them already, and
> tracking all of them from different threads is time-consuming. I will
> happily test them early as soon as they are sent.

I lost track of the series well, but I do remember I had to adjust the 
original series to get it running on linux-next.
Please keep me on CC so I can add my local changes if necessary.
I have a proof of concept for HDMI audio, which is based on the base HDMI 
support. I can continue on that after merge, but I'm lacking an idea how to 
add some kind of "bridge" into the audio pipeline.

Best regards
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

[PATCH 5/6] drm/bridge: dpu-dprc: Use dev_err_probe

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein 
---
 drivers/gpu/drm/imx/dpu/dpu-dprc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/dpu/dpu-dprc.c 
b/drivers/gpu/drm/imx/dpu/dpu-dprc.c
index 261c9566721e..6467ad960080 100644
--- a/drivers/gpu/drm/imx/dpu/dpu-dprc.c
+++ b/drivers/gpu/drm/imx/dpu/dpu-dprc.c
@@ -612,7 +612,8 @@ static int dpu_dprc_probe(struct platform_device *pdev)
 
dprc->prgs[i] = dpu_prg_lookup_by_phandle(dev, "fsl,prgs", i);
if (!dprc->prgs[i])
-   return -EPROBE_DEFER;
+   return dev_err_probe(dev, -EPROBE_DEFER,
+"Failed to lookup fsl,prgs\n");
 
if (i == 1)
dpu_prg_set_auxiliary(dprc->prgs[i]);
@@ -623,11 +624,10 @@ static int dpu_dprc_probe(struct platform_device *pdev)
 
ret = devm_request_irq(dev, wrap_irq, dpu_dprc_wrap_irq_handler,
   IRQF_SHARED, dev_name(dev), dprc);
-   if (ret < 0) {
-   dev_err(dev, "failed to request dpr_wrap irq(%u): %d\n",
-   wrap_irq, ret);
-   return ret;
-   }
+   if (ret < 0)
+   return dev_err_probe(dev, ret,
+"failed to request dpr_wrap irq(%u)\n",
+wrap_irq);
 
platform_set_drvdata(pdev, dprc);
 
-- 
2.34.1

[PATCH 3/6] drm/bridge: imx: imx-ldb-helper: Use dev_err_probe

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein 
---
 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c 
b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
index 6967325cd8ee..9b872cfb849c 100644
--- a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
+++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
@@ -172,7 +172,7 @@ int ldb_find_next_bridge_helper(struct ldb *ldb)
 {
struct device *dev = ldb->dev;
struct ldb_channel *ldb_ch;
-   int ret, i;
+   int i;
 
for (i = 0; i < MAX_LDB_CHAN_NUM; i++) {
ldb_ch = ldb->channel[i];
@@ -182,14 +182,9 @@ int ldb_find_next_bridge_helper(struct ldb *ldb)
 
ldb_ch->next_bridge = devm_drm_of_get_bridge(dev, ldb_ch->np,
 1, 0);
-   if (IS_ERR(ldb_ch->next_bridge)) {
-   ret = PTR_ERR(ldb_ch->next_bridge);
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev,
- "failed to get next bridge: %d\n",
- ret);
-   return ret;
-   }
+   if (IS_ERR(ldb_ch->next_bridge))
+   return dev_err_probe(dev, PTR_ERR(ldb_ch->next_bridge),
+"failed to find next bridge\n");
}
 
return 0;
-- 
2.34.1

[PATCH 2/6] drm/bridge: imx: imx8qxp-ldb: Use dev_err_probe

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein 
---
 drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c | 37 
 1 file changed, 12 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
index 7984da9c0a35..423196d2204d 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
@@ -557,10 +557,8 @@ static int imx8qxp_ldb_parse_dt_companion(struct 
imx8qxp_ldb *imx8qxp_ldb)
 
imx8qxp_ldb->companion = of_drm_find_bridge(companion_port);
if (!imx8qxp_ldb->companion) {
-   ret = -EPROBE_DEFER;
-   DRM_DEV_DEBUG_DRIVER(dev,
-"failed to find bridge for companion 
bridge: %d\n",
-ret);
+   ret = dev_err_probe(dev, -EPROBE_DEFER,
+   "failed to find bridge for companion 
bridge\n");
goto out;
}
 
@@ -590,22 +588,14 @@ static int imx8qxp_ldb_probe(struct platform_device *pdev)
return -ENOMEM;
 
imx8qxp_ldb->clk_pixel = devm_clk_get(dev, "pixel");
-   if (IS_ERR(imx8qxp_ldb->clk_pixel)) {
-   ret = PTR_ERR(imx8qxp_ldb->clk_pixel);
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev,
- "failed to get pixel clock: %d\n", ret);
-   return ret;
-   }
+   if (IS_ERR(imx8qxp_ldb->clk_pixel))
+   return dev_err_probe(dev, PTR_ERR(imx8qxp_ldb->clk_pixel),
+"failed to get pixel clock\n");
 
imx8qxp_ldb->clk_bypass = devm_clk_get(dev, "bypass");
-   if (IS_ERR(imx8qxp_ldb->clk_bypass)) {
-   ret = PTR_ERR(imx8qxp_ldb->clk_bypass);
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev,
- "failed to get bypass clock: %d\n", ret);
-   return ret;
-   }
+   if (IS_ERR(imx8qxp_ldb->clk_bypass))
+   return dev_err_probe(dev, PTR_ERR(imx8qxp_ldb->clk_bypass),
+"failed to get bypass clock\n");
 
imx8qxp_ldb->dev = dev;
 
@@ -640,13 +630,10 @@ static int imx8qxp_ldb_probe(struct platform_device *pdev)
}
 
imx8qxp_ldb_ch->phy = devm_of_phy_get(dev, ldb_ch->np, "lvds_phy");
-   if (IS_ERR(imx8qxp_ldb_ch->phy)) {
-   ret = PTR_ERR(imx8qxp_ldb_ch->phy);
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dev, "failed to get channel%d PHY: %d\n",
- imx8qxp_ldb->active_chno, ret);
-   return ret;
-   }
+   if (IS_ERR(imx8qxp_ldb_ch->phy))
+   return dev_err_probe(dev, PTR_ERR(imx8qxp_ldb_ch->phy),
+"failed to get channel%d PHY\n",
+imx8qxp_ldb->active_chno);
 
ret = ldb_find_next_bridge_helper(ldb);
if (ret)
-- 
2.34.1

[PATCH 0/6] dev_err_probe usage for imx8qxp DPU pipeline

Hi everyone,

while working on i.MX8QXP DPU/LVDS output I come across these fixes simplifying
the code and improving debugging, while also creating less noise.
It touches several files as the output pipeline is rather complex.

Best regards,
Alexander

Alexander Stein (6):
  drm/bridge: imx8qxp-pxl2dpi: Use dev_err_probe
  drm/bridge: imx: imx8qxp-ldb: Use dev_err_probe
  drm/bridge: imx: imx-ldb-helper: Use dev_err_probe
  drm/bridge: imx8qxp-pixel-link: Use dev_err_probe
  drm/bridge: dpu-dprc: Use dev_err_probe
  drm/bridge: dpu-core: Don't print error on -EPROBE_DEFER

 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c   | 13 ++-
 drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c  | 37 ++-
 .../gpu/drm/bridge/imx/imx8qxp-pixel-link.c   | 19 +++---
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c  | 26 -
 drivers/gpu/drm/imx/dpu/dpu-core.c|  7 ++--
 drivers/gpu/drm/imx/dpu/dpu-dprc.c| 12 +++---
 6 files changed, 39 insertions(+), 75 deletions(-)

-- 
2.34.1

Re: [PATCH v9 08/12] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF

2023-12-18 Thread neil . armstrong


Hi,

On 27/11/2023 09:38, Jerome Brunet wrote:






I suspect mipi_dsi_pxclk_div was added to achieve fractional vclk/bitclk ratios,
since it doesn't exist on AXG. Not sure we would ever need it... and none
of the other upstream DSI drivers supports such setups.

The main reasons I set only mipi_dsi_pxclk in DT is because :
1) the DSI controller requires a bitclk to respond, pclk is not enough
2) GP0 is disabled with an invalid config at cold boot, thus we cannot
rely on a default/safe rate on an initial prepare_enable().
This permits setting initial valid state for the DSI controller, while
the actual bitclk and vclk are calculated dynamically with panel/bridge
runtime parameters.

Nothing against setting rate in DT when it is static. Setting it then
overriding it is not easy to follow.


Yup, would be simpler to only have parenting set in DT, since it must
stay static, I'm fine trying to move rate setup to code.


To work around GP0 not being set, assuming you want to keep rate
propagation as it is, you could call clk_set_rate() on cts_encl (possibly w/o
enabling it) to force a setup on gp0 then clk_prepare_enable() on
pxclk. You'd get a your safe rate on GP0 and the clock you need on pxclk.
It is a bit hackish. Might be better to claim gp0 in your driver to
manage it directly, cutting rate propagation above it to control each
branch of the subtree as you need. It seems you need to have control over
that anyway and it would be clear GP0 is expected to belong to DSI.


Controlling the PLL from the DSI controller seems violating too much layers,
DSI controller driver is not feed directly by the PLL so it's a non-sense
regarding DT properties.


Not sure what you mean by this. You have shown in your the commit
message that the DSI clocks make significant subtree. I don't see a
problem if you need to manage the root of that subtree. I'd be great if
you didn't need to, but it is what it is ...


I really think the choice of PLL should not be done by the DSI controller,
but by the Video pipeline driver or statically until we can do this.

My point is that we should only define the clocks that are related to each
hardware, for example the whole VCLK/VCLK2 clocks should be defined for the
VPU HW, then only the few endpoint clocks should be defined for the HDMI
or DSI controllers, PHY clock and ENCI/ENCP for HDMI, DSI and ENCL for DSI.

The big plan is to entirely switch to CCF for VPU, but first I want to have
DSI working, and since DSI needs GP0, we need CCF for that so the intermediate
plan is to have partial CCF handling only for DSI with fixed clock tree in DT,
then in the future the Meson DRM driver would set up the appropriate clock
tree for HDMI, DSI, Composite and perhaps DP for T7 SoCs then the controller
bridge will call the clk_set_rate() in the same design I did for DSI.

Here's the tracked item: 
https://gitlab.com/amlogic-foss/mainline-linux-issues-tracker/-/issues/9

CCF clock control is a mandatory item to solved dual-head display: 
https://gitlab.com/amlogic-foss/mainline-linux-issues-tracker/-/issues/6





Setting a safe clock from the DSI controller probe is an idea, but again I
don't know which value I should use...


You mentionned that the problem comes DSI bridges that needs to change
at runtime. I don't know much about those TBH, but is there
anyway you can come up with a static GP0 rate that would then be able to
divide to serve all the rates bridge would need in your use case ?


No, there's no such things in the DSI world, MIPI only specifies the electrical
and transport layer, everything else is custom per vendor.



GP0 can go a lot higher than ~100MHz and there are dividers unused in the
tree it seems.

I suppose there is a finite number of required rate for each use case ?
If there are not too many and there is a common divider that allows a
common rate GP0 can do, it would solve your problem. It's a lot of if
but It is worth checking.

This is how audio works and DT assigned rate is a good match in this case.


Yeah I know, but I would love it but no...





I'll review the clk parenting flags and try to hack something.

Thanks,
Neil




Thanks,
Neil

[RFC PATCH net-next v5 02/14] net: page_pool: factor out page_pool recycle check

The check is duplicated in 2 places, factor it out into a common helper.

Signed-off-by: Mina Almasry 
---
 net/core/page_pool.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 45bb4210412d..0edb9251d98d 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -657,6 +657,11 @@ static bool page_pool_recycle_in_cache(struct page *page,
return true;
 }
 
+static bool __page_pool_page_can_be_recycled(const struct page *page)
+{
+   return page_ref_count(page) == 1 && !page_is_pfmemalloc(page);
+}
+
 /* If the page refcnt == 1, this will try to recycle the page.
  * if PP_FLAG_DMA_SYNC_DEV is set, we'll try to sync the DMA area for
  * the configured size min(dma_sync_size, pool->max_len).
@@ -678,7 +683,7 @@ __page_pool_put_page(struct page_pool *pool, struct page 
*page,
 * page is NOT reusable when allocated when system is under
 * some pressure. (page_is_pfmemalloc)
 */
-   if (likely(page_ref_count(page) == 1 && !page_is_pfmemalloc(page))) {
+   if (likely(__page_pool_page_can_be_recycled(page))) {
/* Read barrier done in page_ref_count / READ_ONCE */
 
if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
@@ -793,7 +798,7 @@ static struct page *page_pool_drain_frag(struct page_pool 
*pool,
if (likely(page_pool_unref_page(page, drain_count)))
return NULL;
 
-   if (page_ref_count(page) == 1 && !page_is_pfmemalloc(page)) {
+   if (__page_pool_page_can_be_recycled(page)) {
if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
page_pool_dma_sync_for_device(pool, page, -1);
 
-- 
2.43.0.472.g3155946c3a-goog

Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers

2023-12-18 Thread Conor Dooley

On Sun, Dec 17, 2023 at 11:00:07PM +0100, Javier Martinez Canillas wrote:
> Conor Dooley  writes:
> 
> Hello Conor,
> 
> > On Sun, Dec 17, 2023 at 10:33:24PM +0100, Javier Martinez Canillas wrote:
> 
> [...]
> 
> >> >> +then:
> >> >> +  properties:
> >> >> +width:
> >> >> +  default: 96
> >> >> +height:
> >> >> +  default: 64
> >> >
> >> > Do you envisage a rake of devices that are going to end up in this
> >> > binding? Otherwise, why not unconditionally set the constraints?
> >> >
> >> 
> >> Because these are only for the default width and height, there can be
> >> panels using the same controller but that have a different resolution.
> >> 
> >> For example, there are panels using the SSD1306 controller that have
> >> 128x32 [0], 64x32 [1] or 128x64 [2] resolutions.
> >
> > This, as you know, does not matter here.
> >
> 
> Are you sure? What I tried to say is that the SSD133x are just OLED
> controllers and manufacturers use those chips to attach a panel that
> has a certain resolution.
> 
> While it makes sense to use all the supported width and height, some
> manufacturers chose to have a smaller panel instead (I used SSD1306
> as an example because I knew about these but the same might be true
> for let's say SSD1331).
> 
> Or saying another way, are you sure that every manufacturer selling
> RGB OLED panels using the SSD1331 chip will use the default resolution
> and users won't have to set a custom width and height ?

That's not at all what I was saying. I just meant unconditionally set
the constraints on the property (in this case the default) since you
only have one compatible. Not unconditionally set the height and width.

Apologies if if that was unclear.

Thanks,
Conor.

> I have already chosen to make the DT binding as simple as possible to
> prevent what happened with the SSD1306 "solomon,page-offset" property
> that has a broken default [0] but I think that not allowing to set the
> resolution is already too restrictive and would make it unusable for
> any panel that doesn't have the default width and height.
> 
> [0]: 
> https://lists.freedesktop.org/archives/dri-devel/2023-November/431150.html
> 
> >> But answering your question, yes I think that more devices for this
> >> SSD133x family are going to be added later. Looking at [3], there is
> >> at least SSD1333 that has a different default resolutions (176x176).
> >
> > That's fair enough though. I'd probably err on the side of introducing
> > this complexity when the other users actually show up though.
> >
> 
> Agree and the reason why I did not include entries for the SSD1332 and
> SSD1333. I was planning to add those only if there were users since it
> seems that the SSD1331 is the most popular controller from this family.
> 
> But as explained, even for the SSD1331 it may be needed to set a width
> and height that is different than the default of this panel controller.
> 
> -- 
> Best regards,
> 
> Javier Martinez Canillas
> Core Platforms
> Red Hat
> 


signature.asc
Description: PGP signature

[RFC PATCH net-next v5 11/14] tcp: RX path for devmem TCP

In tcp_recvmsg_locked(), detect if the skb being received by the user
is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
flag - pass it to tcp_recvmsg_devmem() for custom handling.

tcp_recvmsg_devmem() copies any data in the skb header to the linear
buffer, and returns a cmsg to the user indicating the number of bytes
returned in the linear buffer.

tcp_recvmsg_devmem() then loops over the unaccessible devmem skb frags,
and returns to the user a cmsg_devmem indicating the location of the
data in the dmabuf device memory. cmsg_devmem contains this information:

1. the offset into the dmabuf where the payload starts. 'frag_offset'.
2. the size of the frag. 'frag_size'.
3. an opaque token 'frag_token' to return to the kernel when the buffer
is to be released.

The pages awaiting freeing are stored in the newly added
sk->sk_user_frags, and each page passed to userspace is get_page()'d.
This reference is dropped once the userspace indicates that it is
done reading this page.  All pages are released when the socket is
destroyed.

Signed-off-by: Willem de Bruijn 
Signed-off-by: Kaiyuan Zhang 
Signed-off-by: Mina Almasry 

---

Changes in v1:
- Added dmabuf_id to dmabuf_cmsg (David/Stan).
- Devmem -> dmabuf (David).
- Change tcp_recvmsg_dmabuf() check to skb->dmabuf (Paolo).
- Use __skb_frag_ref() & napi_pp_put_page() for refcounting (Yunsheng).

RFC v3:
- Fixed issue with put_cmsg() failing silently.

---
 include/linux/socket.h|   1 +
 include/net/netmem.h  |  13 ++
 include/net/sock.h|   2 +
 include/uapi/asm-generic/socket.h |   5 +
 include/uapi/linux/uio.h  |  10 ++
 net/ipv4/tcp.c| 190 +-
 net/ipv4/tcp_ipv4.c   |   9 ++
 7 files changed, 225 insertions(+), 5 deletions(-)

diff --git a/include/linux/socket.h b/include/linux/socket.h
index cfcb7e2c3813..fe2b9e2081bb 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -326,6 +326,7 @@ struct ucred {
  * plain text and require encryption
  */
 
+#define MSG_SOCK_DEVMEM 0x200  /* Receive devmem skbs as cmsg */
 #define MSG_ZEROCOPY   0x400   /* Use user data in kernel path */
 #define MSG_SPLICE_PAGES 0x800 /* Splice the pages from the iterator 
in sendmsg() */
 #define MSG_FASTOPEN   0x2000  /* Send data in TCP SYN */
diff --git a/include/net/netmem.h b/include/net/netmem.h
index ab3824b7b789..fa6d7b7ddef9 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -64,6 +64,19 @@ static inline unsigned int net_iov_idx(const struct net_iov 
*niov)
return niov - net_iov_owner(niov)->niovs;
 }
 
+static inline unsigned long net_iov_virtual_addr(const struct net_iov *niov)
+{
+   struct dmabuf_genpool_chunk_owner *owner = net_iov_owner(niov);
+
+   return owner->base_virtual +
+  ((unsigned long)net_iov_idx(niov) << PAGE_SHIFT);
+}
+
+static inline u32 net_iov_binding_id(const struct net_iov *niov)
+{
+   return net_iov_owner(niov)->binding->id;
+}
+
 static inline dma_addr_t net_iov_dma_addr(const struct net_iov *niov)
 {
struct dmabuf_genpool_chunk_owner *owner = net_iov_owner(niov);
diff --git a/include/net/sock.h b/include/net/sock.h
index 8b6fe164b218..8eccf6ed8eb1 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -353,6 +353,7 @@ struct sk_filter;
   *@sk_txtime_unused: unused txtime flags
   *@ns_tracker: tracker for netns reference
   *@sk_bind2_node: bind node in the bhash2 table
+  *@sk_user_frags: xarray of pages the user is holding a reference on.
   */
 struct sock {
/*
@@ -545,6 +546,7 @@ struct sock {
struct rcu_head sk_rcu;
netns_tracker   ns_tracker;
struct hlist_node   sk_bind2_node;
+   struct xarray   sk_user_frags;
 };
 
 enum sk_pacing {
diff --git a/include/uapi/asm-generic/socket.h 
b/include/uapi/asm-generic/socket.h
index 8ce8a39a1e5f..25a2f5255f52 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -135,6 +135,11 @@
 #define SO_PASSPIDFD   76
 #define SO_PEERPIDFD   77
 
+#define SO_DEVMEM_LINEAR   98
+#define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF   99
+#define SCM_DEVMEM_DMABUF  SO_DEVMEM_DMABUF
+
 #if !defined(__KERNEL__)
 
 #if __BITS_PER_LONG == 64 || (defined(__x86_64__) && defined(__ILP32__))
diff --git a/include/uapi/linux/uio.h b/include/uapi/linux/uio.h
index 059b1a9147f4..ad92e37699da 100644
--- a/include/uapi/linux/uio.h
+++ b/include/uapi/linux/uio.h
@@ -20,6 +20,16 @@ struct iovec
__kernel_size_t iov_len; /* Must be size_t (1003.1g) */
 };
 
+struct dmabuf_cmsg {
+   __u64 frag_offset;  /* offset into the dmabuf where the frag starts.
+*/
+   __u32 frag_size;/* size of the frag. */
+

Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

2023-12-18 Thread Laurent Pinchart

On Fri, Dec 15, 2023 at 05:09:41PM -0300, Fabio Estevam wrote:
> On Fri, Dec 15, 2023 at 4:01 PM Adam Ford  wrote:
> 
> > Thanks for the list.  I was able to successfully build the stable 6.6
> > branch with those patches applied and I have the HDMI working.
> > Unfortunately, I get build errors on the linux-next, so it's going to
> > take me a little time to sort through all of this.
> 
> If you need help to figure this problem out, please let me know.
> 
> I haven't tried it against linux-next.
> 
> > I am thinking that it would be better to consolidate all these
> > together into one series instead of piecemealing it.  However, there
> > are some items that can be submitted right away without significantly
> > reworking them against linux-next.  Do people have a preference?
> 
> I think it makes sense to re-submit the "easy ones" right away.

Agreed. The more we can merge quickly, the easier it will become to
rebase and upstream the rest.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers

2023-12-18 Thread Krzysztof Kozlowski

On 17/12/2023 11:07, Javier Martinez Canillas wrote:
>> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: solomon,ssd1331
> +then:
> +  properties:
> +width:
> +  default: 96
> +height:
> +  default: 64
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +

Use 4 spaces for example indentation.

Best regards,
Krzysztof

Re: [PULL] drm-xe-next

2023-12-18 Thread Oded Gabbay

On Sat, Dec 16, 2023 at 12:28 AM Rodrigo Vivi  wrote:
>
> Hi Dave and Sima,
>
> Here goes the first pull request for the drm/xe driver.
>
> Our team was focused on putting together a driver that uses most, if not all,
> of the key drm concepts and has a functional display that is shared with i915.
> All the platforms are still protected by the force_probe protection because 
> they
> are either officially supported by i915, or because they are still under
> enablement like Lunar Lake.
>
> We still have a lot of work ahead of us, but we believe that it will be better
> to work with all of these cross-driver concepts after we are merged to 
> drm-next
> along with the other drivers.
>
> Besides the cross-driver collaboration and enabling of upcoming hardware, one 
> of
> our key areas will be to improve performance and address reports by users so 
> that
> the driver keeps getting better.
>
> I’m having the honor to send this first pull request on behalf of the new 
> team of
> maintainers that we are putting together for the xe driver: Lucas, Thomas, and
> Oded. I’m going to assist them to get this through and to set up the drm-tip
> development flow. Then, you should expect future pull requests coming directly
> from them. Likely, with a rotation of duties that they will define by 
> themselves,
> but that should be similar to drm-intel and drm-misc.
>
> Thanks,
> Rodrigo.

Hi Rodrigo,
You and the team did a great job on bringing the driver to this stage. Congrats!

I reviewed a large part of the driver, mainly focusing on init/fini,
ioctls, memory management, dma-buf.
There were multiple issues raised and all of them were fixed/answered
to my satisfaction.

For the PR:
Acked-by: Oded Gabbay 

Thanks,
Oded

>
> The following changes since commit a60501d7c2d3e70b3545b9b96576628e369d8e85:
>
>   Merge tag 'drm-misc-next-2023-12-07' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-12-08 16:27:00 
> +1000)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/drm/xe/kernel.git 
> tags/drm-xe-next-2023-12-15-pr1
>
> for you to fetch changes up to ac62a6ea9c2030910344723bab3e3f0d04c8a6f4:
>
>   MAINTAINERS: Updates to Intel DRM (2023-12-15 16:41:56 -0500)
>
> 
> Introduce a new DRM driver for Intel GPUs
>
> Xe, is a new driver for Intel GPUs that supports both integrated and
> discrete platforms. The experimental support starts with Tiger Lake.
> i915 will continue be the main production driver for the platforms
> up to Meteor Lake and Alchemist. Then the goal is to make this Intel
> Xe driver the primary driver for Lunar Lake and newer platforms.
>
> It uses most, if not all, of the key drm concepts, in special: TTM,
> drm-scheduler, drm-exec, drm-gpuvm/gpuva and others.
>
> It reuses/shares i915 code for display support.
>
> 
> Alan Previn (1):
>   drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN
>
> Alexander Usyskin (1):
>   drm/xe/gsc: enable pvc support
>
> Andrzej Hajda (1):
>   drm/xe: implement driver initiated function-reset
>
> Animesh Manna (1):
>   drm/xe/dsb: DSB implementation for xe
>
> Anshuman Gupta (7):
>   drm/xe/pm: Disable PM on unbounded pcie parent bridge
>   drm/xe/pm: Add pci d3cold_capable support
>   drm/xe/pm: Refactor xe_pm_runtime_init
>   drm/xe/pm: Add vram_d3cold_threshold Sysfs
>   drm/xe/pm: Toggle d3cold_allowed using vram_usages
>   drm/xe/pm: Init pcode and restore vram on power lost
>   drm/xe/pm: Add vram_d3cold_threshold for d3cold capable device
>
> Anusha Srivatsa (10):
>   drm/xe/huc: Support for loading unversiond HuC
>   drm/xe: Load HuC on Alderlake S
>   drm/xe: GuC and HuC loading support for RKL
>   drm/xe: Add Rocketlake device info
>   drm/xe/kunit: Handle fake device creation for all platform/subplatform 
> cases
>   drm/xe: Add missing ADL entries to xe_test_wa
>   drm/xe/rplu: s/ADLP/ALDERLAKE_P
>   drm/xe/rpls: Add RPLS Support
>   drm/xe/rpls: Add Stepping info for RPLS
>   drm/xe: Add missing ADL entries to xe_test_wa
>
> Aravind Iddamsetty (5):
>   drm/xe: Get GT clock to nanosecs
>   drm/xe: Use spinlock in forcewake instead of mutex
>   drm/xe/pmu: Enable PMU interface
>   drm/xe/pmu: Drop interrupt pmu event
>   drm/xe: Fix lockdep warning in xe_force_wake calls
>
> Ashutosh Dixit (2):
>   drm/xe/uapi: Use common drm_xe_ext_set_property extension
>   drm/xe/pmu: Remove PMU from Xe till uapi is finalized
>
> Badal Nilawar (11):
>   drm/xe: Donot apply forcewake while reading actual frequency
>   drm/xe/mtl: Add support to get C6 residency/status of MTL
>   drm/xe/hwmon: Expose power attributes
>   drm/xe/hwmon: Expose card reactive critical power
>   drm/xe/hwmon: Expose input voltage attribute
>   drm/xe/hwmon: Expose hwmon energy attribute

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

2023-12-18 Thread Maxime Ripard

On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
> Hi Maxime,
> 
> > Am 15.12.2023 um 14:33 schrieb Maxime Ripard :
> > 
> >>> 
> >>> It's for a separate architecture, with a separate driver, maintained out
> >>> of tree by a separate community, with a separate set of requirements as
> >>> evidenced by the other thread. And that's all fine in itself, but
> >>> there's very little reason to put these two bindings in the same file.
> >>> 
> >>> We could also turn this around, why is it important that it's in the
> >>> same file?
> >> 
> >> Same vendor. And enough similarity in architectures, even a logical 
> >> sequence
> >> of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
> >> (SGX and Rogue seem to be just trade names for their architecture 
> >> development).
> > 
> > Again, none of that matters for *where* the binding is stored.
> 
> So what then speaks against extending the existing bindings file as proposed
> here?

I mean, apart from everything you quoted, then sure, nothing speaks
against it.

> >> AFAIK bindings should describe hardware and not communities or drivers
> >> or who is currently maintaining it. The latter can change, the first not.
> > 
> > Bindings are supposed to describe hardware indeed. Nothing was ever said
> > about where those bindings are supposed to be located.
> > 
> > There's hundreds of other YAML bindings describing devices of the same
> > vendors and different devices from the same generation.
> 
> Usually SoC seem to be split over multiple files by subsystem. Not by versions
> or generations. If the subsystems are similar enough they share the same 
> bindings
> doc instead of having one for each generation duplicating a lot of code.
> 
> Here is a comparable example that combines multiple vendors and generations:
> 
> Documentation/devicetree/bindings/usb/generic-ehci.yaml

EHCI is a single interface for USB2.0 controllers. It's a standard API,
and is made of a single driver that requires minor modifications to deal
with multiple devices.

We're very far from the same situation here.

> > If anything it'll make it easier for you. I'm really not sure why it is
> > controversial and you're fighting this so hard.
> 
> Well, you made it controversial by proposing to split what IMHO belongs 
> together.

No, reviews aren't controversial. The controversy started when you chose
to oppose it while you could have just rolled with it.

> I feel that the original patch is good enough for its purpose and follows
> some design pattern that can be deduced from other binding docs.

[citation needed]

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v2 4/5] drm/atomic: Make the drm_atomic_state documentation less ambiguous

2023-12-18 Thread Maxime Ripard

Hi,

On Fri, Dec 15, 2023 at 04:54:28PM +0200, Pekka Paalanen wrote:
> On Thu, 14 Dec 2023 11:09:15 +0100
> Maxime Ripard  wrote:
> 
> > The current documentation of drm_atomic_state says that it's the "global
> > state object". This is confusing since, while it does contain all the
> > objects affected by an update and their respective states, if an object
> > isn't affected by this update it won't be part of it.
> > 
> > Thus, it's not truly a "global state", unlike object state structures
> > that do contain the entire state of a given object.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  include/drm/drm_atomic.h | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > index 914574b58ae7..5df67e587816 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -346,7 +346,13 @@ struct __drm_private_objs_state {
> >  };
> >  
> >  /**
> > - * struct drm_atomic_state - the global state object for atomic updates
> > + * struct drm_atomic_state - Atomic commit structure
> > + *
> > + * This structure is the kernel counterpart of @drm_mode_atomic and 
> > represents
> > + * an atomic commit that transitions from an old to a new display state. It
> > + * contains all the objects affected by an atomic commits and both the new
> 
> *by the atomic commit and
> 
> > + * state structures and pointers to the old state structures for
> > + * these.
> >   *
> >   * States are added to an atomic update by calling 
> > drm_atomic_get_crtc_state(),
> >   * drm_atomic_get_plane_state(), drm_atomic_get_connector_state(), or for
> 
> Acked-by: Pekka Paalanen 

I've applied the series with the typos changes you asked for

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] dt-bindings: display: Add SSD133x OLED controllers

2023-12-18 Thread Conor Dooley

On Mon, Dec 18, 2023 at 02:20:35PM +0100, Javier Martinez Canillas wrote:
> Add a Device Tree binding schema for the OLED panels based on the
> Solomon SSD133x family of controllers.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
> Changes in v2:
> - Unconditionally set the width and height constraints (Conor Dooley).
> - Fix indentation in the DTS examples (Krzysztof Kozlowski).
> 
>  .../bindings/display/solomon,ssd133x.yaml | 57 +++
>  1 file changed, 57 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml 
> b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
> new file mode 100644
> index ..8feee9eef0fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/solomon,ssd133x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Solomon SSD133x OLED Display Controllers
> +
> +maintainers:
> +  - Javier Martinez Canillas 
> +
> +properties:
> +  compatible:
> +enum:
> +  - solomon,ssd1331
> +
> +required:
> +  - compatible
> +  - reg
> +
> +allOf:
> +  - $ref: solomon,ssd-common.yaml#
> +
> +  - properties:
> +  width:
> +default: 96
> +  height:
> +default: 64

diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml 
b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
index 8feee9eef0fd..ffc939c782eb 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
@@ -9,24 +9,24 @@ title: Solomon SSD133x OLED Display Controllers
 maintainers:
   - Javier Martinez Canillas 
 
+allOf:
+  - $ref: solomon,ssd-common.yaml#
+
 properties:
   compatible:
 enum:
   - solomon,ssd1331
 
+  width:
+default: 96
+
+  height:
+default: 64
+
 required:
   - compatible
   - reg
 
-allOf:
-  - $ref: solomon,ssd-common.yaml#
-
-  - properties:
-  width:
-default: 96
-  height:
-default: 64
-
 unevaluatedProperties: false
 
 examples:

The properties stuff doesn't need to be in the allOf. Although, I took
the opportunity to look at ssd-common.yaml. How do the height/width here
differ from the vendor prefixed versions in that file?


signature.asc
Description: PGP signature

[RFC PATCH net-next v5 14/14] selftests: add ncdevmem, netcat for devmem TCP

ncdevmem is a devmem TCP netcat. It works similarly to netcat, but it
sends and receives data using the devmem TCP APIs. It uses udmabuf as
the dmabuf provider. It is compatible with a regular netcat running on
a peer, or a ncdevmem running on a peer.

In addition to normal netcat support, ncdevmem has a validation mode,
where it sends a specific pattern and validates this pattern on the
receiver side to ensure data integrity.

Suggested-by: Stanislav Fomichev 
Signed-off-by: Mina Almasry 

---

Changes in v1:
- Many more general cleanups (Willem).
- Removed driver reset (Jakub).
- Removed hardcoded if index (Paolo).

RFC v2:
- General cleanups (Willem).

---
 tools/testing/selftests/net/.gitignore |   1 +
 tools/testing/selftests/net/Makefile   |   5 +
 tools/testing/selftests/net/ncdevmem.c | 489 +
 3 files changed, 495 insertions(+)
 create mode 100644 tools/testing/selftests/net/ncdevmem.c

diff --git a/tools/testing/selftests/net/.gitignore 
b/tools/testing/selftests/net/.gitignore
index 2f9d378edec3..b644dbae58b7 100644
--- a/tools/testing/selftests/net/.gitignore
+++ b/tools/testing/selftests/net/.gitignore
@@ -17,6 +17,7 @@ ipv6_flowlabel
 ipv6_flowlabel_mgr
 log.txt
 msg_zerocopy
+ncdevmem
 nettest
 psock_fanout
 psock_snd
diff --git a/tools/testing/selftests/net/Makefile 
b/tools/testing/selftests/net/Makefile
index 14bd68da7466..d7a66563ffe7 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -5,6 +5,10 @@ CFLAGS =  -Wall -Wl,--no-as-needed -O2 -g
 CFLAGS += -I../../../../usr/include/ $(KHDR_INCLUDES)
 # Additional include paths needed by kselftest.h
 CFLAGS += -I../
+CFLAGS += -I../../../net/ynl/generated/
+CFLAGS += -I../../../net/ynl/lib/
+
+LDLIBS += ../../../net/ynl/lib/ynl.a ../../../net/ynl/generated/protos.a
 
 TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh \
  rtnetlink.sh xfrm_policy.sh test_blackhole_dev.sh
@@ -92,6 +96,7 @@ TEST_PROGS += test_vxlan_nolocalbypass.sh
 TEST_PROGS += test_bridge_backup_port.sh
 TEST_PROGS += fdb_flush.sh
 TEST_PROGS += fq_band_pktlimit.sh
+TEST_GEN_FILES += ncdevmem
 
 TEST_FILES := settings
 
diff --git a/tools/testing/selftests/net/ncdevmem.c 
b/tools/testing/selftests/net/ncdevmem.c
new file mode 100644
index ..7fbeee02b9a2
--- /dev/null
+++ b/tools/testing/selftests/net/ncdevmem.c
@@ -0,0 +1,489 @@
+// SPDX-License-Identifier: GPL-2.0
+#define _GNU_SOURCE
+#define __EXPORTED_HEADERS__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#define __iovec_defined
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "netdev-user.h"
+#include 
+
+#define PAGE_SHIFT 12
+#define TEST_PREFIX "ncdevmem"
+#define NUM_PAGES 16000
+
+#ifndef MSG_SOCK_DEVMEM
+#define MSG_SOCK_DEVMEM 0x200
+#endif
+
+/*
+ * tcpdevmem netcat. Works similarly to netcat but does device memory TCP
+ * instead of regular TCP. Uses udmabuf to mock a dmabuf provider.
+ *
+ * Usage:
+ *
+ * On server:
+ * ncdevmem -s  -c  -f eth1 -d 3 -n :06:00.0 -l \
+ * -p 5201 -v 7
+ *
+ * On client:
+ * yes $(echo -e \\x01\\x02\\x03\\x04\\x05\\x06) | \
+ * tr \\n \\0 | \
+ * head -c 5G | \
+ * nc  5201 -p 5201
+ *
+ * Note this is compatible with regular netcat. i.e. the sender or receiver can
+ * be replaced with regular netcat to test the RX or TX path in isolation.
+ */
+
+static char *server_ip = "192.168.1.4";
+static char *client_ip = "192.168.1.2";
+static char *port = "5201";
+static size_t do_validation;
+static int queue_num = 15;
+static char *ifname = "eth1";
+static unsigned int ifindex = 3;
+static char *nic_pci_addr = ":06:00.0";
+static unsigned int iterations;
+static unsigned int dmabuf_id;
+
+void print_bytes(void *ptr, size_t size)
+{
+   unsigned char *p = ptr;
+   int i;
+
+   for (i = 0; i < size; i++)
+   printf("%02hhX ", p[i]);
+   printf("\n");
+}
+
+void print_nonzero_bytes(void *ptr, size_t size)
+{
+   unsigned char *p = ptr;
+   unsigned int i;
+
+   for (i = 0; i < size; i++)
+   putchar(p[i]);
+   printf("\n");
+}
+
+void validate_buffer(void *line, size_t size)
+{
+   static unsigned char seed = 1;
+   unsigned char *ptr = line;
+   int errors = 0;
+   size_t i;
+
+   for (i = 0; i < size; i++) {
+   if (ptr[i] != seed) {
+   fprintf(stderr,
+   "Failed validation: expected=%u, actual=%u, 
index=%lu\n",
+   seed, ptr[i], i);
+   errors++;
+   if (errors > 20)
+   error(1, 0, "validation failed.");
+   }
+   seed++;
+   if (seed =

[PULL] drm-intel-next

2023-12-18 Thread Rodrigo Vivi

Hi Dave and Sima,

Here goes our latest drm-intel-next pull-request towards 6.8.

drm-intel-next-2023-12-18:

- Drop pointless null checks and fix a scaler bug (Ville)
- Meteor Lake display fixes and clean-ups (RK, Jani, Andrzej, Mika, Imre)
- Clean-up around flip done IRQ (Ville)
- Fix eDP Meteor Lake bug (Jani)
- Bigjoiner fixes (Ankit, Ville)
- Cdclk/voltage_level cleanups and fixes (Ville)
- DMC event stuff (Ville)
- Remove dead code around intel_atomic_helper->free_list (Jouni)

Thanks,
Rodrigo.

The following changes since commit 10690b8a49bceafb1badf0ad91842a359e796d8b:

  drm/i915/display: Add intel_fb_bo_framebuffer_fini (2023-12-07 17:31:02 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-12-18

for you to fetch changes up to 716c3cf21784479a1934b670ec67f320cbb5d308:

  drm/i915/display: Remove dead code around intel_atomic_helper->free_list 
(2023-12-18 13:37:01 +0200)


- Drop pointless null checks and fix a scaler bug (Ville)
- Meteor Lake display fixes and clean-ups (RK, Jani, Andrzej, Mika, Imre)
- Clean-up around flip done IRQ (Ville)
- Fix eDP Meteor Lake bug (Jani)
- Bigjoiner fixes (Ankit, Ville)
- Cdclk/voltage_level cleanups and fixes (Ville)
- DMC event stuff (Ville)
- Remove dead code around intel_atomic_helper->free_list (Jouni)


Andrzej Hajda (1):
  drm/i915/display: do not use cursor size reduction on MTL

Ankit Nautiyal (1):
  drm/i915/display: Get bigjoiner config before dsc config during readout

Imre Deak (1):
  drm/i915/mtl: Fix HDMI/DP PLL clock selection

Jani Nikula (1):
  drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

Jouni Högander (1):
  drm/i915/display: Remove dead code around intel_atomic_helper->free_list

Mika Kahola (1):
  drm/i915/display: Wait for PHY readiness not needed for disabling sequence

Radhakrishna Sripada (3):
  drm/i915/mtl: Use port clock compatible numbers for C20 phy
  drm/i915/mtl: Remove misleading "clock" field from C20 pll_state
  drm/i915/mtl: Rename the link_bit_rate to clock in C20 pll_state

Ville Syrjälä (24):
  drm/i915: Fix remapped stride with CCS on ADL+
  drm/i915: Fix intel_atomic_setup_scalers() plane_state handling
  drm/i915: Streamline intel_dsc_pps_read()
  drm/i915: Drop redundant NULL check
  drm/i915: Drop crtc NULL check from intel_crtc_active()
  drm/i915: Drop NULL fb check from intel_fb_uses_dpt()
  drm/i915: Drop redunant null check from intel_get_frame_time_us()
  drm/i915: s/cstate/crtc_state/ in intel_get_frame_time_us()
  drm/i915/tv: Drop redundant null checks
  drm/i915: Stop accessing crtc->state from the flip done irq
  drm/i915: Drop irqsave/restore for flip_done_handler()
  drm/i915: Reject async flips with bigjoiner
  drm/i915/cdclk: s/-1/~0/ when dealing with unsigned values
  drm/i915/cdclk: Give the squash waveform length a name
  drm/i915/cdclk: Remove the assumption that cdclk divider==2 when using 
squashing
  drm/i915/cdclk: Rewrite cdclk->voltage_level selection to use tables
  drm/i915/mtl: Fix voltage_level for cdclk==480MHz
  drm/i915: Split intel_ddi_compute_min_voltage_level() into platform 
variants
  drm/i915/mtl: Calculate the correct voltage level from port_clock
  drm/i915: Simplify intel_ddi_compute_min_voltage_level()
  drm/i915/dmc: Don't enable any pipe DMC events
  drm/i915/dmc: Also disable the flip queue event on TGL main DMC
  drm/i915/dmc: Also disable HRR event on TGL/ADLS main DMC
  drm/i915/dmc: Print out the DMC mmio register list at fw load time

 drivers/gpu/drm/i915/display/i9xx_wm.c |   2 +-
 drivers/gpu/drm/i915/display/intel_bios.c  |   3 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c | 111 ++--
 drivers/gpu/drm/i915/display/intel_crtc.c  |   9 +-
 drivers/gpu/drm/i915/display/intel_cx0_phy.c   |  82 +---
 drivers/gpu/drm/i915/display/intel_ddi.c   |  48 +--
 drivers/gpu/drm/i915/display/intel_ddi.h   |   3 +-
 drivers/gpu/drm/i915/display/intel_display.c   |  33 ++---
 drivers/gpu/drm/i915/display/intel_display_core.h  |   6 -
 .../gpu/drm/i915/display/intel_display_device.h|   2 +-
 .../gpu/drm/i915/display/intel_display_driver.c|   7 -
 drivers/gpu/drm/i915/display/intel_display_irq.c   |  15 +--
 drivers/gpu/drm/i915/display/intel_display_types.h |   6 +-
 drivers/gpu/drm/i915/display/intel_dmc.c   | 147 ++---
 drivers/gpu/drm/i915/display/intel_dmc_regs.h  |   1 +
 .../gpu/drm/i915/display/intel_dp_link_training.c  |  31 +++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c|   2 +-
 drivers/gpu/drm/i915/display/intel_fb.c|  18 ++-
 drivers/gpu/drm/i915/display/intel_psr.c   |   6

Re: [PATCH] RFC: drm/lima: fix calling drm_mm_init with an empty range

2023-12-18 Thread Qiang Yu

Thanks for the fix. It could be done in a simpler way that swap the
va_start/va_end init/fini and empty_vm create/release.

On Thu, Dec 14, 2023 at 5:04 PM Alban Browaeys  wrote:
>
> For the empty_vm initialization the range is empty which is not supported
> by drm_mm_init.
>
> With CONFIG_DRM_DEBUG_MM set, I get:
> [ cut here ]
>  kernel BUG at drivers/gpu/drm/drm_mm.c:965!
>  Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
>  Modules linked in: lima(+) drm_shmem_helper gpu_sched s5p_jpeg s5p_g2d
>  videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2
>  videobuf2_common s5p_cec tun fuse configfs auth_rpcgss sunrpc ip_tables
>  x_tables autofs4 btrfs lzo_compress zlib_deflate raid10 raid456
>  async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon
>  raid6_pq libcrc32c raid1 raid0 linear md_mod dm_mirror dm_region_hash
>  dm_log hid_logitech_hidpp hid_logitech_dj
>  CPU: 0 PID: 1033 Comm: systemd-udevd Not tainted 6.4.0-rc1-debug+ #230
>  Hardware name: Samsung Exynos (Flattened Device Tree)
>  PC is at drm_mm_init+0x94/0x98
>  LR is at 0x0
>  Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
>   drm_mm_init from lima_vm_create+0xcc/0x108 [lima]
>   lima_vm_create [lima] from lima_device_init+0xd8/0x4a0 [lima]
>   lima_device_init [lima] from lima_pdev_probe.part.0+0x6c/0x158 [lima]
>   lima_pdev_probe.part.0 [lima] from platform_probe+0x64/0xc0
>   platform_probe from call_driver_probe+0x2c/0x110
>
> The drm_mm.c line 965 is:
> drivers/gpu/drm/drm_mm.c
> void drm_mm_init(struct drm_mm *mm, u64 start, u64 size)
> {
> DRM_MM_BUG_ON(start + size <= start);
>
> lima_vm_create is called with va_start and va_end both unset
> in lima_device_init line 371:
> ldev->empty_vm = lima_vm_create(ldev);
>
> Signed-off-by: Alban Browaeys 
> ---
>  drivers/gpu/drm/lima/lima_device.c |  2 +-
>  drivers/gpu/drm/lima/lima_drv.c|  2 +-
>  drivers/gpu/drm/lima/lima_vm.c | 10 +++---
>  drivers/gpu/drm/lima/lima_vm.h |  3 ++-
>  4 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_device.c 
> b/drivers/gpu/drm/lima/lima_device.c
> index 02cef0cea657..bd3afff0f44a 100644
> --- a/drivers/gpu/drm/lima/lima_device.c
> +++ b/drivers/gpu/drm/lima/lima_device.c
> @@ -368,7 +368,7 @@ int lima_device_init(struct lima_device *ldev)
> if (err)
> goto err_out0;
>
> -   ldev->empty_vm = lima_vm_create(ldev);
> +   ldev->empty_vm = lima_vm_create(ldev, false);
> if (!ldev->empty_vm) {
> err = -ENOMEM;
> goto err_out1;
> diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
> index 10fd9154cc46..ca09142e0ac1 100644
> --- a/drivers/gpu/drm/lima/lima_drv.c
> +++ b/drivers/gpu/drm/lima/lima_drv.c
> @@ -219,7 +219,7 @@ static int lima_drm_driver_open(struct drm_device *dev, 
> struct drm_file *file)
> if (!priv)
> return -ENOMEM;
>
> -   priv->vm = lima_vm_create(ldev);
> +   priv->vm = lima_vm_create(ldev, true);
> if (!priv->vm) {
> err = -ENOMEM;
> goto err_out0;
> diff --git a/drivers/gpu/drm/lima/lima_vm.c b/drivers/gpu/drm/lima/lima_vm.c
> index 2b2739adc7f5..7f9775eefd78 100644
> --- a/drivers/gpu/drm/lima/lima_vm.c
> +++ b/drivers/gpu/drm/lima/lima_vm.c
> @@ -197,7 +197,7 @@ u32 lima_vm_get_va(struct lima_vm *vm, struct lima_bo *bo)
> return ret;
>  }
>
> -struct lima_vm *lima_vm_create(struct lima_device *dev)
> +struct lima_vm *lima_vm_create(struct lima_device *dev, bool has_drm_mm)
>  {
> struct lima_vm *vm;
>
> @@ -221,7 +221,10 @@ struct lima_vm *lima_vm_create(struct lima_device *dev)
> goto err_out1;
> }
>
> -   drm_mm_init(&vm->mm, dev->va_start, dev->va_end - dev->va_start);
> +   if (has_drm_mm) {
> +   vm->has_drm_mm = true;
> +   drm_mm_init(&vm->mm, dev->va_start, dev->va_end - 
> dev->va_start);
> +   }
>
> return vm;
>
> @@ -237,7 +240,8 @@ void lima_vm_release(struct kref *kref)
> struct lima_vm *vm = container_of(kref, struct lima_vm, refcount);
> int i;
>
> -   drm_mm_takedown(&vm->mm);
> +   if (vm->has_drm_mm)
> +   drm_mm_takedown(&vm->mm);
>
> for (i = 0; i < LIMA_VM_NUM_BT; i++) {
> if (vm->bts[i].cpu)
> diff --git a/drivers/gpu/drm/lima/lima_vm.h b/drivers/gpu/drm/lima/lima_vm.h
> index 3a7c74822d8b..e7443f410d6d 100644
> --- a/drivers/gpu/drm/lima/lima_vm.h
> +++ b/drivers/gpu/drm/lima/lima_vm.h
> @@ -30,6 +30,7 @@ struct lima_vm {
> struct mutex lock;
> struct kref refcount;
>
> +   bool has_drm_mm;
> struct drm_mm mm;
>
> struct lima_device *dev;
> @@ -43,7 +44,7 @@ void lima_vm_bo_del(struct lima_vm *vm, struct lima_bo *bo);
>
>  u32 lima_vm_get_va(struct lima_vm *vm, struct lima_bo *bo);
>
> -struct lima_vm *lima_vm_create(

Re: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()

2023-12-18 Thread Laurent Pinchart

Hi Biju,

Thank you for the patch.

On Thu, Nov 16, 2023 at 12:24:24PM +, Biju Das wrote:
> The rcar_du_vsps_init() doesn't free the np allocated by
> of_parse_phandle_with_fixed_args() for the non-error case.
> 
> Fix memory leak for the non-error case.
> 
> While at it, replace the label 'error'->'done' as it applies to non-error
> case as well and update the error check condition for rcar_du_vsp_init()
> to avoid breakage in future, if it returns positive value.
> 
> Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same 
> VSP")
> Signed-off-by: Biju Das 

Reviewed-by: Laurent Pinchart 

> ---
> v1->v2:
>  * Replaced the label 'error'->'done' as it applies to non-error case as
>well.
>  * Update the error check condition for rcar_du_vsp_init() to avoid
>breakage in future, if it returns positive value.
> ---
>  drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> index 70d8ad065bfa..4c8fe83dd610 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> @@ -705,7 +705,7 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
>   ret = of_parse_phandle_with_fixed_args(np, vsps_prop_name,
>  cells, i, &args);
>   if (ret < 0)
> - goto error;
> + goto done;
>  
>   /*
>* Add the VSP to the list or update the corresponding existing
> @@ -743,13 +743,11 @@ static int rcar_du_vsps_init(struct rcar_du_device 
> *rcdu)
>   vsp->dev = rcdu;
>  
>   ret = rcar_du_vsp_init(vsp, vsps[i].np, vsps[i].crtcs_mask);
> - if (ret < 0)
> - goto error;
> + if (ret)
> + goto done;
>   }
>  
> - return 0;
> -
> -error:
> +done:
>   for (i = 0; i < ARRAY_SIZE(vsps); ++i)
>   of_node_put(vsps[i].np);
>  

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers

2023-12-18 Thread Conor Dooley

On Sun, Dec 17, 2023 at 10:33:24PM +0100, Javier Martinez Canillas wrote:
> Conor Dooley  writes:
> 
> Hello Connor,
> 
> > On Sun, Dec 17, 2023 at 11:07:03AM +0100, Javier Martinez Canillas wrote:
> 
> [...]
> 
> >> +properties:
> >> +  compatible:
> >> +enum:
> >> +  - solomon,ssd1331
> >> +
> >> +required:
> >> +  - compatible
> >> +  - reg
> >> +
> >> +allOf:
> >> +  - $ref: solomon,ssd-common.yaml#
> >> +
> >> +  - if:
> >> +  properties:
> >> +compatible:
> >> +  contains:
> >> +const: solomon,ssd1331
> >> +then:
> >> +  properties:
> >> +width:
> >> +  default: 96
> >> +height:
> >> +  default: 64
> >
> > Do you envisage a rake of devices that are going to end up in this
> > binding? Otherwise, why not unconditionally set the constraints?
> >
> 
> Because these are only for the default width and height, there can be
> panels using the same controller but that have a different resolution.
> 
> For example, there are panels using the SSD1306 controller that have
> 128x32 [0], 64x32 [1] or 128x64 [2] resolutions.

This, as you know, does not matter here.

> But answering your question, yes I think that more devices for this
> SSD133x family are going to be added later. Looking at [3], there is
> at least SSD1333 that has a different default resolutions (176x176).

That's fair enough though. I'd probably err on the side of introducing
this complexity when the other users actually show up though.

> 
> I think that even the SSD135x family could be supported by the same
> modsetting pipeline, but I need to get one to figure it out.
> 
> [0]: https://es.aliexpress.com/item/1005003648174074.html
> [1]: 
> https://www.buydisplay.com/white-0-49-inch-oled-display-64x32-iic-i2c-ssd1306-connector-fpc
> [2]: https://es.aliexpress.com/item/1005001582340858.html?gatewayAdapt=glo2esp
> [3]: https://www.solomon-systech.com/product-search/?technology=oled-display
> 
> > Cheers,
> > Conor.
> 
> -- 
> Best regards,
> 
> Javier Martinez Canillas
> Core Platforms
> Red Hat
> 


signature.asc
Description: PGP signature

[PATCH 2/2] drm/ssd130x: Add support for the SSD133x OLED controller family

The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot
matrix OLED panels, add a modesetting pipeline to support the chip family.

The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths
but only the former is implemented for now. This is because the 256 color
depth format matches a fourcc code already present in DRM (RGB8), but the
65k pixel format does not match the existing RG16 fourcc code format.

Instead of a R:G:B 5:6:5, the controller expects the 16-bit pixels to be
R:G:B 6:5:6, and so a new fourcc needs to be added to support this format.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/gpu/drm/solomon/ssd130x-i2c.c |   5 +
 drivers/gpu/drm/solomon/ssd130x-spi.c |   7 +
 drivers/gpu/drm/solomon/ssd130x.c | 370 ++
 drivers/gpu/drm/solomon/ssd130x.h |   5 +-
 4 files changed, 386 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c 
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
index f2ccab9c06d9..a047dbec4e48 100644
--- a/drivers/gpu/drm/solomon/ssd130x-i2c.c
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -105,6 +105,11 @@ static const struct of_device_id ssd130x_of_match[] = {
.compatible = "solomon,ssd1327",
.data = &ssd130x_variants[SSD1327_ID],
},
+   /* ssd133x family */
+   {
+   .compatible = "solomon,ssd1331",
+   .data = &ssd130x_variants[SSD1331_ID],
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, ssd130x_of_match);
diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c 
b/drivers/gpu/drm/solomon/ssd130x-spi.c
index 84e035a7ab3f..84bfde31d172 100644
--- a/drivers/gpu/drm/solomon/ssd130x-spi.c
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -142,6 +142,11 @@ static const struct of_device_id ssd130x_of_match[] = {
.compatible = "solomon,ssd1327",
.data = &ssd130x_variants[SSD1327_ID],
},
+   /* ssd133x family */
+   {
+   .compatible = "solomon,ssd1331",
+   .data = &ssd130x_variants[SSD1331_ID],
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, ssd130x_of_match);
@@ -166,6 +171,8 @@ static const struct spi_device_id ssd130x_spi_table[] = {
{ "ssd1322", SSD1322_ID },
{ "ssd1325", SSD1325_ID },
{ "ssd1327", SSD1327_ID },
+   /* ssd133x family */
+   { "ssd1331", SSD1331_ID },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(spi, ssd130x_spi_table);
diff --git a/drivers/gpu/drm/solomon/ssd130x.c 
b/drivers/gpu/drm/solomon/ssd130x.c
index bef293922b98..447d0c7c88c6 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -119,6 +119,26 @@
 #define SSD130X_SET_VCOMH_VOLTAGE  0xbe
 #define SSD132X_SET_FUNCTION_SELECT_B  0xd5
 
+/* ssd133x commands */
+#define SSD133X_SET_COL_RANGE  0x15
+#define SSD133X_SET_ROW_RANGE  0x75
+#define SSD133X_CONTRAST_A 0x81
+#define SSD133X_CONTRAST_B 0x82
+#define SSD133X_CONTRAST_C 0x83
+#define SSD133X_SET_MASTER_CURRENT 0x87
+#define SSD132X_SET_PRECHARGE_A0x8a
+#define SSD132X_SET_PRECHARGE_B0x8b
+#define SSD132X_SET_PRECHARGE_C0x8c
+#define SSD133X_SET_DISPLAY_START  0xa1
+#define SSD133X_SET_DISPLAY_OFFSET 0xa2
+#define SSD133X_SET_DISPLAY_NORMAL 0xa4
+#define SSD133X_SET_MASTER_CONFIG  0xad
+#define SSD133X_POWER_SAVE_MODE0xb0
+#define SSD133X_PHASES_PERIOD  0xb1
+#define SSD133X_SET_CLOCK_FREQ 0xb3
+#define SSD133X_SET_PRECHARGE_VOLTAGE  0xbb
+#define SSD133X_SET_VCOMH_VOLTAGE  0xbe
+
 #define MAX_CONTRAST 255
 
 const struct ssd130x_deviceinfo ssd130x_variants[] = {
@@ -180,6 +200,12 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_width = 128,
.default_height = 128,
.family_id = SSD132X_FAMILY,
+   },
+   /* ssd133x family */
+   [SSD1331_ID] = {
+   .default_width = 96,
+   .default_height = 64,
+   .family_id = SSD133X_FAMILY,
}
 };
 EXPORT_SYMBOL_NS_GPL(ssd130x_variants, DRM_SSD130X);
@@ -589,6 +615,117 @@ static int ssd132x_init(struct ssd130x_device *ssd130x)
return 0;
 }
 
+static int ssd133x_init(struct ssd130x_device *ssd130x)
+{
+   int ret;
+
+   /* Set color A contrast */
+   ret = ssd130x_write_cmd(ssd130x, 2, SSD133X_CONTRAST_A, 0x91);
+   if (ret < 0)
+   return ret;
+
+   /* Set color B contrast */
+   ret = ssd130x_write_cmd(ssd130x, 2, SSD133X_CONTRAST_B, 0x50);
+   if (ret < 0)
+   return ret;
+
+   /* Set color C contrast */
+   ret = ssd130x_write_cmd(ssd130x, 2, SSD133X_CONTRAST_C, 0x7d);
+   i

[PATCH v2 2/2] drm/rockchip: rk3066_hdmi: drop custom fill_modes hook

2023-12-18 Thread Johan Jonker

CRTC size validation for the display controller has been added with
Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
hardware capabilities"), so we can drop the custom fill_modes hook.

Signed-off-by: Johan Jonker 
---
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c 
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 0dac6d133767..6dadd753985c 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -501,18 +501,6 @@ rk3066_hdmi_connector_best_encoder(struct drm_connector 
*connector)
return &hdmi->encoder.encoder;
 }

-static int
-rk3066_hdmi_probe_single_connector_modes(struct drm_connector *connector,
-uint32_t maxX, uint32_t maxY)
-{
-   if (maxX > 1920)
-   maxX = 1920;
-   if (maxY > 1080)
-   maxY = 1080;
-
-   return drm_helper_probe_single_connector_modes(connector, maxX, maxY);
-}
-
 static void rk3066_hdmi_connector_destroy(struct drm_connector *connector)
 {
drm_connector_unregister(connector);
@@ -520,7 +508,7 @@ static void rk3066_hdmi_connector_destroy(struct 
drm_connector *connector)
 }

 static const struct drm_connector_funcs rk3066_hdmi_connector_funcs = {
-   .fill_modes = rk3066_hdmi_probe_single_connector_modes,
+   .fill_modes = drm_helper_probe_single_connector_modes,
.detect = rk3066_hdmi_connector_detect,
.destroy = rk3066_hdmi_connector_destroy,
.reset = drm_atomic_helper_connector_reset,
--
2.39.2

[RFC PATCH net-next v5 13/14] net: add devmem TCP documentation

Signed-off-by: Mina Almasry 

---

v1 -> v2:

- Missing spdx (simon)
- add to index.rst (simon)

---
 Documentation/networking/devmem.rst | 271 
 Documentation/networking/index.rst  |   1 +
 2 files changed, 272 insertions(+)
 create mode 100644 Documentation/networking/devmem.rst

diff --git a/Documentation/networking/devmem.rst 
b/Documentation/networking/devmem.rst
new file mode 100644
index ..4712f029e5ed
--- /dev/null
+++ b/Documentation/networking/devmem.rst
@@ -0,0 +1,271 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Device Memory TCP
+=
+
+
+Intro
+=
+
+Device memory TCP (devmem TCP) enables receiving data directly into device
+memory (dmabuf). The feature is currently implemented for TCP sockets.
+
+
+Opportunity
+---
+
+A large amount of data transfers have device memory as the source and/or
+destination. Accelerators drastically increased the volume of such transfers.
+Some examples include:
+
+- Distributed training, where ML accelerators, such as GPUs on different hosts,
+  exchange data among them.
+
+- Distributed raw block storage applications transfer large amounts of data 
with
+  remote SSDs, much of this data does not require host processing.
+
+Today, the majority of the Device-to-Device data transfers the network are
+implemented as the following low level operations: Device-to-Host copy,
+Host-to-Host network transfer, and Host-to-Device copy.
+
+The implementation is suboptimal, especially for bulk data transfers, and can
+put significant strains on system resources such as host memory bandwidth and
+PCIe bandwidth.
+
+Devmem TCP optimizes this use case by implementing socket APIs that enable
+the user to receive incoming network packets directly into device memory.
+
+Packet payloads go directly from the NIC to device memory.
+
+Packet headers go to host memory and are processed by the TCP/IP stack
+normally. The NIC must support header split to achieve this.
+
+Advantages:
+
+- Alleviate host memory bandwidth pressure, compared to existing
+  network-transfer + device-copy semantics.
+
+- Alleviate PCIe bandwidth pressure, by limiting data transfer to the lowest
+  level of the PCIe tree, compared to traditional path which sends data through
+  the root complex.
+
+
+More Info
+-
+
+  slides, video
+https://netdevconf.org/0x17/sessions/talk/device-memory-tcp.html
+
+  patchset
+[RFC PATCH v3 00/12] Device Memory TCP
+
https://lore.kernel.org/lkml/20231106024413.2801438-1-almasrym...@google.com/T/
+
+
+Interface
+=
+
+Example
+---
+
+tools/testing/selftests/net/ncdevmem.c:do_server shows an example of setting up
+the RX path of this API.
+
+NIC Setup
+-
+
+Header split, flow steering, & RSS are required features for devmem TCP.
+
+Header split is used to split incoming packets into a header buffer in host
+memory, and a payload buffer in device memory.
+
+Flow steering & RSS are used to ensure that only flows targeting devmem land on
+RX queue bound to devmem.
+
+Enable header split & flow steering:
+
+::
+
+   # enable header split (assuming priv-flag)
+   ethtool --set-priv-flags eth1 enable-header-split on
+
+   # enable flow steering
+   ethtool -K eth1 ntuple on
+
+Configure RSS to steer all traffic away from the target RX queue (queue 15 in
+this example):
+
+::
+
+   ethtool --set-rxfh-indir eth1 equal 15
+
+
+The user must bind a dmabuf to any number of RX queues on a given NIC using
+netlink API:
+
+::
+
+   /* Bind dmabuf to NIC RX queue 15 */
+   struct netdev_queue *queues;
+   queues = malloc(sizeof(*queues) * 1);
+
+   queues[0]._present.type = 1;
+   queues[0]._present.idx = 1;
+   queues[0].type = NETDEV_RX_QUEUE_TYPE_RX;
+   queues[0].idx = 15;
+
+   *ys = ynl_sock_create(&ynl_netdev_family, &yerr);
+
+   req = netdev_bind_rx_req_alloc();
+   netdev_bind_rx_req_set_ifindex(req, 1 /* ifindex */);
+   netdev_bind_rx_req_set_dmabuf_fd(req, dmabuf_fd);
+   __netdev_bind_rx_req_set_queues(req, queues, n_queue_index);
+
+   rsp = netdev_bind_rx(*ys, req);
+
+   dmabuf_id = rsp->dmabuf_id;
+
+
+The netlink API returns a dmabuf_id: a unique ID that refers to this dmabuf
+that has been bound.
+
+Socket Setup
+
+
+The socket must be flow steering to the dmabuf bound RX queue:
+
+::
+
+   ethtool -N eth1 flow-type tcp4 ... queue 15,
+
+
+Receiving data
+--
+
+The user application must signal to the kernel that it is capable of receiving
+devmem data by passing the MSG_SOCK_DEVMEM flag to recvmsg:
+
+::
+
+   ret = recvmsg(fd, &msg, MSG_SOCK_DEVMEM);
+
+Applications that do not specify the MSG_SOCK_DEVMEM flag will receive an 
EFAULT
+on devmem data.
+
+Devmem data is received directly into the dmabuf bound to the NIC in 'NIC
+Setup', and the kernel signals such to the user via the SCM_DEVMEM_* cmsgs:
+
+::
+
+   for (cm = CMSG_FIRSTHDR(

[PATCH 0/2] drm/solomon: Add support for the SSD133x controller family

Hello,

This patch-set adds support for the family of SSD133x Solomon controllers,
such as the SSD1331. These are used for RGB Dot Matrix OLED/PLED panels.

The patches were tested on a Waveshare SSD1331 display using glmark2-drm,
fbcon, fbtests and the retroarch emulator.

Patch #1 adds a DT binding schema for the SSD133x controllers and patch #2
extends the ssd130x DRM driver to support the SSD133x controller family.

Best regards,
Javier


Javier Martinez Canillas (2):
  dt-bindings: display: Add SSD133x OLED controllers
  drm/ssd130x: Add support for the SSD133x OLED controller family

 .../bindings/display/solomon,ssd133x.yaml |  63 +++
 drivers/gpu/drm/solomon/ssd130x-i2c.c |   5 +
 drivers/gpu/drm/solomon/ssd130x-spi.c |   7 +
 drivers/gpu/drm/solomon/ssd130x.c | 370 ++
 drivers/gpu/drm/solomon/ssd130x.h |   5 +-
 5 files changed, 449 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/solomon,ssd133x.yaml

-- 
2.43.0

[PATCH v2 0/2] Rockchip rk3066_hdmi update

2023-12-18 Thread Johan Jonker

Update the Rockchip rk3066_hdmi driver in a somewhat similar way
to what is proposed for the inno_hdmi driver.

Changed V2:
  Drop already applied patches
  Remove "Remove useless output format" patch for now
  Add fill_modes hook removal patch

Johan Jonker (2):
  drm/rockchip: rk3066_hdmi: remove unused drm device pointer
  drm/rockchip: rk3066_hdmi: drop custom fill_modes hook

 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

--
2.39.2

[PATCH] drm/msm/a6xx: Fix recovery vs runpm race

2023-12-18 Thread Rob Clark

From: Rob Clark 

a6xx_recover() is relying on the gpu lock to serialize against incoming
submits doing a runpm get, as it tries to temporarily balance out the
runpm gets with puts in order to power off the GPU.  Unfortunately this
gets worse when we (in a later patch) will move the runpm get out of the
scheduler thread/work to move it out of the fence signaling path.

Instead we can just simplify the whole thing by using force_suspend() /
force_resume() instead of trying to be clever.

Reported-by: David Heidelberg 
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10272
Fixes: abe2023b4cea ("drm/msm/gpu: Push gpu lock down past runpm")
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 268737e59131..a5660d63535b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1244,12 +1244,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
dev_pm_genpd_add_notifier(gmu->cxpd, &gmu->pd_nb);
dev_pm_genpd_synced_poweroff(gmu->cxpd);
 
-   /* Drop the rpm refcount from active submits */
-   if (active_submits)
-   pm_runtime_put(&gpu->pdev->dev);
-
-   /* And the final one from recover worker */
-   pm_runtime_put_sync(&gpu->pdev->dev);
+   pm_runtime_force_suspend(&gpu->pdev->dev);
 
if (!wait_for_completion_timeout(&gmu->pd_gate, msecs_to_jiffies(1000)))
DRM_DEV_ERROR(&gpu->pdev->dev, "cx gdsc didn't collapse\n");
@@ -1258,10 +1253,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
 
pm_runtime_use_autosuspend(&gpu->pdev->dev);
 
-   if (active_submits)
-   pm_runtime_get(&gpu->pdev->dev);
-
-   pm_runtime_get_sync(&gpu->pdev->dev);
+   pm_runtime_force_resume(&gpu->pdev->dev);
 
gpu->active_submits = active_submits;
mutex_unlock(&gpu->active_lock);
-- 
2.43.0

[PATCH] drm/bridge: ps8640: Fix size mismatch warning w/ len

2023-12-18 Thread Douglas Anderson

After commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of
ps8640 to fetch the EDID"), I got an error compiling:

  error: comparison of distinct pointer types
  ('typeof (len) *' (aka 'unsigned int *') and
   'typeof (msg->size) *' (aka 'unsigned long *'))
  [-Werror,-Wcompare-distinct-pointer-types]

Fix it by declaring the `len` as size_t.

Fixes: 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch 
the EDID")
Signed-off-by: Douglas Anderson 
---
Sorry for sending this hot on the heels of the other patch, but for
some reason that other patch compiled fine for me until I picked it
back to my downstream tree. I'll see if I can track down why. In any
case, as soon as I see a Reviewed-by tag I'll land this.

 drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index d264b80d909d..541e4f5afc4c 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -210,7 +210,7 @@ static ssize_t ps8640_aux_transfer_msg(struct drm_dp_aux 
*aux,
struct ps8640 *ps_bridge = aux_to_ps8640(aux);
struct regmap *map = ps_bridge->regmap[PAGE0_DP_CNTL];
struct device *dev = &ps_bridge->page[PAGE0_DP_CNTL]->dev;
-   unsigned int len = msg->size;
+   size_t len = msg->size;
unsigned int data;
unsigned int base;
int ret;
-- 
2.43.0.472.g3155946c3a-goog

Re: [PATCH 1/5] clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate



On 2023-12-18 at 14:35:19 +0100, Frank Oltmanns  wrote:
> The Allwinner A64 manual lists the following constraints for the
> PLL-MIPI clock:
>  - M/N >= 3
>  - (PLL_VIDEO0)/M >= 24MHz
>
> The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
> these constraints.
>
> Signed-off-by: Frank Oltmanns 
> ---
>  drivers/clk/sunxi-ng/ccu_nkm.c | 23 +++
>  drivers/clk/sunxi-ng/ccu_nkm.h |  8 
>  2 files changed, 31 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> index eed64547ad42..2af5c1ebd527 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> @@ -16,6 +16,20 @@ struct _ccu_nkm {
>   unsigned long   m, min_m, max_m;
>  };
>
> +static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long 
> parent,
> +   unsigned long n, unsigned long m)
> +{
> + struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
> +
> + if (nkm->max_mn_ratio && (m > nkm->max_mn_ratio * n))
> + return false;
> +
> + if (nkm->parent_wo_nk && (parent < nkm->parent_wo_nk * m))
> + return false;
> +
> + return true;
> +}
> +
>  static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common 
> *common,
>  struct clk_hw *parent_hw,
>  unsigned long *parent, 
> unsigned long rate,
> @@ -32,6 +46,9 @@ static unsigned long 
> ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
>
>   tmp_parent = clk_hw_round_rate(parent_hw, rate 
> * _m / (_n * _k));
>
> + if (!ccu_nkm_is_valid_rate(common, tmp_parent, 
> _n, _m))
> + continue;
> +
>   tmp_rate = tmp_parent * _n * _k / _m;
>
>   if (ccu_is_better_rate(common, rate, tmp_rate, 
> best_rate) ||
> @@ -65,6 +82,12 @@ static unsigned long ccu_nkm_find_best(unsigned long 
> parent, unsigned long rate,
>   for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
>   for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
>   for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
> + if ((common->reg == 0x040) && (_m > 3 * _n))
> + break;
> +
> + if ((common->reg == 0x040) && (parent < 
> 2400 * _m))
> + continue;
> +

This, of course, is rubbish and should be this instead:
+   if (!ccu_nkm_is_valid_rate(common, parent, _n, 
_m))
+   continue;
+

I'll submit a V2 after receiving some feedback.

>   unsigned long tmp_rate;
>
>   tmp_rate = parent * _n * _k / _m;
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
> index 6601defb3f38..d3d3eaf55faf 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
> @@ -16,6 +16,12 @@
>   * struct ccu_nkm - Definition of an N-K-M clock
>   *
>   * Clocks based on the formula parent * N * K / M
> + *
> + * @max_mn_ratio:Maximum value for M / N.
> + * @parent_wo_nk:The minimum rate the parent must provide after applying 
> the divisor,
> + *   but without applying the multipliers, i.e. the 
> contstraint
> + *  (parent rate)/M >= parent_wo_nk
> + *   must be fulfilled.
>   */
>  struct ccu_nkm {
>   u32 enable;
> @@ -27,6 +33,8 @@ struct ccu_nkm {
>   struct ccu_mux_internal mux;
>
>   unsigned intfixed_post_div;
> + unsigned long   max_mn_ratio;
> + unsigned long   parent_wo_nk;
>
>   struct ccu_common   common;
>  };

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

2023-12-18 Thread H. Nikolaus Schaller




> Am 18.12.2023 um 11:14 schrieb Maxime Ripard :
> 
> On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
>> Hi Maxime,
>> 
>>> Am 15.12.2023 um 14:33 schrieb Maxime Ripard :
>>> 
> 
> It's for a separate architecture, with a separate driver, maintained out
> of tree by a separate community, with a separate set of requirements as
> evidenced by the other thread. And that's all fine in itself, but
> there's very little reason to put these two bindings in the same file.
> 
> We could also turn this around, why is it important that it's in the
> same file?
 
 Same vendor. And enough similarity in architectures, even a logical 
 sequence
 of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
 (SGX and Rogue seem to be just trade names for their architecture 
 development).
>>> 
>>> Again, none of that matters for *where* the binding is stored.
>> 
>> So what then speaks against extending the existing bindings file as proposed
>> here?
> 
> I mean, apart from everything you quoted, then sure, nothing speaks
> against it.
> 
 AFAIK bindings should describe hardware and not communities or drivers
 or who is currently maintaining it. The latter can change, the first not.
>>> 
>>> Bindings are supposed to describe hardware indeed. Nothing was ever said
>>> about where those bindings are supposed to be located.
>>> 
>>> There's hundreds of other YAML bindings describing devices of the same
>>> vendors and different devices from the same generation.
>> 
>> Usually SoC seem to be split over multiple files by subsystem. Not by 
>> versions
>> or generations. If the subsystems are similar enough they share the same 
>> bindings
>> doc instead of having one for each generation duplicating a lot of code.
>> 
>> Here is a comparable example that combines multiple vendors and generations:
>> 
>> Documentation/devicetree/bindings/usb/generic-ehci.yaml
> 
> EHCI is a single interface for USB2.0 controllers. It's a standard API,
> and is made of a single driver that requires minor modifications to deal
> with multiple devices.
> 
> We're very far from the same situation here.

How far are we really? And, it is the purpose of the driver to handle different 
cases.

That there are currently two drivers is just a matter of history and not a 
necessity.

> 
>>> If anything it'll make it easier for you. I'm really not sure why it is
>>> controversial and you're fighting this so hard.
>> 
>> Well, you made it controversial by proposing to split what IMHO belongs 
>> together.
> 
> No, reviews aren't controversial.
> The controversy started when you chose
> to oppose it while you could have just rolled with it.

Well, you asked

"I think it would be best to have a separate file for this, img,sgx.yaml
maybe?"

and

"Because it's more convenient?"

I understood that as an invitation for discussing the pros and cons and working 
out the
most convenient solution. And that involves playing the devil's advocate which 
of course
is controversial by principle.

Now, IMHO all the pros and cons are on the table and the question is who makes 
a decision
how to go.

> 
>> I feel that the original patch is good enough for its purpose and follows
>> some design pattern that can be deduced from other binding docs.
> 
> [citation needed]

Joke: Documentation/devicetree/bindings/* - I am not aware of a formal analysis 
of course.

But see my example for ehci. It follows the pattern I mean. If clocks, regs, 
interrupts,
resets, and more properties are (almost) the same, then group them and just 
differentiate
by different compatible strings. If necessary use some - if: clauses.

It is the task of drivers to handle the details.

As my other (maybe more important) comment to this patch did indicate we IMHO 
can easily
live with something like

+  - items:
+  - enum:
+  - ti,am62-gpu # IMG AXE GPU model/revision is fully discoverable
+  - ti,omap3430-gpu # sgx530 Rev 121
+  - ti,omap3630-gpu # sgx530 Rev 125
+  - ingenic,jz4780-gpu # sgx540 Rev 130
+  - ti,omap4430-gpu # sgx540 Rev 120
+  - allwinner,sun6i-a31-gpu # sgx544 MP2 Rev 115
+  - ti,omap4470-gpu # sgx544 MP1 Rev 112
+  - ti,omap5432-gpu # sgx544 MP2 Rev 105
+  - ti,am5728-gpu # sgx544 MP2 Rev 116
+  - ti,am6548-gpu # sgx544 MP1 Rev 117

And leave it to drivers using a table to deduce the generation and
revision or read it out from the chip. And there can even be different
drivers handling only a subset of the potential compatibles.

Then the currently-out-of-tree driver for the sgx5 can be reworked in
less than half an hour without loosing functionality.

BR,
Nikolaus

Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

2023-12-18 Thread Luca Ceresoli

Hi,

On Mon, 18 Dec 2023 04:36:55 +0200
Laurent Pinchart  wrote:

> On Fri, Dec 15, 2023 at 05:09:41PM -0300, Fabio Estevam wrote:
> > On Fri, Dec 15, 2023 at 4:01 PM Adam Ford  wrote:
> >   
> > > Thanks for the list.  I was able to successfully build the stable 6.6
> > > branch with those patches applied and I have the HDMI working.
> > > Unfortunately, I get build errors on the linux-next, so it's going to
> > > take me a little time to sort through all of this.  
> > 
> > If you need help to figure this problem out, please let me know.
> > 
> > I haven't tried it against linux-next.
> >   
> > > I am thinking that it would be better to consolidate all these
> > > together into one series instead of piecemealing it.  However, there
> > > are some items that can be submitted right away without significantly
> > > reworking them against linux-next.  Do people have a preference?  
> > 
> > I think it makes sense to re-submit the "easy ones" right away.  
> 
> Agreed. The more we can merge quickly, the easier it will become to
> rebase and upstream the rest.

I agree as well, "release early, release often". These patches are
around since a long time and lots of people are using them already, and
tracking all of them from different threads is time-consuming. I will
happily test them early as soon as they are sent.

Luca

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

[PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers

Add a Device Tree binding schema for the OLED panels based on the
Solomon SSD133x family of controllers.

Signed-off-by: Javier Martinez Canillas 
---

 .../bindings/display/solomon,ssd133x.yaml | 63 +++
 1 file changed, 63 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/solomon,ssd133x.yaml

diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml 
b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
new file mode 100644
index ..eee8d8c9ca35
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd133x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD133x OLED Display Controllers
+
+maintainers:
+  - Javier Martinez Canillas 
+
+properties:
+  compatible:
+enum:
+  - solomon,ssd1331
+
+required:
+  - compatible
+  - reg
+
+allOf:
+  - $ref: solomon,ssd-common.yaml#
+
+  - if:
+  properties:
+compatible:
+  contains:
+const: solomon,ssd1331
+then:
+  properties:
+width:
+  default: 96
+height:
+  default: 64
+
+unevaluatedProperties: false
+
+examples:
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+oled@3c {
+compatible = "solomon,ssd1331";
+reg = <0x3c>;
+reset-gpios = <&gpio2 7>;
+};
+
+};
+  - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+oled@0 {
+compatible = "solomon,ssd1331";
+reg = <0x0>;
+reset-gpios = <&gpio2 7>;
+dc-gpios = <&gpio2 8>;
+spi-max-frequency = <1000>;
+};
+};
-- 
2.43.0

Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers

Conor Dooley  writes:

Hello Conor,

> On Sun, Dec 17, 2023 at 10:33:24PM +0100, Javier Martinez Canillas wrote:

[...]

>> >> +then:
>> >> +  properties:
>> >> +width:
>> >> +  default: 96
>> >> +height:
>> >> +  default: 64
>> >
>> > Do you envisage a rake of devices that are going to end up in this
>> > binding? Otherwise, why not unconditionally set the constraints?
>> >
>> 
>> Because these are only for the default width and height, there can be
>> panels using the same controller but that have a different resolution.
>> 
>> For example, there are panels using the SSD1306 controller that have
>> 128x32 [0], 64x32 [1] or 128x64 [2] resolutions.
>
> This, as you know, does not matter here.
>

Are you sure? What I tried to say is that the SSD133x are just OLED
controllers and manufacturers use those chips to attach a panel that
has a certain resolution.

While it makes sense to use all the supported width and height, some
manufacturers chose to have a smaller panel instead (I used SSD1306
as an example because I knew about these but the same might be true
for let's say SSD1331).

Or saying another way, are you sure that every manufacturer selling
RGB OLED panels using the SSD1331 chip will use the default resolution
and users won't have to set a custom width and height ?

I have already chosen to make the DT binding as simple as possible to
prevent what happened with the SSD1306 "solomon,page-offset" property
that has a broken default [0] but I think that not allowing to set the
resolution is already too restrictive and would make it unusable for
any panel that doesn't have the default width and height.

[0]: https://lists.freedesktop.org/archives/dri-devel/2023-November/431150.html

>> But answering your question, yes I think that more devices for this
>> SSD133x family are going to be added later. Looking at [3], there is
>> at least SSD1333 that has a different default resolutions (176x176).
>
> That's fair enough though. I'd probably err on the side of introducing
> this complexity when the other users actually show up though.
>

Agree and the reason why I did not include entries for the SSD1332 and
SSD1333. I was planning to add those only if there were users since it
seems that the SSD1331 is the most popular controller from this family.

But as explained, even for the SSD1331 it may be needed to set a width
and height that is different than the default of this panel controller.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

[PATCH v2 1/2] dt-bindings: display: Add SSD133x OLED controllers

Add a Device Tree binding schema for the OLED panels based on the
Solomon SSD133x family of controllers.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v2:
- Unconditionally set the width and height constraints (Conor Dooley).
- Fix indentation in the DTS examples (Krzysztof Kozlowski).

 .../bindings/display/solomon,ssd133x.yaml | 57 +++
 1 file changed, 57 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/solomon,ssd133x.yaml

diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml 
b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
new file mode 100644
index ..8feee9eef0fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd133x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD133x OLED Display Controllers
+
+maintainers:
+  - Javier Martinez Canillas 
+
+properties:
+  compatible:
+enum:
+  - solomon,ssd1331
+
+required:
+  - compatible
+  - reg
+
+allOf:
+  - $ref: solomon,ssd-common.yaml#
+
+  - properties:
+  width:
+default: 96
+  height:
+default: 64
+
+unevaluatedProperties: false
+
+examples:
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+oled@3c {
+compatible = "solomon,ssd1331";
+reg = <0x3c>;
+reset-gpios = <&gpio2 7>;
+};
+
+};
+  - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+oled@0 {
+compatible = "solomon,ssd1331";
+reg = <0x0>;
+reset-gpios = <&gpio2 7>;
+dc-gpios = <&gpio2 8>;
+spi-max-frequency = <1000>;
+};
+};
-- 
2.43.0

Re: [RFC PATCH] KVM: Introduce KVM VIRTIO device

2023-12-18 Thread Yan Zhao

On Fri, Dec 15, 2023 at 02:23:48PM +0800, Tian, Kevin wrote:
> > From: Zhao, Yan Y 
> > Sent: Thursday, December 14, 2023 6:35 PM
> > 
> > - For host non-MMIO pages,
> >   * virtio guest frontend and host backend driver should be synced to use
> > the same memory type to map a buffer. Otherwise, there will be
> > potential problem for incorrect memory data. But this will only impact
> > the buggy guest alone.
> >   * for live migration,
> > as QEMU will read all guest memory during live migration, page aliasing
> > could happen.
> > Current thinking is to disable live migration if a virtio device has
> > indicated its noncoherent state.
> > As a follow-up, we can discuss other solutions. e.g.
> > (a) switching back to coherent path before starting live migration.
> 
> both guest/host switching to coherent or host-only?
> 
> host-only certainly is problematic if guest is still using non-coherent.
Both.

> on the other hand I'm not sure whether the host/guest gfx stack is
> capable of switching between coherent and non-coherent path in-fly
> when the buffer is right being rendered.
> 
Yes. I'm also not sure about it. But it's an option though.

> > (b) read/write of guest memory with clflush during live migration.
> 
> write is irrelevant as it's only done in the resume path where the
> guest is not running.
Given host write is with PAT WB and hardware is in no-snoop mode, is it
better to perform cache flush after host write?
(can do more investigation to check if it's necessary).

BTW, there's also post-copy live migration, in which case the guest is
running :)

> 
> > 
> > Implementation Consideration
> > ===
> > There is a previous series [1] from google to serve the same purpose to
> > let KVM be aware of virtio GPU's noncoherent DMA status. That series
> > requires a new memslot flag, and special memslots in user space.
> > 
> > We don't choose to use memslot flag to request honoring guest memory
> > type.
> 
> memslot flag has the potential to restrict the impact e.g. when using
> clflush-before-read in migration? Of course the implication is to
> honor guest type only for the selected slot in KVM instead of applying
> to the entire guest memory as in previous series (which selects this
> way because vmx_get_mt_mask() is in perf-critical path hence not
> good to check memslot flag?)
>
I think checking memslot flag in itself is all right.
But memslot flag does not contain the memory type that host is using for
the memslot.
On the other hand, virtio GPU is not the only source of non-coherent DMAs.
Memslot flag way is not applicable to pass-through GPUs, due to lacking of
coordination between guest and host.


> > Instead we hope to make the honoring request to be explicit (not tied to a
> > memslot flag). This is because once guest memory type is honored, not only
> > memory used by guest virtio device, but all guest memory is facing page
> > aliasing issue potentially. KVM needs a generic solution to take care of
> > page aliasing issue rather than counting on memory type of a special
> > memslot being aligned in host and guest.
> > (we can discuss what a generic solution to handle page aliasing issue will
> > look like in later follow-up series).
> > 
> > On the other hand, we choose to introduce a KVM virtio device rather than
> > just provide an ioctl to wrap kvm_arch_[un]register_noncoherent_dma()
> > directly, which is based on considerations that
> 
> I wonder it's over-engineered for the purpose.
> 
> why not just introducing a KVM_CAP and allowing the VMM to enable?
As we hope to increase non-coherent DMA count on hot-plug of a non-coherent
device and decrease non-coherent DMA count on hot-unplug of the non-coherent
device, a KVM_CAP looks requiring user to maintain a ref count before turning
on/off, which is less desired. Agree?

> KVM doesn't need to know the exact source of requiring it...
Maybe we can use the source info in a way like this:
1. indicate the source is not a passthrough device
2. record relationship between GPA and memory type.

Then, if KVM knows non-coherent DMAs do not contain any passthrough 
devices, it can force a GPA's memory type (by ignoring guest PAT) to the
one specified by host (in 2), so as to avoid cache flush operations before
live migration.

If there are passthrough devices involved later, we can zap the EPT and
rebuild memory type to honor guest PAT, resorting to cache flush before
live migration to maintain coherency.

[PATCH v2 1/2] drm/rockchip: rk3066_hdmi: remove unused drm device pointer

2023-12-18 Thread Johan Jonker

The drm_dev field in the rk3066_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.

Signed-off-by: Johan Jonker 
---
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c 
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 62e6d8187de7..0dac6d133767 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -40,7 +40,6 @@ struct rk3066_hdmi_i2c {

 struct rk3066_hdmi {
struct device *dev;
-   struct drm_device *drm_dev;
struct regmap *grf_regmap;
int irq;
struct clk *hclk;
@@ -752,7 +751,6 @@ static int rk3066_hdmi_bind(struct device *dev, struct 
device *master,
return -ENOMEM;

hdmi->dev = dev;
-   hdmi->drm_dev = drm;
hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(hdmi->regs))
return PTR_ERR(hdmi->regs);
--
2.39.2

[PATCH AUTOSEL 6.1 05/15] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc

From: Ziqi Zhao 

[ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]

The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.

Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao 
Reported-and-tested-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Tested-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20230721161446.8602-1-astraj...@yahoo.com
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index df9bf3c9206e7..d718c17ab1e9f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -715,8 +715,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
-   int ret;
-   int i;
+   int ret, i, num_connectors;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -851,6 +850,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
 
+   num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned 
long)crtc_req->set_connectors_ptr;
@@ -871,6 +871,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
 
connector_set[i] = connector;
+   num_connectors++;
}
}
 
@@ -879,7 +880,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
-   set.num_connectors = crtc_req->count_connectors;
+   set.num_connectors = num_connectors;
set.fb = fb;
 
if (drm_drv_uses_atomic_modeset(dev))
@@ -892,7 +893,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
 
if (connector_set) {
-   for (i = 0; i < crtc_req->count_connectors; i++) {
+   for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
-- 
2.43.0

[PATCH AUTOSEL 6.6 07/18] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc

From: Ziqi Zhao 

[ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]

The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.

Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao 
Reported-and-tested-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Tested-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20230721161446.8602-1-astraj...@yahoo.com
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index df9bf3c9206e7..d718c17ab1e9f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -715,8 +715,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
-   int ret;
-   int i;
+   int ret, i, num_connectors;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -851,6 +850,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
 
+   num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned 
long)crtc_req->set_connectors_ptr;
@@ -871,6 +871,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
 
connector_set[i] = connector;
+   num_connectors++;
}
}
 
@@ -879,7 +880,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
-   set.num_connectors = crtc_req->count_connectors;
+   set.num_connectors = num_connectors;
set.fb = fb;
 
if (drm_drv_uses_atomic_modeset(dev))
@@ -892,7 +893,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
 
if (connector_set) {
-   for (i = 0; i < crtc_req->count_connectors; i++) {
+   for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
-- 
2.43.0

Re: [PATCH v3 1/2] drm/buddy: Implement tracking clear page feature

2023-12-18 Thread kernel test robot

Hi Arunpravin,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next 
drm-intel/for-linux-next-fixes drm/drm-next drm-exynos/exynos-drm-next 
drm-tip/drm-tip linus/master v6.7-rc5 next-20231215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Arunpravin-Paneer-Selvam/drm-amdgpu-Enable-clear-page-functionality/20231214-214811
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20231214134240.3183-1-Arunpravin.PaneerSelvam%40amd.com
patch subject: [PATCH v3 1/2] drm/buddy: Implement tracking clear page feature
config: arc-randconfig-001-20231215 
(https://download.01.org/0day-ci/archive/20231218/202312180258.cty6xurg-...@intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231218/202312180258.cty6xurg-...@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/202312180258.cty6xurg-...@intel.com/

All warnings (new ones prefixed by >>):

>> scripts/kernel-doc: drivers/gpu/drm/drm_buddy.c:337: warning: Function 
>> parameter or struct member 'flags' not described in 'drm_buddy_free_list'

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

[RFC PATCH net-next v5 05/14] netdev: netdevice devmem allocator

Implement netdev devmem allocator. The allocator takes a given struct
netdev_dmabuf_binding as input and allocates net_iov from that
binding.

The allocation simply delegates to the binding's genpool for the
allocation logic and wraps the returned memory region in a net_iov
struct.

Signed-off-by: Willem de Bruijn 
Signed-off-by: Kaiyuan Zhang 
Signed-off-by: Mina Almasry 

---

v1:
- Rename devmem -> dmabuf (David).

---
 include/net/devmem.h | 12 
 include/net/netmem.h | 26 ++
 net/core/dev.c   | 38 ++
 3 files changed, 76 insertions(+)

diff --git a/include/net/devmem.h b/include/net/devmem.h
index 85ccbbe84c65..4207adadc2bb 100644
--- a/include/net/devmem.h
+++ b/include/net/devmem.h
@@ -67,6 +67,8 @@ struct dmabuf_genpool_chunk_owner {
 };
 
 #ifdef CONFIG_DMA_SHARED_BUFFER
+struct net_iov *netdev_alloc_dmabuf(struct netdev_dmabuf_binding *binding);
+void netdev_free_dmabuf(struct net_iov *ppiov);
 void __netdev_dmabuf_binding_free(struct netdev_dmabuf_binding *binding);
 int netdev_bind_dmabuf(struct net_device *dev, unsigned int dmabuf_fd,
   struct netdev_dmabuf_binding **out);
@@ -74,6 +76,16 @@ void netdev_unbind_dmabuf(struct netdev_dmabuf_binding 
*binding);
 int netdev_bind_dmabuf_to_queue(struct net_device *dev, u32 rxq_idx,
struct netdev_dmabuf_binding *binding);
 #else
+static inline struct net_iov *
+netdev_alloc_dmabuf(struct netdev_dmabuf_binding *binding)
+{
+   return NULL;
+}
+
+static inline void netdev_free_dmabuf(struct net_iov *ppiov)
+{
+}
+
 static inline void
 __netdev_dmabuf_binding_free(struct netdev_dmabuf_binding *binding)
 {
diff --git a/include/net/netmem.h b/include/net/netmem.h
index 45eb42d9990b..7fce2efc8707 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -14,8 +14,34 @@
 
 struct net_iov {
struct dmabuf_genpool_chunk_owner *owner;
+   unsigned long dma_addr;
 };
 
+static inline struct dmabuf_genpool_chunk_owner *
+net_iov_owner(const struct net_iov *niov)
+{
+   return niov->owner;
+}
+
+static inline unsigned int net_iov_idx(const struct net_iov *niov)
+{
+   return niov - net_iov_owner(niov)->niovs;
+}
+
+static inline dma_addr_t net_iov_dma_addr(const struct net_iov *niov)
+{
+   struct dmabuf_genpool_chunk_owner *owner = net_iov_owner(niov);
+
+   return owner->base_dma_addr +
+  ((dma_addr_t)net_iov_idx(niov) << PAGE_SHIFT);
+}
+
+static inline struct netdev_dmabuf_binding *
+net_iov_binding(const struct net_iov *niov)
+{
+   return net_iov_owner(niov)->binding;
+}
+
 /* netmem */
 
 struct netmem {
diff --git a/net/core/dev.c b/net/core/dev.c
index 2e474099267a..20ba528ef426 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2119,6 +2119,44 @@ static int netdev_restart_rx_queue(struct net_device 
*dev, int rxq_idx)
return err;
 }
 
+struct net_iov *netdev_alloc_dmabuf(struct netdev_dmabuf_binding *binding)
+{
+   struct dmabuf_genpool_chunk_owner *owner;
+   unsigned long dma_addr;
+   struct net_iov *niov;
+   ssize_t offset;
+   ssize_t index;
+
+   dma_addr = gen_pool_alloc_owner(binding->chunk_pool, PAGE_SIZE,
+   (void **)&owner);
+   if (!dma_addr)
+   return NULL;
+
+   offset = dma_addr - owner->base_dma_addr;
+   index = offset / PAGE_SIZE;
+   niov = &owner->niovs[index];
+
+   niov->pp_magic = 0;
+   niov->pp = NULL;
+   niov->dma_addr = 0;
+   atomic_long_set(&niov->pp_ref_count, 0);
+
+   netdev_dmabuf_binding_get(binding);
+
+   return niov;
+}
+
+void netdev_free_dmabuf(struct net_iov *niov)
+{
+   struct netdev_dmabuf_binding *binding = net_iov_binding(niov);
+   unsigned long dma_addr = net_iov_dma_addr(niov);
+
+   if (gen_pool_has_addr(binding->chunk_pool, dma_addr, PAGE_SIZE))
+   gen_pool_free(binding->chunk_pool, dma_addr, PAGE_SIZE);
+
+   netdev_dmabuf_binding_put(binding);
+}
+
 /* Protected by rtnl_lock() */
 static DEFINE_XARRAY_FLAGS(netdev_dmabuf_bindings, XA_FLAGS_ALLOC1);
 
-- 
2.43.0.472.g3155946c3a-goog

Re: [PATCH] drm/rockchip: vop2: Avoid use regmap_reinit_cache at runtime

2023-12-18 Thread Marek Szyprowski

On 17.12.2023 09:44, Andy Yan wrote:
> From: Andy Yan 
>
> Marek Report a possible irq lock inversion dependency warning when
> commit 81a06f1d02e5 ("Revert "drm/rockchip: vop2: Use regcache_sync()
> to fix suspend/resume"") lands linux-next.
>
> I can reproduce this warning with:
> CONFIG_PROVE_LOCKING=y
> CONFIG_DEBUG_LOCKDEP=y
>
> It seems than when use regmap_reinit_cache at runtime whith Mark's
> commit 3d59c22bbb8d ("drm/rockchip: vop2: Convert to use maple tree
> register cache"), it will trigger a possible irq lock inversion dependency
> warning.
>
> One solution is switch back to REGCACHE_RBTREE, but it seems that
> REGCACHE_MAPLE is the future, so I avoid ues regmap_reinit_cache,
> and drop all the regcache when vop is disabled, then we get a fresh
> start at next enbable time.
>
> [8.425923] dwmmc_rockchip fe2b.mmc: IDMAC supports 32-bit address 
> mode.
> [8.427020] dwmmc_rockchip fe2b.mmc: Using internal DMA controller.
> [8.428013] dwmmc_rockchip fe2b.mmc: Version ID is 270a
> [8.429088] dwmmc_rockchip fe2b.mmc: DW MMC controller at irq 78,32 
> bit host data width,256 deep fifo
> [8.454219] mmc_host mmc0: Bus speed (slot 0) = 375000Hz (slot req 
> 40Hz, actual 375000HZ div = 0)
> [8.465446] rockchip-drm display-subsystem: bound fe04.vop (ops 
> vop2_component_ops)
> [8.475586] dwhdmi-rockchip fe0a.hdmi: Detected HDMI TX controller 
> v2.11a with HDCP (DWC HDMI 2.0 TX PHY)
> [8.484326] dwhdmi-rockchip fe0a.hdmi: registered DesignWare HDMI I2C 
> bus driver
> [8.490505] rockchip-drm display-subsystem: bound fe0a.hdmi (ops 
> dw_hdmi_rockchip_ops)
> [8.501151] [drm] Initialized rockchip 1.0.0 20140818 for 
> display-subsystem on minor 0
> [8.895456]
> [8.895473] 
> [8.895480] WARNING: possible irq lock inversion dependency detected
> [8.895486] 6.7.0-rc5-next-20231215 #514 Not tainted
> [8.895496] 
> [8.895501] swapper/0/0 just changed the state of lock:
> [8.895510] 070b6018 
> (rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock){-...}-{2:2}, at: 
> regmap_lock_spinlock
> +0x14/0x24
> [8.895560] but this lock took another, HARDIRQ-unsafe lock in the past:
> [8.895566]  (&mt->ma_lock){+.+.}-{2:2}
> [8.895580]
> [8.895580]
> [8.895580] and interrupts could create inverse lock ordering between them.
> [8.895580]
> [8.895585]
> [8.895585] other info that might help us debug this:
> [8.895590]  Possible interrupt unsafe locking scenario:
> [8.895590]
> [8.895594]CPU0CPU1
> [8.895598]
> [8.895602]   lock(&mt->ma_lock);
> [8.895614]local_irq_disable();
> [8.895617]
> lock(rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock);
> [8.895629]lock(&mt->ma_lock);
> [8.895641]   
> [8.895644]   lock(rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock);
> [8.895655]
> [8.895655]  *** DEADLOCK ***
> [8.895655]
> [8.895659] no locks held by swapper/0/0.
> [8.895664]
> [8.895664] the shortest dependencies between 2nd lock and 1st lock:
> [8.895672]  -> (&mt->ma_lock){+.+.}-{2:2} ops: 12 {
> [8.895704] HARDIRQ-ON-W at:
> [8.895713]   lock_acquire+0x238/0x354
> [8.895732]   _raw_spin_lock+0x3c/0x50
> [8.895749]   regcache_maple_exit+0x64/0xc4
> [8.895766]   regcache_exit+0x48/0xac
> [8.895780]   regmap_reinit_cache+0x18/0x98
> [8.895793] 
> vop2_crtc_atomic_enable+0xefc/0x1074
> [8.895810]   
> drm_atomic_helper_commit_modeset_enables+0xac/0x264
> [8.895826]   
> drm_atomic_helper_commit_tail_rpm+0x2c/0x78
> [8.895841]   commit_tail+0x9c/0x178
> [8.895855]   drm_atomic_helper_commit+0x17c/0x1ac
> [8.895869]   drm_atomic_commit+0xac/0xec
> [8.895885]   
> drm_client_modeset_commit_atomic+0x230/0x290
> [8.895896]   
> drm_client_modeset_commit_locked+0x54/0x1c4
> [8.895907]   drm_client_modeset_commit+0x2c/0x50
> [8.895917]   
> __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
> [8.895934]   drm_fb_helper_set_par+0x30/0x48
> [8.895948]   fbcon_init+0x40c/0x498
> [8.895961]   visual_init+0xb0/0x108
> [8.895972]   do_bind_con_driver+0x1b8/0x38c
> [8.895983]   do_take_over_console+0x148/0x1d4
> [8.895993]   do_fbcon_takeover+0x6c/0

[PATCH AUTOSEL 5.4 3/7] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc

From: Ziqi Zhao 

[ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]

The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.

Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao 
Reported-and-tested-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Tested-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20230721161446.8602-1-astraj...@yahoo.com
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4936e1080e417..38ce608648b0d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -535,8 +535,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
-   int ret;
-   int i;
+   int ret, i, num_connectors;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -674,6 +673,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
 
+   num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned 
long)crtc_req->set_connectors_ptr;
@@ -694,6 +694,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
 
connector_set[i] = connector;
+   num_connectors++;
}
}
 
@@ -702,7 +703,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
-   set.num_connectors = crtc_req->count_connectors;
+   set.num_connectors = num_connectors;
set.fb = fb;
 
if (drm_drv_uses_atomic_modeset(dev))
@@ -715,7 +716,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
 
if (connector_set) {
-   for (i = 0; i < crtc_req->count_connectors; i++) {
+   for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
-- 
2.43.0

[PATCH v2 2/2] drm/ssd130x: Add support for the SSD133x OLED controller family