date:20240612

With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/vfb.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson 
---
 drivers/video/fbdev/vfb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index f86149ba3835..158e48385c24 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -546,5 +546,6 @@ static void __exit vfb_exit(void)
 
 module_exit(vfb_exit);
 
+MODULE_DESCRIPTION("Virtual Frame Buffer driver");
 MODULE_LICENSE("GPL");
 #endif /* MODULE */

---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-vfb-a4ed3808e861

Re: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU

Hi Tomeu,

kernel test robot noticed the following build errors:

[auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670]

url:
https://github.com/intel-lab-lkp/linux/commits/Tomeu-Vizoso/iommu-rockchip-Add-compatible-for-rockchip-rk3588-iommu/20240612-215814
base:   83a7eefedc9b56fe7bfeff13b6c7356688ffa670
patch link:
https://lore.kernel.org/r/20240612-6-10-rocket-v1-6-060e48eea250%40tomeuvizoso.net
patch subject: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU
config: s390-allyesconfig 
(https://download.01.org/0day-ci/archive/20240613/202406131022.1jkns7me-...@intel.com/config)
compiler: s390-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240613/202406131022.1jkns7me-...@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/202406131022.1jkns7me-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/clk.h:13,
from drivers/accel/rocket/rocket_drv.c:4:
>> drivers/accel/rocket/rocket_drv.c:213:31: error: 'rocket_pm_ops' undeclared 
>> here (not in a function); did you mean 'rocket_probe'?
 213 | .pm = pm_ptr(_pm_ops),
 |   ^
   include/linux/kernel.h:48:44: note: in definition of macro 'PTR_IF'
  48 | #define PTR_IF(cond, ptr)   ((cond) ? (ptr) : NULL)
 |^~~
   drivers/accel/rocket/rocket_drv.c:213:23: note: in expansion of macro 
'pm_ptr'
 213 | .pm = pm_ptr(_pm_ops),
 |   ^~


vim +213 drivers/accel/rocket/rocket_drv.c

   207  
   208  static struct platform_driver rocket_driver = {
   209  .probe = rocket_probe,
   210  .remove_new = rocket_remove,
   211  .driver  = {
   212  .name = "rocket",
 > 213  .pm = pm_ptr(_pm_ops),
   214  .of_match_table = dt_match,
   215  },
   216  };
   217  module_platform_driver(rocket_driver);
   218  

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

Re: [PATCH v2] drm/bridge: simple-bridge: Add support for TI TDP158

2024-06-12 Thread Marc Gonzalez

On 28/05/2024 03:13, Dmitry Baryshkov wrote:

> Bindings please. Also, note that per the datasheet the bridge uses two
> supplies, Vcc for 3.3V and Vdd for 1.1V, so it doesn't fully fit the
> simple-bridge.c (which might need to be adjusted for the second supply).
> Chapter 7.3.2 of the datasheet points out that Vcc should be brought up
> before Vdd.

Is something simple like below acceptable?


// SPDX-License-Identifier: GPL-2.0-only
/*
 * Copyright 2024 Freebox SAS
 */

#include 
#include 
#include 
#include 

struct tdp158 {
struct i2c_client *client;
struct gpio_desc *OE; // Operation Enable
struct drm_bridge bridge;
};

static int tdp158_probe(struct i2c_client *client)
{
struct device *dev = >dev;
struct tdp158 *tdp158;
int err;

tdp158 = devm_kzalloc(dev, sizeof(*tdp158), GFP_KERNEL);
if (!tdp158)
return -ENOMEM;

tdp158->client = client;
i2c_set_clientdata(client, tdp158);

err = devm_regulator_get_enable(dev, "Vcc"); // 3.3V
msleep(100);
if (err)
return dev_err_probe(dev, err, "Vcc");

err = devm_regulator_get_enable(dev, "Vdd"); // 1.1V
msleep(100);
if (err)
return dev_err_probe(dev, err, "Vdd");

tdp158->OE = devm_gpiod_get(dev, "OE", GPIOD_OUT_LOW);
if (IS_ERR(tdp158->OE))
return dev_err_probe(dev, PTR_ERR(tdp158->OE), "OE pin");

gpiod_set_value_cansleep(tdp158->OE, 1);

tdp158->bridge.of_node = dev->of_node;

return devm_drm_bridge_add(dev, >bridge);
}

static const struct of_device_id tdp158_match_table[] = {
{ .compatible = "ti,tdp158" },
{ }
};
MODULE_DEVICE_TABLE(of, tdp158_match_table);

static struct i2c_driver tdp158_driver = {
.probe = tdp158_probe,
.driver = {
.name = "tdp158",
.of_match_table = tdp158_match_table,
},
};

module_i2c_driver(tdp158_driver);

MODULE_DESCRIPTION("TI TDP158 driver");
MODULE_LICENSE("GPL");

Re: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU

Hi Tomeu,

kernel test robot noticed the following build errors:

[auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670]

url:
https://github.com/intel-lab-lkp/linux/commits/Tomeu-Vizoso/iommu-rockchip-Add-compatible-for-rockchip-rk3588-iommu/20240612-215814
base:   83a7eefedc9b56fe7bfeff13b6c7356688ffa670
patch link:
https://lore.kernel.org/r/20240612-6-10-rocket-v1-6-060e48eea250%40tomeuvizoso.net
patch subject: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU
config: loongarch-allmodconfig 
(https://download.01.org/0day-ci/archive/20240613/202406130901.oiofrkfe-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240613/202406130901.oiofrkfe-...@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/202406130901.oiofrkfe-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/loongarch/include/asm/processor.h:17,
from arch/loongarch/include/asm/thread_info.h:15,
from include/linux/thread_info.h:60,
from include/asm-generic/current.h:6,
from ./arch/loongarch/include/generated/asm/current.h:1,
from include/linux/mutex.h:14,
from include/linux/notifier.h:14,
from include/linux/clk.h:14,
from drivers/accel/rocket/rocket_core.c:6:
>> arch/loongarch/include/uapi/asm/ptrace.h:25:25: error: expected identifier 
>> before '(' token
  25 | #define PC  (GPR_END + 2)
 | ^
   drivers/accel/rocket/rocket_registers.h:53:9: note: in expansion of macro 
'PC'
  53 | PC = 0x0100,
 | ^~


vim +25 arch/loongarch/include/uapi/asm/ptrace.h

803b0fc5c3f2ba Huacai Chen 2022-05-31  16  
803b0fc5c3f2ba Huacai Chen 2022-05-31  17  /*
803b0fc5c3f2ba Huacai Chen 2022-05-31  18   * For PTRACE_{POKE,PEEK}USR. 0 - 31 
are GPRs,
803b0fc5c3f2ba Huacai Chen 2022-05-31  19   * 32 is syscall's original ARG0, 33 
is PC, 34 is BADVADDR.
803b0fc5c3f2ba Huacai Chen 2022-05-31  20   */
803b0fc5c3f2ba Huacai Chen 2022-05-31  21  #define GPR_BASE 0
803b0fc5c3f2ba Huacai Chen 2022-05-31  22  #define GPR_NUM  32
803b0fc5c3f2ba Huacai Chen 2022-05-31  23  #define GPR_END  
(GPR_BASE + GPR_NUM - 1)
803b0fc5c3f2ba Huacai Chen 2022-05-31  24  #define ARG0 (GPR_END + 1)
803b0fc5c3f2ba Huacai Chen 2022-05-31 @25  #define PC   (GPR_END + 2)
803b0fc5c3f2ba Huacai Chen 2022-05-31  26  #define BADVADDR (GPR_END + 3)
803b0fc5c3f2ba Huacai Chen 2022-05-31  27  

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

Re: [PATCH v3 2/4] dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998

2024-06-12 Thread Marc Gonzalez

On 12/06/2024 19:44, Vinod Koul wrote:

> On 06-06-24, 18:07, Marc Gonzalez wrote:
>
>> HDMI TX block embedded in the APQ8098.
> 
> This one too

I assume this refers to:
"Why is the patch titled display/msm, this is phy patch and it should be
tagged as such."

I always copy what others have done before me:

$ git log --oneline Documentation/devicetree/bindings/display/msm/hdmi.yaml
27339d689d2f9 dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998
6c04d89a6138a dt-bindings: display/msm: hdmi: mark hdmi-mux-supply as deprecated
e3c5ce88e8f93 dt-bindings: display/msm: hdmi: mark old GPIO properties as 
deprecated
2f14bc38d88a4 dt-bindings: display/msm: hdmi: split and convert to yaml

Are you saying we should diverge from the previous nomenclature?

Regards.

[PATCH] video: macmodes: add missing MODULE_DESCRIPTION() macro

With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/macmodes.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson 
---
 drivers/video/fbdev/macmodes.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/macmodes.c b/drivers/video/fbdev/macmodes.c
index af86c081d2be..d6be3c67d3df 100644
--- a/drivers/video/fbdev/macmodes.c
+++ b/drivers/video/fbdev/macmodes.c
@@ -411,4 +411,5 @@ int mac_find_mode(struct fb_var_screeninfo *var, struct 
fb_info *info,
 }
 EXPORT_SYMBOL(mac_find_mode);
 
+MODULE_DESCRIPTION("MacOS video mode library");
 MODULE_LICENSE("GPL");

---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-macmodes-7a15b2b20b12

[PATCH net-next v12 10/13] 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 

---

v11:
- Refactor to common function te remove conditional lock sparse warning
  (Paolo)

v7:
- Updated the SO_DEVMEM_* uapi to use the next available entries (Arnd).
- Updated dmabuf_cmsg struct to be __u64 padded (Arnd).
- Squashed fix from Eric to initialize sk_user_frags for passive
  sockets (Eric).

v6
- skb->dmabuf -> skb->readable (Pavel)
- Fixed asm definitions of SO_DEVMEM_LINEAR/SO_DEVMEM_DMABUF not found
  on some archs.
- Squashed in locking optimizations from eduma...@google.com. With this
  change we lock the xarray once per per tcp_recvmsg_dmabuf() rather
  than once per frag in xa_alloc().

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.

---
 arch/alpha/include/uapi/asm/socket.h  |   5 +
 arch/mips/include/uapi/asm/socket.h   |   5 +
 arch/parisc/include/uapi/asm/socket.h |   5 +
 arch/sparc/include/uapi/asm/socket.h  |   5 +
 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  |  13 ++
 net/ipv4/tcp.c| 255 +-
 net/ipv4/tcp_ipv4.c   |  10 +
 net/ipv4/tcp_minisocks.c  |   2 +
 12 files changed, 316 insertions(+), 5 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/socket.h 
b/arch/alpha/include/uapi/asm/socket.h
index e94f621903fee..ef4656a41058a 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -140,6 +140,11 @@
 #define SO_PASSPIDFD   76
 #define SO_PEERPIDFD   77
 
+#define SO_DEVMEM_LINEAR   78
+#define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF   79
+#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 60ebaed28a4ca..414807d55e33f 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -151,6 +151,11 @@
 #define SO_PASSPIDFD   76
 #define SO_PEERPIDFD   77
 
+#define SO_DEVMEM_LINEAR   78
+#define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF   79
+#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 be264c2b1a117..2b817efd45444 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -132,6 +132,11 @@
 #define SO_PASSPIDFD   0x404A
 #define SO_PEERPIDFD   0x404B
 
+#define SO_DEVMEM_LINEAR   78
+#define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF   79
+#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 682da3714686c..00248fc689773 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -133,6 +133,11 @@
 #define SO_PASSPIDFD 0x0055
 #define SO_PEERPIDFD 0x0056
 
+#define SO_DEVMEM_LINEAR 0x0057
+#define SCM_DEVMEM_LINEARSO_DEVMEM_LINEAR
+#define SO_DEVMEM_DMABUF 0x0058
+#define SCM_DEVMEM_DMABUFSO_DEVMEM_DMABUF
+
 #if !defined(__KERNEL__)
 
 
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 89d16b90370bd..b0defc2ea40ed 100644
--- a/include/linux/socket.h
+++

[PATCH net-next v12 13/13] 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 

---
v9: 
https://lore.kernel.org/netdev/20240403002053.2376017-15-almasrym...@google.com/
- Remove unused nic_pci_addr entry (Cong).

v6:
- Updated to bind 8 queues.
- Added RSS configuration.
- Added some more tests for the netlink API.

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 | 542 +
 3 files changed, 548 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 49a56eb5d0368..9cd3c99c6e5d4 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 6da63d1831c11..2600cce3ee382 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 += fdb_flush.sh
 TEST_PROGS += fq_band_pktlimit.sh
 TEST_PROGS += vlan_hw_filter.sh
 TEST_PROGS += bpf_offload.py
+TEST_GEN_FILES += ncdevmem
 
 TEST_FILES := settings
 TEST_FILES += in_netns.sh lib.sh net_helper.sh setup_loopback.sh setup_veth.sh
diff --git a/tools/testing/selftests/net/ncdevmem.c 
b/tools/testing/selftests/net/ncdevmem.c
new file mode 100644
index 0..e00255e54f77b
--- /dev/null
+++ b/tools/testing/selftests/net/ncdevmem.c
@@ -0,0 +1,542 @@
+// 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 start_queue = 8;
+static int num_queues = 8;
+static char *ifname = "eth1";
+static unsigned int ifindex = 3;
+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,

[PATCH net-next v12 12/13] net: add devmem TCP documentation

Add documentation outlining the usage and details of devmem TCP.

Signed-off-by: Mina Almasry 
Reviewed-by: Bagas Sanjaya 

---

v9: 
https://lore.kernel.org/netdev/20240403002053.2376017-14-almasrym...@google.com/
- Bagas doc suggestions.

v8:
- Applied docs suggestions (Randy). Thanks!

v7:
- Applied docs suggestions (Jakub).

v2:

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

---
 Documentation/networking/devmem.rst | 258 
 Documentation/networking/index.rst  |   1 +
 2 files changed, 259 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 0..f32acfd62075d
--- /dev/null
+++ b/Documentation/networking/devmem.rst
@@ -0,0 +1,258 @@
+.. 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 number of data transfers have device memory as the source and/or
+destination. Accelerators drastically increased the prevalence of such
+transfers.  Some examples include:
+
+- Distributed training, where ML accelerators, such as GPUs on different hosts,
+  exchange data.
+
+- Distributed raw block storage applications transfer large amounts of data 
with
+  remote SSDs. Much of this data does not require host processing.
+
+Typically the Device-to-Device data transfers in 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 flow involving host copies 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 the 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 v6 00/12] Device Memory TCP
+
https://lore.kernel.org/netdev/20240305020153.2787423-1-almasrym...@google.com/
+
+
+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
+an RX queue bound to devmem.
+
+Enable header split & flow steering::
+
+   # enable header split
+   ethtool -G eth1 tcp-data-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
+the 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(_netdev_family, );
+
+   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 steered 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_SOCK_DEVMEM);
+
+Applications that do not specify the MSG_SOCK_DEVMEM flag will receive an

[PATCH net-next v12 07/13] 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 

---

v11:
- Rebase to not use the ops. (Christoph)

v8:
- Use skb_frag_size instead of frag->bv_len to fix patch-by-patch build
  error

v6:
- refactor new memory provider functions into net/core/devmem.c (Pavel)

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

---
 include/net/mp_dmabuf_devmem.h  | 44 
 include/net/netmem.h| 15 +++
 include/net/page_pool/helpers.h | 22 ++
 include/net/page_pool/types.h   |  2 +
 net/core/devmem.c   | 74 +
 net/core/page_pool.c| 70 +++
 6 files changed, 201 insertions(+), 26 deletions(-)
 create mode 100644 include/net/mp_dmabuf_devmem.h

diff --git a/include/net/mp_dmabuf_devmem.h b/include/net/mp_dmabuf_devmem.h
new file mode 100644
index 0..300a2356eed00
--- /dev/null
+++ b/include/net/mp_dmabuf_devmem.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Dmabuf device memory provider.
+ *
+ * Authors:Mina Almasry 
+ *
+ */
+#ifndef _NET_MP_DMABUF_DEVMEM_H
+#define _NET_MP_DMABUF_DEVMEM_H
+
+#include 
+
+#if defined(CONFIG_DMA_SHARED_BUFFER) && defined(CONFIG_GENERIC_ALLOCATOR)
+int mp_dmabuf_devmem_init(struct page_pool *pool);
+
+netmem_ref mp_dmabuf_devmem_alloc_netmems(struct page_pool *pool, gfp_t gfp);
+
+void mp_dmabuf_devmem_destroy(struct page_pool *pool);
+
+bool mp_dmabuf_devmem_release_page(struct page_pool *pool, netmem_ref netmem);
+#else
+static inline int mp_dmabuf_devmem_init(struct page_pool *pool)
+{
+   return -EOPNOTSUPP;
+}
+
+static inline netmem_ref mp_dmabuf_devmem_alloc_netmems(struct page_pool *pool,
+   gfp_t gfp)
+{
+   return 0;
+}
+
+static inline void mp_dmabuf_devmem_destroy(struct page_pool *pool)
+{
+}
+
+static inline bool mp_dmabuf_devmem_release_page(struct page_pool *pool,
+netmem_ref netmem)
+{
+   return false;
+}
+#endif
+
+#endif /* _NET_MP_DMABUF_DEVMEM_H */
diff --git a/include/net/netmem.h b/include/net/netmem.h
index 35ad237fdf29e..7c28d6fac6242 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -100,6 +100,21 @@ static inline struct page *netmem_to_page(netmem_ref 
netmem)
return (__force struct page *)netmem;
 }
 
+static inline struct net_iov *netmem_to_net_iov(netmem_ref netmem)
+{
+   if (netmem_is_net_iov(netmem))
+   return (struct net_iov *)((__force unsigned long)netmem &
+ ~NET_IOV);
+
+   DEBUG_NET_WARN_ON_ONCE(true);
+   return NULL;
+}
+
+static inline netmem_ref net_iov_to_netmem(struct net_iov *niov)
+{
+   return (__force netmem_ref)((unsigned long)niov | NET_IOV);
+}
+
 static inline netmem_ref page_to_netmem(struct page *page)
 {
return (__force netmem_ref)page;
diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
index 1770c7be24afc..731f2d1e1ee10 100644
--- a/include/net/page_pool/helpers.h
+++ b/include/net/page_pool/helpers.h
@@ -477,4 +477,26 @@ static inline void page_pool_nid_changed(struct page_pool 
*pool, int new_nid)
page_pool_update_nid(pool, new_nid);
 }
 
+static inline void page_pool_set_pp_info(struct page_pool *pool,
+netmem_ref netmem)
+{
+   netmem_set_pp(netmem, pool);
+   netmem_or_pp_magic(netmem, PP_SIGNATURE);
+
+   /* Ensuring all pages have been split into one fragment initially:
+* page_pool_set_pp_info() is only called once for every page when it
+* is allocated from the page allocator and page_pool_fragment_page()
+* is dirtying the same cache line as the page->pp_magic above, so
+* the overhead is negligible.
+*/
+   page_pool_fragment_netmem(netmem, 1);
+   if (pool->has_init_callback)
+   pool->slow.init_callback(netmem, pool->slow.init_arg);
+}
+
+static inline void page_pool_clear_pp_info(netmem_ref netmem)
+{
+   netmem_clear_pp_magic(netmem);
+   netmem_set_pp(netmem, NULL);
+}
 #endif /*

[PATCH net-next v12 06/13] 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 

---

v9: 
https://lore.kernel.org/netdev/20240403002053.2376017-8-almasrym...@google.com/
- Remove CONFIG checks in netmem_is_net_iov() (Pavel/David/Jens)

v7:
- Remove static_branch_unlikely from netmem_to_net_iov(). We're getting
  better results from the fast path in bench_page_pool_simple tests
  without the static_branch_unlikely, and the addition of
  static_branch_unlikely doesn't improve performance of devmem TCP.

  Additionally only check netmem_to_net_iov() if
  CONFIG_DMA_SHARED_BUFFER is enabled, otherwise dmabuf net_iovs cannot
  exist anyway.

  net-next base: 8 cycle fast path.
  with static_branch_unlikely: 10 cycle fast path.
  without static_branch_unlikely: 9 cycle fast path.
  CONFIG_DMA_SHARED_BUFFER disabled: 8 cycle fast path as baseline.

  Performance of devmem TCP is at 95% line rate is regardless of
  static_branch_unlikely or not.

v6:
- Rebased on top of the merged netmem_ref type.
- Rebased on top of the merged skb_pp_frag_ref() changes.

v5:
- 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.

Cc: linux...@kvack.org
Cc: Matthew Wilcox 

---
 include/net/netmem.h| 137 ++--
 include/net/page_pool/helpers.h |  25 +++---
 net/core/devmem.c   |   3 +
 net/core/page_pool.c|  26 +++---
 net/core/skbuff.c   |  22 +++--
 5 files changed, 168 insertions(+), 45 deletions(-)

diff --git a/include/net/netmem.h b/include/net/netmem.h
index 664df8325ece5..35ad237fdf29e 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -9,14 +9,51 @@
 #define _NET_NETMEM_H
 
 #include 
+#include 
 
 /* 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,20 +84,22 @@ net_iov_binding(const struct net_iov *niov)
  */
 typedef unsigned long __bitwise netmem_ref;
 
+static inline bool netmem_is_net_iov(const netmem_ref netmem)
+{
+   return (__force unsigned long)netmem & NET_IOV;
+}
+
 /* This conversion fails (returns NULL) if the netmem_ref is not struct page
  * backed.
- *
- * Currently struct page is the only possible netmem, and this helper never
- * fails.
  */
 static inline struct page *netmem_to_page(netmem_ref netmem)
 {
+   if (WARN_ON_ONCE(netmem_is_net_iov(netmem)))
+   return NULL;
+
return (__force struct page *)netmem;
 }
 
-/* Converting from page to netmem is always safe, because a page can always be
- * a netmem.
- */
 static inline netmem_ref page_to_netmem(struct page *page)
 {
return (__force netmem_ref)page;
@@ -68,17 +107,103 @@ static

[PATCH net-next v12 09/13] net: add support for skbs with unreadable frags

For device memory TCP, we expect the skb headers to be available in host
memory for access, and we expect the skb frags to be in device memory
and unaccessible to the host. We expect there to be no mixing and
matching of device memory frags (unaccessible) with host memory frags
(accessible) in the same skb.

Add a skb->devmem flag which indicates whether the frags in this skb
are device memory frags or not.

__skb_fill_netmem_desc() now checks frags added to skbs for net_iov,
and marks the skb as skb->devmem accordingly.

Add checks through the network stack to avoid accessing the frags of
devmem skbs and avoid coalescing devmem skbs with non devmem skbs.

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


---

v11:
- drop excessive checks for frag 0 pull (Paolo)

v9: 
https://lore.kernel.org/netdev/20240403002053.2376017-11-almasrym...@google.com/
- change skb->readable to skb->unreadable (Pavel/David).

skb->readable was very complicated, because by default skbs are readable
so the flag needed to be set to true in all code paths where new skbs
were created or cloned. Forgetting to set skb->readable=true in some
paths caused crashes.

Flip it to skb->unreadable so that the default 0 value works well, and
we only need to set it to true when we add unreadable frags.

v6
- skb->dmabuf -> skb->readable (Pavel). Pavel's original suggestion was
  to remove the skb->dmabuf flag entirely, but when I looked into it
  closely, I found the issue that if we remove the flag we have to
  dereference the shinfo(skb) pointer to obtain the first frag, which
  can cause a performance regression if it dirties the cache line when
  the shinfo(skb) was not really needed. Instead, I converted the
  skb->dmabuf flag into a generic skb->readable flag which can be
  re-used by io_uring.

Changes in v1:
- Rename devmem -> dmabuf (David).
- Flip skb_frags_not_readable (Jakub).

---
 include/linux/skbuff.h | 19 +++--
 include/net/tcp.h  |  5 +++--
 net/core/datagram.c|  6 ++
 net/core/skbuff.c  | 48 --
 net/ipv4/tcp.c |  3 +++
 net/ipv4/tcp_input.c   | 13 +---
 net/ipv4/tcp_output.c  |  5 -
 net/packet/af_packet.c |  4 ++--
 8 files changed, 91 insertions(+), 12 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0a4df0025e6dc..9c9be08f96aa7 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -827,6 +827,8 @@ enum skb_tstamp_type {
  * @csum_level: indicates the number of consecutive checksums found in
  * the packet minus one that have been verified as
  * CHECKSUM_UNNECESSARY (max 3)
+ * @unreadable: indicates that at least 1 of the fragments in this skb is
+ * unreadable.
  * @dst_pending_confirm: need to confirm neighbour
  * @decrypted: Decrypted SKB
  * @slow_gro: state present at GRO time, slower prepare step required
@@ -1008,7 +1010,7 @@ struct sk_buff {
 #if IS_ENABLED(CONFIG_IP_SCTP)
__u8csum_not_inet:1;
 #endif
-
+   __u8unreadable:1;
 #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
__u16   tc_index;   /* traffic control index */
 #endif
@@ -1800,6 +1802,12 @@ static inline void skb_zcopy_downgrade_managed(struct 
sk_buff *skb)
__skb_zcopy_downgrade_managed(skb);
 }
 
+/* Return true if frags in this skb are readable by the host. */
+static inline bool skb_frags_readable(const struct sk_buff *skb)
+{
+   return !skb->unreadable;
+}
+
 static inline void skb_mark_not_on_list(struct sk_buff *skb)
 {
skb->next = NULL;
@@ -2516,10 +2524,17 @@ static inline void skb_len_add(struct sk_buff *skb, int 
delta)
 static inline void __skb_fill_netmem_desc(struct sk_buff *skb, int i,
  netmem_ref netmem, int off, int size)
 {
-   struct page *page = netmem_to_page(netmem);
+   struct page *page;
 
__skb_fill_netmem_desc_noacc(skb_shinfo(skb), i, netmem, off, size);
 
+   if (netmem_is_net_iov(netmem)) {
+   skb->unreadable = true;
+   return;
+   }
+
+   page = netmem_to_page(netmem);
+
/* Propagate page pfmemalloc to the skb if we can. The problem is
 * that not all callers have unique ownership of the page but rely
 * on page_is_pfmemalloc doing the right thing(tm).
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 2aac11e7e1cc5..e8f6e602c2ad4 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1060,7 +1060,7 @@ static inline int tcp_skb_mss(const struct sk_buff *skb)
 
 static inline bool tcp_skb_can_collapse_to(const struct sk_buff *skb)
 {
-   return likely(!TCP_SKB_CB(skb)->eor);
+   return likely(!TCP_SKB_CB(skb)->eor && skb_frags_readable(skb));
 }
 
 static inline bool tcp_skb_can_collapse(const struct sk_buff *to,
@@ -1069,7 +1069,8 @@ static

[PATCH net-next v12 03/13] 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 

---

v11:
- Fix build error with CONFIG_DMA_SHARED_BUFFER &&
  !CONFIG_GENERIC_ALLOCATOR
- Rebased on top of no memory provider ops.

v10:
- Moved net_iov_dma_addr() to devmem.h and made it devmem specific
  helper (David).

v9: https://lore.kernel.org/all/20240403002053.2376017-5-almasrym...@google.com/
- Removed net_devmem_restart_rx_queues and put it in its own patch
  (David).

v8:
- move dmabuf_devmem_ops usage to later patch to avoid patch-by-patch
  build error.

v7:
- Use IS_ERR() instead of IS_ERR_OR_NULL() for the dma_buf_get() return
  value.
- Changes netdev_* naming in devmem.c to net_devmem_* (Yunsheng).
- DMA_BIDIRECTIONAL -> DMA_FROM_DEVICE (Yunsheng).
- Added a comment around recovering of the old rx queue in
  net_devmem_restart_rx_queue(), and added freeing of old_mem if the
  restart of the old queue fails. (Yunsheng).
- Use kernel-family sock-priv (Jakub).
- Put pp_memory_provider_params in netdev_rx_queue instead of the
  dma-buf specific binding (Pavel & David).
- Move queue management ops to queue_mgmt_ops instead of netdev_ops
  (Jakub).
- Remove excess whitespaces (Jakub).
- Use genlmsg_iput (Jakub).

v6:
- Validate rx queue index
- Refactor new functions into devmem.c (Pavel)

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

---
 Documentation/netlink/specs/netdev.yaml |   4 +
 include/net/devmem.h| 111 +++
 include/net/netdev_rx_queue.h   |   2 +
 include/net/netmem.h|  10 +
 include/net/page_pool/types.h   |   6 +
 net/core/Makefile   |   2 +-
 net/core/dev.c  |   3 +
 net/core/devmem.c   | 252 
 net/core/netdev-genl-gen.c  |   4 +
 net/core/netdev-genl-gen.h  |   4 +
 net/core/netdev-genl.c  | 101 +-
 11 files changed, 496 insertions(+), 3 deletions(-)
 create mode 100644 include/net/devmem.h
 create mode 100644 net/core/devmem.c

diff --git a/Documentation/netlink/specs/netdev.yaml 
b/Documentation/netlink/specs/netdev.yaml
index 899ac0882a098..d6d7cb01c145c 100644
--- a/Documentation/netlink/specs/netdev.yaml
+++ b/Documentation/netlink/specs/netdev.yaml
@@ -673,6 +673,10 @@ operations:
 - tx-packets
 - tx-bytes
 
+kernel-family:
+  headers: [ "linux/list.h"]
+  sock-priv: struct list_head
+
 mcast-groups:
   list:
 -
diff --git a/include/net/devmem.h b/include/net/devmem.h
new file mode 100644
index 0..eaf3fd965d7a8
--- /dev/null
+++ b/include/net/devmem.h
@@ -0,0 +1,111 @@
+/* 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 net_devmem_dmabuf_binding {
+   struct dma_buf *dmabuf;
+   struct dma_buf_attachment

[PATCH net-next v12 11/13] 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 reuse.

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

---

v10:
- Fix leak of tokens (Nikolay).

v7:
- Updated SO_DEVMEM_* uapi to use the next available entry (Arnd).

v6:
- Squash in locking optimizations from eduma...@google.com. With his
  changes we lock the xarray once per sock_devmem_dontneed operation
  rather than once per frag.

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  |  1 +
 arch/mips/include/uapi/asm/socket.h   |  1 +
 arch/parisc/include/uapi/asm/socket.h |  1 +
 arch/sparc/include/uapi/asm/socket.h  |  1 +
 include/uapi/asm-generic/socket.h |  1 +
 include/uapi/linux/uio.h  |  4 ++
 net/core/sock.c   | 61 +++
 7 files changed, 70 insertions(+)

diff --git a/arch/alpha/include/uapi/asm/socket.h 
b/arch/alpha/include/uapi/asm/socket.h
index ef4656a41058a..251b73c5481ea 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -144,6 +144,7 @@
 #define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
 #define SO_DEVMEM_DMABUF   79
 #define SCM_DEVMEM_DMABUF  SO_DEVMEM_DMABUF
+#define SO_DEVMEM_DONTNEED 80
 
 #if !defined(__KERNEL__)
 
diff --git a/arch/mips/include/uapi/asm/socket.h 
b/arch/mips/include/uapi/asm/socket.h
index 414807d55e33f..8ab7582291abf 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -155,6 +155,7 @@
 #define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
 #define SO_DEVMEM_DMABUF   79
 #define SCM_DEVMEM_DMABUF  SO_DEVMEM_DMABUF
+#define SO_DEVMEM_DONTNEED 80
 
 #if !defined(__KERNEL__)
 
diff --git a/arch/parisc/include/uapi/asm/socket.h 
b/arch/parisc/include/uapi/asm/socket.h
index 2b817efd45444..38fc0b188e084 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -136,6 +136,7 @@
 #define SCM_DEVMEM_LINEAR  SO_DEVMEM_LINEAR
 #define SO_DEVMEM_DMABUF   79
 #define SCM_DEVMEM_DMABUF  SO_DEVMEM_DMABUF
+#define SO_DEVMEM_DONTNEED 80
 
 #if !defined(__KERNEL__)
 
diff --git a/arch/sparc/include/uapi/asm/socket.h 
b/arch/sparc/include/uapi/asm/socket.h
index 00248fc689773..57084ed2f3c4e 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -137,6 +137,7 @@
 #define SCM_DEVMEM_LINEARSO_DEVMEM_LINEAR
 #define SO_DEVMEM_DMABUF 0x0058
 #define SCM_DEVMEM_DMABUFSO_DEVMEM_DMABUF
+#define SO_DEVMEM_DONTNEED   0x0059
 
 #if !defined(__KERNEL__)
 
diff --git a/include/uapi/asm-generic/socket.h 
b/include/uapi/asm-generic/socket.h
index 25a2f5255f523..1acb77780f103 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 3a22ddae376a2..d17f8fcd93ec9 100644
--- a/include/uapi/linux/uio.h
+++ b/include/uapi/linux/uio.h
@@ -33,6 +33,10 @@ struct dmabuf_cmsg {
 */
 };
 
+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 69baddcfbd8c1..41586277c8dbb 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -124,6 +124,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1049,6 +1050,62 @@ 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, k, netmem_num = 0;
+   struct dmabuf_token *tokens;
+   netmem_ref netmems[16];
+   int ret = 0;
+
+   if (sk->sk_type != SOCK_STREAM || sk->sk_protocol != IPPROTO_TCP)
+   return -EBADF;
+
+   if (optlen % sizeof(struct dmabuf_token) ||
+   optlen > sizeof(*tokens) * 128)
+   return -EINVAL;
+
+   tokens = kvmalloc_array(128, sizeof(*tokens), GFP_KERNEL);
+   if (!tokens)
+   return -ENOMEM;
+
+   num_tokens = optlen / sizeof(struct dmabuf_token);
+   if (copy_from_sockptr(tokens, optval, optlen)) {
+   kvfree(tokens);
+   return -EFAULT;
+   }
+
+   xa_lock_bh(>sk_user_frags);
+   for (i = 0; i < num_tokens;

[PATCH net-next v12 08/13] 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 


---

v10:
- Fixed newly generated kdoc warnings found by patchwork. While we're
  at it, fix the Return section of the functions I touched.

v6:
- Rebased on top of the merged netmem changes.

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

---
 include/linux/skbuff.h | 42 +-
 include/linux/skbuff_ref.h |  9 
 net/core/dev.c |  3 ++-
 net/core/gro.c |  3 ++-
 net/core/skbuff.c  | 11 ++
 net/ipv4/esp4.c|  3 ++-
 net/ipv4/tcp.c |  3 +++
 net/ipv6/esp6.c|  3 ++-
 8 files changed, 67 insertions(+), 10 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index fe7d8dbef77e1..0a4df0025e6dc 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3492,21 +3492,58 @@ static inline void skb_frag_off_copy(skb_frag_t *fragto,
fragto->offset = fragfrom->offset;
 }
 
+/* Return: 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->netmem);
+}
+
+/**
+ * skb_frag_net_iov - retrieve the net_iov referred to by fragment
+ * @frag: the fragment
+ *
+ * Return: the  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->netmem);
+}
+
 /**
  * skb_frag_page - retrieve the page referred to by a paged fragment
  * @frag: the paged fragment
  *
- * Returns the  page associated with @frag.
+ * Return: the  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->netmem);
 }
 
+/**
+ * skb_frag_netmem - retrieve the netmem referred to by a fragment
+ * @frag: the fragment
+ *
+ * Return: the _ref associated with @frag.
+ */
+static inline netmem_ref skb_frag_netmem(const skb_frag_t *frag)
+{
+   return frag->netmem;
+}
+
 int skb_pp_cow_data(struct page_pool *pool, struct sk_buff **pskb,
unsigned int headroom);
 int skb_cow_data_for_xdp(struct page_pool *pool, struct sk_buff **pskb,
 struct bpf_prog *prog);
+
 /**
  * skb_frag_address - gets the address of the data contained in a paged 
fragment
  * @frag: the paged fragment buffer
@@ -3516,6 +3553,9 @@ int skb_cow_data_for_xdp(struct page_pool *pool, struct 
sk_buff **pskb,
  */
 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/include/linux/skbuff_ref.h b/include/linux/skbuff_ref.h
index 16c241a234728..0f3c58007488a 100644
--- a/include/linux/skbuff_ref.h
+++ b/include/linux/skbuff_ref.h
@@ -34,14 +34,13 @@ static inline void skb_frag_ref(struct sk_buff *skb, int f)
 
 bool napi_pp_put_page(netmem_ref netmem);
 
-static inline void
-skb_page_unref(struct page *page, bool recycle)
+static inline void skb_page_unref(netmem_ref netmem, bool recycle)
 {
 #ifdef CONFIG_PAGE_POOL
-   if (recycle && napi_pp_put_page(page_to_netmem(page)))
+   if (recycle && napi_pp_put_page(netmem))
return;
 #endif
-   put_page(page);
+   put_page(netmem_to_page(netmem));
 }
 
 /**
@@ -54,7 +53,7 @@ skb_page_unref(struct page *page, bool recycle)
  */
 static inline void __skb_frag_unref(skb_frag_t *frag, bool recycle)
 {
-   skb_page_unref(skb_frag_page(frag), recycle);
+   skb_page_unref(skb_frag_netmem(frag), recycle);
 }
 
 /**
diff --git a/net/core/dev.c b/net/core/dev.c
index 84c9f96a6c9bf..7bbc3d94e01fa 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3432,8 +3432,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 = _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 b3b43de1a6502..26f09c3e830b7 100644
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -408,7 +408,8 @@ static inline void skb_gro_reset_offset(struct sk_buff 
*skb, u32 nhoff)
pinfo = skb_shinfo(skb);
frag0

[PATCH net-next v12 04/13] 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 

---

v11:
- Fix extraneous inline directive (Paolo)

v8:
- Rename netdev_dmabuf_binding -> net_devmem_dmabuf_binding to avoid
  patch-by-patch build error.
- Move niov->pp_magic/pp/pp_ref_counter usage to later patch to avoid
  patch-by-patch build error.

v7:
- netdev_ -> net_devmem_* naming (Yunsheng).

v6:
- Add comment on net_iov_dma_addr to explain why we don't use
  niov->dma_addr (Pavel)
- Refactor new functions into net/core/devmem.c (Pavel)

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

---
 include/net/devmem.h | 13 +
 include/net/netmem.h | 18 ++
 net/core/devmem.c| 44 
 3 files changed, 75 insertions(+)

diff --git a/include/net/devmem.h b/include/net/devmem.h
index eaf3fd965d7a8..b65795a8f8f13 100644
--- a/include/net/devmem.h
+++ b/include/net/devmem.h
@@ -68,7 +68,20 @@ int net_devmem_bind_dmabuf(struct net_device *dev, unsigned 
int dmabuf_fd,
 void net_devmem_unbind_dmabuf(struct net_devmem_dmabuf_binding *binding);
 int net_devmem_bind_dmabuf_to_queue(struct net_device *dev, u32 rxq_idx,
struct net_devmem_dmabuf_binding *binding);
+struct net_iov *
+net_devmem_alloc_dmabuf(struct net_devmem_dmabuf_binding *binding);
+void net_devmem_free_dmabuf(struct net_iov *ppiov);
 #else
+static inline struct net_iov *
+net_devmem_alloc_dmabuf(struct net_devmem_dmabuf_binding *binding)
+{
+   return NULL;
+}
+
+static inline void net_devmem_free_dmabuf(struct net_iov *ppiov)
+{
+}
+
 static inline void
 __net_devmem_dmabuf_binding_free(struct net_devmem_dmabuf_binding *binding)
 {
diff --git a/include/net/netmem.h b/include/net/netmem.h
index 72e932a1a9489..01dbdd216fae7 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -14,8 +14,26 @@
 
 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 struct net_devmem_dmabuf_binding *
+net_iov_binding(const struct net_iov *niov)
+{
+   return net_iov_owner(niov)->binding;
+}
+
 /* netmem */
 
 /**
diff --git a/net/core/devmem.c b/net/core/devmem.c
index 951a06004c430..b53ea67c020d3 100644
--- a/net/core/devmem.c
+++ b/net/core/devmem.c
@@ -32,6 +32,14 @@ static void net_devmem_dmabuf_free_chunk_owner(struct 
gen_pool *genpool,
kfree(owner);
 }
 
+static dma_addr_t net_devmem_get_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);
+}
+
 void __net_devmem_dmabuf_binding_free(struct net_devmem_dmabuf_binding 
*binding)
 {
size_t size, avail;
@@ -54,6 +62,42 @@ void __net_devmem_dmabuf_binding_free(struct 
net_devmem_dmabuf_binding *binding)
kfree(binding);
 }
 
+struct net_iov *
+net_devmem_alloc_dmabuf(struct net_devmem_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 **));
+   if (!dma_addr)
+   return NULL;
+
+   offset = dma_addr - owner->base_dma_addr;
+   index = offset / PAGE_SIZE;
+   niov = >niovs[index];
+
+   niov->dma_addr = 0;
+
+   net_devmem_dmabuf_binding_get(binding);
+
+   return niov;
+}
+
+void net_devmem_free_dmabuf(struct net_iov *niov)
+{
+   struct net_devmem_dmabuf_binding *binding = net_iov_binding(niov);
+   unsigned long dma_addr = net_devmem_get_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);
+
+   net_devmem_dmabuf_binding_put(binding);
+}
+
 /* Protected by rtnl_lock() */
 static DEFINE_XARRAY_FLAGS(net_devmem_dmabuf_bindings, XA_FLAGS_ALLOC1);
 
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH net-next v12 05/13] page_pool: convert to use netmem

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

---

v12:
- Fix allmodconfig build error. Very recently renesas/ravb_main.c added
  a dependency on page_pool that I missed in my rebase. The dependency
  calls page_pool_alloc() directly as it wants to set a custom gfp_mask,
  which is unique as all other drivers call a wrapper to that function.
  Fix it by adding netmem_to_page() in the driver.
- Fix printing netmem trace printing (Pavel).

v11:
- Fix typing to remove sparse warning. (Paolo/Steven)

v9:
- Fix sparse error (Simon).

v8:
- Fix napi_pp_put_page() taking netmem instead of page to fix
  patch-by-patch build error.
- Add net/netmem.h include in this patch to fix patch-by-patch build
  error.

v6:

- Rebased on top of the merged netmem_ref type.

Cc: linux...@kvack.org
Cc: Matthew Wilcox 

---
 drivers/net/ethernet/renesas/ravb_main.c |   5 +-
 include/linux/skbuff_ref.h   |   4 +-
 include/net/netmem.h |  15 ++
 include/net/page_pool/helpers.h  | 120 ++---
 include/net/page_pool/types.h|  14 +-
 include/trace/events/page_pool.h |  30 +--
 net/bpf/test_run.c   |   5 +-
 net/core/page_pool.c | 304 ---
 net/core/skbuff.c|   8 +-
 9 files changed, 305 insertions(+), 200 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index c1546b916e4ef..093236ebfeecb 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -303,8 +303,9 @@ ravb_alloc_rx_buffer(struct net_device *ndev, int q, u32 
entry, gfp_t gfp_mask,
 
rx_buff = >rx_buffers[q][entry];
size = info->rx_buffer_size;
-   rx_buff->page = page_pool_alloc(priv->rx_pool[q], _buff->offset,
-   , gfp_mask);
+   rx_buff->page = netmem_to_page(page_pool_alloc(priv->rx_pool[q],
+  _buff->offset,
+  , gfp_mask));
if (unlikely(!rx_buff->page)) {
/* We just set the data size to 0 for a failed mapping which
 * should prevent DMA from happening...
diff --git a/include/linux/skbuff_ref.h b/include/linux/skbuff_ref.h
index 11f0a40634033..16c241a234728 100644
--- a/include/linux/skbuff_ref.h
+++ b/include/linux/skbuff_ref.h
@@ -32,13 +32,13 @@ static inline void skb_frag_ref(struct sk_buff *skb, int f)
__skb_frag_ref(_shinfo(skb)->frags[f]);
 }
 
-bool napi_pp_put_page(struct page *page);
+bool napi_pp_put_page(netmem_ref netmem);
 
 static inline void
 skb_page_unref(struct page *page, bool recycle)
 {
 #ifdef CONFIG_PAGE_POOL
-   if (recycle && napi_pp_put_page(page))
+   if (recycle && napi_pp_put_page(page_to_netmem(page)))
return;
 #endif
put_page(page);
diff --git a/include/net/netmem.h b/include/net/netmem.h
index 01dbdd216fae7..664df8325ece5 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -66,4 +66,19 @@ static inline netmem_ref page_to_netmem(struct page *page)
return (__force netmem_ref)page;
 }
 
+static inline int netmem_ref_count(netmem_ref netmem)
+{
+   return page_ref_count(netmem_to_page(netmem));
+}
+
+static inline unsigned long netmem_to_pfn(netmem_ref netmem)
+{
+   return page_to_pfn(netmem_to_page(netmem));
+}
+
+static inline netmem_ref netmem_compound_head(netmem_ref 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 873631c79ab16..5e129d5304f53 100644
--- a/include/net/page_pool/helpers.h
+++ b/include/net/page_pool/helpers.h
@@ -55,6 +55,8 @@
 #include 
 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_PAGE_POOL_STATS
 /* Deprecated driver-facing API, use netlink instead */
@@ -103,7 +105,7 @@ static inline struct

[PATCH net-next v12 02/13] net: netdev netlink api to bind dma-buf to a net device

API takes the dma-buf fd as input, and binds it to the netdevice. The
user can specify the rx queues to bind the dma-buf to.

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

---

v7:
- Use flags: [ admin-perm ] instead of a CAP_NET_ADMIN check.

Changes in v1:
- Add rx-queue-type to distingish rx from tx (Jakub)
- Return dma-buf ID from netlink API (David, Stan)

Changes in RFC-v3:
- Support binding multiple rx rx-queues

---
 Documentation/netlink/specs/netdev.yaml | 53 +
 include/uapi/linux/netdev.h | 19 +
 net/core/netdev-genl-gen.c  | 19 +
 net/core/netdev-genl-gen.h  |  2 +
 net/core/netdev-genl.c  |  6 +++
 tools/include/uapi/linux/netdev.h   | 19 +
 6 files changed, 118 insertions(+)

diff --git a/Documentation/netlink/specs/netdev.yaml 
b/Documentation/netlink/specs/netdev.yaml
index 959755be4d7f9..899ac0882a098 100644
--- a/Documentation/netlink/specs/netdev.yaml
+++ b/Documentation/netlink/specs/netdev.yaml
@@ -268,6 +268,45 @@ attribute-sets:
 name: napi-id
 doc: ID of the NAPI instance which services this queue.
 type: u32
+  -
+name: queue-dmabuf
+attributes:
+  -
+name: type
+doc: rx or tx queue
+type: u8
+enum: queue-type
+  -
+name: idx
+doc: queue index
+type: u32
+
+  -
+name: bind-dmabuf
+attributes:
+  -
+name: ifindex
+doc: netdev ifindex to bind the dma-buf to.
+type: u32
+checks:
+  min: 1
+  -
+name: queues
+doc: receive queues to bind the dma-buf to.
+type: nest
+nested-attributes: queue-dmabuf
+multi-attr: true
+  -
+name: dmabuf-fd
+doc: dmabuf file descriptor to bind.
+type: u32
+  -
+name: dmabuf-id
+doc: id of the dmabuf binding
+type: u32
+checks:
+  min: 1
+
 
   -
 name: qstats
@@ -579,6 +618,20 @@ operations:
   attributes:
 - ifindex
 reply: *queue-get-op
+-
+  name: bind-rx
+  doc: Bind dmabuf to netdev
+  attribute-set: bind-dmabuf
+  flags: [ admin-perm ]
+  do:
+request:
+  attributes:
+- ifindex
+- dmabuf-fd
+- queues
+reply:
+  attributes:
+- dmabuf-id
 -
   name: napi-get
   doc: Get information about NAPI instances configured on the system.
diff --git a/include/uapi/linux/netdev.h b/include/uapi/linux/netdev.h
index 43742ac5b00da..190a504a62358 100644
--- a/include/uapi/linux/netdev.h
+++ b/include/uapi/linux/netdev.h
@@ -136,6 +136,24 @@ enum {
NETDEV_A_QUEUE_MAX = (__NETDEV_A_QUEUE_MAX - 1)
 };
 
+enum {
+   NETDEV_A_QUEUE_DMABUF_TYPE = 1,
+   NETDEV_A_QUEUE_DMABUF_IDX,
+
+   __NETDEV_A_QUEUE_DMABUF_MAX,
+   NETDEV_A_QUEUE_DMABUF_MAX = (__NETDEV_A_QUEUE_DMABUF_MAX - 1)
+};
+
+enum {
+   NETDEV_A_BIND_DMABUF_IFINDEX = 1,
+   NETDEV_A_BIND_DMABUF_QUEUES,
+   NETDEV_A_BIND_DMABUF_DMABUF_FD,
+   NETDEV_A_BIND_DMABUF_DMABUF_ID,
+
+   __NETDEV_A_BIND_DMABUF_MAX,
+   NETDEV_A_BIND_DMABUF_MAX = (__NETDEV_A_BIND_DMABUF_MAX - 1)
+};
+
 enum {
NETDEV_A_QSTATS_IFINDEX = 1,
NETDEV_A_QSTATS_QUEUE_TYPE,
@@ -184,6 +202,7 @@ enum {
NETDEV_CMD_PAGE_POOL_CHANGE_NTF,
NETDEV_CMD_PAGE_POOL_STATS_GET,
NETDEV_CMD_QUEUE_GET,
+   NETDEV_CMD_BIND_RX,
NETDEV_CMD_NAPI_GET,
NETDEV_CMD_QSTATS_GET,
 
diff --git a/net/core/netdev-genl-gen.c b/net/core/netdev-genl-gen.c
index 8350a0afa9ec7..9acd0d893765a 100644
--- a/net/core/netdev-genl-gen.c
+++ b/net/core/netdev-genl-gen.c
@@ -27,6 +27,11 @@ const struct nla_policy 
netdev_page_pool_info_nl_policy[NETDEV_A_PAGE_POOL_IFIND
[NETDEV_A_PAGE_POOL_IFINDEX] = NLA_POLICY_FULL_RANGE(NLA_U32, 
_a_page_pool_ifindex_range),
 };
 
+const struct nla_policy 
netdev_queue_dmabuf_nl_policy[NETDEV_A_QUEUE_DMABUF_IDX + 1] = {
+   [NETDEV_A_QUEUE_DMABUF_TYPE] = NLA_POLICY_MAX(NLA_U8, 1),
+   [NETDEV_A_QUEUE_DMABUF_IDX] = { .type = NLA_U32, },
+};
+
 /* NETDEV_CMD_DEV_GET - do */
 static const struct nla_policy netdev_dev_get_nl_policy[NETDEV_A_DEV_IFINDEX + 
1] = {
[NETDEV_A_DEV_IFINDEX] = NLA_POLICY_MIN(NLA_U32, 1),
@@ -58,6 +63,13 @@ static const struct nla_policy 
netdev_queue_get_dump_nl_policy[NETDEV_A_QUEUE_IF
[NETDEV_A_QUEUE_IFINDEX] = NLA_POLICY_MIN(NLA_U32, 1),
 };
 
+/* NETDEV_CMD_BIND_RX - do */
+static const struct nla_policy 
netdev_bind_rx_nl_policy[NETDEV_A_BIND_DMABUF_DMABUF_FD + 1] = {
+   [NETDEV_A_BIND_DMABUF_IFINDEX] = NLA_POLICY_MIN(NLA_U32, 1),
+   [NETDEV_A_BIND_DMABUF_DMABUF_FD] = { .type = NLA_U32, },
+   [NETDEV_A_BIND_DMABUF_QUEUES] = 
NLA_POLICY_NESTED(netdev_queue_dmabuf_nl_policy),
+};
+
 /* NETDEV_CMD_NAPI_GET - do */
 static const struct nla_policy

[PATCH net-next v12 00/13] Device Memory TCP

v12: https://patchwork.kernel.org/project/netdevbpf/list/?series=859747=*


Major changes:
--

This iteration only addresses one minor comment from Pavel with regards
to the trace printing of netmem, and the patchwork build error
introduced in v11 because I missed doing an allmodconfig build, sorry.

Other than that v11, AFAICT, received no feedback. There is one
discussion about how the specifics of  plugging io uring memory through
the page pool, but not relevant to content in this particular patchset,
AFAICT.

As usual, the full devmem TCP changes including the full GVE driver
implementation is here:

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

v11: https://patchwork.kernel.org/project/netdevbpf/list/?series=857457=*


Major Changes:
--

v11 addresses feedback received in v10. The major change is the removal
of the memory provider ops as requested by Christoph. We still
accomplish the same thing, but utilizing direct function calls with if
statements rather than generic ops.

Additionally address sparse warnings, bugs and review comments from
folks that reviewed.

As usual, the full devmem TCP changes including the full GVE driver
implementation is here:

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

Detailed changelog:
---

- Fixes in netdev_rx_queue_restart() from Pavel & David.
- Remove commit e650e8c3a36f5 ("net: page_pool: create hooks for
custom page providers") from the series to address Christoph's
feedback and rebased other patches on the series on this change.
- Fixed build errors with CONFIG_DMA_SHARED_BUFFER &&
  !CONFIG_GENERIC_ALLOCATOR build.
- Fixed sparse warnings pointed out by Paolo.
- Drop unnecessary gro_pull_from_frag0 checks.
- Added Bagas reviewed-by to docs.

Cc: Bagas Sanjaya 
Cc: Steven Rostedt 
Cc: Christoph Hellwig 
Cc: Nikolay Aleksandrov 

v10: https://patchwork.kernel.org/project/netdevbpf/list/?series=852422=*


Major Changes:
--

v9 was sent right before the merge window closed (sorry!). v10 is almost
a re-send of the series now that the merge window re-opened. Only
rebased to latest net-next and addressed some minor iterative comments
received on v9.

As usual, the full devmem TCP changes including the full GVE driver
implementation is here:

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

Detailed changelog:
---

- Fixed tokens leaking in DONTNEED setsockopt (Nikolay).
- Moved net_iov_dma_addr() to devmem.c and made it a devmem specific
  helpers (David).
- Rename hook alloc_pages to alloc_netmems as alloc_pages is now
  preprocessor macro defined and causes a build error.

v9:
===

Major Changes:
--

GVE queue API has been merged. Submitting this version as non-RFC after
rebasing on top of the merged API, and dropped the out of tree queue API
I was carrying on github. Addressed the little feedback v8 has received.

Detailed changelog:
--
- Added new patch from David Wei to this series for
  netdev_rx_queue_restart()
  - Fixed sparse error.
  - Removed CONFIG_ checks in netmem_is_net_iov()
  - Flipped skb->readable to skb->unreadable
  - Minor fixes to selftests & docs.

RFC v8:
===

Major Changes:
--

- Fixed build error generated by patch-by-patch build.
- Applied docs suggestions from Randy.

RFC v7:
===

Major Changes:
--

This revision largely rebases on top of net-next and addresses the feedback
RFCv6 received from folks, namely Jakub, Yunsheng, Arnd, David, & Pavel.

The series remains in RFC because the queue-API ndos defined in this
series are not yet implemented. I have a GVE implementation I carry out
of tree for my testing. A upstreamable GVE implementation is in the
works. Aside from that, in my estimation all the patches are ready for
review/merge. Please do take a look.

As usual the full devmem TCP changes including the full GVE driver
implementation is here:

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

Detailed changelog:

- Use admin-perm in netlink API.
- Addressed feedback from Jakub with regards to netlink API
  implementation.
- Renamed devmem.c functions to something more appropriate for that
  file.
- Improve the performance seen through the page_pool benchmark.
- Fix the value definition of all the SO_DEVMEM_* uapi.
- Various fixes to documentation.

Perf - page-pool benchmark:
---

Improved performance of bench_page_pool_simple.ko tests compared to v6:

https://pastebin.com/raw/v5dYRg8L

  net-next base: 8 cycle fast path.
  RFC v6: 10 cycle fast path.
  RFC v7: 9 cycle fast path.
  RFC v7 with CONFIG_DMA_SHARED_BUFFER disabled: 8 cycle fast path,
 same as baseline.

Perf - Devmem TCP benchmark:
-

Perf is about the same regardless of the changes in v7, namely the
removal of the static_branch_unlikely to improve the page_pool benchmark
performance:

189/200gbps

[PATCH net-next v12 01/13] netdev: add netdev_rx_queue_restart()

Add netdev_rx_queue_restart() function to netdev_rx_queue.h

Signed-off-by: David Wei 
Signed-off-by: Mina Almasry 

---

v11:
- Fix not checking dev->queue_mgmt_ops (Pavel).
- Fix ndo_queue_mem_free call that passed the wrong pointer (David).

v9: https://lore.kernel.org/all/20240502045410.3524155-4...@davidwei.uk/
(submitted by David).
- fixed SPDX license identifier (Simon).
- Rebased on top of merged queue API definition, and changed
  implementation to match that.
- Replace rtnl_lock() with rtnl_is_locked() to make it useable from my
  netlink code where rtnl is already locked.

---
 include/net/netdev_rx_queue.h |  3 ++
 net/core/Makefile |  1 +
 net/core/netdev_rx_queue.c| 74 +++
 3 files changed, 78 insertions(+)
 create mode 100644 net/core/netdev_rx_queue.c

diff --git a/include/net/netdev_rx_queue.h b/include/net/netdev_rx_queue.h
index aa1716fb0e53c..e78ca52d67fbf 100644
--- a/include/net/netdev_rx_queue.h
+++ b/include/net/netdev_rx_queue.h
@@ -54,4 +54,7 @@ get_netdev_rx_queue_index(struct netdev_rx_queue *queue)
return index;
 }
 #endif
+
+int netdev_rx_queue_restart(struct net_device *dev, unsigned int rxq);
+
 #endif
diff --git a/net/core/Makefile b/net/core/Makefile
index 62be9aef25285..f82232b358a2c 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_NETDEV_ADDR_LIST_TEST) += dev_addr_lists_test.o
 
 obj-y += net-sysfs.o
 obj-y += hotdata.o
+obj-y += netdev_rx_queue.o
 obj-$(CONFIG_PAGE_POOL) += page_pool.o page_pool_user.o
 obj-$(CONFIG_PROC_FS) += net-procfs.o
 obj-$(CONFIG_NET_PKTGEN) += pktgen.o
diff --git a/net/core/netdev_rx_queue.c b/net/core/netdev_rx_queue.c
new file mode 100644
index 0..de0575cf6df5d
--- /dev/null
+++ b/net/core/netdev_rx_queue.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include 
+#include 
+#include 
+
+int netdev_rx_queue_restart(struct net_device *dev, unsigned int rxq_idx)
+{
+   void *new_mem, *old_mem;
+   int err;
+
+   if (!dev->queue_mgmt_ops || !dev->queue_mgmt_ops->ndo_queue_stop ||
+   !dev->queue_mgmt_ops->ndo_queue_mem_free ||
+   !dev->queue_mgmt_ops->ndo_queue_mem_alloc ||
+   !dev->queue_mgmt_ops->ndo_queue_start)
+   return -EOPNOTSUPP;
+
+   DEBUG_NET_WARN_ON_ONCE(!rtnl_is_locked());
+
+   new_mem = kvzalloc(dev->queue_mgmt_ops->ndo_queue_mem_size, GFP_KERNEL);
+   if (!new_mem)
+   return -ENOMEM;
+
+   old_mem = kvzalloc(dev->queue_mgmt_ops->ndo_queue_mem_size, GFP_KERNEL);
+   if (!old_mem) {
+   err = -ENOMEM;
+   goto err_free_new_mem;
+   }
+
+   err = dev->queue_mgmt_ops->ndo_queue_mem_alloc(dev, new_mem, rxq_idx);
+   if (err)
+   goto err_free_old_mem;
+
+   err = dev->queue_mgmt_ops->ndo_queue_stop(dev, old_mem, rxq_idx);
+   if (err)
+   goto err_free_new_queue_mem;
+
+   err = dev->queue_mgmt_ops->ndo_queue_start(dev, new_mem, rxq_idx);
+   if (err)
+   goto err_start_queue;
+
+   dev->queue_mgmt_ops->ndo_queue_mem_free(dev, old_mem);
+
+   kvfree(old_mem);
+   kvfree(new_mem);
+
+   return 0;
+
+err_start_queue:
+   /* Restarting the queue with old_mem should be successful as we haven't
+* changed any of the queue configuration, and there is not much we can
+* do to recover from a failure here.
+*
+* WARN if the we fail to recover the old rx queue, and at least free
+* old_mem so we don't also leak that.
+*/
+   if (dev->queue_mgmt_ops->ndo_queue_start(dev, old_mem, rxq_idx)) {
+   WARN(1,
+"Failed to restart old queue in error path. RX queue %d 
may be unhealthy.",
+rxq_idx);
+   dev->queue_mgmt_ops->ndo_queue_mem_free(dev, old_mem);
+   }
+
+err_free_new_queue_mem:
+   dev->queue_mgmt_ops->ndo_queue_mem_free(dev, new_mem);
+
+err_free_old_mem:
+   kvfree(old_mem);
+
+err_free_new_mem:
+   kvfree(new_mem);
+
+   return err;
+}
-- 
2.45.2.505.gda0bf45e8d-goog

Re: [PATCH v4 10/13] drm/msm/dpu: allow sharing SSPP between planes

2024-06-12 Thread Abhinav Kumar





On 6/12/2024 2:08 AM, Dmitry Baryshkov wrote:

On Wed, 12 Jun 2024 at 02:12, Abhinav Kumar  wrote:




On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:

Since SmartDMA planes provide two rectangles, it is possible to use them
to drive two different DRM planes, first plane getting the rect_0,
another one using rect_1 of the same SSPP. The sharing algorithm is
pretty simple, it requires that each of the planes can be driven by the
single rectangle and only consequetive planes are considered.



consequetive - > consecutive

Can you please explain why only consecutive planes are considered for this?

So lets say we have 4 virtual planes : 0, 1, 2, 3

It will try 0-1, 1-2, 2-3

Because all planes are virtual, there are only 3 unique pairs to be
considered? Otherwise technically 6 pairs are possible.


An implementation that tries all 6 pairs taking the zpos and the
overlapping into account is appreciated. I cared for the simplest case
here. Yes, further optimizations can be implemented.



Ok got it. So you would like to build a better one on top of this.
But I see one case where this has an issue or is not optimal. Pls see below.




General request:

Patches 1-9 : Add support for using 2 SSPPs in one plane
Patches 10-12 : Add support for using two rectangles of the same SSPP as
two virtual planes
Patch 13 : Can be pushed along with the first set.

Can we break up this series in this way to make it easier to test and
land the bulk of it in this cycle?


Sure.



Thanks.



I have some doubts on patches 10-12 and would like to spend more time
reviewing and testing this. So I am trying to reduce the debt of patches
we have been carrying as this is a tricky feature to simulate and test
the cases.


Signed-off-by: Dmitry Baryshkov 
---
   drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 128 +++---
   1 file changed, 112 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index cde20c1fa90d..2e1c544efc4a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -886,10 +886,9 @@ static int dpu_plane_atomic_check_nopipe(struct drm_plane 
*plane,
   return 0;
   }

-static int dpu_plane_is_multirect_parallel_capable(struct dpu_sw_pipe *pipe,
-struct dpu_sw_pipe_cfg 
*pipe_cfg,
-const struct dpu_format *fmt,
-uint32_t max_linewidth)
+static int dpu_plane_is_multirect_capable(struct dpu_sw_pipe *pipe,
+   struct dpu_sw_pipe_cfg *pipe_cfg,
+   const struct dpu_format *fmt)
   {
   if (drm_rect_width(_cfg->src_rect) != 
drm_rect_width(_cfg->dst_rect) ||
   drm_rect_height(_cfg->src_rect) != 
drm_rect_height(_cfg->dst_rect))
@@ -901,6 +900,13 @@ static int dpu_plane_is_multirect_parallel_capable(struct 
dpu_sw_pipe *pipe,
   if (DPU_FORMAT_IS_YUV(fmt))
   return false;

+ return true;
+}
+
+static int dpu_plane_is_parallel_capable(struct dpu_sw_pipe_cfg *pipe_cfg,
+  const struct dpu_format *fmt,
+  uint32_t max_linewidth)
+{
   if (DPU_FORMAT_IS_UBWC(fmt) &&
   drm_rect_width(_cfg->src_rect) > max_linewidth / 2)
   return false;
@@ -908,6 +914,82 @@ static int dpu_plane_is_multirect_parallel_capable(struct 
dpu_sw_pipe *pipe,
   return true;
   }

+static int dpu_plane_is_multirect_parallel_capable(struct dpu_sw_pipe *pipe,
+struct dpu_sw_pipe_cfg 
*pipe_cfg,
+const struct dpu_format *fmt,
+uint32_t max_linewidth)
+{
+ return dpu_plane_is_multirect_capable(pipe, pipe_cfg, fmt) &&
+ dpu_plane_is_parallel_capable(pipe_cfg, fmt, max_linewidth);
+}
+
+
+static int dpu_plane_try_multirect(struct dpu_plane_state *pstate,
+struct dpu_plane_state *prev_pstate,
+const struct dpu_format *fmt,
+uint32_t max_linewidth)
+{
+ struct dpu_sw_pipe *pipe = >pipe;
+ struct dpu_sw_pipe *r_pipe = >r_pipe;
+ struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
+ struct dpu_sw_pipe *prev_pipe = _pstate->pipe;
+ struct dpu_sw_pipe_cfg *prev_pipe_cfg = _pstate->pipe_cfg;
+ const struct dpu_format *prev_fmt =
+ to_dpu_format(msm_framebuffer_format(prev_pstate->base.fb));
+ u16 max_tile_height = 1;
+
+ if (prev_pstate->r_pipe.sspp != NULL ||
+ prev_pipe->multirect_mode != DPU_SSPP_MULTIRECT_NONE)
+ return false;
+
+ if (!dpu_plane_is_multirect_capable(pipe, pipe_cfg, fmt) ||
+ !dpu_plane_is_multirect_capable(prev_pipe, prev_pipe_cfg, prev_fmt)

Re: [PATCH net-next v11 05/13] page_pool: convert to use netmem

2024-06-12 Thread Jakub Kicinski

On Fri,  7 Jun 2024 00:51:15 + Mina Almasry wrote:
> 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 current 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.

Sorry for lack of meaningful review, busy times, in the meantime:

drivers/net/ethernet/renesas/ravb_main.c:306:16: error: incompatible integer to 
pointer conversion assigning to 'struct page *' from 'netmem_ref' (aka 
'unsigned long') [-Wint-conversion]
  306 | rx_buff->page = page_pool_alloc(priv->rx_pool[q], 
_buff->offset,
  |   ^ 
~~~
  307 | , gfp_mask);
  | 
-- 
pw-bot: cr

Re: [PATCH 2/9] iommu/rockchip: Attach multiple power domains

2024-06-12 Thread Sebastian Reichel

Hi,

On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
> IOMMUs with multiple base addresses can also have multiple power
> domains.
> 
> The base framework only takes care of a single power domain, as some
> devices will need for these power domains to be powered on in a specific
> order.
> 
> Use a helper function to stablish links in the order in which they are
> in the DT.
> 
> This is needed by the IOMMU used by the NPU in the RK3588.
> 
> Signed-off-by: Tomeu Vizoso 
> ---

To me it looks like this is multiple IOMMUs, which should each get
their own node. I don't see a good reason for merging these
together.

I will still review this assuming there is one. That would require
to first of all update the DT binding:

Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml

1. It does not allow using "power-domain-names" property
2. It limits the number of allowed power-domains to 1
3. It limits the number of allowed base addresses to 2

Looking at the DT patch you also add more interrupts and clocks,
which are also limited by the binding. You should see a bunch of
warnings when you check the DTBS via 'make dtbs_check'

>  drivers/iommu/rockchip-iommu.c | 36 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index f5629515bd78..673b0ebb6262 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -6,6 +6,8 @@
>   *   Daniel Kurtz 
>   */
>  
> +#include "linux/err.h"
> +#include "linux/pm_domain.h"
>  #include 
>  #include 
>  #include 
> @@ -115,6 +117,7 @@ struct rk_iommu {
>   struct iommu_device iommu;
>   struct list_head node; /* entry in rk_iommu_domain.iommus */
>   struct iommu_domain *domain; /* domain to which iommu is attached */
> + struct dev_pm_domain_list *pmdomains;
>  };
>  
>  struct rk_iommudata {
> @@ -1186,6 +1189,7 @@ static int rk_iommu_probe(struct platform_device *pdev)
>   struct resource *res;
>   const struct rk_iommu_ops *ops;
>   int num_res = pdev->num_resources;
> + int pm_domain_count;
>   int err, i;
>  
>   iommu = devm_kzalloc(dev, sizeof(*iommu), GFP_KERNEL);
> @@ -1271,6 +1275,35 @@ static int rk_iommu_probe(struct platform_device *pdev)
>   if (!dma_dev)
>   dma_dev = >dev;
>  
> + pm_domain_count = of_property_count_strings(iommu->dev->of_node, 
> "power-domain-names");

pm_domain_count = device_property_string_array_count(iommu->dev, 
"power-domain-names");

When possible using device_property_ is prefered, since it allows
reusing code for systems not using DT.

> + if (pm_domain_count > 0) {
> + const char **pm_domains = kvmalloc_array(pm_domain_count, 
> sizeof(*pm_domains), GFP_KERNEL);
> + struct dev_pm_domain_attach_data pm_domain_data = {
> + .pd_names = pm_domains,
> + .num_pd_names = pm_domain_count,
> + .pd_flags = PD_FLAG_DEV_LINK_ON,
> + };
> + int i;
> +
> + if (!pm_domain_data.pd_names) {
> + err = -ENOMEM;
> + goto err_remove_sysfs;
> + }
> +
> + for (i = 0; i < pm_domain_count; i++) {
> + err = 
> of_property_read_string_index(iommu->dev->of_node, "power-domain-names", i, 
> _domains[i]);
> + if (err) {
> + kfree(pm_domains);
> + goto err_remove_sysfs;
> + }
> + }

There is a helper to read a string array:

err = device_property_read_string_array(iommu->dev, "power-domain-names", 
pm_domains, pm_domain_count);

-- Sebastian

> +
> + err = dev_pm_domain_attach_list(iommu->dev, _domain_data, 
> >pmdomains);
> + kfree(pm_domains);
> + if (err < 0)
> + goto err_remove_sysfs;
> + }
> +
>   pm_runtime_enable(dev);
>  
>   for (i = 0; i < iommu->num_irq; i++) {
> @@ -1292,6 +1325,7 @@ static int rk_iommu_probe(struct platform_device *pdev)
>   return 0;
>  err_pm_disable:
>   pm_runtime_disable(dev);
> + dev_pm_domain_detach_list(iommu->pmdomains);
>  err_remove_sysfs:
>   iommu_device_sysfs_remove(>iommu);
>  err_unprepare_clocks:
> @@ -1310,6 +1344,8 @@ static void rk_iommu_shutdown(struct platform_device 
> *pdev)
>   devm_free_irq(iommu->dev, irq, iommu);
>   }
>  
> + dev_pm_domain_detach_list(iommu->pmdomains);
> +
>   pm_runtime_force_suspend(>dev);
>  }
>  
> 
> -- 
> 2.45.2
> 
> 


signature.asc
Description: PGP signature

Re: [PATCH 1/9] iommu/rockchip: Add compatible for rockchip,rk3588-iommu

2024-06-12 Thread Sebastian Reichel

Hello Tomeu,

On Wed, Jun 12, 2024 at 03:52:54PM GMT, Tomeu Vizoso wrote:
> So far, seems to be fully compatible with the one in the RK3568.
> 
> The bindings already had this compatible, but the driver didn't
> advertise it.
> 
> Signed-off-by: Tomeu Vizoso 
> ---

The driver does not need to advise it, since it already handles
"rockchip,rk3568-iommu" and the correct compatible for the RK3588
IOMMU is:

compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";

i.e. with the RK3568 compatible as fallback. So the kernel will
just bind to the fallback compatible. Iff differences are found
in the future, the kernel can start to make use of the more
specific compatible.

-- Sebastian

>  drivers/iommu/rockchip-iommu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 4b369419b32c..f5629515bd78 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1363,6 +1363,9 @@ static const struct of_device_id rk_iommu_dt_ids[] = {
>   {   .compatible = "rockchip,rk3568-iommu",
>   .data = _data_ops_v2,
>   },
> + {   .compatible = "rockchip,rk3588-iommu",
> + .data = _data_ops_v2,
> + },
>   { /* sentinel */ }
>  };
>  
> 
> -- 
> 2.45.2
> 
> 


signature.asc
Description: PGP signature

[PATCH v2 8/8] drm/amdgpu: Call drm_atomic_helper_shutdown() at shutdown time

Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.

The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.

Suggested-by: Maxime Ripard 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Xinhui Pan 
Signed-off-by: Douglas Anderson 
---
This commit is only compile-time tested.

...and further, I'd say that this patch is more of a plea for help
than a patch I think is actually right. I'm _fairly_ certain that
drm/amdgpu needs this call at shutdown time but the logic is a bit
hard for me to follow. I'd appreciate if anyone who actually knows
what this should look like could illuminate me, or perhaps even just
post a patch themselves!

(no changes since v1)

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  2 ++
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f87d53e183c3..c202a1d5ff5f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1197,6 +1197,7 @@ static inline struct amdgpu_device 
*amdgpu_ttm_adev(struct ttm_device *bdev)
 int amdgpu_device_init(struct amdgpu_device *adev,
   uint32_t flags);
 void amdgpu_device_fini_hw(struct amdgpu_device *adev);
+void amdgpu_device_shutdown_hw(struct amdgpu_device *adev);
 void amdgpu_device_fini_sw(struct amdgpu_device *adev);
 
 int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 861ccff78af9..a8c4b8412e04 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4531,6 +4531,16 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
 
 }
 
+void amdgpu_device_shutdown_hw(struct amdgpu_device *adev)
+{
+   if (adev->mode_info.mode_config_initialized) {
+   if (!drm_drv_uses_atomic_modeset(adev_to_drm(adev)))
+   drm_helper_force_disable_all(adev_to_drm(adev));
+   else
+   drm_atomic_helper_shutdown(adev_to_drm(adev));
+   }
+}
+
 void amdgpu_device_fini_sw(struct amdgpu_device *adev)
 {
int idx;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index ea14f1c8f430..b34bf9259d5c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2409,6 +2409,8 @@ amdgpu_pci_shutdown(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
struct amdgpu_device *adev = drm_to_adev(dev);
 
+   amdgpu_device_shutdown_hw(adev);
+
if (amdgpu_ras_intr_triggered())
return;
 
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH v2 7/8] drm/radeon: Call drm_helper_force_disable_all() at shutdown/remove time

Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all() will cause panels to get disabled
cleanly which may be important for their power sequencing. Future
changes will remove any custom powering off in individual panel
drivers so the DRM drivers need to start getting this right.

The fact that we should call drm_atomic_helper_shutdown(), or in this
case the non-atomic equivalent drm_helper_force_disable_all(), in the
case of OS shutdown/restart comes straight out of the kernel doc
"driver instance overview" in drm_drv.c.

NOTE: in order to get things inserted in the right place, I had to
replace the old/deprecated drm_put_dev() function with the equivalent
new calls.

Suggested-by: Maxime Ripard 
Reviewed-by: Maxime Ripard 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Xinhui Pan 
Signed-off-by: Douglas Anderson 
---
I honestly have no idea if I got this patch right. The shutdown()
function already had some special case logic for PPC, Loongson, and
VMs and I don't 100% for sure know how this interacts with
those. Everything here is just compile tested.

(no changes since v1)

 drivers/gpu/drm/radeon/radeon_drv.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 7bf08164140e..9ea7f163a731 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -38,6 +38,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -330,7 +331,9 @@ radeon_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
 
-   drm_put_dev(dev);
+   drm_dev_unregister(dev);
+   drm_helper_force_disable_all(dev);
+   drm_dev_put(dev);
 }
 
 static void
@@ -341,6 +344,8 @@ radeon_pci_shutdown(struct pci_dev *pdev)
 */
if (radeon_device_is_virtual())
radeon_pci_remove(pdev);
+   else
+   drm_helper_force_disable_all(pci_get_drvdata(pdev));
 
 #if defined(CONFIG_PPC64) || defined(CONFIG_MACH_LOONGSON64)
/*
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH v2 6/8] drm/gma500: Call drm_helper_force_disable_all() at shutdown/remove time

Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all() will cause panels to get disabled
cleanly which may be important for their power sequencing. Future
changes will remove any custom powering off in individual panel
drivers so the DRM drivers need to start getting this right.

The fact that we should call drm_atomic_helper_shutdown(), or in this
case the non-atomic equivalent drm_helper_force_disable_all(), in the
case of OS shutdown/restart comes straight out of the kernel doc
"driver instance overview" in drm_drv.c.

Suggested-by: Maxime Ripard 
Reviewed-by: Maxime Ripard 
Signed-off-by: Douglas Anderson 
---
This commit is only compile-time tested.

(no changes since v1)

 drivers/gpu/drm/gma500/psb_drv.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 8b64f61ffaf9..a5a399bbe8f5 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -20,6 +20,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -485,6 +486,12 @@ static void psb_pci_remove(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
 
drm_dev_unregister(dev);
+   drm_helper_force_disable_all(dev);
+}
+
+static void psb_pci_shutdown(struct pci_dev *pdev)
+{
+   drm_helper_force_disable_all(pci_get_drvdata(pdev));
 }
 
 static DEFINE_RUNTIME_DEV_PM_OPS(psb_pm_ops, gma_power_suspend, 
gma_power_resume, NULL);
@@ -521,6 +528,7 @@ static struct pci_driver psb_pci_driver = {
.id_table = pciidlist,
.probe = psb_pci_probe,
.remove = psb_pci_remove,
+   .shutdown = psb_pci_shutdown,
.driver.pm = _pm_ops,
 };
 
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH v2 3/8] drm/tegra: Call drm_atomic_helper_shutdown() at shutdown time

Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.

The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.

Suggested-by: Maxime Ripard 
Reviewed-by: Maxime Ripard 
Signed-off-by: Douglas Anderson 
---
This commit is only compile-time tested.

(no changes since v1)

 drivers/gpu/drm/tegra/drm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 03d1c76aec2d..d9f0728c3afd 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1330,6 +1330,11 @@ static int host1x_drm_remove(struct host1x_device *dev)
return 0;
 }
 
+static void host1x_drm_shutdown(struct host1x_device *dev)
+{
+   drm_atomic_helper_shutdown(dev_get_drvdata(>dev));
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int host1x_drm_suspend(struct device *dev)
 {
@@ -1398,6 +1403,7 @@ static struct host1x_driver host1x_drm_driver = {
},
.probe = host1x_drm_probe,
.remove = host1x_drm_remove,
+   .shutdown = host1x_drm_shutdown,
.subdevs = host1x_drm_subdevs,
 };
 
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH v2 4/8] drm/arcpgu: Call drm_atomic_helper_shutdown() at shutdown time

Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.

The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.

Suggested-by: Maxime Ripard 
Reviewed-by: Maxime Ripard 
Signed-off-by: Douglas Anderson 
---
This commit is only compile-time tested.

(no changes since v1)

 drivers/gpu/drm/tiny/arcpgu.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
index 4f8f3172379e..85b21f5aac55 100644
--- a/drivers/gpu/drm/tiny/arcpgu.c
+++ b/drivers/gpu/drm/tiny/arcpgu.c
@@ -412,6 +412,11 @@ static void arcpgu_remove(struct platform_device *pdev)
arcpgu_unload(drm);
 }
 
+static void arcpgu_shutdown(struct platform_device *pdev)
+{
+   drm_atomic_helper_shutdown(platform_get_drvdata(pdev));
+}
+
 static const struct of_device_id arcpgu_of_table[] = {
{.compatible = "snps,arcpgu"},
{}
@@ -422,6 +427,7 @@ MODULE_DEVICE_TABLE(of, arcpgu_of_table);
 static struct platform_driver arcpgu_platform_driver = {
.probe = arcpgu_probe,
.remove_new = arcpgu_remove,
+   .shutdown = arcpgu_shutdown,
.driver = {
   .name = "arcpgu",
   .of_match_table = arcpgu_of_table,
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH v2 5/8] drm/sprd: Call drm_atomic_helper_shutdown() at remove time

Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at remove time. Let's
add it.

The fact that we should call drm_atomic_helper_shutdown() in the case
of OS driver remove comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.

While at it, let's also fix it so that if the driver's bind fails or
if a driver gets unbound that the drvdata gets set to NULL. This will
make sure we can't get confused during a later shutdown().

Suggested-by: Maxime Ripard 
Reviewed-by: Maxime Ripard 
Signed-off-by: Douglas Anderson 
---
This commit is only compile-time tested.

While making this patch, I noticed that the bind() function of this
driver is using "devm". That's probably a bug. As per kernel docs [1]
"the lifetime of the aggregate driver does not align with any of the
underlying struct device instances. Therefore devm cannot be used and
all resources acquired or allocated in this callback must be
explicitly released in the unbind callback". Fixing that is outside
the scope of this commit.

[1] https://docs.kernel.org/driver-api/component.html

(no changes since v1)

 drivers/gpu/drm/sprd/sprd_drm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
index a74cd0caf645..d4453430dd1f 100644
--- a/drivers/gpu/drm/sprd/sprd_drm.c
+++ b/drivers/gpu/drm/sprd/sprd_drm.c
@@ -114,6 +114,7 @@ static int sprd_drm_bind(struct device *dev)
drm_kms_helper_poll_fini(drm);
 err_unbind_all:
component_unbind_all(drm->dev, drm);
+   platform_set_drvdata(pdev, NULL);
return ret;
 }
 
@@ -122,10 +123,11 @@ static void sprd_drm_unbind(struct device *dev)
struct drm_device *drm = dev_get_drvdata(dev);
 
drm_dev_unregister(drm);
-
drm_kms_helper_poll_fini(drm);
+   drm_atomic_helper_shutdown(drm);
 
component_unbind_all(drm->dev, drm);
+   dev_set_drvdata(dev, NULL);
 }
 
 static const struct component_master_ops drm_component_ops = {
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH v2 2/8] drm/nouveau: Call drm_atomic_helper_shutdown() or equiv at shutdown time

Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() (or
drm_helper_force_disable_all() if not using atomic) at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.

The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.

Suggested-by: Maxime Ripard 
Reviewed-by: Maxime Ripard 
Signed-off-by: Douglas Anderson 
---
This commit is only compile-time tested. I made my best guess about
how to fit this into the existing code. If someone wishes a different
style, please yell.

(no changes since v1)

 drivers/gpu/drm/nouveau/nouveau_display.c  |  9 +
 drivers/gpu/drm/nouveau/nouveau_display.h  |  1 +
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 13 +
 drivers/gpu/drm/nouveau/nouveau_drv.h  |  1 +
 drivers/gpu/drm/nouveau/nouveau_platform.c |  6 ++
 5 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index d4725a968827..15da55c382f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -645,6 +645,15 @@ nouveau_display_fini(struct drm_device *dev, bool suspend, 
bool runtime)
disp->fini(dev, runtime, suspend);
 }
 
+void
+nouveau_display_shutdown(struct drm_device *dev)
+{
+   if (drm_drv_uses_atomic_modeset(dev))
+   drm_atomic_helper_shutdown(dev);
+   else
+   drm_helper_force_disable_all(dev);
+}
+
 static void
 nouveau_display_create_properties(struct drm_device *dev)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h 
b/drivers/gpu/drm/nouveau/nouveau_display.h
index 2ab2ddb1eadf..9df62e833cda 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.h
+++ b/drivers/gpu/drm/nouveau/nouveau_display.h
@@ -47,6 +47,7 @@ void nouveau_display_destroy(struct drm_device *dev);
 int  nouveau_display_init(struct drm_device *dev, bool resume, bool runtime);
 void nouveau_display_hpd_resume(struct drm_device *dev);
 void nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime);
+void nouveau_display_shutdown(struct drm_device *dev);
 int  nouveau_display_suspend(struct drm_device *dev, bool runtime);
 void nouveau_display_resume(struct drm_device *dev, bool runtime);
 int  nouveau_display_vblank_enable(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index a947e1d5f309..b41154c9b9cc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -894,6 +894,18 @@ nouveau_drm_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
 }
 
+void
+nouveau_drm_device_shutdown(struct drm_device *dev)
+{
+   nouveau_display_shutdown(dev);
+}
+
+static void
+nouveau_drm_shutdown(struct pci_dev *pdev)
+{
+   nouveau_drm_device_shutdown(pci_get_drvdata(pdev));
+}
+
 static int
 nouveau_do_suspend(struct drm_device *dev, bool runtime)
 {
@@ -1361,6 +1373,7 @@ nouveau_drm_pci_driver = {
.id_table = nouveau_drm_pci_table,
.probe = nouveau_drm_probe,
.remove = nouveau_drm_remove,
+   .shutdown = nouveau_drm_shutdown,
.driver.pm = _pm_ops,
 };
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 25fca98a20bc..78a91686006b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -327,6 +327,7 @@ struct drm_device *
 nouveau_platform_device_create(const struct nvkm_device_tegra_func *,
   struct platform_device *, struct nvkm_device **);
 void nouveau_drm_device_remove(struct drm_device *dev);
+void nouveau_drm_device_shutdown(struct drm_device *dev);
 
 #define NV_PRINTK(l,c,f,a...) do { 
\
struct nouveau_cli *_cli = (c);\
diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c 
b/drivers/gpu/drm/nouveau/nouveau_platform.c
index bf2dc7567ea4..511f3a0c6ee9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_platform.c
+++ b/drivers/gpu/drm/nouveau/nouveau_platform.c
@@ -49,6 +49,11 @@ static void nouveau_platform_remove(struct platform_device 
*pdev)
nouveau_drm_device_remove(dev);
 }
 
+static void nouveau_platform_shutdown(struct platform_device *pdev)
+{
+   nouveau_drm_device_shutdown(platform_get_drvdata(pdev));
+}
+
 #if IS_ENABLED(CONFIG_OF)
 static const struct nvkm_device_tegra_func gk20a_platform_data = {
.iommu_bit = 34,
@@ -93,4 +98,5 @@ struct platform_driver nouveau_platform_driver = {
},
.probe = nouveau_platform_probe,
.remove_new = nouveau_platform_remove,
+   .shutdown = nouveau_platform_shutdown,
 };
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH v2 1/8] drm/kmb: Call drm_atomic_helper_shutdown() at shutdown time

Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.

The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.

Suggested-by: Maxime Ripard 
Reviewed-by: Maxime Ripard 
Signed-off-by: Douglas Anderson 
---
This commit is only compile-time tested.

(no changes since v1)

 drivers/gpu/drm/kmb/kmb_drv.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c
index 169b83987ce2..73d82b4d33e7 100644
--- a/drivers/gpu/drm/kmb/kmb_drv.c
+++ b/drivers/gpu/drm/kmb/kmb_drv.c
@@ -475,6 +475,11 @@ static void kmb_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(drm);
 }
 
+static void kmb_shutdown(struct platform_device *pdev)
+{
+   drm_atomic_helper_shutdown(platform_get_drvdata(pdev));
+}
+
 static int kmb_probe(struct platform_device *pdev)
 {
struct device *dev = get_device(>dev);
@@ -621,6 +626,7 @@ static SIMPLE_DEV_PM_OPS(kmb_pm_ops, kmb_pm_suspend, 
kmb_pm_resume);
 static struct platform_driver kmb_platform_driver = {
.probe = kmb_probe,
.remove_new = kmb_remove,
+   .shutdown = kmb_shutdown,
.driver = {
.name = "kmb-drm",
.pm = _pm_ops,
-- 
2.45.2.505.gda0bf45e8d-goog

[PATCH v2 0/8] drm: make leftover drivers call drm_atomic_helper_shutdown() at the right times

This patch series is the leftovers of a patch series sent in September
2023 [1] in an attempt to get some of the patches landed finally.

This patch series originally came about after a _long_ discussion
between me and Maxime Ripard in response to a different patch I sent
out [2]. As part of that discussion, we realized that it would be good
if DRM drivers consistently called drm_atomic_helper_shutdown()
properly at shutdown and driver remove time as it's documented that
they should do. The eventual goal of this would be to enable removing
some hacky code from panel drivers where they had to hook into
shutdown themselves because the DRM driver wasn't calling them.

It turns out that quite a lot of drivers seemed to be missing
drm_atomic_helper_shutdown() in one or both places that it was
supposed to be. This patch series attempts to fix all the drivers that
I was able to identify.

NOTE: fixing this wasn't exactly cookie cutter. Each driver has its
own unique way of setting itself up and tearing itself down. Some
drivers also use the component model, which adds extra fun. I've made
my best guess at solving this and I've run a bunch of compile tests
(specifically, allmodconfig for amd64, arm64, and powerpc). That being
said, these code changes are not totally trivial and I've done zero
real testing on them. Making these patches was also a little mind
numbing and I'm certain my eyes glazed over at several points when
writing them. What I'm trying to say is to please double-check that I
didn't do anything too silly, like cast your driver's drvdata to the
wrong type. Even better, test these patches!

Apparently most of these drivers now land through drm-misc [3], so
hopefully they can land. The two that don't (amdgpu and radeon) are
the ones I'm most ucertain about anyway so I've stuck them at the end.
If I've totally buggered those up feel free to take my patch as a bug
report and submit your own proper fix. ...or if there's some reason
that we don't need to do anything for those drivers then let me know
and we can drop them.

I'd like to call out a few drivers that I _didn't_ fix in this series
and why. If any of these drivers should be fixed then please yell.
- DRM drivers backed by usb_driver (like gud, gm12u320, udl): I didn't
add the call to drm_atomic_helper_shutdown() at shutdown time
because there's no ".shutdown" callback for them USB drivers. Given
that USB is hotpluggable, I'm assuming that they are robust against
this and the special shutdown callback isn't needed.
- ofdrm and simpledrm: These didn't have drm_atomic_helper_shutdown()
in either shutdown or remove, but I didn't add it. I think that's OK
since they're sorta special and not really directly controlling
hardware power sequencing.
- virtio, vkms, vmwgfx, xen: I believe these are all virtual (thus
they wouldn't directly drive a panel) and adding the shutdown
didn't look straightforward, so I skipped them.

I've let each patch in the series get CCed straight from
get_maintainer. That means not everyone will have received every patch
but everyone should be on the cover letter. I know some people dislike
this but when touching this many drivers there's not much
choice. dri-devel and lkml have been CCed and lore/lei exist, so
hopefully that's enough for folks. I'm happy to add people to the
whole series for future posts.

[1] https://lore.kernel.org/r/20230901234202.566951-1-diand...@chromium.org
[2]
https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid
[3] https://lore.kernel.org/r/Zmm6_27GikpmT3HQ@phenom.ffwll.local

Changes in v2:
- Gathered whatever hadn't landed, rebased, and reposted.

Douglas Anderson (8):
drm/kmb: Call drm_atomic_helper_shutdown() at shutdown time
drm/nouveau: Call drm_atomic_helper_shutdown() or equiv at shutdown
time
drm/tegra: Call drm_atomic_helper_shutdown() at shutdown time
drm/arcpgu: Call drm_atomic_helper_shutdown() at shutdown time
drm/sprd: Call drm_atomic_helper_shutdown() at remove time
drm/gma500: Call drm_helper_force_disable_all() at shutdown/remove
time
drm/radeon: Call drm_helper_force_disable_all() at shutdown/remove
time
drm/amdgpu: Call drm_atomic_helper_shutdown() at shutdown time

[PATCH] fbdev: goldfishfb: add missing MODULE_DESCRIPTION() macro

With ARCH=arm64, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in 
drivers/video/fbdev/goldfishfb.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson 
---
 drivers/video/fbdev/goldfishfb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index ca9e8255947c..5f8de1ec23c3 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -321,4 +321,5 @@ static struct platform_driver goldfish_fb_driver = {
 
 module_platform_driver(goldfish_fb_driver);
 
+MODULE_DESCRIPTION("Goldfish Virtual Platform Framebuffer driver");
 MODULE_LICENSE("GPL v2");

---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-cb9dc649c945

Re: [PATCH v11 1/8] x86/vmware: Introduce VMware hypercall API

2024-06-12 Thread Alexey Makhalov


Borislav, please review v11 implementation of 1/8 based on your proposal.
I'm waiting for your feedback before sending full v11 patchset.
Thanks,
--Alexey

On 6/6/24 4:23 PM, Alexey Makhalov wrote:

Introduce vmware_hypercall family of functions. It is a common
implementation to be used by the VMware guest code and virtual
device drivers in architecture independent manner.

The API consists of vmware_hypercallX and vmware_hypercall_hb_{out,in}
set of functions by analogy with KVM hypercall API. Architecture
specific implementation is hidden inside.

It will simplify future enhancements in VMware hypercalls such
as SEV-ES and TDX related changes without needs to modify a
caller in device drivers code.

Current implementation extends an idea from commit bac7b4e84323
("x86/vmware: Update platform detection code for VMCALL/VMMCALL
hypercalls") to have a slow, but safe path vmware_hypercall_slow()
earlier during the boot when alternatives are not yet applied.
The code inherits VMWARE_CMD logic from the commit mentioned above.

Move common macros from vmware.c to vmware.h.

Signed-off-by: Alexey Makhalov 
---
  arch/x86/include/asm/vmware.h | 279 --
  arch/x86/kernel/cpu/vmware.c  |  58 ++-
  2 files changed, 315 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index ac9fc51e2b18..724c8b9b4b8d 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -7,26 +7,277 @@
  #include 
  
  /*

- * The hypercall definitions differ in the low word of the %edx argument
- * in the following way: the old port base interface uses the port
- * number to distinguish between high- and low bandwidth versions.
+ * VMware hypercall ABI.
+ *
+ * - Low bandwidth (LB) hypercalls (I/O port based, vmcall and vmmcall)
+ * have up to 6 input and 6 output arguments passed and returned using
+ * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
+ * %esi (arg4), %edi (arg5).
+ * The following input arguments must be initialized by the caller:
+ * arg0 - VMWARE_HYPERVISOR_MAGIC
+ * arg2 - Hypercall command
+ * arg3 bits [15:0] - Port number, LB and direction flags
+ *
+ * - High bandwidth (HB) hypercalls are I/O port based only. They have
+ * up to 7 input and 7 output arguments passed and returned using
+ * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
+ * %esi (arg4), %edi (arg5), %ebp (arg6).
+ * The following input arguments must be initialized by the caller:
+ * arg0 - VMWARE_HYPERVISOR_MAGIC
+ * arg1 - Hypercall command
+ * arg3 bits [15:0] - Port number, HB and direction flags
+ *
+ * For compatibility purposes, x86_64 systems use only lower 32 bits
+ * for input and output arguments.
+ *
+ * The hypercall definitions differ in the low word of the %edx (arg3)
+ * in the following way: the old I/O port based interface uses the port
+ * number to distinguish between high- and low bandwidth versions, and
+ * uses IN/OUT instructions to define transfer direction.
   *
   * The new vmcall interface instead uses a set of flags to select
   * bandwidth mode and transfer direction. The flags should be loaded
- * into %dx by any user and are automatically replaced by the port
- * number if the VMWARE_HYPERVISOR_PORT method is used.
- *
- * In short, new driver code should strictly use the new definition of
- * %dx content.
+ * into arg3 by any user and are automatically replaced by the port
+ * number if the I/O port method is used.
+ */
+
+#define VMWARE_HYPERVISOR_HB   BIT(0)
+#define VMWARE_HYPERVISOR_OUT  BIT(1)
+
+#define VMWARE_HYPERVISOR_PORT 0x5658
+#define VMWARE_HYPERVISOR_PORT_HB  (VMWARE_HYPERVISOR_PORT | \
+VMWARE_HYPERVISOR_HB)
+
+#define VMWARE_HYPERVISOR_MAGIC0x564d5868U
+
+#define VMWARE_CMD_GETVERSION  10
+#define VMWARE_CMD_GETHZ   45
+#define VMWARE_CMD_GETVCPU_INFO68
+#define VMWARE_CMD_STEALCLOCK  91
+
+#define CPUID_VMWARE_FEATURES_ECX_VMMCALL  BIT(0)
+#define CPUID_VMWARE_FEATURES_ECX_VMCALL   BIT(1)
+
+extern unsigned long vmware_hypercall_slow(unsigned long cmd,
+  unsigned long in1, unsigned long in3,
+  unsigned long in4, unsigned long in5,
+  u32 *out1, u32 *out2, u32 *out3,
+  u32 *out4, u32 *out5);
+
+/*
+ * The low bandwidth call. The low word of %edx is presumed to have OUT bit
+ * set. The high word of %edx may contain input data from the caller.
   */
+#define VMWARE_HYPERCALL   \
+   ALTERNATIVE_2("movw %[port], %%dx\n\t"\
+ "inl (%%dx), %%eax",\
+ "vmcall", X86_FEATURE_VMCALL,   \
+ "vmmcall", X86_FEATURE_VMW_VMMCALL)
+

[drm-misc:topic/rust-drm 5/21] error[E0425]: cannot find value `THIS_MODULE` in the crate root

tree:   git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head:   8f5d38cf42672216b6162952b8ad13a9b15ba78c
commit: 456e8d5810088a0b3ded31a3936062bab3984e86 [5/21] rust: introduce 
`InPlaceModule`
config: x86_64-rhel-8.3-rust 
(https://download.01.org/0day-ci/archive/20240613/202406130541.arc78zvs-...@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 
617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240613/202406130541.arc78zvs-...@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/202406130541.arc78zvs-...@intel.com/

All errors (new ones prefixed by >>):

>> error[E0425]: cannot find value `THIS_MODULE` in the crate root
   --> rust/doctests_kernel_generated.rs:1700:1
   |
   1700 | / kernel::module_phy_driver! {
   1701 | | drivers: [PhySample],
   1702 | | device_table: [
   1703 | | DeviceId::new_with_driver::()
   ...|
   1708 | | license: "GPL",
   1709 | | }
   | |_^ not found in the crate root
   |
   = note: this error originates in the macro `$crate::prelude::module` which 
comes from the expansion of the macro `kernel::module_phy_driver` (in Nightly 
builds, run with -Z macro-backtrace for more info)

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

Re: [PATCH v6,04/24] v4l: add documentation for restricted memory flag

2024-06-12 Thread Nicolas Dufresne

Hi,

Le mercredi 12 juin 2024 à 23:25 +0300, Laurent Pinchart a écrit :
> On Wed, Jun 12, 2024 at 03:43:58PM -0400, Nicolas Dufresne wrote:
> > Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > > > Why is this flag needed ? Given that the usage model requires the V4L2
> > > > device to be a dma buf importer, why would userspace set the
> > > > V4L2_BUF_CAP_SUPPORTS_RESTRICTED_MEM flag and pass a non-restricted
> > > > buffer to the device ?
> > > 
> > > Given that the flag is specified at REQBUF / CREATE_BUFS time, it's
> > > actually useful to tell the driver the queue is operating in restricted
> > > (aka secure) mode.
> > > 
> > > I suppose we could handle that at the time of a first QBUF, but that
> > > would make the driver initialization and validation quite a bit of pain.
> > > So I'd say that the design being proposed here makes things simpler and
> > > more clear, even if it doesn't add any extra functionality.
> > 
> > There is few more reasons I notice in previous series (haven't read the 
> > latest):
> > 
> > - The driver needs to communicate through the OPTEE rather then SCP and some
> > communication are needed just to figure-out things like supported 
> > profile/level
> > resolutions etc.
> > - The driver needs to allocate auxiliary buffers in secure heap too, 
> > allocation
> > at runtime are not the best
> 
> Will the same driver support both modes on the same system ?

Yes, as per this implementation, it seems you can flip from one mode to another
even on the same instance.

Nicolas

> 
> > Note that the discussion around this flag already took place in the very 
> > first
> > iteration of the serie, it was originally using a CID and that was a 
> > proposed
> > replacement from Hans.
>

[PATCH v2 9/9] drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff

From: Ville Syrjälä 

I don't think the display hardware really has such chroma
plane tile row alignment requirements as outlined in
commit d156135e6a54 ("drm/i915/tgl: Make sure a semiplanar
UV plane is tile row size aligned")

Bspec had the same exact thing to say about earlier hardware
as well, but we never cared and things work just fine.

The one thing mentioned in that commit that is definitely
true however is the fence alignment issue. But we don't
deal with that on earlier hardware either. We do have code
to deal with that issue for the first color plane, but not
the chroma planes. So I think if we did want to check this
more extensively we should do it in the same places where
we already check the first color plane (namely
convert_plane_offset_to_xy() and intel_fb_bo_framebuffer_init()).

Reviewed-by: Imre Deak 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fb.c| 12 +---
 drivers/gpu/drm/i915/display/intel_fb.h|  1 -
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 14 --
 3 files changed, 1 insertion(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index a11c1cf6f548..f23547a88b1f 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -585,12 +585,6 @@ static bool is_gen12_ccs_cc_plane(const struct 
drm_framebuffer *fb, int color_pl
return intel_fb_rc_ccs_cc_plane(fb) == color_plane;
 }
 
-bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int color_plane)
-{
-   return intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier) &&
-   color_plane == 1;
-}
-
 bool is_surface_linear(const struct drm_framebuffer *fb, int color_plane)
 {
return fb->modifier == DRM_FORMAT_MOD_LINEAR ||
@@ -1020,11 +1014,7 @@ static int intel_fb_offset_to_xy(int *x, int *y,
struct drm_i915_private *i915 = to_i915(fb->dev);
unsigned int height, alignment, unused;
 
-   if (DISPLAY_VER(i915) >= 12 &&
-   !intel_fb_needs_pot_stride_remap(to_intel_framebuffer(fb)) &&
-   is_semiplanar_uv_plane(fb, color_plane))
-   alignment = intel_tile_row_size(fb, color_plane);
-   else if (fb->modifier != DRM_FORMAT_MOD_LINEAR)
+   if (fb->modifier != DRM_FORMAT_MOD_LINEAR)
alignment = intel_tile_size(i915);
else
alignment = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h 
b/drivers/gpu/drm/i915/display/intel_fb.h
index 1b1fef2dc39a..6dee0c8b7f22 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -34,7 +34,6 @@ bool intel_fb_is_ccs_modifier(u64 modifier);
 bool intel_fb_is_rc_ccs_cc_modifier(u64 modifier);
 bool intel_fb_is_mc_ccs_modifier(u64 modifier);
 
-bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int color_plane);
 bool intel_fb_is_ccs_aux_plane(const struct drm_framebuffer *fb, int 
color_plane);
 int intel_fb_rc_ccs_cc_plane(const struct drm_framebuffer *fb);
 
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index a1c4778cf656..ba5a628b4757 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -515,20 +515,6 @@ static u32 tgl_plane_min_alignment(struct intel_plane 
*plane,
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
return mult * 4 * 1024;
 
-   if (is_semiplanar_uv_plane(fb, color_plane)) {
-   if (intel_fb_uses_dpt(fb))
-   return 512 * 4 * 1024;
-
-   /*
-* TODO: cross-check wrt. the bspec stride in bytes * 64 bytes
-* alignment for linear UV planes on all platforms.
-*/
-   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
-   return 256 * 1024;
-
-   return intel_tile_row_size(fb, color_plane);
-   }
-
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
case I915_FORMAT_MOD_X_TILED:
-- 
2.44.2

[PATCH v2 8/9] drm/i915: Update plane alignment requirements for TGL+

From: Ville Syrjälä 

Currently we still use the SKL+ PLANE_SURF alignment even
for TGL+ even though the hardware no longer needs it.
Introduce a separate tgl_plane_min_alignment() and update
it to more accurately reflect the hardware requirements.

v2: Don't screw up DPT+semiplanar 2MiB alignment

Reviewed-by: Imre Deak 
Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/skl_universal_plane.c| 109 ++
 1 file changed, 61 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index d4c1db3fb9e3..a1c4778cf656 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -503,75 +503,85 @@ skl_plane_max_stride(struct intel_plane *plane,
max_pixels, max_bytes);
 }
 
-static unsigned int skl_plane_min_alignment(struct intel_plane *plane,
-   const struct drm_framebuffer *fb,
-   int color_plane)
+static u32 tgl_plane_min_alignment(struct intel_plane *plane,
+  const struct drm_framebuffer *fb,
+  int color_plane)
 {
-   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
-
-   if (intel_fb_uses_dpt(fb)) {
-   /* AUX_DIST needs only 4K alignment */
-   if (intel_fb_is_ccs_aux_plane(fb, color_plane))
-   return 512 * 4096;
-
-   /*
-* FIXME ADL sees GGTT/DMAR faults with async
-* flips unless we align to 16k at least.
-* Figure out what's going on here...
-*/
-   if (IS_ALDERLAKE_P(dev_priv) &&
-   !intel_fb_is_ccs_modifier(fb->modifier) &&
-   HAS_ASYNC_FLIPS(dev_priv))
-   return 512 * 16 * 1024;
-
-   return 512 * 4096;
-   }
+   struct drm_i915_private *i915 = to_i915(plane->base.dev);
+   /* PLANE_SURF GGTT -> DPT alignment */
+   int mult = intel_fb_uses_dpt(fb) ? 512 : 1;
 
/* AUX_DIST needs only 4K alignment */
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
-   return 4096;
+   return mult * 4 * 1024;
 
if (is_semiplanar_uv_plane(fb, color_plane)) {
+   if (intel_fb_uses_dpt(fb))
+   return 512 * 4 * 1024;
+
/*
 * TODO: cross-check wrt. the bspec stride in bytes * 64 bytes
 * alignment for linear UV planes on all platforms.
 */
-   if (DISPLAY_VER(dev_priv) >= 12) {
-   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
-   return 256 * 1024;
-
-   return intel_tile_row_size(fb, color_plane);
-   }
-
-   return 4096;
-   }
-
-   drm_WARN_ON(_priv->drm, color_plane != 0);
-
-   switch (fb->modifier) {
-   case DRM_FORMAT_MOD_LINEAR:
-   return 256 * 1024;
-   case I915_FORMAT_MOD_X_TILED:
-   if (HAS_ASYNC_FLIPS(dev_priv))
+   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
return 256 * 1024;
-   return 0;
+
+   return intel_tile_row_size(fb, color_plane);
+   }
+
+   switch (fb->modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_4_TILED:
+   /*
+* FIXME ADL sees GGTT/DMAR faults with async
+* flips unless we align to 16k at least.
+* Figure out what's going on here...
+*/
+   if (IS_ALDERLAKE_P(i915) && HAS_ASYNC_FLIPS(i915))
+   return mult * 16 * 1024;
+   return mult * 4 * 1024;
case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
-   return 16 * 1024;
+   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
+   case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+   /*
+* Align to at least 4x1 main surface
+* tiles (16K) to match 64B of AUX.
+*/
+   return max(mult * 4 * 1024, 16 * 1024);
+   default:
+   MISSING_CASE(fb->modifier);
+   return 0;
+   }
+}
+
+static u32 skl_plane_min_alignment(struct intel_plane *plane,
+  const struct drm_framebuffer *fb,
+  int color_plane)
+{
+   /*
+*

[PATCH v2 7/9] drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c

From: Ville Syrjälä 

Now that all pre-skl platforms have their own .min_alignment()
functions the remainder of intel_surf_alignment() can be hoisted
into skl_univerals_plane.c (and renamed appropriately).

Reviewed-by: Imre Deak 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fb.c   | 77 +--
 drivers/gpu/drm/i915/display/intel_fb.h   |  4 +-
 .../drm/i915/display/skl_universal_plane.c| 77 ++-
 3 files changed, 78 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 7f6a3de07cad..a11c1cf6f548 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -585,7 +585,7 @@ static bool is_gen12_ccs_cc_plane(const struct 
drm_framebuffer *fb, int color_pl
return intel_fb_rc_ccs_cc_plane(fb) == color_plane;
 }
 
-static bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int 
color_plane)
+bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int color_plane)
 {
return intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier) &&
color_plane == 1;
@@ -777,81 +777,6 @@ bool intel_fb_uses_dpt(const struct drm_framebuffer *fb)
intel_fb_modifier_uses_dpt(to_i915(fb->dev), fb->modifier);
 }
 
-unsigned int intel_surf_alignment(struct intel_plane *plane,
- const struct drm_framebuffer *fb,
- int color_plane)
-{
-   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
-
-   if (intel_fb_uses_dpt(fb)) {
-   /* AUX_DIST needs only 4K alignment */
-   if (intel_fb_is_ccs_aux_plane(fb, color_plane))
-   return 512 * 4096;
-
-   /*
-* FIXME ADL sees GGTT/DMAR faults with async
-* flips unless we align to 16k at least.
-* Figure out what's going on here...
-*/
-   if (IS_ALDERLAKE_P(dev_priv) &&
-   !intel_fb_is_ccs_modifier(fb->modifier) &&
-   HAS_ASYNC_FLIPS(dev_priv))
-   return 512 * 16 * 1024;
-
-   return 512 * 4096;
-   }
-
-   /* AUX_DIST needs only 4K alignment */
-   if (intel_fb_is_ccs_aux_plane(fb, color_plane))
-   return 4096;
-
-   if (is_semiplanar_uv_plane(fb, color_plane)) {
-   /*
-* TODO: cross-check wrt. the bspec stride in bytes * 64 bytes
-* alignment for linear UV planes on all platforms.
-*/
-   if (DISPLAY_VER(dev_priv) >= 12) {
-   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
-   return 256 * 1024;
-
-   return intel_tile_row_size(fb, color_plane);
-   }
-
-   return 4096;
-   }
-
-   drm_WARN_ON(_priv->drm, color_plane != 0);
-
-   switch (fb->modifier) {
-   case DRM_FORMAT_MOD_LINEAR:
-   return 256 * 1024;
-   case I915_FORMAT_MOD_X_TILED:
-   if (HAS_ASYNC_FLIPS(dev_priv))
-   return 256 * 1024;
-   return 0;
-   case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
-   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
-   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
-   case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
-   case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
-   case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
-   return 16 * 1024;
-   case I915_FORMAT_MOD_Y_TILED_CCS:
-   case I915_FORMAT_MOD_Yf_TILED_CCS:
-   case I915_FORMAT_MOD_Y_TILED:
-   case I915_FORMAT_MOD_4_TILED:
-   case I915_FORMAT_MOD_Yf_TILED:
-   return 1 * 1024 * 1024;
-   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
-   case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
-   case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
-   return 16 * 1024;
-   default:
-   MISSING_CASE(fb->modifier);
-   return 0;
-   }
-}
-
 void intel_fb_plane_get_subsampling(int *hsub, int *vsub,
const struct drm_framebuffer *fb,
int color_plane)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h 
b/drivers/gpu/drm/i915/display/intel_fb.h
index 16ebb573643f..1b1fef2dc39a 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -34,6 +34,7 @@ bool intel_fb_is_ccs_modifier(u64 modifier);
 bool intel_fb_is_rc_ccs_cc_modifier(u64 modifier);
 bool intel_fb_is_mc_ccs_modifier(u64 modifier);
 
+bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int color_plane);
 bool intel_fb_is_ccs_aux_plane(const struct drm_framebuffer *fb, int 
color_plane);
 int intel_fb_rc_ccs_cc_plane(const struct drm_framebuffer *fb);
 
@@ -60,9 +61,6 @@ unsigned int intel_tile_height(const

[PATCH v2 6/9] drm/i915: Split pre-skl platforms out from intel_surf_alignment()

From: Ville Syrjälä 

Extract the necessary chunks from intel_surf_alignment()
into per-platform variants for all pre-skl primary/sprite
planes.

Reviewed-by: Imre Deak 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/i9xx_plane.c   | 69 -
 drivers/gpu/drm/i915/display/intel_fb.c | 17 +
 drivers/gpu/drm/i915/display/intel_sprite.c | 28 -
 3 files changed, 96 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 53b18efaa88c..9447f7229b60 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -764,6 +764,66 @@ i8xx_plane_max_stride(struct intel_plane *plane,
return 8 * 1024;
 }
 
+static unsigned int vlv_primary_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+   struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+   switch (fb->modifier) {
+   case I915_FORMAT_MOD_X_TILED:
+   if (HAS_ASYNC_FLIPS(i915))
+   return 256 * 1024;
+   return 4 * 1024;
+   case DRM_FORMAT_MOD_LINEAR:
+   return 128 * 1024;
+   default:
+   MISSING_CASE(fb->modifier);
+   return 0;
+   }
+}
+
+static unsigned int g4x_primary_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+   struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+   switch (fb->modifier) {
+   case I915_FORMAT_MOD_X_TILED:
+   if (HAS_ASYNC_FLIPS(i915))
+   return 256 * 1024;
+   return 4 * 1024;
+   case DRM_FORMAT_MOD_LINEAR:
+   return 4 * 1024;
+   default:
+   MISSING_CASE(fb->modifier);
+   return 0;
+   }
+}
+
+static unsigned int i965_plane_min_alignment(struct intel_plane *plane,
+const struct drm_framebuffer *fb,
+int color_plane)
+{
+   switch (fb->modifier) {
+   case I915_FORMAT_MOD_X_TILED:
+   return 4 * 1024;
+   case DRM_FORMAT_MOD_LINEAR:
+   return 128 * 1024;
+   default:
+   MISSING_CASE(fb->modifier);
+   return 0;
+   }
+}
+
+static unsigned int i9xx_plane_min_alignment(struct intel_plane *plane,
+const struct drm_framebuffer *fb,
+int color_plane)
+{
+   return 0;
+}
+
 static const struct drm_plane_funcs i965_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -869,7 +929,14 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
plane->max_stride = ilk_primary_max_stride;
}
 
-   plane->min_alignment = intel_surf_alignment;
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   plane->min_alignment = vlv_primary_min_alignment;
+   else if (DISPLAY_VER(dev_priv) >= 5 || IS_G4X(dev_priv))
+   plane->min_alignment = g4x_primary_min_alignment;
+   else if (DISPLAY_VER(dev_priv) == 4)
+   plane->min_alignment = i965_plane_min_alignment;
+   else
+   plane->min_alignment = i9xx_plane_min_alignment;
 
if (IS_I830(dev_priv) || IS_I845G(dev_priv)) {
plane->update_arm = i830_plane_update_arm;
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index b5d31ccf013a..7f6a3de07cad 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -777,19 +777,6 @@ bool intel_fb_uses_dpt(const struct drm_framebuffer *fb)
intel_fb_modifier_uses_dpt(to_i915(fb->dev), fb->modifier);
 }
 
-static unsigned int intel_linear_alignment(const struct drm_i915_private 
*dev_priv)
-{
-   if (DISPLAY_VER(dev_priv) >= 9)
-   return 256 * 1024;
-   else if (IS_I965G(dev_priv) || IS_I965GM(dev_priv) ||
-IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
-   return 128 * 1024;
-   else if (DISPLAY_VER(dev_priv) >= 4)
-   return 4 * 1024;
-   else
-   return 0;
-}
-
 unsigned int intel_surf_alignment(struct intel_plane *plane,
  const struct drm_framebuffer *fb,
  int color_plane)
@@ -825,7 +812,7 @@ unsigned int intel_surf_alignment(struct intel_plane *plane,
 */
if (DISPLAY_VER(dev_priv) >= 12) {
if

[PATCH v2 5/9] drm/i915: Split cursor alignment to per-platform vfuncs

From: Ville Syrjälä 

Split intel_cursor_alignment() into per-platform variants.

Reviewed-by: Imre Deak 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cursor.c | 40 +++--
 drivers/gpu/drm/i915/display/intel_fb.c | 16 -
 drivers/gpu/drm/i915/display/intel_fb.h |  3 --
 3 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 5f8c23296b61..8e95ed0beeb9 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -194,6 +194,13 @@ i845_cursor_max_stride(struct intel_plane *plane,
return 2048;
 }
 
+static unsigned int i845_cursor_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+   return 32;
+}
+
 static u32 i845_cursor_ctl_crtc(const struct intel_crtc_state *crtc_state)
 {
u32 cntl = 0;
@@ -344,6 +351,28 @@ i9xx_cursor_max_stride(struct intel_plane *plane,
return plane->base.dev->mode_config.cursor_width * 4;
 }
 
+static unsigned int i830_cursor_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+   /* "AlmadorM Errata – Requires 32-bpp cursor data to be 16KB aligned." 
*/
+   return 16 * 1024; /* physical */
+}
+
+static unsigned int i85x_cursor_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+   return 256; /* physical */
+}
+
+static unsigned int i9xx_cursor_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+   return 4 * 1024; /* physical for i915/i945 */
+}
+
 static u32 i9xx_cursor_ctl_crtc(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -942,20 +971,27 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv,
 
if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
cursor->max_stride = i845_cursor_max_stride;
+   cursor->min_alignment = i845_cursor_min_alignment;
cursor->update_arm = i845_cursor_update_arm;
cursor->disable_arm = i845_cursor_disable_arm;
cursor->get_hw_state = i845_cursor_get_hw_state;
cursor->check_plane = i845_check_cursor;
} else {
cursor->max_stride = i9xx_cursor_max_stride;
+
+   if (IS_I830(dev_priv))
+   cursor->min_alignment = i830_cursor_min_alignment;
+   else if (IS_I85X(dev_priv))
+   cursor->min_alignment = i85x_cursor_min_alignment;
+   else
+   cursor->min_alignment = i9xx_cursor_min_alignment;
+
cursor->update_arm = i9xx_cursor_update_arm;
cursor->disable_arm = i9xx_cursor_disable_arm;
cursor->get_hw_state = i9xx_cursor_get_hw_state;
cursor->check_plane = i9xx_check_cursor;
}
 
-   cursor->min_alignment = intel_cursor_alignment;
-
cursor->cursor.base = ~0;
cursor->cursor.cntl = ~0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 0abb80972885..b5d31ccf013a 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -777,22 +777,6 @@ bool intel_fb_uses_dpt(const struct drm_framebuffer *fb)
intel_fb_modifier_uses_dpt(to_i915(fb->dev), fb->modifier);
 }
 
-unsigned int intel_cursor_alignment(struct intel_plane *plane,
-   const struct drm_framebuffer *fb,
-   int color_plane)
-{
-   struct drm_i915_private *i915 = to_i915(plane->base.dev);
-
-   if (IS_I830(i915))
-   return 16 * 1024;
-   else if (IS_I85X(i915))
-   return 256;
-   else if (IS_I845G(i915) || IS_I865G(i915))
-   return 32;
-   else
-   return 4 * 1024;
-}
-
 static unsigned int intel_linear_alignment(const struct drm_i915_private 
*dev_priv)
 {
if (DISPLAY_VER(dev_priv) >= 9)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h 
b/drivers/gpu/drm/i915/display/intel_fb.h
index 86c01a3ce81e..16ebb573643f 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -60,9 +60,6 @@ unsigned int intel_tile_height(const struct drm_framebuffer 
*fb, int color_plane
 unsigned int intel_tile_row_size(const struct drm_framebuffer *fb, int 
color_plane);

[PATCH v2 4/9] drm/i915: Introduce fb->min_alignment

From: Ville Syrjälä 

Different planes could have different alignment requirements
even for the same format/modifier. Collect the alignment
requirements across all planes capable of scanning out the
fb such that the alignment is satisfactory to all those
planes.

So far this was sort of handle by making sure intel_surf_alignment()
declares the superset of all planes' alignment requirements,
but maintaining that manually is annoying. So we're going to move
towards each plane declaring only its own requirements, and thus
we need code to generate the superset.

v2: Drop the borked per-plane vma optimization (Imre)
Assert that the plane's declared alignment is POT (Imre)

Cc: Imre Deak 
Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_types.h|  2 ++
 drivers/gpu/drm/i915/display/intel_fb.c   | 29 +++
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |  5 ++--
 drivers/gpu/drm/i915/display/intel_fbdev.c| 18 +---
 4 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0c165572fbd0..af7cc3d6c82b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -146,6 +146,8 @@ struct intel_framebuffer {
};
 
struct i915_address_space *dpt_vm;
+
+   unsigned int min_alignment;
 };
 
 enum intel_hotplug_state {
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index b3a48754a417..0abb80972885 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -11,6 +11,7 @@
 
 #include "gem/i915_gem_object.h"
 #include "i915_drv.h"
+#include "intel_atomic_plane.h"
 #include "intel_display.h"
 #include "intel_display_types.h"
 #include "intel_dpt.h"
@@ -1617,6 +1618,32 @@ bool intel_fb_supports_90_270_rotation(const struct 
intel_framebuffer *fb)
   fb->base.modifier == I915_FORMAT_MOD_Yf_TILED;
 }
 
+static unsigned int intel_fb_min_alignment(const struct drm_framebuffer *fb)
+{
+   struct drm_i915_private *i915 = to_i915(fb->dev);
+   struct intel_plane *plane;
+   unsigned int min_alignment = 0;
+
+   for_each_intel_plane(>drm, plane) {
+   unsigned int plane_min_alignment;
+
+   if (!drm_plane_has_format(>base, fb->format->format, 
fb->modifier))
+   continue;
+
+   plane_min_alignment = plane->min_alignment(plane, fb, 0);
+
+   drm_WARN_ON(>drm, plane_min_alignment &&
+   !is_power_of_2(plane_min_alignment));
+
+   if (intel_plane_needs_physical(plane))
+   continue;
+
+   min_alignment = max(min_alignment, plane_min_alignment);
+   }
+
+   return min_alignment;
+}
+
 int intel_fill_fb_info(struct drm_i915_private *i915, struct intel_framebuffer 
*fb)
 {
struct drm_i915_gem_object *obj = intel_fb_obj(>base);
@@ -1699,6 +1726,8 @@ int intel_fill_fb_info(struct drm_i915_private *i915, 
struct intel_framebuffer *
return -EINVAL;
}
 
+   fb->min_alignment = intel_fb_min_alignment(>base);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c 
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index 9b0f1ea41b70..575b271e012b 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -233,10 +233,9 @@ void intel_fb_unpin_vma(struct i915_vma *vma, unsigned 
long flags)
 static unsigned int
 intel_plane_fb_min_alignment(const struct intel_plane_state *plane_state)
 {
-   struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
-   const struct drm_framebuffer *fb = plane_state->hw.fb;
+   const struct intel_framebuffer *fb = 
to_intel_framebuffer(plane_state->hw.fb);
 
-   return plane->min_alignment(plane, fb, 0);
+   return fb->min_alignment;
 }
 
 static unsigned int
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 6e5f88f20482..49a1ac4f5491 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -47,7 +47,6 @@
 #include "gem/i915_gem_object.h"
 
 #include "i915_drv.h"
-#include "intel_crtc.h"
 #include "intel_display_types.h"
 #include "intel_fb.h"
 #include "intel_fb_pin.h"
@@ -173,21 +172,6 @@ static const struct fb_ops intelfb_ops = {
 
 __diag_pop();
 
-static unsigned int intel_fbdev_min_alignment(const struct drm_framebuffer *fb)
-{
-   struct drm_i915_private *i915 = to_i915(fb->dev);
-   struct intel_plane *plane;
-   struct intel_crtc *crtc;
-
-   crtc = intel_first_crtc(i915);
-   if (!crtc)
-   return 0;
-
-   plane = to_intel_plane(crtc->base.primary);
-
-   return plane->min_alignment(plane, fb, 0);
-}
-
 static

[PATCH v2 3/9] drm/i915: Introduce the plane->min_alignment() vfunc

From: Ville Syrjälä 

Different hardware generations have different scanout alignment
requirements. Introduce a new vfunc that will allow us to
make that distinction without horrible if-ladders.

For now we directly plug in the existing intel_surf_alignment()
and intel_cursor_alignment() functions.

For fbdev we (temporarily) introduce intel_fbdev_min_alignment()
that simply queries the alignment from the primary plane of
the first crtc.

TODO: someone will need to fix xe's alignment handling

Reviewed-by: Imre Deak 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/i9xx_plane.c |  8 ++--
 drivers/gpu/drm/i915/display/intel_cursor.c   |  2 +
 .../drm/i915/display/intel_display_types.h|  3 ++
 drivers/gpu/drm/i915/display/intel_fb.c   | 22 +-
 drivers/gpu/drm/i915/display/intel_fb.h   |  7 +++-
 drivers/gpu/drm/i915/display/intel_fb_pin.c   | 40 ++-
 drivers/gpu/drm/i915/display/intel_fb_pin.h   |  3 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c| 21 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |  2 +
 .../drm/i915/display/skl_universal_plane.c| 11 +++--
 drivers/gpu/drm/xe/display/xe_fb_pin.c|  3 +-
 drivers/gpu/drm/xe/display/xe_plane_initial.c |  4 +-
 12 files changed, 89 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 864d94406894..53b18efaa88c 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -225,8 +225,8 @@ static u32 i9xx_plane_ctl(const struct intel_crtc_state 
*crtc_state,
 
 int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
 {
-   struct drm_i915_private *dev_priv =
-   to_i915(plane_state->uapi.plane->dev);
+   struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
int src_x, src_y, src_w;
u32 offset;
@@ -267,7 +267,7 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
 * despite them not using the linear offset anymore.
 */
if (DISPLAY_VER(dev_priv) >= 4 && fb->modifier == 
I915_FORMAT_MOD_X_TILED) {
-   unsigned int alignment = intel_surf_alignment(fb, 0);
+   unsigned int alignment = plane->min_alignment(plane, fb, 0);
int cpp = fb->format->cpp[0];
 
while ((src_x + src_w) * cpp > 
plane_state->view.color_plane[0].mapping_stride) {
@@ -869,6 +869,8 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
plane->max_stride = ilk_primary_max_stride;
}
 
+   plane->min_alignment = intel_surf_alignment;
+
if (IS_I830(dev_priv) || IS_I845G(dev_priv)) {
plane->update_arm = i830_plane_update_arm;
} else {
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 7f7fc710350c..5f8c23296b61 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -954,6 +954,8 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv,
cursor->check_plane = i9xx_check_cursor;
}
 
+   cursor->min_alignment = intel_cursor_alignment;
+
cursor->cursor.base = ~0;
cursor->cursor.cntl = ~0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 4fa785fd664e..0c165572fbd0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1560,6 +1560,9 @@ struct intel_plane {
int (*max_height)(const struct drm_framebuffer *fb,
  int color_plane,
  unsigned int rotation);
+   unsigned int (*min_alignment)(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane);
unsigned int (*max_stride)(struct intel_plane *plane,
   u32 pixel_format, u64 modifier,
   unsigned int rotation);
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 8069abf91c5e..b3a48754a417 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -776,8 +776,12 @@ bool intel_fb_uses_dpt(const struct drm_framebuffer *fb)
intel_fb_modifier_uses_dpt(to_i915(fb->dev), fb->modifier);
 }
 
-unsigned int intel_cursor_alignment(const struct drm_i915_private *i915)
+unsigned int intel_cursor_alignment(struct intel_plane *plane,
+   const struct drm_framebuffer *fb,
+   int color_plane)

[PATCH v2 1/9] drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format()

From: Ville Syrjälä 

Rename drm_plane_check_pixel_format() to drm_plane_has_format()
and change the return type accordingly. Allows one to write
more natural code.

Also matches drm_any_plane_has_format() better.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic.c|  7 ++-
 drivers/gpu/drm/drm_crtc.c  |  6 ++
 drivers/gpu/drm/drm_crtc_internal.h |  4 ++--
 drivers/gpu/drm/drm_plane.c | 22 ++
 4 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 07b4b394e3bf..6e516c39a372 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -608,7 +608,6 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
unsigned int fb_width, fb_height;
struct drm_mode_rect *clips;
uint32_t num_clips;
-   int ret;
 
/* either *both* CRTC and FB must be set, or neither */
if (crtc && !fb) {
@@ -635,14 +634,12 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
}
 
/* Check whether this plane supports the fb pixel format. */
-   ret = drm_plane_check_pixel_format(plane, fb->format->format,
-  fb->modifier);
-   if (ret) {
+   if (!drm_plane_has_format(plane, fb->format->format, fb->modifier)) {
drm_dbg_atomic(plane->dev,
   "[PLANE:%d:%s] invalid pixel format %p4cc, 
modifier 0x%llx\n",
   plane->base.id, plane->name,
   >format->format, fb->modifier);
-   return ret;
+   return -EINVAL;
}
 
/* Give drivers some help against integer overflows */
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 483969b84a30..3488ff067c69 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -789,12 +789,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
 * case.
 */
if (!plane->format_default) {
-   ret = drm_plane_check_pixel_format(plane,
-  fb->format->format,
-  fb->modifier);
-   if (ret) {
+   if (!drm_plane_has_format(plane, fb->format->format, 
fb->modifier)) {
drm_dbg_kms(dev, "Invalid pixel format %p4cc, 
modifier 0x%llx\n",
>format->format, fb->modifier);
+   ret = -EINVAL;
goto out;
}
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 20e9d7b206a2..cdd60f2a4052 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -272,8 +272,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 /* drm_plane.c */
 int drm_plane_register_all(struct drm_device *dev);
 void drm_plane_unregister_all(struct drm_device *dev);
-int drm_plane_check_pixel_format(struct drm_plane *plane,
-u32 format, u64 modifier);
+bool drm_plane_has_format(struct drm_plane *plane,
+ u32 format, u64 modifier);
 struct drm_mode_rect *
 __drm_plane_get_damage_clips(const struct drm_plane_state *state);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 57662a1fd345..268aa2299df5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -877,8 +877,8 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
return 0;
 }
 
-int drm_plane_check_pixel_format(struct drm_plane *plane,
-u32 format, u64 modifier)
+bool drm_plane_has_format(struct drm_plane *plane,
+ u32 format, u64 modifier)
 {
unsigned int i;
 
@@ -887,24 +887,24 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
break;
}
if (i == plane->format_count)
-   return -EINVAL;
+   return false;
 
if (plane->funcs->format_mod_supported) {
if (!plane->funcs->format_mod_supported(plane, format, 
modifier))
-   return -EINVAL;
+   return false;
} else {
if (!plane->modifier_count)
-   return 0;
+   return true;
 
for (i = 0; i < plane->modifier_count; i++) {
if (modifier == plane->modifiers[i])
break;
}
if (i == plane->modifier_count)
-   return -EINVAL;
+   return false;
}
 
-

[PATCH v2 2/9] drm: Export drm_plane_has_format()

From: Ville Syrjälä 

Export drm_plane_has_format() so that drivers can use it.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_crtc_internal.h | 2 --
 drivers/gpu/drm/drm_plane.c | 1 +
 include/drm/drm_plane.h | 2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index cdd60f2a4052..1f73b8d6d750 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -272,8 +272,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 /* drm_plane.c */
 int drm_plane_register_all(struct drm_device *dev);
 void drm_plane_unregister_all(struct drm_device *dev);
-bool drm_plane_has_format(struct drm_plane *plane,
- u32 format, u64 modifier);
 struct drm_mode_rect *
 __drm_plane_get_damage_clips(const struct drm_plane_state *state);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 268aa2299df5..a51d4dd3f7de 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -906,6 +906,7 @@ bool drm_plane_has_format(struct drm_plane *plane,
 
return true;
 }
+EXPORT_SYMBOL(drm_plane_has_format);
 
 static int __setplane_check(struct drm_plane *plane,
struct drm_crtc *crtc,
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 9507542121fa..dd718c62ac31 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -972,6 +972,8 @@ static inline struct drm_plane *drm_plane_find(struct 
drm_device *dev,
 #define drm_for_each_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
 
+bool drm_plane_has_format(struct drm_plane *plane,
+ u32 format, u64 modifier);
 bool drm_any_plane_has_format(struct drm_device *dev,
  u32 format, u64 modifier);
 
-- 
2.44.2

[PATCH v2 0/9] drm/i915: Polish plane surface alignment handling

From: Ville Syrjälä 

intel_surf_alignment() in particular has devolved into
a complete mess. Redesign the code so that we can handle
alignment restrictions in a nicer. Also adjust alignment
for TGL+ to actually match the hardware requirements.

v2: Drop the per-plane vma stuff as it was borked
Don't temporarily remove the 2MiB DPT alignment for UV on TGL

Ville Syrjälä (9):
  drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format()
  drm: Export drm_plane_has_format()
  drm/i915: Introduce the plane->min_alignment() vfunc
  drm/i915: Introduce fb->min_alignment
  drm/i915: Split cursor alignment to per-platform vfuncs
  drm/i915: Split pre-skl platforms out from intel_surf_alignment()
  drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c
  drm/i915: Update plane alignment requirements for TGL+
  drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff

 drivers/gpu/drm/drm_atomic.c  |   7 +-
 drivers/gpu/drm/drm_crtc.c|   6 +-
 drivers/gpu/drm/drm_crtc_internal.h   |   2 -
 drivers/gpu/drm/drm_plane.c   |  23 ++-
 drivers/gpu/drm/i915/display/i9xx_plane.c |  75 -
 drivers/gpu/drm/i915/display/intel_cursor.c   |  38 +
 .../drm/i915/display/intel_display_types.h|   5 +
 drivers/gpu/drm/i915/display/intel_fb.c   | 151 --
 drivers/gpu/drm/i915/display/intel_fb.h   |   3 -
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |  39 +++--
 drivers/gpu/drm/i915/display/intel_fb_pin.h   |   3 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c|   5 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |  26 +++
 .../drm/i915/display/skl_universal_plane.c|  85 +-
 drivers/gpu/drm/xe/display/xe_fb_pin.c|   3 +-
 drivers/gpu/drm/xe/display/xe_plane_initial.c |   4 +-
 include/drm/drm_plane.h   |   2 +
 17 files changed, 309 insertions(+), 168 deletions(-)

-- 
2.44.2

Re: [PATCH v5 2/3] drm: Allow drivers to choose plane types to async flip

On Wed, Jun 12, 2024 at 04:37:12PM -0300, André Almeida wrote:
> Different planes may have different capabilities of doing async flips,
> so create a field to let drivers allow async flip per plane type.
> 
> Signed-off-by: André Almeida 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
>  drivers/gpu/drm/drm_plane.c   | 3 +++
>  include/drm/drm_plane.h   | 5 +
>  3 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 57662a1fd345..bbcec3940636 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -385,6 +385,9 @@ static int __drm_universal_plane_init(struct drm_device 
> *dev,
>  
>   drm_modeset_lock_init(>mutex);
>  
> + if (type == DRM_PLANE_TYPE_PRIMARY)
> + plane->async_flip = true;
> +

Why? Also note that the commit message writes about adding the field,
not about enabling it for the primary planes.

>   plane->base.properties = >properties;
>   plane->dev = dev;
>   plane->funcs = funcs;


-- 
With best wishes
Dmitry

Re: [PATCH v8 03/13] PCI: Reimplement plural devres functions

2024-06-12 Thread Bjorn Helgaas

On Wed, Jun 12, 2024 at 10:51:40AM +0200, Philipp Stanner wrote:
> On Tue, 2024-06-11 at 16:44 -0500, Bjorn Helgaas wrote:
> > I'm trying to merge these into pci/next, but I'm having a hard time
> > writing the merge commit log.  I want a one-sentence description of
> > each patch that tells me what the benefit of the patch is.  Usually
> > the subject line is a good start.
> > 
> > "Reimplement plural devres functions" is kind of vague and doesn't
> > quite motivate this patch, and I'm having a hard time extracting the
> > relevant details from the commit log below.
> 
> I would say that the summary would be something along the lines:
> "Set ground layer for devres simplification and extension"
> 
> because this patch simplifies the existing functions and adds
> infrastructure that can later be used to deprecate the bloated existing
> functions, remove the hybrid mechanism and add pcim_iomap_range().

I think something concrete like "Add partial-BAR devres support" would
give people a hint about what to look for.

This patch contains quite a bit more than that, and if it were
possible, it might be nice to split the rest to a different patch, but
I'm not sure it's even possible and I just want to get this series out
the door.

If the commit log includes the partial-BAR idea and the specific
functions added, I think that will hold together.  And then it makes
sense for why the "plural" functions would be implemented on top of
the "singular" ones.

> > > Implement a set of singular functions 
> > 
> > What is this set of functions?  My guess is below.
> > 
> > > that use devres as it's intended and
> > > use those singular functions to reimplement the plural functions.
> > 
> > What does "as it's intended" mean?  Too nebulous to fit here.
> 
> Well, the idea behind devres is that you allocate a device resource
> _for each_ object you want to be freed / deinitialized automatically.
> One devres object per driver / subsystem object, one devres callback
> per cleanup job for the driver / subsystem.
> 
> What PCI devres did instead was to use just ONE devres object _for
> everything_ and then it had to implement all sorts of checks to check
> which sub-resource this master resource is actually about:
> 
> (from devres.c)
> static void pcim_release(struct device *gendev, void *res)
> {
>   struct pci_dev *dev = to_pci_dev(gendev);
>   struct pci_devres *this = res;
>   int i;
> 
>   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++)
>   if (this->region_mask & (1 << i))
>   pci_release_region(dev, i);
> 
>   if (this->mwi)
>   pci_clear_mwi(dev);
> 
>   if (this->restore_intx)
>   pci_intx(dev, this->orig_intx);
> 
>   if (this->enabled && !this->pinned)
>   pci_disable_device(dev);
> }
> 
> 
> So one could dare to say that devres was partially re-implemented on
> top of devres.
> 
> The for-loop and the if-conditions constitute that "re-implementation".
> No one has any clue why it has been done that way, because it provides
> 0 upsides and would have been far easier to implement by just letting
> devres do its job.
> 
> Would you like to see the above details in the commit message?

No.  Just remove the "use devres as it's intended" since that's not
needed to motivate this patch.  I think we need fewer and
more-specific words.

Bjorn

[linux-next:master] BUILD REGRESSION 03d44168cbd7fc57d5de56a3730427db758fc7f6

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 03d44168cbd7fc57d5de56a3730427db758fc7f6  Add linux-next specific 
files for 20240612

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202406130139.tv8i316r-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dtb: 
dma-controller@838: Unevaluated properties are not allowed ('compatible' 
was unexpected)
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dtb: 
dma-controller@838: compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma'] is 
too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dtb: 
dma-controller@838: interrupt-names: ['qdma-error', 'qdma-queue0', 
'qdma-queue1', 'qdma-queue2', 'qdma-queue3'] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dtb: 
dma-controller@838: interrupts: [[0, 43, 4], [0, 251, 4], [0, 252, 4], [0, 
253, 4], [0, 254, 4]] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dtb: 
dma-controller@838: Unevaluated properties are not allowed ('compatible' 
was unexpected)
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dtb: 
dma-controller@838: compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma'] is 
too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dtb: 
dma-controller@838: interrupt-names: ['qdma-error', 'qdma-queue0', 
'qdma-queue1', 'qdma-queue2', 'qdma-queue3'] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dtb: 
dma-controller@838: interrupts: [[0, 43, 4], [0, 251, 4], [0, 252, 4], [0, 
253, 4], [0, 254, 4]] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dtb: 
dma-controller@838: Unevaluated properties are not allowed ('compatible' 
was unexpected)
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dtb: 
dma-controller@838: compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma'] is 
too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dtb: 
dma-controller@838: interrupt-names: ['qdma-error', 'qdma-queue0', 
'qdma-queue1', 'qdma-queue2', 'qdma-queue3'] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dtb: 
dma-controller@838: interrupts: [[0, 43, 4], [0, 251, 4], [0, 252, 4], [0, 
253, 4], [0, 254, 4]] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dtb: 
dma-controller@838: Unevaluated properties are not allowed ('compatible' 
was unexpected)
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dtb: 
dma-controller@838: compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma'] is 
too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dtb: 
dma-controller@838: interrupt-names: ['qdma-error', 'qdma-queue0', 
'qdma-queue1', 'qdma-queue2', 'qdma-queue3'] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dtb: 
dma-controller@838: interrupts: [[0, 43, 4], [0, 251, 4], [0, 252, 4], [0, 
253, 4], [0, 254, 4]] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: 
dma-controller@838: Unevaluated properties are not allowed ('compatible' 
was unexpected)
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: 
dma-controller@838: compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma'] is 
too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: 
dma-controller@838: interrupt-names: ['qdma-error', 'qdma-queue0', 
'qdma-queue1', 'qdma-queue2', 'qdma-queue3'] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: 
dma-controller@838: interrupts: [[0, 43, 4], [0, 251, 4], [0, 252, 4], [0, 
253, 4], [0, 254, 4]] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dtb: 
dma-controller@838: Unevaluated properties are not allowed ('compatible' 
was unexpected)
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dtb: 
dma-controller@838: compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma'] is 
too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dtb: 
dma-controller@838: interrupt-names: ['qdma-error', 'qdma-queue0', 
'qdma-queue1', 'qdma-queue2', 'qdma-queue3'] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dtb: 
dma-controller@838: interrupts: [[0, 43, 4], [0, 251, 4], [0, 252, 4], [0, 
253, 4], [0, 254, 4]] is too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dtb: 
dma-controller@838: Unevaluated properties are not allowed ('compatible' 
was unexpected)
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dtb: 
dma-controller@838: compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma'] is 
too long
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dtb: 
dma-controller@838: interrupt-names: ['qdma-error', 'qdma-queue0', 
'qdma-queue1', 'qdma-queue2

Re: [PATCH v6,04/24] v4l: add documentation for restricted memory flag

2024-06-12 Thread Laurent Pinchart

On Wed, Jun 12, 2024 at 03:43:58PM -0400, Nicolas Dufresne wrote:
> Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > > Why is this flag needed ? Given that the usage model requires the V4L2
> > > device to be a dma buf importer, why would userspace set the
> > > V4L2_BUF_CAP_SUPPORTS_RESTRICTED_MEM flag and pass a non-restricted
> > > buffer to the device ?
> > 
> > Given that the flag is specified at REQBUF / CREATE_BUFS time, it's
> > actually useful to tell the driver the queue is operating in restricted
> > (aka secure) mode.
> > 
> > I suppose we could handle that at the time of a first QBUF, but that
> > would make the driver initialization and validation quite a bit of pain.
> > So I'd say that the design being proposed here makes things simpler and
> > more clear, even if it doesn't add any extra functionality.
> 
> There is few more reasons I notice in previous series (haven't read the 
> latest):
> 
> - The driver needs to communicate through the OPTEE rather then SCP and some
> communication are needed just to figure-out things like supported 
> profile/level
> resolutions etc.
> - The driver needs to allocate auxiliary buffers in secure heap too, 
> allocation
> at runtime are not the best

Will the same driver support both modes on the same system ?

> Note that the discussion around this flag already took place in the very first
> iteration of the serie, it was originally using a CID and that was a proposed
> replacement from Hans.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v5 2/3] drm: Allow drivers to choose plane types to async flip

2024-06-12 Thread Ville Syrjälä

On Wed, Jun 12, 2024 at 04:37:12PM -0300, André Almeida wrote:
> Different planes may have different capabilities of doing async flips,
> so create a field to let drivers allow async flip per plane type.
> 
> Signed-off-by: André Almeida 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
>  drivers/gpu/drm/drm_plane.c   | 3 +++
>  include/drm/drm_plane.h   | 5 +
>  3 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 2e1d9391febe..dd4b1578f141 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1079,9 +1079,9 @@ int drm_atomic_set_property(struct drm_atomic_state 
> *state,
>   break;
>   }
>  
> - if (async_flip && plane_state->plane->type != 
> DRM_PLANE_TYPE_PRIMARY) {
> + if (async_flip && !plane_state->plane->async_flip) {

You alreayd have 'plane', no need to dog it out again.

>   drm_dbg_atomic(prop->dev,
> -"[OBJECT:%d] Only primary planes can be 
> changed during async flip\n",
> +"[OBJECT:%d] This type of plane cannot 
> be changed during async flip\n",
>  obj->id);

"[PLANE:%d:%s] does not support async flips"
or something like it would make more sense to me.

>   ret = -EINVAL;
>   break;
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 57662a1fd345..bbcec3940636 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -385,6 +385,9 @@ static int __drm_universal_plane_init(struct drm_device 
> *dev,
>  
>   drm_modeset_lock_init(>mutex);
>  
> + if (type == DRM_PLANE_TYPE_PRIMARY)
> + plane->async_flip = true;

Setting that would be the job of the driver.

You could probably just nuke mode_config.async_page_flip
and replace it fully with plane.async_flip checks.

> +
>   plane->base.properties = >properties;
>   plane->dev = dev;
>   plane->funcs = funcs;
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 9507542121fa..0bebc72af5c3 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -786,6 +786,11 @@ struct drm_plane {
>* @kmsg_panic: Used to register a panic notifier for this plane
>*/
>   struct kmsg_dumper kmsg_panic;
> +
> + /**
> +  * @async_flip: indicates if a plane can do async flips
> +  */
> + bool async_flip;
>  };
>  
>  #define obj_to_plane(x) container_of(x, struct drm_plane, base)
> -- 
> 2.45.2

-- 
Ville Syrjälä
Intel

Re: [PATCH 9/9] accel/rocket: Add IOCTLs for synchronizing memory accesses

2024-06-12 Thread Friedrich Vock


On 12.06.24 15:53, Tomeu Vizoso wrote:

The NPU cores have their own access to the memory bus, and this isn't
cache coherent with the CPUs.

Add IOCTLs so userspace can mark when the caches need to be flushed, and
also when a writer job needs to be waited for before the buffer can be
accessed from the CPU.

Initially based on the same IOCTLs from the Etnaviv driver.

Signed-off-by: Tomeu Vizoso 
---
  drivers/accel/rocket/rocket_drv.c |  2 ++
  drivers/accel/rocket/rocket_gem.c | 68 +++
  drivers/accel/rocket/rocket_gem.h |  7 +++-
  include/uapi/drm/rocket_accel.h   | 20 +++-
  4 files changed, 95 insertions(+), 2 deletions(-)

diff --git a/drivers/accel/rocket/rocket_drv.c 
b/drivers/accel/rocket/rocket_drv.c
index adcb9a685dd8..d41a4f4b330d 100644
--- a/drivers/accel/rocket/rocket_drv.c
+++ b/drivers/accel/rocket/rocket_drv.c
@@ -73,6 +73,8 @@ static const struct drm_ioctl_desc rocket_drm_driver_ioctls[] 
= {
DRM_IOCTL_DEF_DRV(ROCKET_##n, rocket_ioctl_##func, 0)

ROCKET_IOCTL(CREATE_BO, create_bo),
+   ROCKET_IOCTL(PREP_BO, prep_bo),
+   ROCKET_IOCTL(FINI_BO, fini_bo),
ROCKET_IOCTL(SUBMIT, submit),
  };

diff --git a/drivers/accel/rocket/rocket_gem.c 
b/drivers/accel/rocket/rocket_gem.c
index e10eb886f150..afacdf91491e 100644
--- a/drivers/accel/rocket/rocket_gem.c
+++ b/drivers/accel/rocket/rocket_gem.c
@@ -2,7 +2,9 @@
  /* Copyright 2024 Tomeu Vizoso  */

  #include 
+#include 
  #include 
+#include 

  #include "rocket_gem.h"

@@ -66,3 +68,69 @@ int rocket_ioctl_create_bo(struct drm_device *dev, void 
*data, struct drm_file *

return ret;
  }
+
+static inline enum dma_data_direction rocket_op_to_dma_dir(u32 op)
+{
+   if (op & ROCKET_PREP_READ)
+   return DMA_FROM_DEVICE;
+   else if (op & ROCKET_PREP_WRITE)
+   return DMA_TO_DEVICE;
+   else
+   return DMA_BIDIRECTIONAL;


Drive-by comment: This logic looks incorrect to me? If op ==
ROCKET_PREP_READ | ROCKET_PREP_WRITE, this code will return
DMA_FROM_DEVICE when it should return DMA_BIDIRECTIONAL.

The logic would work if it was inverted:
if (!(op & ROCKET_PREP_WRITE))
return DMA_FROM_DEVICE;
else if (!(op & ROCKET_PREP_READ))
return DMA_TO_DEVICE;
else
return DMA_BIDIRECTIONAL;

Thanks,
Friedrich


+}
+
+int rocket_ioctl_prep_bo(struct drm_device *dev, void *data, struct drm_file 
*file)
+{
+   struct drm_rocket_prep_bo *args = data;
+   unsigned long timeout = drm_timeout_abs_to_jiffies(args->timeout_ns);
+   struct drm_gem_object *gem_obj;
+   struct drm_gem_shmem_object *shmem_obj;
+   bool write = !!(args->op & ROCKET_PREP_WRITE);
+   long ret = 0;
+
+   if (args->op & ~(ROCKET_PREP_READ | ROCKET_PREP_WRITE))
+   return -EINVAL;
+
+   gem_obj = drm_gem_object_lookup(file, args->handle);
+   if (!gem_obj)
+   return -ENOENT;
+
+   ret = dma_resv_wait_timeout(gem_obj->resv, dma_resv_usage_rw(write),
+   true, timeout);
+   if (!ret)
+   ret = timeout ? -ETIMEDOUT : -EBUSY;
+
+   shmem_obj = _rocket_bo(gem_obj)->base;
+
+   dma_sync_sgtable_for_cpu(dev->dev, shmem_obj->sgt, 
rocket_op_to_dma_dir(args->op));
+   to_rocket_bo(gem_obj)->last_cpu_prep_op = args->op;
+
+   drm_gem_object_put(gem_obj);
+
+   return ret;
+}
+
+int rocket_ioctl_fini_bo(struct drm_device *dev, void *data, struct drm_file 
*file)
+{
+   struct drm_rocket_fini_bo *args = data;
+   struct drm_gem_object *gem_obj;
+   struct rocket_gem_object *rkt_obj;
+   struct drm_gem_shmem_object *shmem_obj;
+
+   gem_obj = drm_gem_object_lookup(file, args->handle);
+   if (!gem_obj)
+   return -ENOENT;
+
+   rkt_obj = to_rocket_bo(gem_obj);
+   shmem_obj = _obj->base;
+
+   WARN_ON(rkt_obj->last_cpu_prep_op == 0);
+
+   dma_sync_sgtable_for_device(dev->dev, shmem_obj->sgt,
+   
rocket_op_to_dma_dir(rkt_obj->last_cpu_prep_op));
+   rkt_obj->last_cpu_prep_op = 0;
+
+   drm_gem_object_put(gem_obj);
+
+   return 0;
+}
diff --git a/drivers/accel/rocket/rocket_gem.h 
b/drivers/accel/rocket/rocket_gem.h
index 2cb294f25c19..9b1c485ec600 100644
--- a/drivers/accel/rocket/rocket_gem.h
+++ b/drivers/accel/rocket/rocket_gem.h
@@ -13,16 +13,21 @@ struct rocket_gem_object {
struct mutex mutex;
size_t size;
u32 offset;
+   u32 last_cpu_prep_op;
  };

  struct drm_gem_object *rocket_gem_create_object(struct drm_device *dev, 
size_t size);

  int rocket_ioctl_create_bo(struct drm_device *dev, void *data, struct 
drm_file *file);

+int rocket_ioctl_prep_bo(struct drm_device *dev, void *data, struct drm_file 
*file);
+
+int rocket_ioctl_fini_bo(struct drm_device *dev, void *data, struct drm_file 
*file);
+
  static inline
  struct  rocket_gem_object *to_rocket_bo(struct drm_gem_object *obj)
  {

Re: [PATCH v6,04/24] v4l: add documentation for restricted memory flag

2024-06-12 Thread Nicolas Dufresne

Hi,

Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > Why is this flag needed ? Given that the usage model requires the V4L2
> > device to be a dma buf importer, why would userspace set the
> > V4L2_BUF_CAP_SUPPORTS_RESTRICTED_MEM flag and pass a non-restricted
> > buffer to the device ?
> 
> Given that the flag is specified at REQBUF / CREATE_BUFS time, it's
> actually useful to tell the driver the queue is operating in restricted
> (aka secure) mode.
> 
> I suppose we could handle that at the time of a first QBUF, but that
> would make the driver initialization and validation quite a bit of pain.
> So I'd say that the design being proposed here makes things simpler and
> more clear, even if it doesn't add any extra functionality.

There is few more reasons I notice in previous series (haven't read the latest):

- The driver needs to communicate through the OPTEE rather then SCP and some
communication are needed just to figure-out things like supported profile/level
resolutions etc.
- The driver needs to allocate auxiliary buffers in secure heap too, allocation
at runtime are not the best

Note that the discussion around this flag already took place in the very first
iteration of the serie, it was originally using a CID and that was a proposed
replacement from Hans.

regards,
Nicolas

[PATCH v5 3/3] drm/amdgpu: Make it possible to async flip overlay planes

amdgpu can handle async flips on overlay planes, so mark it as true
during the plane initialization.

Signed-off-by: André Almeida 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 8a4c40b4c27e..dc5392c08a87 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1708,6 +1708,7 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager 
*dm,
} else if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
unsigned int zpos = 1 + drm_plane_index(plane);
drm_plane_create_zpos_property(plane, zpos, 1, 254);
+   plane->async_flip = true;
} else if (plane->type == DRM_PLANE_TYPE_CURSOR) {
drm_plane_create_zpos_immutable_property(plane, 255);
}
-- 
2.45.2

[PATCH v5 2/3] drm: Allow drivers to choose plane types to async flip

Different planes may have different capabilities of doing async flips,
so create a field to let drivers allow async flip per plane type.

Signed-off-by: André Almeida 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
 drivers/gpu/drm/drm_plane.c   | 3 +++
 include/drm/drm_plane.h   | 5 +
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 2e1d9391febe..dd4b1578f141 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1079,9 +1079,9 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
 
-   if (async_flip && plane_state->plane->type != 
DRM_PLANE_TYPE_PRIMARY) {
+   if (async_flip && !plane_state->plane->async_flip) {
drm_dbg_atomic(prop->dev,
-  "[OBJECT:%d] Only primary planes can be 
changed during async flip\n",
+  "[OBJECT:%d] This type of plane cannot 
be changed during async flip\n",
   obj->id);
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 57662a1fd345..bbcec3940636 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -385,6 +385,9 @@ static int __drm_universal_plane_init(struct drm_device 
*dev,
 
drm_modeset_lock_init(>mutex);
 
+   if (type == DRM_PLANE_TYPE_PRIMARY)
+   plane->async_flip = true;
+
plane->base.properties = >properties;
plane->dev = dev;
plane->funcs = funcs;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 9507542121fa..0bebc72af5c3 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -786,6 +786,11 @@ struct drm_plane {
 * @kmsg_panic: Used to register a panic notifier for this plane
 */
struct kmsg_dumper kmsg_panic;
+
+   /**
+* @async_flip: indicates if a plane can do async flips
+*/
+   bool async_flip;
 };
 
 #define obj_to_plane(x) container_of(x, struct drm_plane, base)
-- 
2.45.2

[PATCH v5 1/3] drm/atomic: Allow userspace to use explicit sync with atomic async flips

Allow userspace to use explicit synchronization with atomic async flips.
That means that the flip will wait for some hardware fence, and then
will flip as soon as possible (async) in regard of the vblank.

Signed-off-by: André Almeida 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 22bbb2d83e30..2e1d9391febe 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1070,7 +1070,9 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
 
-   if (async_flip && prop != config->prop_fb_id) {
+   if (async_flip &&
+   prop != config->prop_fb_id &&
+   prop != config->prop_in_fence_fd) {
ret = drm_atomic_plane_get_property(plane, plane_state,
prop, _val);
ret = drm_atomic_check_prop_changes(ret, old_val, 
prop_value, prop);
-- 
2.45.2

[PATCH v5 0/3] drm/atomic: Allow drivers to write their own plane check for async

Hi,

AMD hardware can do async flips with overlay planes, so this patchset does a
small redesign to allow drivers to choose per plane type if they can or cannot
do async flips.

It also allows async commits with IN_FENCE_ID in any driver.

Changes from v4:
- Rebased on top current drm-misc/drm-misc-next

Changes from v3:
- Major patchset redesign 
v3: https://lore.kernel.org/lkml/20240128212515.630345-1-andrealm...@igalia.com/

Changes from v2:
 - Allow IN_FENCE_ID for any driver
 - Allow overlay planes again
v2: https://lore.kernel.org/lkml/20240119181235.255060-1-andrealm...@igalia.com/

Changes from v1:
 - Drop overlay planes option for now
v1: 
https://lore.kernel.org/dri-devel/20240116045159.1015510-1-andrealm...@igalia.com/

André Almeida (3):
  drm/atomic: Allow userspace to use explicit sync with atomic async
flips
  drm: Allow drivers to choose plane types to async flip
  drm/amdgpu: Make it possible to async flip overlay planes

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
 drivers/gpu/drm/drm_atomic_uapi.c   | 4 +++-
 include/drm/drm_plane.h | 5 +
 3 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.45.2

Re: [PATCH v2 4/4] drm/msm/dpu: Add SM7150 support

On Wed, Jun 12, 2024 at 09:43:36PM +0300, Danila Tikhonov wrote:
> Add definitions for the display hardware used on the Qualcomm SM7150
> platform.
> 
> Signed-off-by: Danila Tikhonov 
> ---
>  .../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 349 ++
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   1 +
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   1 +
>  4 files changed, 352 insertions(+)
>  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h
> 

[...]

> +static const struct dpu_sspp_cfg sm7150_sspp[] = {
> + {
> + .name = "sspp_0", .id = SSPP_VIG0,
> + .base = 0x4000, .len = 0x1f0,
> + .features = VIG_SDM845_MASK,
> + .sblk = _vig_sblk_qseed3_1_4,

dpu_vig_sblk_qseed3_2_4 (and further on).

> + .xin_id = 0,
> + .type = SSPP_TYPE_VIG,
> + .clk_ctrl = DPU_CLK_CTRL_VIG0,
> + }, {
> + .name = "sspp_1", .id = SSPP_VIG1,
> + .base = 0x6000, .len = 0x1f0,
> + .features = VIG_SDM845_MASK,
> + .sblk = _vig_sblk_qseed3_1_4,
> + .xin_id = 4,
> + .type = SSPP_TYPE_VIG,
> + .clk_ctrl = DPU_CLK_CTRL_VIG1,
> + }, {
> + .name = "sspp_2", .id = SSPP_DMA0,
> + .base = 0x24000, .len = 0x1f0,
> + .features = DMA_SDM845_MASK,
> + .sblk = _dma_sblk,
> + .xin_id = 1,
> + .type = SSPP_TYPE_DMA,
> + .clk_ctrl = DPU_CLK_CTRL_DMA0,
> + }, {
> + .name = "sspp_9", .id = SSPP_DMA1,
> + .base = 0x26000, .len = 0x1f0,
> + .features = DMA_SDM845_MASK,
> + .sblk = _dma_sblk,
> + .xin_id = 5,
> + .type = SSPP_TYPE_DMA,
> + .clk_ctrl = DPU_CLK_CTRL_DMA1,
> + }, {
> + .name = "sspp_10", .id = SSPP_DMA2,
> + .base = 0x28000, .len = 0x1f0,
> + .features = DMA_CURSOR_SDM845_MASK,
> + .sblk = _dma_sblk,
> + .xin_id = 9,
> + .type = SSPP_TYPE_DMA,
> + .clk_ctrl = DPU_CLK_CTRL_DMA2,
> + },
> +};
> +
> +static const struct dpu_lm_cfg sm7150_lm[] = {
> + {
> + .name = "lm_0", .id = LM_0,
> + .base = 0x44000, .len = 0x320,
> + .features = MIXER_SDM845_MASK,
> + .sblk = _lm_sblk,
> + .lm_pair = LM_1,
> + .pingpong = PINGPONG_0,
> + .dspp = DSPP_0,
> + }, {
> + .name = "lm_1", .id = LM_1,
> + .base = 0x45000, .len = 0x320,
> + .features = MIXER_SDM845_MASK,
> + .sblk = _lm_sblk,
> + .lm_pair = LM_0,
> + .pingpong = PINGPONG_1,
> + .dspp = DSPP_1,
> + }, {
> + .name = "lm_2", .id = LM_2,
> + .base = 0x46000, .len = 0x320,
> + .features = MIXER_SDM845_MASK,
> + .sblk = _lm_sblk,
> + .lm_pair = LM_3,
> + .pingpong = PINGPONG_2,
> + }, {
> + .name = "lm_3", .id = LM_3,
> + .base = 0x47000, .len = 0x320,
> + .features = MIXER_SDM845_MASK,
> + .sblk = _lm_sblk,
> + .lm_pair = LM_2,
> + .pingpong = PINGPONG_3,
> + }, {
> + .name = "lm_4", .id = LM_4,
> + .base = 0x0, .len = 0x320,
> + .features = MIXER_SDM845_MASK,
> + .sblk = _lm_sblk,
> + .lm_pair = 0,
> + .pingpong = PINGPONG_4,
> + }, {
> + .name = "lm_5", .id = LM_5,
> + .base = 0x0, .len = 0x320,
> + .features = MIXER_SDM845_MASK,
> + .sblk = _lm_sblk,
> + .lm_pair = 0,
> + .pingpong = PINGPONG_5,
> + },

Please drop LM_4 and LM_5, I don't think they are really a part of the
hardware (especially with base = 0).

> +};
> +

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/4] drm/msm: mdss: Add SM7150 support

On Wed, Jun 12, 2024 at 09:43:34PM +0300, Danila Tikhonov wrote:
> Add support for MDSS on SM7150.
> 
> Signed-off-by: Danila Tikhonov 
> ---
>  drivers/gpu/drm/msm/msm_mdss.c | 8 
>  1 file changed, 8 insertions(+)
> 


Reviewed-by: Dmitry Baryshkov 

-- 
With best wishes
Dmitry

Re: [PATCH v3] drm/panel: truly-nt35521: transition to mipi_dsi wrapped functions

On Wed, Jun 12, 2024 at 10:09:42PM +0530, Tejas Vipin wrote:
> Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce
> mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
> ("drm/mipi-dsi: wrap more functions for streamline handling") for the
> sony tulip truly nt35521 panel.
> 
> Reviewed-by: Douglas Anderson 
> Signed-off-by: Tejas Vipin 
> ---
> Changes in v3:
> - Fix code style
> - Changed calls to mipi_dsi_msleep
> 
> Changes in v2:
> - Fix patch format
> - Fix code style
> 
> v1: 
> https://lore.kernel.org/all/485eef24-ddad-466a-a89f-f9f226801...@gmail.com/
> 
> v2: 
> https://lore.kernel.org/all/3288287d-8344-4b37-a333-722cf12fe...@gmail.com/
> ---
>  .../panel/panel-sony-tulip-truly-nt35521.c| 433 +-
>  1 file changed, 207 insertions(+), 226 deletions(-)
> 


Reviewed-by: Dmitry Baryshkov 

-- 
With best wishes
Dmitry

Re: [PATCH 3/3] drm/todo: Add TODO entry for "lints"

On Wed, Jun 12, 2024 at 04:35:53PM +0200, Maxime Ripard wrote:
> Having lints would prove beneficial to prevent the same dark patterns
> from reoccuring over and over again in drivers.
> 
> Add a TODO entry for that.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/gpu/todo.rst | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 94139c652663..16a9a24b33a6 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -717,10 +717,38 @@ doesn't or document it if it does would be of great 
> help.
>  
>  Contact: Maxime Ripard 
>  
>  Level: Intermediate
>  
> +Create lints for KMS drivers
> +
> +
> +Over time, we've accumulated a list of dark patterns in KMS drivers that
> +should be avoided. However, none of them are published anywhere, and not
> +all reviewers are aware of them. It creates a situation where we have
> +more drivers with problematic / deprecated code, even though we know
> +that they shouldn't.
> +
> +We should create a set of coccinelle scripts that match these patterns,
> +and make new drivers run that list. And possibly integrate them in CI.
> +
> +These patterns include:
> +
> +  - Drivers using kzalloc() or devm_kzalloc() to allocate their memory,
> +instead of drmm_kzalloc().
> +
> +  - Drivers not protecting their device resources (MMIO, clocks,
> +regulators, etc.) by drm_dev_enter() and drm_dev_exit().
> +
> +  - Drivers using drm_dev_unregister() instead of drm_dev_unplug().
> +
> +  - Drivers not calling drm_atomic_helper_shutdown() at shutdown

- Drivers setting state->allow_modeset manually.

> +
> +Contact: Maxime Ripard 
> +
> +Level: Intermediate
> +
>  Enable trinity for DRM
>  --
>  
>  And fix up the fallout. Should be really interesting ...
>  
> -- 
> 2.45.2
> 

-- 
With best wishes
Dmitry

[PATCH v2 3/4] dt-bindings: display/msm: Add SM7150 DPU

Document the DPU hardware found on the Qualcomm SM7150 platform.

Signed-off-by: Danila Tikhonov 
---
 .../bindings/display/msm/qcom,sm7150-dpu.yaml | 143 ++
 1 file changed, 143 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml 
b/Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
new file mode 100644
index 0..1a44cad131a72
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm7150-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM7150 Display DPU
+
+maintainers:
+  - Danila Tikhonov 
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+  compatible:
+const: qcom,sm7150-dpu
+
+  reg:
+items:
+  - description: Address offset and size for mdp register set
+  - description: Address offset and size for vbif register set
+
+  reg-names:
+items:
+  - const: mdp
+  - const: vbif
+
+  clocks:
+items:
+  - description: Display hf axi clock
+  - description: Display ahb clock
+  - description: Display rotator clock
+  - description: Display lut clock
+  - description: Display core clock
+  - description: Display vsync clock
+
+  clock-names:
+items:
+  - const: bus
+  - const: iface
+  - const: rot
+  - const: lut
+  - const: core
+  - const: vsync
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+display-controller@ae01000 {
+compatible = "qcom,sm7150-dpu";
+reg = <0x0ae01000 0x8f000>,
+  <0x0aeb 0x2008>;
+reg-names = "mdp", "vbif";
+
+clocks = <_disp_hf_axi_clk>,
+ <_mdss_ahb_clk>,
+ <_mdss_rot_clk>,
+ <_mdss_mdp_lut_clk>,
+ <_mdss_mdp_clk>,
+ <_mdss_vsync_clk>;
+clock-names = "bus",
+  "iface",
+  "rot",
+  "lut",
+  "core",
+  "vsync";
+
+assigned-clocks = <_mdss_vsync_clk>;
+assigned-clock-rates = <1920>;
+
+operating-points-v2 = <_opp_table>;
+power-domains = < RPMHPD_CX>;
+
+interrupt-parent = <>;
+interrupts = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dpu_intf1_out: endpoint {
+remote-endpoint = <_dsi0_in>;
+};
+};
+
+port@1 {
+reg = <1>;
+dpu_intf2_out: endpoint {
+remote-endpoint = <_dsi1_in>;
+};
+};
+
+port@2 {
+reg = <2>;
+dpu_intf0_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+
+mdp_opp_table: opp-table {
+compatible = "operating-points-v2";
+
+opp-1920 {
+opp-hz = /bits/ 64 <1920>;
+required-opps = <_opp_min_svs>;
+};
+
+opp-2 {
+opp-hz = /bits/ 64 <2>;
+required-opps = <_opp_low_svs>;
+};
+
+opp-3 {
+opp-hz = /bits/ 64 <3>;
+required-opps = <_opp_svs>;
+};
+
+opp-34400 {
+opp-hz = /bits/ 64 <34400>;
+required-opps = <_opp_svs_l1>;
+};
+
+opp-43000 {
+opp-hz = /bits/ 64 <43000>;
+required-opps = <_opp_nom>;
+};
+};
+};
+...
-- 
2.45.2

[PATCH v2 4/4] drm/msm/dpu: Add SM7150 support

Add definitions for the display hardware used on the Qualcomm SM7150
platform.

Signed-off-by: Danila Tikhonov 
---
 .../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 349 ++
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   1 +
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   1 +
 4 files changed, 352 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h
new file mode 100644
index 0..4d50814edcffd
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h
@@ -0,0 +1,349 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Danila Tikhonov 
+ */
+
+#ifndef _DPU_5_2_SM7150_H
+#define _DPU_5_2_SM7150_H
+
+static const struct dpu_caps sm7150_dpu_caps = {
+   .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+   .max_mixer_blendstages = 0xb,
+   .has_src_split = true,
+   .has_dim_layer = true,
+   .has_idle_pc = true,
+   .has_3d_merge = true,
+   .max_linewidth = 2880,
+   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .max_hdeci_exp = MAX_HORZ_DECIMATION,
+   .max_vdeci_exp = MAX_VERT_DECIMATION,
+};
+
+static const struct dpu_mdp_cfg sm7150_mdp = {
+   .name = "top_0",
+   .base = 0x0, .len = 0x45c,
+   .features = BIT(DPU_MDP_AUDIO_SELECT),
+   .clk_ctrls = {
+   [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
+   [DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
+   [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
+   [DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
+   [DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2bc, .bit_off = 8 },
+   [DPU_CLK_CTRL_WB2] = { .reg_off = 0x2bc, .bit_off = 16 },
+   },
+};
+
+static const struct dpu_ctl_cfg sm7150_ctl[] = {
+   {
+   .name = "ctl_0", .id = CTL_0,
+   .base = 0x1000, .len = 0x1e0,
+   .features = BIT(DPU_CTL_ACTIVE_CFG) | 
BIT(DPU_CTL_SPLIT_DISPLAY),
+   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+   }, {
+   .name = "ctl_1", .id = CTL_1,
+   .base = 0x1200, .len = 0x1e0,
+   .features = BIT(DPU_CTL_ACTIVE_CFG) | 
BIT(DPU_CTL_SPLIT_DISPLAY),
+   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+   }, {
+   .name = "ctl_2", .id = CTL_2,
+   .base = 0x1400, .len = 0x1e0,
+   .features = BIT(DPU_CTL_ACTIVE_CFG),
+   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+   }, {
+   .name = "ctl_3", .id = CTL_3,
+   .base = 0x1600, .len = 0x1e0,
+   .features = BIT(DPU_CTL_ACTIVE_CFG),
+   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+   }, {
+   .name = "ctl_4", .id = CTL_4,
+   .base = 0x1800, .len = 0x1e0,
+   .features = BIT(DPU_CTL_ACTIVE_CFG),
+   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
+   }, {
+   .name = "ctl_5", .id = CTL_5,
+   .base = 0x1a00, .len = 0x1e0,
+   .features = BIT(DPU_CTL_ACTIVE_CFG),
+   .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 23),
+   },
+};
+
+static const struct dpu_sspp_cfg sm7150_sspp[] = {
+   {
+   .name = "sspp_0", .id = SSPP_VIG0,
+   .base = 0x4000, .len = 0x1f0,
+   .features = VIG_SDM845_MASK,
+   .sblk = _vig_sblk_qseed3_1_4,
+   .xin_id = 0,
+   .type = SSPP_TYPE_VIG,
+   .clk_ctrl = DPU_CLK_CTRL_VIG0,
+   }, {
+   .name = "sspp_1", .id = SSPP_VIG1,
+   .base = 0x6000, .len = 0x1f0,
+   .features = VIG_SDM845_MASK,
+   .sblk = _vig_sblk_qseed3_1_4,
+   .xin_id = 4,
+   .type = SSPP_TYPE_VIG,
+   .clk_ctrl = DPU_CLK_CTRL_VIG1,
+   }, {
+   .name = "sspp_2", .id = SSPP_DMA0,
+   .base = 0x24000, .len = 0x1f0,
+   .features = DMA_SDM845_MASK,
+   .sblk = _dma_sblk,
+   .xin_id = 1,
+   .type = SSPP_TYPE_DMA,
+   .clk_ctrl = DPU_CLK_CTRL_DMA0,
+   }, {
+   .name = "sspp_9", .id = SSPP_DMA1,
+   .base = 0x26000, .len = 0x1f0,
+   .features = DMA_SDM845_MASK,
+   .sblk = _dma_sblk,
+   .xin_id = 5,
+   .type = SSPP_TYPE_DMA,
+   .clk_ctrl = DPU_CLK_CTRL_DMA1,
+   }, {
+   .name = "sspp_10", .id = SSPP_DMA2,
+   .base = 0x28000, .len = 0x1f0,
+   .features = DMA_CURSOR_SDM845_MASK,
+

[PATCH v2 2/4] drm/msm: mdss: Add SM7150 support

Add support for MDSS on SM7150.

Signed-off-by: Danila Tikhonov 
---
 drivers/gpu/drm/msm/msm_mdss.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index fab6ad4e5107c..d90b9471ba6ff 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -632,6 +632,13 @@ static const struct msm_mdss_data sm6350_data = {
.reg_bus_bw = 76800,
 };
 
+static const struct msm_mdss_data sm7150_data = {
+   .ubwc_enc_version = UBWC_2_0,
+   .ubwc_dec_version = UBWC_2_0,
+   .highest_bank_bit = 1,
+   .reg_bus_bw = 76800,
+};
+
 static const struct msm_mdss_data sm8150_data = {
.ubwc_enc_version = UBWC_3_0,
.ubwc_dec_version = UBWC_3_0,
@@ -713,6 +720,7 @@ static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,sm6125-mdss", .data = _data },
{ .compatible = "qcom,sm6350-mdss", .data = _data },
{ .compatible = "qcom,sm6375-mdss", .data = _data },
+   { .compatible = "qcom,sm7150-mdss", .data = _data },
{ .compatible = "qcom,sm8150-mdss", .data = _data },
{ .compatible = "qcom,sm8250-mdss", .data = _data },
{ .compatible = "qcom,sm8350-mdss", .data = _data },
-- 
2.45.2

[PATCH v2 1/4] dt-bindings: display/msm: Add SM7150 MDSS

Document the MDSS hardware found on the Qualcomm SM7150 platform.

Signed-off-by: Danila Tikhonov 
---
 .../display/msm/qcom,sm7150-mdss.yaml | 458 ++
 1 file changed, 458 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml

diff --git 
a/Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml 
b/Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
new file mode 100644
index 0..13c5d5ffabde9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
@@ -0,0 +1,458 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm7150-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM7150 Display MDSS
+
+maintainers:
+  - Danila Tikhonov 
+
+description:
+  SM7150 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+  DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+  compatible:
+const: qcom,sm7150-mdss
+
+  clocks:
+items:
+  - description: Display ahb clock from gcc
+  - description: Display hf axi clock
+  - description: Display sf axi clock
+  - description: Display core clock
+
+  clock-names:
+items:
+  - const: iface
+  - const: bus
+  - const: nrt_bus
+  - const: core
+
+  iommus:
+maxItems: 1
+
+  interconnects:
+items:
+  - description: Interconnect path from mdp0 port to the data bus
+  - description: Interconnect path from mdp1 port to the data bus
+  - description: Interconnect path from CPU to the reg bus
+
+  interconnect-names:
+items:
+  - const: mdp0-mem
+  - const: mdp1-mem
+  - const: cpu-cfg
+
+patternProperties:
+  "^display-controller@[0-9a-f]+$":
+type: object
+additionalProperties: true
+properties:
+  compatible:
+const: qcom,sm7150-dpu
+
+  "^displayport-controller@[0-9a-f]+$":
+type: object
+additionalProperties: true
+properties:
+  compatible:
+const: qcom,sm7150-dp
+
+  "^dsi@[0-9a-f]+$":
+type: object
+additionalProperties: true
+properties:
+  compatible:
+items:
+  - const: qcom,sm7150-dsi-ctrl
+  - const: qcom,mdss-dsi-ctrl
+
+  "^phy@[0-9a-f]+$":
+type: object
+additionalProperties: true
+properties:
+  compatible:
+const: qcom,dsi-phy-10nm
+
+required:
+  - compatible
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+#include 
+#include 
+
+display-subsystem@ae0 {
+compatible = "qcom,sm7150-mdss";
+reg = <0x0ae0 0x1000>;
+reg-names = "mdss";
+
+power-domains = <_mdss_gdsc>;
+
+clocks = <_mdss_ahb_clk>,
+ <_disp_hf_axi_clk>,
+ <_disp_sf_axi_clk>,
+ <_mdss_mdp_clk>;
+clock-names = "iface",
+  "bus",
+  "nrt_bus",
+  "core";
+
+interrupts = ;
+interrupt-controller;
+#interrupt-cells = <1>;
+
+interconnects = <_noc MASTER_MDP_PORT0 QCOM_ICC_TAG_ALWAYS
+ _virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
+<_noc MASTER_MDP_PORT1 QCOM_ICC_TAG_ALWAYS
+ _virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
+<_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ACTIVE_ONLY
+ _noc SLAVE_DISPLAY_CFG 
QCOM_ICC_TAG_ACTIVE_ONLY>;
+interconnect-names = "mdp0-mem",
+ "mdp1-mem",
+ "cpu-cfg";
+
+iommus = <_smmu 0x800 0x440>;
+
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+display-controller@ae01000 {
+compatible = "qcom,sm7150-dpu";
+reg = <0x0ae01000 0x8f000>,
+  <0x0aeb 0x2008>;
+reg-names = "mdp", "vbif";
+
+clocks = <_disp_hf_axi_clk>,
+ <_mdss_ahb_clk>,
+ <_mdss_rot_clk>,
+ <_mdss_mdp_lut_clk>,
+ <_mdss_mdp_clk>,
+ <_mdss_vsync_clk>;
+clock-names = "bus",
+  "iface",
+  "rot",
+  "lut",
+  "core",
+  "vsync";
+
+assigned-clocks = <_mdss_vsync_clk>;
+assigned-clock-rates = <1920>;
+
+operating-points-v2 = <_opp_table>;
+power-domains = < RPMHPD_CX>;
+
+interrupt-parent = <>;
+interrupts = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+

[PATCH v2 0/4] Add MDSS and DPU support for QCOM SM7150 SoC

This series adds MDSS and DPU support for SM7150.

Changes in v2:
- Drop clock controller headers and use invented clocks instead in
patches 1 and 2 (Dmitry and Rob)
- Link to v1:
https://lore.kernel.org/all/20240611223743.113223-1-dan...@jiaxyga.com/

To: Rob Clark 
To: Abhinav Kumar 
To: Dmitry Baryshkov 
To: Sean Paul 
To: Marijn Suijten 
To: Maarten Lankhorst 
To: Maxime Ripard 
To: Thomas Zimmermann 
To: David Airlie 
To: Daniel Vetter 
To: Rob Herring 
To: Krzysztof Kozlowski 
To: Conor Dooley 
To: Ryan McCann 
To: Stephen Boyd 
To: Neil Armstrong 
To: Jonathan Marek 
To: Kuogee Hsieh 
To: Jessica Zhang 
To: Konrad Dybcio 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: devicet...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Danila Tikhonov 

Danila Tikhonov (4):
  dt-bindings: display/msm: Add SM7150 MDSS
  drm/msm: mdss: Add SM7150 support
  dt-bindings: display/msm: Add SM7150 DPU
  drm/msm/dpu: Add SM7150 support

 .../bindings/display/msm/qcom,sm7150-dpu.yaml | 143 ++
 .../display/msm/qcom,sm7150-mdss.yaml | 458 ++
 .../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 349 +
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   1 +
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   1 +
 drivers/gpu/drm/msm/msm_mdss.c|   8 +
 7 files changed, 961 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h

-- 
2.45.2

[drm-misc:topic/rust-drm 3/21] error[E0050]: method `init` has 1 parameter but the declaration in trait `rust_doctest_kernel_build_assert_rs_0::kernel::Module::init` has 2

tree:   git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head:   8f5d38cf42672216b6162952b8ad13a9b15ba78c
commit: 7d4e13685931d292d28484e486b5eb9ad7dba420 [3/21] rust: pass module name 
to `Module::init`
config: x86_64-rhel-8.3-rust 
(https://download.01.org/0day-ci/archive/20240613/202406130231.e4t7rpch-...@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 
617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240613/202406130231.e4t7rpch-...@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/202406130231.e4t7rpch-...@intel.com/

All errors (new ones prefixed by >>):

>> error[E0050]: method `init` has 1 parameter but the declaration in trait 
>> `rust_doctest_kernel_build_assert_rs_0::kernel::Module::init` has 2
   --> rust/doctests_kernel_generated.rs:1700:1
   |
   1700 | / kernel::module_phy_driver! {
   1701 | | drivers: [PhySample],
   1702 | | device_table: [
   1703 | | DeviceId::new_with_driver::()
   ...|
   1708 | | license: "GPL",
   1709 | | }
   | |_^ expected 2 parameters, found 1
   |
>> = note: `init` from trait: `fn(&'static 
>> rust_doctest_kernel_build_assert_rs_0::kernel::prelude::CStr, &'static 
>> rust_doctest_kernel_build_assert_rs_0::kernel::ThisModule) -> 
>> core::result::Result> rust_doctest_kernel_build_assert_rs_0::kernel::error::Error>`
   = note: this error originates in the macro `kernel::module_phy_driver` (in 
Nightly builds, run with -Z macro-backtrace for more info)

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

Re: [PATCH v1] misc: fastrpc: Move fastrpc driver to misc/fastrpc/

On Wed, Jun 12, 2024 at 12:17:28PM +0530, Ekansh Gupta wrote:
> Move fastrpc.c from misc/ to misc/fastrpc/. New C files are planned
> to be added for PD notifications and other missing features. Adding
> and maintaining new files from within fastrpc directory would be easy.
> 
> Example of feature that is being planned to be introduced in a new C
> file:
> https://lore.kernel.org/all/20240606165939.12950-6-quic_ekang...@quicinc.com/
> 
> Signed-off-by: Ekansh Gupta 
> ---
>  MAINTAINERS  |  2 +-
>  drivers/misc/Kconfig | 13 +
>  drivers/misc/Makefile|  2 +-
>  drivers/misc/fastrpc/Kconfig | 16 
>  drivers/misc/fastrpc/Makefile|  2 ++
>  drivers/misc/{ => fastrpc}/fastrpc.c |  0
>  6 files changed, 21 insertions(+), 14 deletions(-)
>  create mode 100644 drivers/misc/fastrpc/Kconfig
>  create mode 100644 drivers/misc/fastrpc/Makefile
>  rename drivers/misc/{ => fastrpc}/fastrpc.c (100%)

Please consider whether it makes sense to move to drivers/accel instead
(and possibly writing a better Kconfig entry, specifying that the driver
is to be used to offload execution to the DSP).

> diff --git a/MAINTAINERS b/MAINTAINERS
> index d6c90161c7bf..e9c79e9063f8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -18501,7 +18501,7 @@ M:Amol Maheshwari 
>  L:   linux-arm-...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
> -F:   drivers/misc/fastrpc.c
> +F:   drivers/misc/fastrpc/
>  F:   include/uapi/misc/fastrpc.h
>  
>  QUALCOMM HEXAGON ARCHITECTURE
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index faf983680040..630e8ccd8669 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -276,18 +276,6 @@ config QCOM_COINCELL
> to maintain PMIC register and RTC state in the absence of
> external power.
>  
> -config QCOM_FASTRPC
> - tristate "Qualcomm FastRPC"
> - depends on ARCH_QCOM || COMPILE_TEST
> - depends on RPMSG
> - select DMA_SHARED_BUFFER
> - select QCOM_SCM
> - help
> -   Provides a communication mechanism that allows for clients to
> -   make remote method invocations across processor boundary to
> -   applications DSP processor. Say M if you want to enable this
> -   module.
> -
>  config SGI_GRU
>   tristate "SGI GRU driver"
>   depends on X86_UV && SMP
> @@ -602,4 +590,5 @@ source "drivers/misc/cardreader/Kconfig"
>  source "drivers/misc/uacce/Kconfig"
>  source "drivers/misc/pvpanic/Kconfig"
>  source "drivers/misc/mchp_pci1/Kconfig"
> +source "drivers/misc/fastrpc/Kconfig"
>  endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 153a3f4837e8..f83d73844ea5 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -16,7 +16,6 @@ obj-$(CONFIG_TIFM_CORE) += tifm_core.o
>  obj-$(CONFIG_TIFM_7XX1)  += tifm_7xx1.o
>  obj-$(CONFIG_PHANTOM)+= phantom.o
>  obj-$(CONFIG_QCOM_COINCELL)  += qcom-coincell.o
> -obj-$(CONFIG_QCOM_FASTRPC)   += fastrpc.o
>  obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o
>  obj-$(CONFIG_SENSORS_APDS990X)   += apds990x.o
>  obj-$(CONFIG_ENCLOSURE_SERVICES) += enclosure.o
> @@ -69,3 +68,4 @@ obj-$(CONFIG_TMR_INJECT)+= xilinx_tmr_inject.o
>  obj-$(CONFIG_TPS6594_ESM)+= tps6594-esm.o
>  obj-$(CONFIG_TPS6594_PFSM)   += tps6594-pfsm.o
>  obj-$(CONFIG_NSM)+= nsm.o
> +obj-y+= fastrpc/
> diff --git a/drivers/misc/fastrpc/Kconfig b/drivers/misc/fastrpc/Kconfig
> new file mode 100644
> index ..3243dc56b2a0
> --- /dev/null
> +++ b/drivers/misc/fastrpc/Kconfig
> @@ -0,0 +1,16 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Qualcomm FastRPC devices
> +#
> +
> +config QCOM_FASTRPC
> + tristate "Qualcomm FastRPC"
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on RPMSG
> + select DMA_SHARED_BUFFER
> + select QCOM_SCM
> + help
> +   Provides a communication mechanism that allows for clients to
> +   make remote method invocations across processor boundary to
> +   applications DSP processor. Say M if you want to enable this
> +   module.
> \ No newline at end of file
> diff --git a/drivers/misc/fastrpc/Makefile b/drivers/misc/fastrpc/Makefile
> new file mode 100644
> index ..77fd2b763b6b
> --- /dev/null
> +++ b/drivers/misc/fastrpc/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_QCOM_FASTRPC)   += fastrpc.o
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc/fastrpc.c
> similarity index 100%
> rename from drivers/misc/fastrpc.c
> rename to drivers/misc/fastrpc/fastrpc.c
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v3 2/4] dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998

2024-06-12 Thread Vinod Koul

On 06-06-24, 18:07, Marc Gonzalez wrote:
> HDMI TX block embedded in the APQ8098.

This one too

-- 
~Vinod

Re: [PATCH v3 1/4] dt-bindings: display/msm: hdmi: add qcom,hdmi-phy-8998

2024-06-12 Thread Vinod Koul

On 06-06-24, 18:07, Marc Gonzalez wrote:
> HDMI PHY block embedded in the APQ8098.

Why is the patch titled display/msm, this is phy patch and it should be
tagged as such..

Pls update

> 
> Acked-by: Rob Herring (Arm) 
> Signed-off-by: Marc Gonzalez 
> ---
>  Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml 
> b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
> index 83fe4b39b56f4..78607ee3e2e84 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
> @@ -14,6 +14,7 @@ properties:
>compatible:
>  enum:
>- qcom,hdmi-phy-8996
> +  - qcom,hdmi-phy-8998
>  
>reg:
>  maxItems: 6
> 
> -- 
> 2.34.1

-- 
~Vinod

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

Hi,

On Wed, Jun 12, 2024 at 9:47 AM Linus Walleij  wrote:
>
> On Wed, Jun 12, 2024 at 5:11 PM Daniel Vetter  wrote:
> > On Wed, Jun 12, 2024 at 07:49:31AM -0700, Doug Anderson wrote:
> (...)
> > > The problem is that the ordering is wrong, I think. Even if the OS was
> > > calling driver shutdown functions in the perfect order (which I'm not
> > > convinced about since panels aren't always child "struct device"s of
> > > the DRM device), the OS should be calling panel shutdown _before_
> > > shutting down the DRM device. That means that with your suggestion:
> > >
> > > 1. Shutdown starts and panel is on.
> > >
> > > 2. OS calls panel shutdown call, which prints warnings because panel
> > > is still on.
> > >
> > > 3. OS calls DRM driver shutdown call, which prints warnings because
> > > someone else turned the panel off.
> >
> > Uh, that's a _much_ more fundamental issue.
> >
> > The fix for that is telling the driver core about this dependency with
> > device_link_add. Unfortuantely, despite years of me trying to push for
> > this, drm_bridge and drm_panel still don't automatically add these,
> > because the situation is a really complex mess.
> >
> > Probably need to read dri-devel archives for all the past attempts around
> > device_link_add.
>
> I think involving Saravana Kannan in the discussions around this
> is the right thing to do, because he knows how to get devicelinks
> to do the right thing.
>
> If we can describe what devicelink needs to do to get this ordering
> right, I'm pretty sure Saravana can tell us how to do it.

I'm really not convinced that hacking with device links in order to
get the shutdown notification in the right order is correct, though.
The idea is that after we're confident that all DRM modeset drivers
are calling shutdown properly that we should _remove_ any code
handling shutdown from panel-edp and panel-simple. They should just
get disabled as part of DRM's shutdown. That means that if we messed
with devicelinks just to get a different shutdown order that it was
just for a short term thing.

That being said, one could argue that having device links between the
DRM device and the panel is the right thing long term anyway and that
may well be. I guess the issue is that it's not necessarily obvious
how the "parent/child" or "supplier/consumer" relationship works w/
DRM devices, especially panels. My instinct says that the panel
logically is a "child" or "consumer" of the DRM device and thus
inserting the correct long term device link would mean we'd get
shutdown notification in the wrong order. It would be hard to argue
that the panel is the "parent" of a DRM device, but I guess you could
call it a "supplier"? ...but it's also a "consumer" of some other
stuff, like the pixels being output and also (perhaps) the DP AUX bus.
All this complexity is why the DRM framework tends to use its own
logic for things like prepare/enable instead of using what Linux gives
you. I'm sure Saravanah can also tell you about all the crazy device
link circular dependencies that DRM has thrown him through...

In any case, I guess I'll continue asserting that I'm not going to try
to solve this problem. If folks don't like my patch and there's no
suggestion other than solving years-old problems then I'm happy to
live with the way things are and hope that someone eventually comes
along and solves it.

-Doug

[PATCH] fbdev: kyro: add missing MODULE_DESCRIPTION() macro

With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in 
drivers/video/fbdev/kyro/kyrofb.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson 
---
 drivers/video/fbdev/kyro/fbdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
index af6c0581d3e2..08ee8baa79f8 100644
--- a/drivers/video/fbdev/kyro/fbdev.c
+++ b/drivers/video/fbdev/kyro/fbdev.c
@@ -811,4 +811,5 @@ module_exit(kyrofb_exit);
 #endif
 
 MODULE_AUTHOR("STMicroelectronics; Paul Mundt ");
+MODULE_DESCRIPTION("STG4000/Kyro/PowerVR 3 driver");
 MODULE_LICENSE("GPL");

---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-kyro-8c888247c44b

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

Sima,

On Wed, Jun 12, 2024 at 8:13 AM Daniel Vetter  wrote:
>
> > > I ran the coccinelle script we started with, and here are the results:
> > >
> > > ./drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1640:25-39: ERROR: KMS driver 
> > > vmw_pci_driver is missing shutdown implementation
> > > ./drivers/gpu/drm/kmb/kmb_drv.c:621:30-49: ERROR: KMS driver 
> > > kmb_platform_driver is missing shutdown implementation
> > > ./drivers/gpu/drm/tiny/arcpgu.c:422:30-52: ERROR: KMS driver 
> > > arcpgu_platform_driver is missing shutdown implementation
> >
> > Sure, although I think we agreed even back when we talked about this
> > last that your coccinelle script wasn't guaranteed to catch every
> > driver. ...so I guess the question is: are we willing to accept that
> > we'll stop disabling panels at shutdown for any drivers that might
> > were missed. For instance, looking at it by hand (which also could
> > miss things), I previously thought that we also might need:
> >
> > * nouveau
> > * tegra
> > * amdgpu
> > * sprd
> > * gma500
> > * radeon
> >
> > I sent patches for those drivers but they don't go through drm-misc
> > and some of the drivers had a lot of abstraction layers and were hard
> > to reason about. I'm also not 100% confident that all of those drivers
> > really are affected--they'd have to be used with panel-simple or
> > panel-edp...
>
> Aside from amdgpu and radeon they're all in -misc now, and Alex is
> generally fairly responsive.

Sorry for not keeping up with things, but can you point to where this
was documented or what patch changed things so that these drivers went
through drm-misc? From the MAINTAINERS file I see commit 5a44d50f0072
("MAINTAINERS: Update drm-misc entry to match all drivers") and that
shows several of these drivers as "X:". As far as I can tell that
means that they _aren't_ handled by drm-misc, right? Maybe the
decision was made elsewhere and MAINTAINERS was just not updated, or
I'm not looking at the right place? I checked drm-misc-next and
drm/next and, for instance, "tegra" and "kmb" still show as excluded.

-Doug

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

2024-06-12 Thread Linus Walleij

On Wed, Jun 12, 2024 at 5:11 PM Daniel Vetter  wrote:
> On Wed, Jun 12, 2024 at 07:49:31AM -0700, Doug Anderson wrote:
(...)
> > The problem is that the ordering is wrong, I think. Even if the OS was
> > calling driver shutdown functions in the perfect order (which I'm not
> > convinced about since panels aren't always child "struct device"s of
> > the DRM device), the OS should be calling panel shutdown _before_
> > shutting down the DRM device. That means that with your suggestion:
> >
> > 1. Shutdown starts and panel is on.
> >
> > 2. OS calls panel shutdown call, which prints warnings because panel
> > is still on.
> >
> > 3. OS calls DRM driver shutdown call, which prints warnings because
> > someone else turned the panel off.
>
> Uh, that's a _much_ more fundamental issue.
>
> The fix for that is telling the driver core about this dependency with
> device_link_add. Unfortuantely, despite years of me trying to push for
> this, drm_bridge and drm_panel still don't automatically add these,
> because the situation is a really complex mess.
>
> Probably need to read dri-devel archives for all the past attempts around
> device_link_add.

I think involving Saravana Kannan in the discussions around this
is the right thing to do, because he knows how to get devicelinks
to do the right thing.

If we can describe what devicelink needs to do to get this ordering
right, I'm pretty sure Saravana can tell us how to do it.

Yours,
Linus Walleij

[PATCH v3] drm/panel: truly-nt35521: transition to mipi_dsi wrapped functions

Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce
mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for the
sony tulip truly nt35521 panel.

Reviewed-by: Douglas Anderson 
Signed-off-by: Tejas Vipin 
---
Changes in v3:
- Fix code style
- Changed calls to mipi_dsi_msleep

Changes in v2:
- Fix patch format
- Fix code style

v1: https://lore.kernel.org/all/485eef24-ddad-466a-a89f-f9f226801...@gmail.com/

v2: https://lore.kernel.org/all/3288287d-8344-4b37-a333-722cf12fe...@gmail.com/
---
 .../panel/panel-sony-tulip-truly-nt35521.c| 433 +-
 1 file changed, 207 insertions(+), 226 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sony-tulip-truly-nt35521.c 
b/drivers/gpu/drm/panel/panel-sony-tulip-truly-nt35521.c
index 6d44970dccd9..4b5088b95861 100644
--- a/drivers/gpu/drm/panel/panel-sony-tulip-truly-nt35521.c
+++ b/drivers/gpu/drm/panel/panel-sony-tulip-truly-nt35521.c
@@ -44,248 +44,229 @@ static void truly_nt35521_reset(struct truly_nt35521 *ctx)
 static int truly_nt35521_on(struct truly_nt35521 *ctx)
 {
struct mipi_dsi_device *dsi = ctx->dsi;
-   struct device *dev = >dev;
-   int ret;
+   struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi };
 
dsi->mode_flags |= MIPI_DSI_MODE_LPM;
 
-   mipi_dsi_generic_write_seq(dsi, 0xf0, 0x55, 0xaa, 0x52, 0x08, 0x00);
-   mipi_dsi_generic_write_seq(dsi, 0xff, 0xaa, 0x55, 0xa5, 0x80);
-   mipi_dsi_generic_write_seq(dsi, 0x6f, 0x11, 0x00);
-   mipi_dsi_generic_write_seq(dsi, 0xf7, 0x20, 0x00);
-   mipi_dsi_generic_write_seq(dsi, 0x6f, 0x01);
-   mipi_dsi_generic_write_seq(dsi, 0xb1, 0x21);
-   mipi_dsi_generic_write_seq(dsi, 0xbd, 0x01, 0xa0, 0x10, 0x08, 0x01);
-   mipi_dsi_generic_write_seq(dsi, 0xb8, 0x01, 0x02, 0x0c, 0x02);
-   mipi_dsi_generic_write_seq(dsi, 0xbb, 0x11, 0x11);
-   mipi_dsi_generic_write_seq(dsi, 0xbc, 0x00, 0x00);
-   mipi_dsi_generic_write_seq(dsi, 0xb6, 0x02);
-   mipi_dsi_generic_write_seq(dsi, 0xf0, 0x55, 0xaa, 0x52, 0x08, 0x01);
-   mipi_dsi_generic_write_seq(dsi, 0xb0, 0x09, 0x09);
-   mipi_dsi_generic_write_seq(dsi, 0xb1, 0x09, 0x09);
-   mipi_dsi_generic_write_seq(dsi, 0xbc, 0x8c, 0x00);
-   mipi_dsi_generic_write_seq(dsi, 0xbd, 0x8c, 0x00);
-   mipi_dsi_generic_write_seq(dsi, 0xca, 0x00);
-   mipi_dsi_generic_write_seq(dsi, 0xc0, 0x04);
-   mipi_dsi_generic_write_seq(dsi, 0xbe, 0xb5);
-   mipi_dsi_generic_write_seq(dsi, 0xb3, 0x35, 0x35);
-   mipi_dsi_generic_write_seq(dsi, 0xb4, 0x25, 0x25);
-   mipi_dsi_generic_write_seq(dsi, 0xb9, 0x43, 0x43);
-   mipi_dsi_generic_write_seq(dsi, 0xba, 0x24, 0x24);
-   mipi_dsi_generic_write_seq(dsi, 0xf0, 0x55, 0xaa, 0x52, 0x08, 0x02);
-   mipi_dsi_generic_write_seq(dsi, 0xee, 0x03);
-   mipi_dsi_generic_write_seq(dsi, 0xb0,
-  0x00, 0xb2, 0x00, 0xb3, 0x00, 0xb6, 0x00, 
0xc3,
-  0x00, 0xce, 0x00, 0xe1, 0x00, 0xf3, 0x01, 
0x11);
-   mipi_dsi_generic_write_seq(dsi, 0xb1,
-  0x01, 0x2e, 0x01, 0x5c, 0x01, 0x82, 0x01, 
0xc3,
-  0x01, 0xfe, 0x02, 0x00, 0x02, 0x37, 0x02, 
0x77);
-   mipi_dsi_generic_write_seq(dsi, 0xb2,
-  0x02, 0xa1, 0x02, 0xd7, 0x02, 0xfe, 0x03, 
0x2c,
-  0x03, 0x4b, 0x03, 0x63, 0x03, 0x8f, 0x03, 
0x90);
-   mipi_dsi_generic_write_seq(dsi, 0xb3, 0x03, 0x96, 0x03, 0x98);
-   mipi_dsi_generic_write_seq(dsi, 0xb4,
-  0x00, 0x81, 0x00, 0x8b, 0x00, 0x9c, 0x00, 
0xa9,
-  0x00, 0xb5, 0x00, 0xcb, 0x00, 0xdf, 0x01, 
0x02);
-   mipi_dsi_generic_write_seq(dsi, 0xb5,
-  0x01, 0x1f, 0x01, 0x51, 0x01, 0x7a, 0x01, 
0xbf,
-  0x01, 0xfa, 0x01, 0xfc, 0x02, 0x34, 0x02, 
0x76);
-   mipi_dsi_generic_write_seq(dsi, 0xb6,
-  0x02, 0x9f, 0x02, 0xd7, 0x02, 0xfc, 0x03, 
0x2c,
-  0x03, 0x4a, 0x03, 0x63, 0x03, 0x8f, 0x03, 
0xa2);
-   mipi_dsi_generic_write_seq(dsi, 0xb7, 0x03, 0xb8, 0x03, 0xba);
-   mipi_dsi_generic_write_seq(dsi, 0xb8,
-  0x00, 0x01, 0x00, 0x02, 0x00, 0x0e, 0x00, 
0x2a,
-  0x00, 0x41, 0x00, 0x67, 0x00, 0x87, 0x00, 
0xb9);
-   mipi_dsi_generic_write_seq(dsi, 0xb9,
-  0x00, 0xe2, 0x01, 0x22, 0x01, 0x54, 0x01, 
0xa3,
-  0x01, 0xe6, 0x01, 0xe7, 0x02, 0x24, 0x02, 
0x67);
-   mipi_dsi_generic_write_seq(dsi, 0xba,
-  0x02, 0x93, 0x02, 0xcd, 0x02, 0xf6, 0x03, 
0x31,
-  0x03, 0x6c, 0x03, 0xe9, 0x03, 0xef, 0x03, 
0xf4);
-

Re: [PATCH 3/9] dt-bindings: mailbox: rockchip,rknn: Add bindings

2024-06-12 Thread Conor Dooley

On Wed, Jun 12, 2024 at 03:52:56PM +0200, Tomeu Vizoso wrote:
> Add the bindings for the Neural Processing Unit IP from Rockchip.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
>  .../devicetree/bindings/npu/rockchip,rknn.yaml | 123 
> +
>  1 file changed, 123 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml 
> b/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml
> new file mode 100644
> index ..570a4889c11c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml
> @@ -0,0 +1,123 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/npu/rockchip,rknn.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Neural Processing Unit IP from Rockchip, based on NVIDIA's NVDLA
> +
> +maintainers:
> +  - Tomeu Vizoso 
> +
> +description: |+

The |+ chomping operator is not needed here.

> +  Rockchip IP for accelerating inference of neural networks, based on 
> NVIDIA's open source NVDLA IP.
> +
> +properties:
> +  compatible:
> +items:
> +  - enum:
> +  - rockchip,rk3588-rknn
> +  - const: rockchip,rknn
> +
> +  reg:
> +description: Base registers for NPU cores
> +minItems: 1
> +maxItems: 20

For all of these properties, you need to describe the individual items.

> +
> +  interrupts:
> +minItems: 1
> +maxItems: 20
> +
> +  interrupt-names:
> +minItems: 1
> +maxItems: 20
> +
> +  clocks:
> +minItems: 1
> +maxItems: 20
> +
> +  clock-names:
> +minItems: 1
> +maxItems: 20
> +
> +  assigned-clocks:
> +maxItems: 1
> +
> +  assigned-clock-rates:
> +maxItems: 1
> +
> +  resets:
> +minItems: 1
> +maxItems: 20
> +
> +  reset-names:
> +minItems: 1
> +maxItems: 20
> +
> +  power-domains:
> +minItems: 1
> +maxItems: 20
> +
> +  power-domain-names:
> +minItems: 1
> +maxItems: 20
> +
> +  iommus:
> +items:
> +  - description: IOMMU for all cores
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - interrupt-names
> +  - clocks
> +  - clock-names
> +  - assigned-clocks
> +  - assigned-clock-rates
> +  - resets
> +  - reset-names
> +  - power-domains
> +  - power-domain-names
> +  - iommus
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +bus {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +rknn: npu@fdab {

Drop the label here, it's not used.

> +  compatible = "rockchip,rk3588-rknn", "rockchip,rknn";
> +  reg = <0x0 0xfdab 0x0 0x9000>,
> +<0x0 0xfdac 0x0 0x9000>,
> +<0x0 0xfdad 0x0 0x9000>;
> +  interrupts = ,
> +   ,
> +   ;
> +  interrupt-names = "npu0_irq", "npu1_irq", "npu2_irq";
> +  clocks = <_clk 0>, < 1>,
> +   < 2>, < 3>,
> +   < 4>, < 5>,
> +   < 6>, < 7>;
> +  clock-names = "clk_npu",
> +  "aclk0", "aclk1", "aclk2",
> +  "hclk0", "hclk1", "hclk2",
> +  "pclk";
> +  assigned-clocks = <_clk 0>;
> +  assigned-clock-rates = <2>;
> +  resets = < 0>, < 1>, < 2>,
> +   < 3>, < 4>, < 5>;
> +  reset-names = "srst_a0", "srst_a1", "srst_a2",
> +"srst_h0", "srst_h1", "srst_h2";
> +  power-domains = < 0>, < 1>, < 2>;
> +  power-domain-names = "npu0", "npu1", "npu2";
> +  iommus = <_mmu>;

> +  status = "disabled";

A disabled example is useless.

> +};
> +};
> +...
> 
> -- 
> 2.45.2
> 


signature.asc
Description: PGP signature

Re: [v2 13/14] drm/msm/hdmi: ensure that HDMI is one if HPD is requested

On Wed, 12 Jun 2024 at 17:32, Markus Elfring  wrote:
>
> >> Would you become interested to apply a statement like 
> >> “guard(mutex)(>state_mutex);”?
> >> https://elixir.bootlin.com/linux/v6.10-rc3/source/include/linux/mutex.h#L196
> >
> > I am not.
>
> Under which circumstances will development interests grow for scope-based 
> resource management?
> https://elixir.bootlin.com/linux/v6.10-rc3/source/include/linux/cleanup.h#L124

I consider guard() and free() to be counterintuitive, harder to follow
and semantically troublesome.

-- 
With best wishes
Dmitry

Re: [PATCH 1/3] drm/todo: Create a TODO item for additional HDMI work

On Wed, 12 Jun 2024 at 17:35, Maxime Ripard  wrote:
>
> We recently added some infrastructure to deal with HDMI but we're still
> lacking a couple of things. Add a TODO entry with the remaining items.
>
> Cc: Dmitry Baryshkov 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/gpu/todo.rst | 29 +
>  1 file changed, 29 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 2ea6ffc9b22b..52fd8672fb6d 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -633,10 +633,39 @@ long as that supports DMA. Otherwise importing can 
> still needlessly fail.
>
>  Contact: Thomas Zimmermann , Daniel Vetter
>
>  Level: Advanced
>
> +Improve HDMI Infrastructure
> +---
> +
> +We have a bunch of helpers to handle HDMI and reduce the boilerplate in
> +drivers. Support so far includes HDMI 1.4 support, but we need to extend
> +it with:
> +
> +  - CEC handling support. CEC requires a bit of integration into every
> +HDMI driver to set the device physical address according to the EDID
> +in `.get_modes`, and to clear/reset it in the hotplug detection
> +path. We should create the 
> ``drm_atomic_helper_connector_hdmi_get_modes()``
> +and ``drm_atomic_helper_connector_hdmi_handle_hotplug()`` helpers to 
> handle
> +this properly, and convert drivers to use them.
> +
> +  - In order to support HDMI 2.0 properly, the scrambler parameters need
> +to be moved into the state. This includes figuring out in
> +drm_atomic_helper_connector_hdmi_check() if the scrambler and TMDS ratio
> +need to be changed, and make the
> +``drm_atomic_helper_connector_hdmi_handle_hotplug()`` helper reset the
> +scrambler status when the device is plugged and unplugged.
> +
> +  - We need to support YUV420 too.

- HDMI audio improvements:
  - Implement the get_eld() and possibly hook_plugged_cb() functions
for hdmi_codec_ops in a generic way. Maybe implementing generic HDMI
hdmi_codec_ops and then providing device-specific hooks to prepare /
shutdown / mute stream.
  - provide helpers to determine ACR / N / CTS params

A different, but closely related topic is HDCP support in a generic
way. 
https://lore.kernel.org/dri-devel/20230419154321.1993419-1-markyac...@google.com/

> +
> +The `vc4` driver is a good example for all this.
> +
> +Contact: Maxime Ripard 
> +
> +Level: Intermediate
> +
>
>  Better Testing
>  ==
>
>  Add unit tests using the Kernel Unit Testing (KUnit) framework
> --
> 2.45.2
>


-- 
With best wishes
Dmitry

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

Hi,

On Wed, Jun 12, 2024 at 8:03 AM Maxime Ripard  wrote:
>
> > > Why does something like this now work?
> > >
> > > drm_panel_shutdown_fixup(panel)
> > > {
> > > /* if you get warnings here, fix your main drm driver to call
> > >  * drm_atomic_helper_shutdown()
> > >  */
> > > if (WARN_ON(panel->enabled))
> > > drm_panel_disable(panel);
> > >
> > > if (WARN_ON(panel->prepared))
> > > drm_panel_unprepare(panel);
> > > }
> > >
> > > And then call that little helper in the relevant panel drivers? Also feel
> > > free to bikeshed the name and maybe put a more lengthly explainer into the
> > > kerneldoc for that ...
> > >
> > > Or am I completely missing the point here?
> >
> > The problem is that the ordering is wrong, I think. Even if the OS was
> > calling driver shutdown functions in the perfect order (which I'm not
> > convinced about since panels aren't always child "struct device"s of
> > the DRM device), the OS should be calling panel shutdown _before_
> > shutting down the DRM device. That means that with your suggestion:
> >
> > 1. Shutdown starts and panel is on.
> >
> > 2. OS calls panel shutdown call, which prints warnings because panel
> > is still on.
> >
> > 3. OS calls DRM driver shutdown call, which prints warnings because
> > someone else turned the panel off.
> >
> > :-P
> >
> > Certainly if I goofed and the above is wrong then let me know--I did
> > my experiments on this many months ago and didn't try repeating them
> > again now.
> >
> > In any case, the only way I could figure out around this was some sort
> > of list. As mentioned in the commit message, it's super ugly and
> > intended to be temporary. Once we solve all the current in-tree
> > drivers, I'd imagine that long term for new DRM drivers this kind of
> > thing would be discovered during bringup of new boards. Usually during
> > bringup of new boards EEs measure timing signals and complain if
> > they're not right. If some EE cared and said we weren't disabling the
> > panel correctly at shutdown time then we'd know there was a problem.
>
> Based on a discussion we had today With Sima on IRC, I think there's
> another way forward.
>
> We were actually discussing refcount'ing the panels to avoid lifetime
> issues. It would require some API overhaul to have a function to
> allocate the drm_panel structure and init'ing the refcount, plus some to
> get / put the references.
>
> Having this refcount would mean that we also get a release function now,
> called when the panel is free'd.
>
> Could we warn if the panel is still prepared/enabled and is about to be
> freed?
>
> It would require to switch panel-simple and panel-edp to that new API,
> but it should be easy enough.

I think there are two problems here:

1. The problem is at shutdown here. Memory isn't freed at shutdown
time. This isn't a lifetime issue. No release functions are involved
in shutdown and we don't free memory then.

2. As I tried to point out, even if we were guaranteed the correct
order it still doesn't help us. In other words: if all device links
were perfect and all ordering was proper then the panel should get
shutdown _before_ the DRM device. That means we can't put a check in
the panel code to see if the DRM device has been shutdown.


-Doug

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

Hi,

On Wed, Jun 12, 2024 at 8:11 AM Daniel Vetter  wrote:
>
> > The problem is that the ordering is wrong, I think. Even if the OS was
> > calling driver shutdown functions in the perfect order (which I'm not
> > convinced about since panels aren't always child "struct device"s of
> > the DRM device), the OS should be calling panel shutdown _before_
> > shutting down the DRM device. That means that with your suggestion:
> >
> > 1. Shutdown starts and panel is on.
> >
> > 2. OS calls panel shutdown call, which prints warnings because panel
> > is still on.
> >
> > 3. OS calls DRM driver shutdown call, which prints warnings because
> > someone else turned the panel off.
>
> Uh, that's a _much_ more fundamental issue.
>
> The fix for that is telling the driver core about this dependency with
> device_link_add. Unfortuantely, despite years of me trying to push for
> this, drm_bridge and drm_panel still don't automatically add these,
> because the situation is a really complex mess.
>
> Probably need to read dri-devel archives for all the past attempts around
> device_link_add.
>
> But the solution is definitely not to have a manually tracked list, what's
> very architectural unsound way to tackle this problem.
>
> > Certainly if I goofed and the above is wrong then let me know--I did
> > my experiments on this many months ago and didn't try repeating them
> > again now.
>
> Oh the issue is very real and known since years. It also wreaks module
> unload and driver unbinding, since currently nothing makes sure your
> drm_panel lives longer than your drm_device.

In this case I'm mostly worried about the device "shutdown" call, so
it's not quite a lifetime issue but it is definitely related.

As per my reply to Maxime, though, I'd expect that if all ordering
issues were fixed and things were perfect then we'd still have a
problem. Specifically it would seem pretty wrong to me to say that the
panel is the "parent" of the DRM device, right? So if the panel is the
"child" of the DRM device that means it'll get shutdown first and that
means that the panel's shutdown call cannot be used to tell whether
the DRM device's shutdown call behaved properly.

> > In any case, the only way I could figure out around this was some sort
> > of list. As mentioned in the commit message, it's super ugly and
> > intended to be temporary. Once we solve all the current in-tree
> > drivers, I'd imagine that long term for new DRM drivers this kind of
> > thing would be discovered during bringup of new boards. Usually during
> > bringup of new boards EEs measure timing signals and complain if
> > they're not right. If some EE cared and said we weren't disabling the
> > panel correctly at shutdown time then we'd know there was a problem.
>
> You've stepped into an entire hornets nest with this device dependency
> issue unfortunately, I'm afraid :-/

As you've said, you've been working on this problem for years. Solving
the device link problem doesn't help me, but even if it did it's
really not fundamental to the problem here. The only need is to get a
warning printed out so we know for sure which DRM drivers need to be
updated before deleting the old crufty code. Blocking that on a
difficult / years-long struggle might not be the best.

That all being said, I'm also totally OK with any of the following:

1. Dropping my patch and just accepting that we will have warnings
printed out for all DRM drivers that do things correctly and have no
warnings for broken DRM drivers.

2. Someone else posting / landing a patch to remove the hacky "disable
/ unprepare" for panel-simple and panel-edp and asserting that they
don't care if they break any DRM drivers that are still broken. I
don't want to be involved in authoring or landing this patch, but I
won't scream loudly if others want to do it.

3. Someone else taking over trying to solve this problem.

...mostly this work is janitorial and I'm trying to help move the DRM
framework forward and get rid of cruft, so if it's going to cause too
much conflict I'm fine just stepping back.

-Doug

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

Hi,

On Wed, Jun 12, 2024 at 8:13 AM Daniel Vetter  wrote:
>
> > > I ran the coccinelle script we started with, and here are the results:
> > >
> > > ./drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1640:25-39: ERROR: KMS driver 
> > > vmw_pci_driver is missing shutdown implementation
> > > ./drivers/gpu/drm/kmb/kmb_drv.c:621:30-49: ERROR: KMS driver 
> > > kmb_platform_driver is missing shutdown implementation
> > > ./drivers/gpu/drm/tiny/arcpgu.c:422:30-52: ERROR: KMS driver 
> > > arcpgu_platform_driver is missing shutdown implementation
> >
> > Sure, although I think we agreed even back when we talked about this
> > last that your coccinelle script wasn't guaranteed to catch every
> > driver. ...so I guess the question is: are we willing to accept that
> > we'll stop disabling panels at shutdown for any drivers that might
> > were missed. For instance, looking at it by hand (which also could
> > miss things), I previously thought that we also might need:
> >
> > * nouveau
> > * tegra
> > * amdgpu
> > * sprd
> > * gma500
> > * radeon
> >
> > I sent patches for those drivers but they don't go through drm-misc
> > and some of the drivers had a lot of abstraction layers and were hard
> > to reason about. I'm also not 100% confident that all of those drivers
> > really are affected--they'd have to be used with panel-simple or
> > panel-edp...
>
> Aside from amdgpu and radeon they're all in -misc now, and Alex is
> generally fairly responsive.

Ah, nice! They weren't when I sent the patches ages ago. I guess I
should go ahead and repost things and maybe they'll get some traction.


> > In any case, having some sort of warning that would give us a
> > definitive answer would be nice. My proposed patch would give us that
> > warning. I could even jump to a WARN_ON right from the start.
>
> Yeah we defo want some warning to at least check this at runtime.

Yeah, my patch today currently just has a "dev_warn", but the question
is whether it would get more attention with a full on WARN_ON(). I
know WARN_ON() can be pretty controversial.

-Doug

Re: [PATCH v5] drm/ci: add tests on vkms

2024-06-12 Thread Helen Koike





On 11/06/2024 07:47, Vignesh Raman wrote:

Hi,

Successful pipeline link,
https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1198487


lgtm, I'm applying this tomorrow if there are no more comments.

Regards,
Helen



Regards,
Vignesh

On 11/06/24 14:40, Vignesh Raman wrote:

Add job that runs igt on top of vkms.

Acked-by: Maíra Canal 
Acked-by: Helen Koike 
Signed-off-by: Vignesh Raman 
Acked-by: Jessica Zhang 
Tested-by: Jessica Zhang 
Acked-by: Maxime Ripard 
Signed-off-by: Helen Koike 
---

v2:
- do not mv modules to /lib/modules in the job definition, leave it to
   crosvm-runner.sh

v3:
- Enable CONFIG_DRM_VKMS in x86_64.config and update xfails

v4:
- Build vkms as module and test with latest IGT.
   This patch depends on 
https://lore.kernel.org/dri-devel/20240130150340.687871-1-vignesh.ra...@collabora.com/


v5:
- Test with the updated IGT and update xfails

---
  MAINTAINERS   |  1 +
  drivers/gpu/drm/ci/build.sh   |  1 -
  drivers/gpu/drm/ci/gitlab-ci.yml  |  1 +
  drivers/gpu/drm/ci/igt_runner.sh  |  6 +-
  drivers/gpu/drm/ci/image-tags.yml |  2 +-
  drivers/gpu/drm/ci/test.yml   | 24 ++-
  drivers/gpu/drm/ci/x86_64.config  |  1 +
  drivers/gpu/drm/ci/xfails/vkms-none-fails.txt | 57 
  .../gpu/drm/ci/xfails/vkms-none-flakes.txt    | 15 +
  drivers/gpu/drm/ci/xfails/vkms-none-skips.txt | 67 +++
  10 files changed, 169 insertions(+), 6 deletions(-)
  create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt
  create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-flakes.txt
  create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-skips.txt

diff --git a/MAINTAINERS b/MAINTAINERS
index 8aee861d18f9..94065f5028cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7036,6 +7036,7 @@ L:    dri-devel@lists.freedesktop.org
  S:    Maintained
  T:    git https://gitlab.freedesktop.org/drm/misc/kernel.git
  F:    Documentation/gpu/vkms.rst
+F:    drivers/gpu/drm/ci/xfails/vkms*
  F:    drivers/gpu/drm/vkms/
  DRM DRIVER FOR VIRTUALBOX VIRTUAL GPU
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index a67871fdcd3f..e938074ac8e7 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -157,7 +157,6 @@ fi
  mkdir -p artifacts/install/lib
  mv install/* artifacts/install/.
-rm -rf artifacts/install/modules
  ln -s common artifacts/install/ci-common
  cp .config artifacts/${CI_JOB_NAME}_config
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml 
b/drivers/gpu/drm/ci/gitlab-ci.yml

index 1b29c3b6406b..80fb0f57ae46 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -123,6 +123,7 @@ stages:
    - msm
    - rockchip
    - virtio-gpu
+  - software-driver
  # YAML anchors for rule conditions
  # 
diff --git a/drivers/gpu/drm/ci/igt_runner.sh 
b/drivers/gpu/drm/ci/igt_runner.sh

index d49ad434b580..79f41d7da772 100755
--- a/drivers/gpu/drm/ci/igt_runner.sh
+++ b/drivers/gpu/drm/ci/igt_runner.sh
@@ -30,10 +30,10 @@ case "$DRIVER_NAME" in
  export IGT_FORCE_DRIVER="panfrost"
  fi
  ;;
-    amdgpu)
+    amdgpu|vkms)
  # Cannot use HWCI_KERNEL_MODULES as at that point we don't 
have the module in /lib

-    mv /install/modules/lib/modules/* /lib/modules/.
-    modprobe amdgpu
+    mv /install/modules/lib/modules/* /lib/modules/. || true
+    modprobe --first-time $DRIVER_NAME
  ;;
  esac
diff --git a/drivers/gpu/drm/ci/image-tags.yml 
b/drivers/gpu/drm/ci/image-tags.yml

index 60323ebc7304..13eda37bdf05 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,7 +4,7 @@ variables:
 DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
 DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
-   DEBIAN_BUILD_TAG: "2023-10-08-config"
+   DEBIAN_BUILD_TAG: "2024-06-10-vkms"
 KERNEL_ROOTFS_TAG: "2023-10-06-amd"
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 322cce714657..ee908b66aad2 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -338,7 +338,7 @@ meson:g12b:
  RUNNER_TAG: mesa-ci-x86-64-lava-meson-g12b-a311d-khadas-vim3
  virtio_gpu:none:
-  stage: virtio-gpu
+  stage: software-driver
    variables:
  CROSVM_GALLIUM_DRIVER: llvmpipe
  DRIVER_NAME: virtio_gpu
@@ -358,3 +358,25 @@ virtio_gpu:none:
  - debian/x86_64_test-gl
  - testing:x86_64
  - igt:x86_64
+
+vkms:none:
+  stage: software-driver
+  variables:
+    DRIVER_NAME: vkms
+    GPU_VERSION: none
+  extends:
+    - .test-gl
+    - .test-rules
+  tags:
+    - kvm
+  script:
+    - ln -sf $CI_PROJECT_DIR/install /install
+    - mv install/bzImage /lava-files/bzImage
+    - mkdir -p /lib/modules
+    - mkdir -p $CI_PROJECT_DIR/results
+    - ln -sf $CI_PROJECT_DIR/results /results
+    - ./install/crosvm-runner.sh

Re: [f2fs-dev] [PATCH] tracing/treewide: Remove second parameter of __assign_str()

2024-06-12 Thread patchwork-bot+f2fs

Hello:

This patch was applied to jaegeuk/f2fs.git (dev)
by Steven Rostedt (Google) :

On Thu, 16 May 2024 13:34:54 -0400 you wrote:
> From: "Steven Rostedt (Google)" 
> 
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.10 and submit it then. Hoping
>to keep the conflicts that it will cause to a minimum.
> ]
> 
> [...]

Here is the summary with links:
  - [f2fs-dev] tracing/treewide: Remove second parameter of __assign_str()
https://git.kernel.org/jaegeuk/f2fs/c/2c92ca849fcc

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

[PATCH] fbdev: viafb: add missing MODULE_DESCRIPTION() macro

With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in 
drivers/video/fbdev/via/viafb.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson 
---
Description derived from the Kconfig entry
---
 drivers/video/fbdev/via/viafbdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/via/viafbdev.c 
b/drivers/video/fbdev/via/viafbdev.c
index a52b1ba43a48..6da5ae7d229a 100644
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -2144,5 +2144,6 @@ MODULE_PARM_DESC(viafb_lcd_port, "Specify LCD output 
port.");
 module_param(viafb_dvi_port, charp, S_IRUSR);
 MODULE_PARM_DESC(viafb_dvi_port, "Specify DVI output port.");
 
+MODULE_DESCRIPTION("VIA UniChrome (Pro) and Chrome9 display driver");
 MODULE_LICENSE("GPL");
 #endif

---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-via-3d7df315eee7

Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers

2024-06-12 Thread David Ahern

On 6/12/24 6:06 AM, Jason Gunthorpe wrote:
> On Tue, Jun 11, 2024 at 11:09:15AM -0700, Mina Almasry wrote:
> 
>> Just curious: in Pavel's effort, io_uring - which is not a device - is
>> trying to share memory with the page_pool, which is also not a device.
>> And Pavel is being asked to wrap the memory in a dmabuf. Is dmabuf
>> going to be the kernel's standard for any memory sharing between any 2
>> components in the future, even when they're not devices?
> 
> dmabuf is how we are refcounting non-struct page memory, there is
> nothing about it that says it has to be MMIO memory, or even that the
> memory doesn't have struct pages.
> 
> All it says is that the memory is alive according to dmabuf
> refcounting rules. And the importer obviously don't get to touch the
> underlying folios, if any.
> 

In addition, the io_uring developers should be considering the use case
of device memory. There is no reason for this design to be limited to
host memory. io_uring should not care (it is not peeking inside the
memory buffers); it is just memory references.

One of io_uring's primary benefits is avoiding system calls. io_uring
works with TCP sockets. Let it work with any dmabuf without concern of
memory type. The performance benefits the Google crowd sees with system
call based apps should be even better with io_uring.

Focus on primitives, building blocks with solid APIs for other
subsystems to leverage and let them be wired up in ways you cannot
imagine today.

[PATCH 0/2] fix handling of incorrect arguments by mipi_dsi_msleep

mipi_dsi_msleep is currently defined such that it treats ctx as an
argument passed by value. In the case of ctx being passed by
reference, it doesn't raise an error, but instead evaluates the
resulting expression in an undesired manner. Since the majority of the
usage of this function passes ctx by reference (similar to
other functions), mipi_dsi_msleep can be modified to treat ctx as a
pointer and do it correctly, and the other calls to this macro can be
adjusted accordingly.

Tejas Vipin (2):
  drm/panel : himax-hx83102: fix incorrect argument to mipi_dsi_msleep
  drm/mipi-dsi: fix handling of ctx in mipi_dsi_msleep

 drivers/gpu/drm/panel/panel-himax-hx83102.c | 6 +++---
 include/drm/drm_mipi_dsi.h  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.45.2

[PATCH 1/2] drm/panel : himax-hx83102: fix incorrect argument to mipi_dsi_msleep

mipi_dsi_msleep should be modified to accept ctx as a pointer and the
function call should be adjusted accordingly.

Fixes: a2ab7cb169da3 ("drm/panel: himax-hx83102: use wrapped MIPI DCS 
functions") 
Signed-off-by: Tejas Vipin 
---
 drivers/gpu/drm/panel/panel-himax-hx83102.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c 
b/drivers/gpu/drm/panel/panel-himax-hx83102.c
index 6009a3fe1b8f..6e4b7e4644ce 100644
--- a/drivers/gpu/drm/panel/panel-himax-hx83102.c
+++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c
@@ -286,7 +286,7 @@ static int boe_nv110wum_init(struct hx83102 *ctx)
mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETBANK, 0x00);
hx83102_enable_extended_cmds(_ctx, false);
 
-   mipi_dsi_msleep(dsi_ctx, 50);
+   mipi_dsi_msleep(_ctx, 50);
 
return dsi_ctx.accum_err;
 };
@@ -391,7 +391,7 @@ static int ivo_t109nw41_init(struct hx83102 *ctx)
mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETBANK, 0x00);
hx83102_enable_extended_cmds(_ctx, false);
 
-   mipi_dsi_msleep(dsi_ctx, 60);
+   mipi_dsi_msleep(_ctx, 60);
 
return dsi_ctx.accum_err;
 };
@@ -538,7 +538,7 @@ static int hx83102_prepare(struct drm_panel *panel)
dsi_ctx.accum_err = ctx->desc->init(ctx);
 
mipi_dsi_dcs_exit_sleep_mode_multi(_ctx);
-   mipi_dsi_msleep(dsi_ctx, 120);
+   mipi_dsi_msleep(_ctx, 120);
mipi_dsi_dcs_set_display_on_multi(_ctx);
if (dsi_ctx.accum_err)
goto poweroff;
-- 
2.45.2

[PATCH 2/2] drm/mipi-dsi: fix handling of ctx in mipi_dsi_msleep

ctx would be better off treated as a pointer to account for most of its
usage so far, and brackets should be added to account for operator 
precedence for correct evaluation.

Fixes: f79d6d28d8fe7 ("drm/mipi-dsi: wrap more functions for streamline 
handling") 
Signed-off-by: Tejas Vipin 
---
 include/drm/drm_mipi_dsi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index bd5a0b6d0711..71d121aeef24 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -293,7 +293,7 @@ ssize_t mipi_dsi_generic_read(struct mipi_dsi_device *dsi, 
const void *params,
 
 #define mipi_dsi_msleep(ctx, delay)\
do {\
-   if (!ctx.accum_err) \
+   if (!(ctx)->accum_err)  \
msleep(delay);  \
} while (0)
 
-- 
2.45.2

[PATCH] fbdev: matroxfb: add missing MODULE_DESCRIPTION() macros

With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in 
drivers/video/fbdev/matrox/matroxfb_accel.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
drivers/video/fbdev/matrox/matroxfb_DAC1064.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
drivers/video/fbdev/matrox/matroxfb_Ti3026.o

Add the missing invocations of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson 
---
Corrections to these descriptions are welcomed. While doing these
cleanups treewide, in most cases I've taken these descriptions
directly from code comments, Kconfig descriptions, or git logs.
However in this directory many of the files have duplicate
descriptions and the Kconfigs have none, so I winged it based upon
eyeballing the code and looking at the existing MODULE_DESCRIPTION()s
---
 drivers/video/fbdev/matrox/matroxfb_DAC1064.c | 1 +
 drivers/video/fbdev/matrox/matroxfb_Ti3026.c  | 1 +
 drivers/video/fbdev/matrox/matroxfb_accel.c   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c 
b/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
index 765e805d14e3..398b7035f5a9 100644
--- a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
+++ b/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
@@ -,4 +,5 @@ EXPORT_SYMBOL(matrox_G100);
 EXPORT_SYMBOL(DAC1064_global_init);
 EXPORT_SYMBOL(DAC1064_global_restore);
 #endif
+MODULE_DESCRIPTION("Matrox Mystique/G100 output driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/matrox/matroxfb_Ti3026.c 
b/drivers/video/fbdev/matrox/matroxfb_Ti3026.c
index 5617c014da87..f53b8066e8a5 100644
--- a/drivers/video/fbdev/matrox/matroxfb_Ti3026.c
+++ b/drivers/video/fbdev/matrox/matroxfb_Ti3026.c
@@ -746,4 +746,5 @@ struct matrox_switch matrox_millennium = {
 };
 EXPORT_SYMBOL(matrox_millennium);
 #endif
+MODULE_DESCRIPTION("Matrox Millennium output driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/matrox/matroxfb_accel.c 
b/drivers/video/fbdev/matrox/matroxfb_accel.c
index ce51227798a1..52e15dc6f45b 100644
--- a/drivers/video/fbdev/matrox/matroxfb_accel.c
+++ b/drivers/video/fbdev/matrox/matroxfb_accel.c
@@ -517,4 +517,5 @@ static void matroxfb_imageblit(struct fb_info* info, const 
struct fb_image* imag
}
 }
 
+MODULE_DESCRIPTION("Accelerated fbops for Matrox 
Millennium/Mystique/G100/G200/G400/G450/G550");
 MODULE_LICENSE("GPL");

---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-matrox-44ec428aa97a

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

2024-06-12 Thread Daniel Vetter

On Wed, Jun 12, 2024 at 07:39:01AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Wed, Jun 12, 2024 at 1:09 AM Maxime Ripard  wrote:
> >
> > Hi,
> >
> > On Tue, Jun 11, 2024 at 07:48:51AM GMT, Douglas Anderson wrote:
> > > At shutdown if you've got a _properly_ coded DRM modeset driver then
> > > you'll get these two warnings at shutdown time:
> > >
> > >   Skipping disable of already disabled panel
> > >   Skipping unprepare of already unprepared panel
> > >
> > > These warnings are ugly and sound concerning, but they're actually a
> > > sign of a properly working system. That's not great.
> > >
> > > It's not easy to get rid of these warnings. Until we know that all DRM
> > > modeset drivers used with panel-simple and panel-edp are properly
> > > calling drm_atomic_helper_shutdown() or drm_helper_force_disable_all()
> > > then the panel drivers _need_ to disable/unprepare themselves in order
> > > to power off the panel cleanly. However, there are lots of DRM modeset
> > > drivers used with panel-edp and panel-simple and it's hard to know
> > > when we've got them all. Since the warning happens only on the drivers
> > > that _are_ updated there's nothing to encourage broken DRM modeset
> > > drivers to get fixed.
> > >
> > > In order to flip the warning to the proper place, we need to know
> > > which modeset drivers are going to shutdown properly. Though ugly, do
> > > this by creating a list of everyone that shuts down properly. This
> > > allows us to generate a warning for the correct case and also lets us
> > > get rid of the warning for drivers that are shutting down properly.
> > >
> > > Maintaining this list is ugly, but the idea is that it's only short
> > > term. Once everyone is converted we can delete the list and call it
> > > done. The list is ugly enough and adding to it is annoying enough that
> > > people should push to make this happen.
> > >
> > > Implement this all in a shared "header" file included by the two panel
> > > drivers that need it. This avoids us adding an new exports while still
> > > allowing the panel drivers to be modules. The code waste should be
> > > small and, as per above, the whole solution is temporary.
> > >
> > > Signed-off-by: Douglas Anderson 
> > > ---
> > > I came up with this idea to help us move forward since otherwise I
> > > couldn't see how we were ever going to fix panel-simple and panel-edp
> > > since they're used by so many DRM Modeset drivers. It's a bit ugly but
> > > I don't hate it. What do others think?
> >
> > I don't think it's the right approach, even more so since we're so close
> > now to having it in every driver.
> >
> > I ran the coccinelle script we started with, and here are the results:
> >
> > ./drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1640:25-39: ERROR: KMS driver 
> > vmw_pci_driver is missing shutdown implementation
> > ./drivers/gpu/drm/kmb/kmb_drv.c:621:30-49: ERROR: KMS driver 
> > kmb_platform_driver is missing shutdown implementation
> > ./drivers/gpu/drm/tiny/arcpgu.c:422:30-52: ERROR: KMS driver 
> > arcpgu_platform_driver is missing shutdown implementation
> 
> Sure, although I think we agreed even back when we talked about this
> last that your coccinelle script wasn't guaranteed to catch every
> driver. ...so I guess the question is: are we willing to accept that
> we'll stop disabling panels at shutdown for any drivers that might
> were missed. For instance, looking at it by hand (which also could
> miss things), I previously thought that we also might need:
> 
> * nouveau
> * tegra
> * amdgpu
> * sprd
> * gma500
> * radeon
> 
> I sent patches for those drivers but they don't go through drm-misc
> and some of the drivers had a lot of abstraction layers and were hard
> to reason about. I'm also not 100% confident that all of those drivers
> really are affected--they'd have to be used with panel-simple or
> panel-edp...

Aside from amdgpu and radeon they're all in -misc now, and Alex is
generally fairly responsive.

> In any case, having some sort of warning that would give us a
> definitive answer would be nice. My proposed patch would give us that
> warning. I could even jump to a WARN_ON right from the start.

Yeah we defo want some warning to at least check this at runtime.

> My proposed patch is self-admittedly super ugly and is also designed
> to be temporary, so I don't think of this as giving up right before
> crossing the finish line but instead accepting a tiny bit of temporary
> ugliness to make sure that we don't accidentally regress anyone. I
> would really hope it would be obvious to anyone writing / reviewing
> drivers that the function I introduced isn't intended for anyone but
> panel-simple and panel-edp.

See my other reply for the proper design fix, and my apologies for what
you stepped into here :-/
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

2024-06-12 Thread Daniel Vetter

On Wed, Jun 12, 2024 at 07:49:31AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Wed, Jun 12, 2024 at 1:58 AM Daniel Vetter  wrote:
> >
> > On Tue, Jun 11, 2024 at 07:48:51AM -0700, Douglas Anderson wrote:
> > > At shutdown if you've got a _properly_ coded DRM modeset driver then
> > > you'll get these two warnings at shutdown time:
> > >
> > >   Skipping disable of already disabled panel
> > >   Skipping unprepare of already unprepared panel
> > >
> > > These warnings are ugly and sound concerning, but they're actually a
> > > sign of a properly working system. That's not great.
> > >
> > > It's not easy to get rid of these warnings. Until we know that all DRM
> > > modeset drivers used with panel-simple and panel-edp are properly
> > > calling drm_atomic_helper_shutdown() or drm_helper_force_disable_all()
> > > then the panel drivers _need_ to disable/unprepare themselves in order
> > > to power off the panel cleanly. However, there are lots of DRM modeset
> > > drivers used with panel-edp and panel-simple and it's hard to know
> > > when we've got them all. Since the warning happens only on the drivers
> > > that _are_ updated there's nothing to encourage broken DRM modeset
> > > drivers to get fixed.
> > >
> > > In order to flip the warning to the proper place, we need to know
> > > which modeset drivers are going to shutdown properly. Though ugly, do
> > > this by creating a list of everyone that shuts down properly. This
> > > allows us to generate a warning for the correct case and also lets us
> > > get rid of the warning for drivers that are shutting down properly.
> > >
> > > Maintaining this list is ugly, but the idea is that it's only short
> > > term. Once everyone is converted we can delete the list and call it
> > > done. The list is ugly enough and adding to it is annoying enough that
> > > people should push to make this happen.
> > >
> > > Implement this all in a shared "header" file included by the two panel
> > > drivers that need it. This avoids us adding an new exports while still
> > > allowing the panel drivers to be modules. The code waste should be
> > > small and, as per above, the whole solution is temporary.
> > >
> > > Signed-off-by: Douglas Anderson 
> > > ---
> > > I came up with this idea to help us move forward since otherwise I
> > > couldn't see how we were ever going to fix panel-simple and panel-edp
> > > since they're used by so many DRM Modeset drivers. It's a bit ugly but
> > > I don't hate it. What do others think?
> >
> > I think it's terrible :-)
> 
> Well, we're in agreement. It is terrible. However, in my opinion it's
> still a reasonable way to move forward.
> 
> 
> > Why does something like this now work?
> >
> > drm_panel_shutdown_fixup(panel)
> > {
> > /* if you get warnings here, fix your main drm driver to call
> >  * drm_atomic_helper_shutdown()
> >  */
> > if (WARN_ON(panel->enabled))
> > drm_panel_disable(panel);
> >
> > if (WARN_ON(panel->prepared))
> > drm_panel_unprepare(panel);
> > }
> >
> > And then call that little helper in the relevant panel drivers? Also feel
> > free to bikeshed the name and maybe put a more lengthly explainer into the
> > kerneldoc for that ...
> >
> > Or am I completely missing the point here?
> 
> The problem is that the ordering is wrong, I think. Even if the OS was
> calling driver shutdown functions in the perfect order (which I'm not
> convinced about since panels aren't always child "struct device"s of
> the DRM device), the OS should be calling panel shutdown _before_
> shutting down the DRM device. That means that with your suggestion:
> 
> 1. Shutdown starts and panel is on.
> 
> 2. OS calls panel shutdown call, which prints warnings because panel
> is still on.
> 
> 3. OS calls DRM driver shutdown call, which prints warnings because
> someone else turned the panel off.

Uh, that's a _much_ more fundamental issue.

The fix for that is telling the driver core about this dependency with
device_link_add. Unfortuantely, despite years of me trying to push for
this, drm_bridge and drm_panel still don't automatically add these,
because the situation is a really complex mess.

Probably need to read dri-devel archives for all the past attempts around
device_link_add.

But the solution is definitely not to have a manually tracked list, what's
very architectural unsound way to tackle this problem.

> Certainly if I goofed and the above is wrong then let me know--I did
> my experiments on this many months ago and didn't try repeating them
> again now.

Oh the issue is very real and known since years. It also wreaks module
unload and driver unbinding, since currently nothing makes sure your
drm_panel lives longer than your drm_device.

> In any case, the only way I could figure out around this was some sort
> of list. As mentioned in the commit message, it's super ugly and
> intended to be temporary. Once we solve all the current in-tree
> drivers, I'd imagine

Re: [PATCH] drm/panel: Avoid warnings w/ panel-simple/panel-edp at shutdown

2024-06-12 Thread Maxime Ripard

On Wed, Jun 12, 2024 at 07:49:31AM GMT, Doug Anderson wrote:
> Hi,
> 
> On Wed, Jun 12, 2024 at 1:58 AM Daniel Vetter  wrote:
> >
> > On Tue, Jun 11, 2024 at 07:48:51AM -0700, Douglas Anderson wrote:
> > > At shutdown if you've got a _properly_ coded DRM modeset driver then
> > > you'll get these two warnings at shutdown time:
> > >
> > >   Skipping disable of already disabled panel
> > >   Skipping unprepare of already unprepared panel
> > >
> > > These warnings are ugly and sound concerning, but they're actually a
> > > sign of a properly working system. That's not great.
> > >
> > > It's not easy to get rid of these warnings. Until we know that all DRM
> > > modeset drivers used with panel-simple and panel-edp are properly
> > > calling drm_atomic_helper_shutdown() or drm_helper_force_disable_all()
> > > then the panel drivers _need_ to disable/unprepare themselves in order
> > > to power off the panel cleanly. However, there are lots of DRM modeset
> > > drivers used with panel-edp and panel-simple and it's hard to know
> > > when we've got them all. Since the warning happens only on the drivers
> > > that _are_ updated there's nothing to encourage broken DRM modeset
> > > drivers to get fixed.
> > >
> > > In order to flip the warning to the proper place, we need to know
> > > which modeset drivers are going to shutdown properly. Though ugly, do
> > > this by creating a list of everyone that shuts down properly. This
> > > allows us to generate a warning for the correct case and also lets us
> > > get rid of the warning for drivers that are shutting down properly.
> > >
> > > Maintaining this list is ugly, but the idea is that it's only short
> > > term. Once everyone is converted we can delete the list and call it
> > > done. The list is ugly enough and adding to it is annoying enough that
> > > people should push to make this happen.
> > >
> > > Implement this all in a shared "header" file included by the two panel
> > > drivers that need it. This avoids us adding an new exports while still
> > > allowing the panel drivers to be modules. The code waste should be
> > > small and, as per above, the whole solution is temporary.
> > >
> > > Signed-off-by: Douglas Anderson 
> > > ---
> > > I came up with this idea to help us move forward since otherwise I
> > > couldn't see how we were ever going to fix panel-simple and panel-edp
> > > since they're used by so many DRM Modeset drivers. It's a bit ugly but
> > > I don't hate it. What do others think?
> >
> > I think it's terrible :-)
> 
> Well, we're in agreement. It is terrible. However, in my opinion it's
> still a reasonable way to move forward.
> 
> 
> > Why does something like this now work?
> >
> > drm_panel_shutdown_fixup(panel)
> > {
> > /* if you get warnings here, fix your main drm driver to call
> >  * drm_atomic_helper_shutdown()
> >  */
> > if (WARN_ON(panel->enabled))
> > drm_panel_disable(panel);
> >
> > if (WARN_ON(panel->prepared))
> > drm_panel_unprepare(panel);
> > }
> >
> > And then call that little helper in the relevant panel drivers? Also feel
> > free to bikeshed the name and maybe put a more lengthly explainer into the
> > kerneldoc for that ...
> >
> > Or am I completely missing the point here?
> 
> The problem is that the ordering is wrong, I think. Even if the OS was
> calling driver shutdown functions in the perfect order (which I'm not
> convinced about since panels aren't always child "struct device"s of
> the DRM device), the OS should be calling panel shutdown _before_
> shutting down the DRM device. That means that with your suggestion:
> 
> 1. Shutdown starts and panel is on.
> 
> 2. OS calls panel shutdown call, which prints warnings because panel
> is still on.
> 
> 3. OS calls DRM driver shutdown call, which prints warnings because
> someone else turned the panel off.
> 
> :-P
> 
> Certainly if I goofed and the above is wrong then let me know--I did
> my experiments on this many months ago and didn't try repeating them
> again now.
> 
> In any case, the only way I could figure out around this was some sort
> of list. As mentioned in the commit message, it's super ugly and
> intended to be temporary. Once we solve all the current in-tree
> drivers, I'd imagine that long term for new DRM drivers this kind of
> thing would be discovered during bringup of new boards. Usually during
> bringup of new boards EEs measure timing signals and complain if
> they're not right. If some EE cared and said we weren't disabling the
> panel correctly at shutdown time then we'd know there was a problem.

Based on a discussion we had today With Sima on IRC, I think there's
another way forward.

We were actually discussing refcount'ing the panels to avoid lifetime
issues. It would require some API overhaul to have a function to
allocate the drm_panel structure and init'ing the refcount, plus some to
get / put the references.

Having this refcount would mean that we

Re: [PATCH] drm/fbdev-dma: fix getting smem_start

2024-06-12 Thread Daniel Vetter

On Wed, Jun 12, 2024 at 10:37:14AM +0200, Thomas Zimmermann wrote:
> Hi Javier
> 
> Am 12.06.24 um 09:49 schrieb Javier Martinez Canillas:
> > Thomas Zimmermann  writes:
> > 
> > Hello Thomas,
> > 
> > > Hi
> > > 
> > > Am 10.06.24 um 10:47 schrieb Thomas Zimmermann:
> > > > Hi
> > > > 
> > > > Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
> > > > > From: Peng Fan 
> > > > > 
> > > > > If 'info->screen_buffer' locates in vmalloc address space, 
> > > > > virt_to_page
> > > > > will not be able to get correct results. With CONFIG_DEBUG_VM and
> > > > > CONFIG_DEBUG_VIRTUAL enabled on ARM64, there is dump below:
> > > > Which graphics driver triggers this bug?
> > > > 
> > > > > [    3.536043] [ cut here ]
> > > > > [    3.540716] virt_to_phys used for non-linear address:
> > > > > 7fc4f540 (0x800086001000)
> > > > > [    3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12
> > > > > __virt_to_phys+0x68/0x98
> > > > > [    3.565455] Modules linked in:
> > > > > [    3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted
> > > > > 6.6.23-06226-g4986cc3e1b75-dirty #250
> > > > > [    3.577310] Hardware name: NXP i.MX95 19X19 board (DT)
> > > > > [    3.582452] Workqueue: events_unbound deferred_probe_work_func
> > > > > [    3.588291] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
> > > > > BTYPE=--)
> > > > > [    3.595233] pc : __virt_to_phys+0x68/0x98
> > > > > [    3.599246] lr : __virt_to_phys+0x68/0x98
> > > > > [    3.603276] sp : 800083603990
> > > > > [    3.677939] Call trace:
> > > > > [    3.680393]  __virt_to_phys+0x68/0x98
> > > > > [    3.684067]  drm_fbdev_dma_helper_fb_probe+0x138/0x238
> > > > > [    3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0
> > > > > [    3.695385]  drm_fb_helper_initial_config+0x4c/0x68
> > > > > [    3.700264]  drm_fbdev_dma_client_hotplug+0x8c/0xe0
> > > > > [    3.705161]  drm_client_register+0x60/0xb0
> > > > > [    3.709269]  drm_fbdev_dma_setup+0x94/0x148
> > > > > 
> > > > > So add a check 'is_vmalloc_addr'.
> > > > > 
> > > > > Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for
> > > > > GEM DMA helpers")
> > > > > Signed-off-by: Peng Fan 
> > > > Reviewed-by: Thomas Zimmermann 
> > > I'm taking back my r-b. The memory is expected to by be physically
> > > contiguous and vmalloc() won't guarantee that.
> > > 
> > Agreed.
> 
> These smem_ fields are clearly designed for PCI BARs of traditional graphics
> cards. So can we even assume contiguous memory for DMA? That was my
> assumption, but with IOMMUs it might not be the case. Fbdev-dma only sets
> smem_start to support a single old userspace driver. Maybe we should further
> restrict usage of this field by making it opt-in for each driver. Best
> regards Thomas

We could make it all conditional on CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM, and
remove the FBINFO_HIDE_SMEM_START flag. The reason I've done the flag is
that with the old fb_mmap code we had to always fill out smem_start to
make mmap work. But now that the various drm fbdev helpers have all their
own mmap implementation, we could make this a lot cleaner.

If I haven't missed anything, that is.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 2/2] drm/mipi-dsi: fix handling of ctx in mipi_dsi_msleep

2024-06-12 Thread neil . armstrong


On 12/06/2024 16:52, Doug Anderson wrote:

Hi,

On Wed, Jun 12, 2024 at 7:34 AM  wrote:


On 12/06/2024 16:21, Doug Anderson wrote:

Hi,

On Wed, Jun 12, 2024 at 6:37 AM Tejas Vipin  wrote:


ctx would be better off treated as a pointer to account for most of its
usage so far, and brackets should be added to account for operator
precedence for correct evaluation.

Fixes: f79d6d28d8fe7 ("drm/mipi-dsi: wrap more functions for streamline 
handling")
Signed-off-by: Tejas Vipin 
---
   include/drm/drm_mipi_dsi.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)


Yeah. Looking closer at the history, it looks like it was always
intended to be a pointer since the first users all used it as a
pointer.

Suggested-by: Douglas Anderson 
Reviewed-by: Douglas Anderson 

I've also compile-tested all the panels currently using mipi_dsi_msleep().

Neil: Given that this is a correctness thing, I'd rather see this land
sooner rather than later. If you agree, maybe you can land these two
patches whenever you're comfortable with them?


Applying them, but inverting them, fix should go first.


Well, they're both fixes, and inverting them means that you get a
compile failure across several panels if you happen to be bisecting
and land on the first commit, but it doesn't really matter. I guess
the compile failure is maybe a benefit given that they were not doing
their delays properly... ;-)


Yes, and thanksfully there's a fix for the build failure!



-Doug

Re: [PATCH 2/2] drm/mipi-dsi: fix handling of ctx in mipi_dsi_msleep