[PATCH] drm/tiny: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tiny/bochs.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tiny/cirrus.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/tiny/gm12u320.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/gpu/drm/tiny/bochs.c| 1 +
drivers/gpu/drm/tiny/cirrus.c | 1 +
drivers/gpu/drm/tiny/gm12u320.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index c23c9f0cf49c..d15f4d3baeab 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -736,4 +736,5 @@ drm_module_pci_driver_if_modeset(bochs_pci_driver,
bochs_modeset);
MODULE_DEVICE_TABLE(pci, bochs_pci_tbl);
MODULE_AUTHOR("Gerd Hoffmann ");
+MODULE_DESCRIPTION("DRM Support for bochs dispi vga interface (qemu stdvga)");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 4e3a152f897a..89484f7084bd 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -760,4 +760,5 @@ static struct pci_driver cirrus_pci_driver = {
drm_module_pci_driver(cirrus_pci_driver)
MODULE_DEVICE_TABLE(pci, pciidlist);
+MODULE_DESCRIPTION("Cirrus driver for QEMU emulated device");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 0187539ff5ea..07c6640022c2 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -755,4 +755,5 @@ static struct usb_driver gm12u320_usb_driver = {
module_usb_driver(gm12u320_usb_driver);
MODULE_AUTHOR("Hans de Goede ");
+MODULE_DESCRIPTION("GM12U320 driver for USB projectors");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-tiny-a3370189f560
[PATCH] drm/bridge: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/bridge/lontium-lt9611.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/bridge/lontium-lt9611uxc.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/bridge/sil-sii8620.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/bridge/sii9234.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/gpu/drm/bridge/lontium-lt9611.c| 1 +
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 +
drivers/gpu/drm/bridge/sii9234.c | 1 +
drivers/gpu/drm/bridge/sil-sii8620.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index b99fe87ec738..73983f9b50cb 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -1195,4 +1195,5 @@ static struct i2c_driver lt9611_driver = {
};
module_i2c_driver(lt9611_driver);
+MODULE_DESCRIPTION("Lontium LT9611 DSI/HDMI bridge driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index ab702471f3ab..724a08f526db 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -1021,6 +1021,7 @@ static struct i2c_driver lt9611uxc_driver = {
module_i2c_driver(lt9611uxc_driver);
MODULE_AUTHOR("Dmitry Baryshkov ");
+MODULE_DESCRIPTION("Lontium LT9611UXC DSI/HDMI bridge driver");
MODULE_LICENSE("GPL v2");
MODULE_FIRMWARE(FW_FILE);
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
index d8373d918324..0c74cdc07032 100644
--- a/drivers/gpu/drm/bridge/sii9234.c
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -961,4 +961,5 @@ static struct i2c_driver sii9234_driver = {
};
module_i2c_driver(sii9234_driver);
+MODULE_DESCRIPTION("Silicon Image SII9234 HDMI/MHL bridge driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 599164e3877d..6bb755e9f0a5 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2384,4 +2384,5 @@ static struct i2c_driver sii8620_driver = {
};
module_i2c_driver(sii8620_driver);
+MODULE_DESCRIPTION("Silicon Image SiI8620 HDMI/MHL bridge driver");
MODULE_LICENSE("GPL v2");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-bridge-6ab32656df86
[PATCH] drm/panel: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-abt-y030xx067a.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-auo-a030jtn01.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-innolux-ej030na.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-newvision-nv3052c.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-novatek-nt39016.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-orisetech-ota5601a.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 1 +
drivers/gpu/drm/panel/panel-auo-a030jtn01.c | 1 +
drivers/gpu/drm/panel/panel-innolux-ej030na.c| 1 +
drivers/gpu/drm/panel/panel-newvision-nv3052c.c | 1 +
drivers/gpu/drm/panel/panel-novatek-nt39016.c| 1 +
drivers/gpu/drm/panel/panel-orisetech-ota5601a.c | 1 +
6 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
index 662c7bcbe6e5..4692c36fe217 100644
--- a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
+++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
@@ -381,4 +381,5 @@ module_spi_driver(y030xx067a_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("Asia Better Technology Ltd. Y030XX067A IPS LCD panel
driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
b/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
index 6c86ebf2cad7..77604d6a4e72 100644
--- a/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
+++ b/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
@@ -305,4 +305,5 @@ module_spi_driver(a030jtn01_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("AU Optronics A030JTN01.0 TFT LCD panel driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
index 8fdbda59be48..f85b7a4cbb42 100644
--- a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
+++ b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
@@ -306,4 +306,5 @@ module_spi_driver(ej030na_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("Innolux/Chimei EJ030NA TFT LCD panel driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
index 1aab0c9ae52f..b8f7c673ab50 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -719,4 +719,5 @@ module_spi_driver(nv3052c_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("NewVision NV3052C IPS LCD panel driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
index 059260262b5a..9fa7654e2b67 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
@@ -356,4 +356,5 @@ module_spi_driver(nt39016_driver);
MODULE_AUTHOR("Maarten ter Huurne ");
MODULE_AUTHOR("Paul Cercueil ");
+MODULE_DESCRIPTION("Novatek NT39016 TFT LCD panel driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
b/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
index c415dacf1816..fc87f61d4400 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
@@ -360,4 +360,5 @@ static struct spi_driver ota5601a_driver = {
module_spi_driver(ota5601a_driver);
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("Orisetech OTA5601A TFT LCD panel driver");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-panel-6580abcf3d7e
[PATCH] drm/ttm/tests: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_device_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_pool_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_resource_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_tt_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_bo_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_device_test.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_tt_test.c | 1 +
6 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
index 1f8a4f8adc92..c18547c65985 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
@@ -619,4 +619,5 @@ static struct kunit_suite ttm_bo_test_suite = {
kunit_test_suites(_bo_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_bo APIs");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_device_test.c
b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
index 19eaff22e6ae..5bdfa4f88438 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_device_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
@@ -209,4 +209,5 @@ static struct kunit_suite ttm_device_test_suite = {
kunit_test_suites(_device_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_device APIs");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 7b7c1fa805fc..d9d29b34b23b 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -156,4 +156,5 @@ void ttm_test_devices_fini(struct kunit *test)
}
EXPORT_SYMBOL_GPL(ttm_test_devices_fini);
+MODULE_DESCRIPTION("TTM KUnit test helper functions");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
index 0a3fede84da9..2d1928b615a0 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -433,4 +433,5 @@ static struct kunit_suite ttm_pool_test_suite = {
kunit_test_suites(_pool_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_pool APIs");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
index 029e1f094bb0..ade487fea179 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
@@ -332,4 +332,5 @@ static struct kunit_suite ttm_resource_test_suite = {
kunit_test_suites(_resource_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_resource and ttm_sys_man APIs");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
index fd4502c18de6..d78e1e9896d8 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
@@ -292,4 +292,5 @@ static struct kunit_suite ttm_tt_test_suite = {
kunit_test_suites(_tt_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_tt APIs");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-ttm-tests-f7b63f46eb3c
Re: [RFC PATCH 3/8] rust: drm: Add Device and Driver abstractions
Hi Lina, Welcome back! On Sun, Jun 09, 2024 at 02:15:57PM +0900, Asahi Lina wrote: > > > On 5/22/24 6:23 AM, Rob Herring wrote: > > On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote: > >> From: Asahi Lina > > This is missing an entry for DRIVER_GEM_GPUVA. And some others perhaps. > > I suppose some are legacy which won't be needed any time soon if ever. > > Not sure if you intend for this to be complete, or you are just adding > > what you are using? Only FEAT_GEM is used by nova ATM. > > > > This was developed before DRIVER_GEM_GPUVA existed ^^ > > I have this in my branch since I'm using the GPUVA manager now. Danilo, > what tree are you using for this submission? It would be good to > coordinate this and try to keep the WIP branches from diverging too much... Trying to prevent things from diverging was one of my main objectives when I started those efforts a couple of month ago (I also sent you a mail for that purpose back then). I am maintaining a couple of branches: In the RfL repository [1]: - staging/rust-device [2] (Device / driver, devres infrastructure) - staging/dev [3] (common branch containing all the Rust infrastructure I'm currently upstreaming, including PCI and firmware abstractions) In the drm-misc repository [4]: - topic/rust-drm [5] (all the DRM abstractions) In the Nova repository [6] - nova-next [7] (the Nova stub driver making use of everything) I regularly rebase those branches and keep them up to date with improvements and feedback from the mailing list. The device / driver and PCI abstractions are getting most of my attention currently, but there are some recent changes (besides some minor ones) on the DRM abstractions I plan to send in a v2 as well: - static const allocation of driver and fops structures - rework of the `Registration` type to use `Devres` and combine the new() and register() methods to register in new() already There is also some more information regarding those branches in the cover letters of the series and the links included there. [1] https://github.com/Rust-for-Linux/linux [2] https://github.com/Rust-for-Linux/linux/tree/staging/rust-device [3] https://github.com/Rust-for-Linux/linux/tree/staging/dev [4] https://gitlab.freedesktop.org/drm/misc/kernel [5] https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/topic/rust-drm [6] https://gitlab.freedesktop.org/drm/nova [7] https://gitlab.freedesktop.org/drm/nova/-/tree/nova-next > > That said, I don't think there's reason to support all features unless > we expect new drivers to actually use them. The goal of the abstractions > is to serve the drivers that will use them, and to evolve together with > them and any newer drivers, not to attempt to be feature-complete from > the get go (it's very difficult to evaluate an abstraction if it has no > users!). In general my approach when writing them was to abstract what I > need and add "obvious" extra trivial features that didn't require much > thought even if I wasn't using them, but otherwise not attempt to > comprehensively cover everything. Fully agree, I think the point here only was whether we want to list all the feature flags in the abstraction already. Which I think is something we can do. However, I'm also find with only listing the ones we actually use and keep adding further ones subsequently. It just shouldn't be random. - Danilo > > ~~ Lina >
Re: [PATCH v8 4/4] ARM: configs: at91: Enable LVDS serializer support
On 21.04.2024 04:10, Dharma Balasubiramani wrote: > Enable LVDS serializer support for display pipeline. > > Signed-off-by: Dharma Balasubiramani > Acked-by: Hari Prasath Gujulan Elango > Acked-by: Nicolas Ferre Applied to at91-defconfig, thanks!
Re: [PATCH v10 0/6] iio: new DMABUF based API v10
On Wed, 5 Jun 2024 13:08:39 +0200 Paul Cercueil wrote: > Hi Jonathan, > > Here is a revised (and hopefully final?) version of my DMABUF patchset. Fingers crossed it's just docs changes for v11. So on to the details of how to merge this... For the DMAEngine maintainers: Given IIO changes dominate this series it makes sense for me to pick it up through IIO. Do you want an immutable branch with the first patch on it, or is this unlikely to cause merge conflicts with any other ongoing work in dmabuffer land? I'm fine either way and if I don't hear back on this will do an immutable branch and announce it when I apply v11 (I hope!) Jonathan > > This v10 removes the extra "flags" parameter of > dmaengine_prep_peripheral_dma_vec(), and adds kernel doc to the function > as Vinod requested. > > As Nuno upstreamed support for output buffers, I (slightly) modified > patch 5/6 and now output buffers are supported with the DMABUF API. > All I did was remove a "fail if output" check really. > > This was based on next-20240605. > > Changelog: > - [1/6]: > - Add kernel doc to dmaengine_prep_peripheral_dma_vec() > - Remove extra flags parameter > - [2/6]: > - Use the new function prototype (without the extra prep_flags). > - [5/6]: > - Remove extra flags parameter to dmaengine_prep_peripheral_dma_vec() > - Add support for TX transfers > > Cheers, > -Paul > > Paul Cercueil (6): > dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() > dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec > iio: core: Add new DMABUF interface infrastructure > iio: buffer-dma: Enable support for DMABUFs > iio: buffer-dmaengine: Support new DMABUF based userspace API > Documentation: iio: Document high-speed DMABUF based API > > Documentation/iio/iio_dmabuf_api.rst | 54 ++ > Documentation/iio/index.rst | 1 + > drivers/dma/dma-axi-dmac.c| 40 ++ > drivers/iio/Kconfig | 1 + > drivers/iio/buffer/industrialio-buffer-dma.c | 180 ++- > .../buffer/industrialio-buffer-dmaengine.c| 62 ++- > drivers/iio/industrialio-buffer.c | 462 ++ > include/linux/dmaengine.h | 33 ++ > include/linux/iio/buffer-dma.h| 31 ++ > include/linux/iio/buffer_impl.h | 30 ++ > include/uapi/linux/iio/buffer.h | 22 + > 11 files changed, 896 insertions(+), 20 deletions(-) > create mode 100644 Documentation/iio/iio_dmabuf_api.rst >
Re: [PATCH v10 4/6] iio: buffer-dma: Enable support for DMABUFs
On Wed, 5 Jun 2024 13:08:43 +0200
Paul Cercueil wrote:
> Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> DMA buffer implementations.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Nuno Sa
>
Same thing on SoB.
Also another missing structure field related docs comment inline.
> diff --git a/include/linux/iio/buffer-dma.h b/include/linux/iio/buffer-dma.h
> index 6e27e47077d5..e54158e53fd6 100644
> --- a/include/linux/iio/buffer-dma.h
> +++ b/include/linux/iio/buffer-dma.h
> @@ -7,6 +7,7 @@
> #ifndef __INDUSTRIALIO_DMA_BUFFER_H__
> #define __INDUSTRIALIO_DMA_BUFFER_H__
>
> +#include
> #include
> #include
> #include
> @@ -16,6 +17,9 @@
> struct iio_dma_buffer_queue;
> struct iio_dma_buffer_ops;
> struct device;
> +struct dma_buf_attachment;
> +struct dma_fence;
> +struct sg_table;
>
> /**
> * enum iio_block_state - State of a struct iio_dma_buffer_block
> @@ -41,6 +45,8 @@ enum iio_block_state {
> * @queue: Parent DMA buffer queue
> * @kref: kref used to manage the lifetime of block
> * @state: Current state of the block
> + * @cyclic: True if this is a cyclic buffer
> + * @fileio: True if this buffer is used for fileio mode
kernel doc needs to be complete. So missing attach, sg_table and fence.
> */
> struct iio_dma_buffer_block {
> /* May only be accessed by the owner of the block */
> @@ -63,6 +69,14 @@ struct iio_dma_buffer_block {
>* queue->list_lock if the block is not owned by the core.
>*/
> enum iio_block_state state;
> +
> + bool cyclic;
> + bool fileio;
> +
> + struct dma_buf_attachment *attach;
> + struct sg_table *sg_table;
> +
> + struct dma_fence *fence;
> };
Re: [PATCH v10 3/6] iio: core: Add new DMABUF interface infrastructure
On Wed, 5 Jun 2024 13:08:42 +0200
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data transfer.
>
> A userspace application can then use this interface to share DMABUF
> objects between several interfaces, allowing it to transfer data in a
> zero-copy fashion, for instance between IIO and the USB stack.
>
> The userspace application can also memory-map the DMABUF objects, and
> access the sample data directly. The advantage of doing this vs. the
> read() interface is that it avoids an extra copy of the data between the
> kernel and userspace. This is particularly userful for high-speed
> devices which produce several megabytes or even gigabytes of data per
> second.
>
> As part of the interface, 3 new IOCTLs have been added:
>
> IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd):
> Attach the DMABUF object identified by the given file descriptor to the
> buffer.
>
> IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd):
> Detach the DMABUF object identified by the given file descriptor from
> the buffer. Note that closing the IIO buffer's file descriptor will
> automatically detach all previously attached DMABUF objects.
>
> IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
> Request a data transfer to/from the given DMABUF object. Its file
> descriptor, as well as the transfer size and flags are provided in the
> "iio_dmabuf" structure.
>
> These three IOCTLs have to be performed on the IIO buffer's file
> descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Nuno Sa
Need a brief note on the sign off chain.
What is Nuno's role in this series as he's not sending the emails and not
marked with Co-developed-by
I gave this a much more thorough look in earlier versions than I have today but
a few really minor things inline (that I might have fixed up whilst applying)
but looks like you'll be done a v11 for Randy's docs comments anyway :(
Jonathan
> diff --git a/drivers/iio/industrialio-buffer.c
> b/drivers/iio/industrialio-buffer.c
> index 0138b21b244f..c98c8ac83785 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> +struct iio_dmabuf_priv {
> + struct list_head entry;
> + struct kref ref;
> +
> + struct iio_buffer *buffer;
> + struct iio_dma_buffer_block *block;
> +
> + u64 context;
> + spinlock_t lock;
Given you are going to have a v11, please add a comment to this lock
to say what data it is protecting.
> +
> + struct dma_buf_attachment *attach;
> + struct sg_table *sgt;
> + enum dma_data_direction dir;
> + atomic_t seqno;
> +};
> diff --git a/include/linux/iio/buffer_impl.h b/include/linux/iio/buffer_impl.h
> index 89c3fd7c29ca..1a221c1d7736 100644
> --- a/include/linux/iio/buffer_impl.h
> +++ b/include/linux/iio/buffer_impl.h
> @@ -9,8 +9,12 @@
> #include
> #include
>
> +struct dma_buf_attachment;
> +struct dma_fence;
> struct iio_dev;
> +struct iio_dma_buffer_block;
> struct iio_buffer;
> +struct sg_table;
>
> /**
> * INDIO_BUFFER_FLAG_FIXED_WATERMARK - Watermark level of the buffer can not
> be
> @@ -39,6 +43,13 @@ struct iio_buffer;
> * device stops sampling. Calles are balanced with
> @enable.
> * @release: called when the last reference to the buffer is dropped,
> * should free all resources allocated by the buffer.
> + * @attach_dmabuf: called from userspace via ioctl to attach one external
> + * DMABUF.
> + * @detach_dmabuf: called from userspace via ioctl to detach one previously
> + * attached DMABUF.
> + * @enqueue_dmabuf: called from userspace via ioctl to queue this DMABUF
> + * object to this buffer. Requires a valid DMABUF fd, that
> + * was previouly attached to this buffer.
Missing docs for lock_queue() and unlock_queue()
Kernel-doc must be complete or bots are going to moan at us :(
> * @modes: Supported operating modes by this buffer type
> * @flags: A bitmask combination of INDIO_BUFFER_FLAG_*
> *
> @@ -68,6 +79,17 @@ struct iio_buffer_access_funcs {
>
> void (*release)(struct iio_buffer *buffer);
>
> + struct iio_dma_buffer_block * (*attach_dmabuf)(struct iio_buffer
> *buffer,
> +struct
> dma_buf_attachment *attach);
> + void (*detach_dmabuf)(struct iio_buffer *buffer,
> + struct iio_dma_buffer_block *block);
> + int (*enqueue_dmabuf)(struct iio_buffer *buffer,
> + struct iio_dma_buffer_block *block,
> + struct dma_fence *fence, struct sg_table *sgt,
> + size_t size, bool cyclic);
> +
Re: [RFC PATCH 3/8] rust: drm: Add Device and Driver abstractions
On 5/22/24 6:23 AM, Rob Herring wrote:
> On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote:
>> From: Asahi Lina
>>
>> Add abstractions for DRM drivers and devices. These go together in one
>> commit since both are fairly tightly coupled types.
>>
>> A few things have been stubbed out, to be implemented as further bits of
>> the DRM subsystem are introduced.
>>
>> Signed-off-by: Asahi Lina
>> Co-developed-by: Danilo Krummrich
>> Signed-off-by: Danilo Krummrich
>> ---
>> rust/bindings/bindings_helper.h | 2 +
>> rust/kernel/drm/device.rs | 87 +
>> rust/kernel/drm/drv.rs | 318
>> rust/kernel/drm/mod.rs | 2 +
>> 4 files changed, 409 insertions(+)
>> create mode 100644 rust/kernel/drm/device.rs
>> create mode 100644 rust/kernel/drm/drv.rs
>
> [...]
>
>> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
>> new file mode 100644
>> index ..5dd8f3f8df7c
>> --- /dev/null
>> +++ b/rust/kernel/drm/drv.rs
>> @@ -0,0 +1,318 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +
>> +//! DRM driver core.
>> +//!
>> +//! C header:
>> [`include/linux/drm/drm_drv.h`](../../../../include/linux/drm/drm_drv.h)
>> +
>> +use crate::{
>> +alloc::flags::*,
>> +bindings, device, drm,
>> +error::code::*,
>> +error::{Error, Result},
>> +prelude::*,
>> +private::Sealed,
>> +str::CStr,
>> +types::{ARef, ForeignOwnable},
>> +ThisModule,
>> +};
>> +use core::{
>> +marker::{PhantomData, PhantomPinned},
>> +pin::Pin,
>> +};
>> +use macros::vtable;
>> +
>> +/// Driver use the GEM memory manager. This should be set for all modern
>> drivers.
>> +pub const FEAT_GEM: u32 = bindings::drm_driver_feature_DRIVER_GEM;
>> +/// Driver supports mode setting interfaces (KMS).
>> +pub const FEAT_MODESET: u32 = bindings::drm_driver_feature_DRIVER_MODESET;
>> +/// Driver supports dedicated render nodes.
>> +pub const FEAT_RENDER: u32 = bindings::drm_driver_feature_DRIVER_RENDER;
>> +/// Driver supports the full atomic modesetting userspace API.
>> +///
>> +/// Drivers which only use atomic internally, but do not support the full
>> userspace API (e.g. not
>> +/// all properties converted to atomic, or multi-plane updates are not
>> guaranteed to be tear-free)
>> +/// should not set this flag.
>> +pub const FEAT_ATOMIC: u32 = bindings::drm_driver_feature_DRIVER_ATOMIC;
>> +/// Driver supports DRM sync objects for explicit synchronization of
>> command submission.
>> +pub const FEAT_SYNCOBJ: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ;
>> +/// Driver supports the timeline flavor of DRM sync objects for explicit
>> synchronization of command
>> +/// submission.
>> +pub const FEAT_SYNCOBJ_TIMELINE: u32 =
>> bindings::drm_driver_feature_DRIVER_SYNCOBJ_TIMELINE;
>
> This is missing an entry for DRIVER_GEM_GPUVA. And some others perhaps.
> I suppose some are legacy which won't be needed any time soon if ever.
> Not sure if you intend for this to be complete, or you are just adding
> what you are using? Only FEAT_GEM is used by nova ATM.
>
This was developed before DRIVER_GEM_GPUVA existed ^^
I have this in my branch since I'm using the GPUVA manager now. Danilo,
what tree are you using for this submission? It would be good to
coordinate this and try to keep the WIP branches from diverging too much...
That said, I don't think there's reason to support all features unless
we expect new drivers to actually use them. The goal of the abstractions
is to serve the drivers that will use them, and to evolve together with
them and any newer drivers, not to attempt to be feature-complete from
the get go (it's very difficult to evaluate an abstraction if it has no
users!). In general my approach when writing them was to abstract what I
need and add "obvious" extra trivial features that didn't require much
thought even if I wasn't using them, but otherwise not attempt to
comprehensively cover everything.
~~ Lina
Re: [PATCH RFC 7/8] drm/sun4i: de3: Implement AFBC support
On Sat, 8 Jun 2024, at 2:32 AM, Andre Przywara wrote: >> Signed-off-by: Jernej Skrabec > This signature suggests that it's indeed Jernej's patch, so it should > have his authorship, as in the other patches, indicated by a line starting > with "From:" before the commit message. Thanks Andre, no this is Jernej's work, I have simply minimally refactored to as cleanly as possible just support the DE33 with this set, and added the device-tree binding docs. My mistake in my git client pulling in his patches, will correct authorship for v2. > "Co-developed-by:" is only used if the patch really has two authors, both > having contributed significantly to the patch. > If you merely post a patch from someone else, then it just needs your > Signed-off-by, as you correctly do below. > > That applies to the other patches as well. Thanks, noted. Will correct in v2. > Cheers, > Andre Regards, Ryan
[PATCH] staging: fbtft: add missing MODULE_DESCRIPTION() macro
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/fbtft/fbtft.o
Add the missing invocation of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/staging/fbtft/fbtft-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index c8d52c63d79f..8e2fd0c0fee2 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -1276,4 +1276,5 @@ void fbtft_remove_common(struct device *dev, struct
fb_info *info)
}
EXPORT_SYMBOL(fbtft_remove_common);
+MODULE_DESCRIPTION("Core FB support for small TFT LCD display modules");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240608-md-drivers-staging-fbtft-b724f0a0ce30
Re: [PATCH RFC 1/8] dt-bindings: bus: allwinner: add H616 DE33 bindings
On Sat, 8 Jun 2024, at 2:23 AM, Conor Dooley wrote: Thanks for the review! >> --- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml >> +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml >> @@ -25,6 +25,7 @@ properties: >>- const: allwinner,sun50i-a64-de2 >>- items: >>- const: allwinner,sun50i-h6-de3 >> + - const: allwinner,sun50i-h616-de33 >>- const: allwinner,sun50i-a64-de2 > > This does not do what you think it does! > It needs to be > items: > - enum: > - h6 > - h616 > - const: a64 > Thanks, will correct in v2. >> + - const: allwinner,sun50i-h616-de33-clk > > I think this is not right, as a corresponding driver change is missing. > Either you're missing a clock driver patch or you didn't test your dts. The clock driver patch with this compatible string is in patch 8/8. >>- allwinner,sun50i-h6-de3-mixer-0 >> + - allwinner,sun50i-h616-de33-mixer-0 > > Your commit message should mention why a fallback is not suitable here. Will do, thanks. > > Thanks, > Conor. > Regards, Ryan
Re: [PATCH v10 6/6] Documentation: iio: Document high-speed DMABUF based API
Hi Paul. On 6/7/24 12:44 AM, Paul Cercueil wrote: > Hi Randy, > > Le jeudi 06 juin 2024 à 10:32 -0700, Randy Dunlap a écrit : >> Hi, >> >> On 6/5/24 4:08 AM, Paul Cercueil wrote: >>> Document the new DMABUF based API. >>> >>> Signed-off-by: Paul Cercueil >>> Signed-off-by: Nuno Sa >>> >>> --- >>> v2: - Explicitly state that the new interface is optional and is >>> not implemented by all drivers. >>> - The IOCTLs can now only be called on the buffer FD returned >>> by >>> IIO_BUFFER_GET_FD_IOCTL. >>> - Move the page up a bit in the index since it is core stuff >>> and not >>> driver-specific. >>> >>> v3: Update the documentation to reflect the new API. >>> >>> v5: Use description lists for the documentation of the three new >>> IOCTLs >>> instead of abusing subsections. >>> >>> v8: Renamed dmabuf_api.rst -> iio_dmabuf_api.rst, and updated >>> index.rst >>> whose format changed in iio/togreg. >>> --- >>> Documentation/iio/iio_dmabuf_api.rst | 54 >>> >>> Documentation/iio/index.rst | 1 + >>> 2 files changed, 55 insertions(+) >>> create mode 100644 Documentation/iio/iio_dmabuf_api.rst >>> >>> diff --git a/Documentation/iio/iio_dmabuf_api.rst >>> b/Documentation/iio/iio_dmabuf_api.rst >>> new file mode 100644 >>> index ..1cd6cd51a582 >>> --- /dev/null >>> +++ b/Documentation/iio/iio_dmabuf_api.rst >>> @@ -0,0 +1,54 @@ >>> +.. SPDX-License-Identifier: GPL-2.0 >>> + >>> +=== >>> +High-speed DMABUF interface for IIO >>> +=== >>> + >>> +1. Overview >>> +=== >>> + >>> +The Industrial I/O subsystem supports access to buffers through a >>> +file-based interface, with read() and write() access calls through >>> the >>> +IIO device's dev node. >>> + >>> +It additionally supports a DMABUF based interface, where the >>> userspace >>> +can attach DMABUF objects (externally created) to a IIO buffer, >>> and >> >> I would say/write: to an IIO buffer, > > Right. > >>> +subsequently use them for data transfers. >>> + >>> +A userspace application can then use this interface to share >>> DMABUF >>> +objects between several interfaces, allowing it to transfer data >>> in a >>> +zero-copy fashion, for instance between IIO and the USB stack. >>> + >>> +The userspace application can also memory-map the DMABUF objects, >>> and >>> +access the sample data directly. The advantage of doing this vs. >>> the >>> +read() interface is that it avoids an extra copy of the data >>> between the >>> +kernel and userspace. This is particularly useful for high-speed >>> devices >>> +which produce several megabytes or even gigabytes of data per >>> second. >>> +It does however increase the userspace-kernelspace synchronization >>> +overhead, as the DMA_BUF_SYNC_START and DMA_BUF_SYNC_END IOCTLs >>> have to >>> +be used for data integrity. >>> + >>> +2. User API >>> +=== >>> + >>> +As part of this interface, three new IOCTLs have been added. These >>> three >>> +IOCTLs have to be performed on the IIO buffer's file descriptor, >>> +obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl. >>> + >>> + ``IIO_BUFFER_DMABUF_ATTACH_IOCTL(int)`` >> >> (int fd) >> ? > > Yes, I can change that. Although it's very obvious what the "int" is > for, given the text above. > Yes. This is just to be consistent with the text below: + ``IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *iio_dmabuf)`` >> >>> + Attach the DMABUF object, identified by its file descriptor, >>> to the >>> + IIO buffer. Returns zero on success, and a negative errno >>> value on >>> + error. >>> + >>> + ``IIO_BUFFER_DMABUF_DETACH_IOCTL(int)`` >> >> ditto. >> >>> + Detach the given DMABUF object, identified by its file >>> descriptor, >>> + from the IIO buffer. Returns zero on success, and a negative >>> errno >>> + value on error. >>> + >>> + Note that closing the IIO buffer's file descriptor will >>> + automatically detach all previously attached DMABUF objects. >>> + >>> + ``IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf >>> *iio_dmabuf)`` >>> + Enqueue a previously attached DMABUF object to the buffer >>> queue. >>> + Enqueued DMABUFs will be read from (if output buffer) or >>> written to >>> + (if input buffer) as long as the buffer is enabled. >> >> thanks. > > Cheers, > -Paul thanks. -- #Randy https://people.kernel.org/tglx/notes-about-netiquette https://subspace.kernel.org/etiquette.html
[PATCH] drm/msm/a6xx: request memory region
The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.
Implement the region-request through the corresponding managed
devres-function.
Signed-off-by: Kiarash Hajian
---
Changes in v6:
-Fix compile error
-Link to v5:
https://lore.kernel.org/all/20240607-memory-v1-1-8664f52fc...@gmail.com
Changes in v5:
- Fix error hanlding problems.
- Link to v4:
https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v4-1-3881a6408...@gmail.com
Changes in v4:
- Combine v3 commits into a singel commit
- Link to v3:
https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v3-0-0a728ad45...@gmail.com
Changes in v3:
- Remove redundant devm_iounmap calls, relying on devres for automatic
resource cleanup.
Changes in v2:
- update the subject prefix to "drm/msm/a6xx:", to match the majority of
other changes to this file.
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 8bea8ef26f77..d26cc6254ef9 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -525,7 +525,7 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
bool pdc_in_aop = false;
if (IS_ERR(pdcptr))
- goto err;
+ return;
if (adreno_is_a650(adreno_gpu) ||
adreno_is_a660_family(adreno_gpu) ||
@@ -541,7 +541,7 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
if (!pdc_in_aop) {
seqptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc_seq");
if (IS_ERR(seqptr))
- goto err;
+ return;
}
/* Disable SDE clock gating */
@@ -633,12 +633,6 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
wmb();
a6xx_rpmh_stop(gmu);
-
-err:
- if (!IS_ERR_OR_NULL(pdcptr))
- iounmap(pdcptr);
- if (!IS_ERR_OR_NULL(seqptr))
- iounmap(seqptr);
}
/*
@@ -1503,7 +1497,7 @@ static void __iomem *a6xx_gmu_get_mmio(struct
platform_device *pdev,
return ERR_PTR(-EINVAL);
}
- ret = ioremap(res->start, resource_size(res));
+ ret = devm_ioremap_resource(>dev, res);
if (!ret) {
DRM_DEV_ERROR(>dev, "Unable to map the %s registers\n",
name);
return ERR_PTR(-EINVAL);
@@ -1613,13 +1607,13 @@ int a6xx_gmu_wrapper_init(struct a6xx_gpu *a6xx_gpu,
struct device_node *node)
gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
if (IS_ERR(gmu->mmio)) {
ret = PTR_ERR(gmu->mmio);
- goto err_mmio;
+ goto err_cleanup;
}
gmu->cxpd = dev_pm_domain_attach_by_name(gmu->dev, "cx");
if (IS_ERR(gmu->cxpd)) {
ret = PTR_ERR(gmu->cxpd);
- goto err_mmio;
+ goto err_cleanup;
}
if (!device_link_add(gmu->dev, gmu->cxpd, DL_FLAG_PM_RUNTIME)) {
@@ -1635,7 +1629,7 @@ int a6xx_gmu_wrapper_init(struct a6xx_gpu *a6xx_gpu,
struct device_node *node)
gmu->gxpd = dev_pm_domain_attach_by_name(gmu->dev, "gx");
if (IS_ERR(gmu->gxpd)) {
ret = PTR_ERR(gmu->gxpd);
- goto err_mmio;
+ goto err_cleanup;
}
gmu->initialized = true;
@@ -1645,9 +1639,7 @@ int a6xx_gmu_wrapper_init(struct a6xx_gpu *a6xx_gpu,
struct device_node *node)
detach_cxpd:
dev_pm_domain_detach(gmu->cxpd, false);
-err_mmio:
- iounmap(gmu->mmio);
-
+err_cleanup:
/* Drop reference taken in of_find_device_by_node */
put_device(gmu->dev);
@@ -1762,7 +1754,7 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
gmu->rscc = a6xx_gmu_get_mmio(pdev, "rscc");
if (IS_ERR(gmu->rscc)) {
ret = -ENODEV;
- goto err_mmio;
+ goto err_cleanup;
}
} else {
gmu->rscc = gmu->mmio + 0x23000;
@@ -1774,13 +1766,13 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0) {
ret = -ENODEV;
- goto err_mmio;
+ goto err_cleanup;
}
gmu->cxpd = dev_pm_domain_attach_by_name(gmu->dev, "cx");
if (IS_ERR(gmu->cxpd)) {
ret = PTR_ERR(gmu->cxpd);
- goto err_mmio;
+ goto err_cleanup;
}
link = device_link_add(gmu->dev, gmu->cxpd, DL_FLAG_PM_RUNTIME);
@@ -1824,10 +1816,7 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
detach_cxpd:
dev_pm_domain_detach(gmu->cxpd, false);
-err_mmio:
-
Re: [PATCH v3 1/2] drm/rockchip: vop: clear DMA stop bit upon vblank on RK3066
Am Sonntag, 2. Juni 2024, 05:35:36 CEST schrieb Val Packett:
>
> On Mon, May 27 2024 at 20:11:49 -03:00:00, Val Packett
> wrote:
> > The RK3066 VOP sets a dma_stop bit when it's done scanning out a frame
> > and needs the driver to acknowledge that by clearing the bit.
> >
> > So unless we clear it "between" frames, the RGB output only shows
> > noise
> > instead of the picture. vblank seems to be the most appropriate place
> > to
> > do it, since it indicates exactly that: that the hardware is done
> > with the frame.
> >
> > This seems to be a redundant synchronization mechanism that was
> > removed
> > in later iterations of the VOP hardware block.
> >
> > Fixes: f4a6de8 ("drm: rockchip: vop: add rk3066 vop definitions")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Val Packett
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
> > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
> > 3 files changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index a13473b2d..2731fe2b2 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -1766,6 +1766,12 @@ static void vop_handle_vblank(struct vop *vop)
> > }
> > spin_unlock(>event_lock);
> >
> > + if (VOP_HAS_REG(vop, common, dma_stop)) {
> > + spin_lock(>reg_lock);
> > + VOP_REG_SET(vop, common, dma_stop, 0);
> > + spin_unlock(>reg_lock);
> > + }
> > +
>
> Oops… so doing it here actually causes deadlocks, unless we also
> change all other reg_lock usages to be spin_lock_irq/spin_unlock_irq.
>
> Not sure if doing that or going back to v1 would be better.
then please go back to v1 (as v4) :-) .
I.e. regular spinlock vs. spin_lock_irq will have performance
implications and this "feature" is a one-time only thing used
only on a more than 10 year old soc, so it really must not affect
stuff coming after it.
Heiko
[PATCH] drm/bridge: it6505: Fix potential NULL dereference
Smatch complains correctly that the NULL checking isn't consistent:
drivers/gpu/drm/bridge/ite-it6505.c:2583 it6505_poweron()
error: we previously assumed 'pdata->pwr18' could be null
(see line 2569)
Add a NULL check to prevent a NULL dereference on the error path.
Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.c
index 3f68c82888c2..4f01fadaec0f 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2580,7 +2580,8 @@ static int it6505_poweron(struct it6505 *it6505)
usleep_range(1000, 2000);
err = regulator_enable(pdata->ovdd);
if (err) {
- regulator_disable(pdata->pwr18);
+ if (pdata->pwr18)
+ regulator_disable(pdata->pwr18);
return err;
}
}
--
2.43.0
[PATCH v3 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature
Add tee client application which will be used for
HDCP 1.x and 2.x authentication in DisplayPort.
Changes in v3:
- remove useless define
- refine the return value
- remove the define which control the log output
- remove the struct hdcp2_handler for HDCP 2.X
- refine the struct for the HDCP information
per suggestion from the previous thread:
https://patchwork.kernel.org/project/linux-mediatek
/patch/20240205055055.25340-2-mac.s...@mediatek.com/
Signed-off-by: mac.shen
---
drivers/gpu/drm/mediatek/Makefile | 5 +-
drivers/gpu/drm/mediatek/tci.h | 143 ++
drivers/gpu/drm/mediatek/tlc_dp_hdcp.c | 595 +
drivers/gpu/drm/mediatek/tlc_dp_hdcp.h | 133 ++
4 files changed, 875 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/tci.h
create mode 100644 drivers/gpu/drm/mediatek/tlc_dp_hdcp.c
create mode 100644 drivers/gpu/drm/mediatek/tlc_dp_hdcp.h
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index 32a2ed6c0cfe..f27ddfbd2e12 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -27,4 +27,7 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
-obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk_dp.o
+mtk-dp-objs := tlc_dp_hdcp.o \
+ mtk_dp.o
+
+obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk-dp.o
diff --git a/drivers/gpu/drm/mediatek/tci.h b/drivers/gpu/drm/mediatek/tci.h
new file mode 100644
index ..48710ce5d391
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/tci.h
@@ -0,0 +1,143 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019-2024 MediaTek Inc.
+ */
+
+#ifndef _TCI_H_
+#define _TCI_H_
+
+#include
+
+#define CMD_DEVICE_ADDED1
+#define CMD_DEVICE_REMOVE 2
+#define CMD_WRITE_VAL 3
+#define CMD_DEVICE_CLEAN4
+#define CMD_ENABLE_ENCRYPT 5
+
+/* V1.x */
+#define CMD_CALCULATE_LM11
+#define CMD_COMPARE_R0 12
+#define CMD_COMPARE_V1 13
+#define CMD_GET_AKSV14
+
+/* V2.x */
+#define CMD_AKE_CERTIFICATE 20
+#define CMD_ENC_KM 21
+#define CMD_AKE_H_PRIME 22
+#define CMD_AKE_PARING 23
+#define CMD_LC_L_PRIME 24
+#define CMD_SKE_CAL_EKS 26
+#define CMD_COMPARE_V2 27
+#define CMD_COMPARE_M 28
+
+#define TYPE_HDCP_PARAM_AN 10
+#define TYPE_HDCP_PARAM_RST_1 11
+#define TYPE_HDCP_PARAM_RST_2 12
+#define TYPE_HDCP_ENABLE_ENCRYPT 13
+#define TYPE_HDCP_DISABLE_ENCRYPT 14
+
+/* reserved:2 */
+#define HDCP2_CERTRX_LEN (HDCP_2_2_RECEIVER_ID_LEN + HDCP_2_2_K_PUB_RX_LEN + \
+ 2 + HDCP_2_2_DCP_LLC_SIG_LEN)
+/* version:1 */
+#define HDCP_2_2_TXCAPS_LEN (HDCP_2_2_TXCAP_MASK_LEN + 1)
+#define PARAM_LEN 1024
+
+#define TCI_LENGTH sizeof(struct tci_t)
+
+struct cmd_hdcp_init_for_verion_t {
+ u32 version;
+ bool need_load_key;
+};
+
+struct cmd_hdcp_write_val_t {
+ u8 type;
+ u8 len;
+ u8 val[DRM_HDCP_AN_LEN];
+};
+
+struct cmd_hdcp_calculate_lm_t {
+ u8 bksv[DRM_HDCP_KSV_LEN];
+};
+
+struct cmd_hdcp_get_aksv_t {
+ u8 aksv[DRM_HDCP_KSV_LEN];
+};
+
+struct cmd_hdcp_ake_certificate_t {
+ u8 certification[HDCP2_CERTRX_LEN];
+ bool stored;
+ u8 m[HDCP_2_2_E_KH_KM_M_LEN - HDCP_2_2_E_KH_KM_LEN];
+ u8 ekm[HDCP_2_2_E_KH_KM_LEN];
+};
+
+struct cmd_hdcp_ake_paring_t {
+ u8 ekm[HDCP_2_2_E_KH_KM_LEN];
+};
+
+struct cmd_hdcp_enc_km_t {
+ u8 enc_km[HDCP_2_2_E_KPUB_KM_LEN];
+};
+
+struct cmd_hdcp_ake_h_prime_t {
+ u8 rtx[HDCP_2_2_RTX_LEN];
+ u8 rrx[HDCP_2_2_RRX_LEN];
+ u8 rx_caps[HDCP_2_2_RXCAPS_LEN];
+ u8 tx_caps[HDCP_2_2_TXCAPS_LEN];
+ u32 rx_h_len;
+ u8 rx_h[HDCP_2_2_H_PRIME_LEN];
+};
+
+struct cmd_hdcp_lc_l_prime_t {
+ u8 rn[HDCP_2_2_RN_LEN];
+ u32 rx_l_len;
+ u8 rx_l[HDCP_2_2_L_PRIME_LEN];
+};
+
+struct cmd_hdcp_ske_eks_t {
+ u8 riv[HDCP_2_2_RIV_LEN];
+ u32 eks_len;
+ u32 eks;
+};
+
+struct cmd_hdcp_compare_t {
+ u32 rx_val_len;
+ u8 rx_val[HDCP_2_2_MPRIME_LEN];
+ u32 param_len;
+ u8 param[PARAM_LEN];
+ u32 out_len;
+ u32 out;
+};
+
+union tci_cmd_body_t {
+ /* Init with special HDCP version */
+ struct cmd_hdcp_init_for_verion_t cmd_hdcp_init_for_verion;
+ /* Write uint32 data to hw */
+ struct cmd_hdcp_write_val_t cmd_hdcp_write_val;
+ /* Get aksv */
+ struct cmd_hdcp_get_aksv_t cmd_hdcp_get_aksv;
+ /* Calculate r0 */
+ struct cmd_hdcp_calculate_lm_t cmd_hdcp_calculate_lm;
+ /* Generate signature for certificate */
+ struct cmd_hdcp_ake_certificate_t cmd_hdcp_ake_certificate;
+ /* To store ekm */
+ struct cmd_hdcp_ake_paring_t cmd_hdcp_ake_paring;
+ /* Encrypt km for V2.2 */
+ struct cmd_hdcp_enc_km_t cmd_hdcp_enc_km;
+ /* Compute H prime */
+ struct cmd_hdcp_ake_h_prime_t cmd_hdcp_ake_h_prime
[PATCH v3 0/3] Add HDCP feature for DisplayPort
Add tee client application, HDCP 1.x and 2.x authentication for DisplayPort to support the HDCP feature. mac.shen (3): Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort Subject: [PATCH] drm/mediatek/dp: Add HDCP1.x feature for DisplayPort drivers/gpu/drm/mediatek/Makefile| 7 +- drivers/gpu/drm/mediatek/mtk_dp.c| 332 ++-- drivers/gpu/drm/mediatek/mtk_dp.h| 103 +++ drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c | 577 ++ drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.h | 17 + drivers/gpu/drm/mediatek/mtk_dp_hdcp2.c | 944 +++ drivers/gpu/drm/mediatek/mtk_dp_hdcp2.h | 25 + drivers/gpu/drm/mediatek/mtk_dp_reg.h| 11 +- drivers/gpu/drm/mediatek/mtk_dpi.c | 3 + drivers/gpu/drm/mediatek/tci.h | 143 drivers/gpu/drm/mediatek/tlc_dp_hdcp.c | 595 ++ drivers/gpu/drm/mediatek/tlc_dp_hdcp.h | 133 12 files changed, 2805 insertions(+), 85 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.h create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.h create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.c create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.h create mode 100644 drivers/gpu/drm/mediatek/tci.h create mode 100644 drivers/gpu/drm/mediatek/tlc_dp_hdcp.c create mode 100644 drivers/gpu/drm/mediatek/tlc_dp_hdcp.h -- 2.43.0
[PATCH v3 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort
Changes in v3:
- refine the function to get system time
- refine the flow to do HDCP with content type and
protection value which set by user space
- refine the flow to update content protection
- refine the flow to do HDCP2.x authentication
per suggestion from the previous thread:
https://patchwork.kernel.org/project/linux-mediatek
/patch/20240205055055.25340-3-mac.s...@mediatek.com/
Signed-off-by: mac.shen
---
drivers/gpu/drm/mediatek/Makefile | 1 +
drivers/gpu/drm/mediatek/mtk_dp.c | 321 +---
drivers/gpu/drm/mediatek/mtk_dp.h | 103 +++
drivers/gpu/drm/mediatek/mtk_dp_hdcp2.c | 944
drivers/gpu/drm/mediatek/mtk_dp_hdcp2.h | 25 +
drivers/gpu/drm/mediatek/mtk_dp_reg.h | 8 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 3 +
7 files changed, 1321 insertions(+), 84 deletions(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.h
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index f27ddfbd2e12..19b7625ae573 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -28,6 +28,7 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
mtk-dp-objs := tlc_dp_hdcp.o \
+ mtk_dp_hdcp2.o \
mtk_dp.o
obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk-dp.o
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 536366956447..12854a04622f 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (c) 2019-2022 MediaTek Inc.
+ * Copyright (c) 2019-2024 MediaTek Inc.
* Copyright (c) 2022 BayLibre
*/
@@ -8,13 +8,13 @@
#include
#include
#include
-#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -30,10 +30,10 @@
#include
#include
#include
-#include
-#include
+#include "mtk_dp.h"
#include "mtk_dp_reg.h"
+#include "mtk_dp_hdcp2.h"
#define MTK_DP_SIP_CONTROL_AARCH32 MTK_SIP_SMC_CMD(0x523)
#define MTK_DP_SIP_ATF_EDP_VIDEO_UNMUTE(BIT(0) | BIT(5))
@@ -52,43 +52,6 @@
#define MTK_DP_VERSION 0x11
#define MTK_DP_SDP_AUI 0x4
-enum {
- MTK_DP_CAL_GLB_BIAS_TRIM = 0,
- MTK_DP_CAL_CLKTX_IMPSE,
- MTK_DP_CAL_LN_TX_IMPSEL_PMOS_0,
- MTK_DP_CAL_LN_TX_IMPSEL_PMOS_1,
- MTK_DP_CAL_LN_TX_IMPSEL_PMOS_2,
- MTK_DP_CAL_LN_TX_IMPSEL_PMOS_3,
- MTK_DP_CAL_LN_TX_IMPSEL_NMOS_0,
- MTK_DP_CAL_LN_TX_IMPSEL_NMOS_1,
- MTK_DP_CAL_LN_TX_IMPSEL_NMOS_2,
- MTK_DP_CAL_LN_TX_IMPSEL_NMOS_3,
- MTK_DP_CAL_MAX,
-};
-
-struct mtk_dp_train_info {
- bool sink_ssc;
- bool cable_plugged_in;
- /* link_rate is in multiple of 0.27Gbps */
- int link_rate;
- int lane_count;
- unsigned int channel_eq_pattern;
-};
-
-struct mtk_dp_audio_cfg {
- bool detect_monitor;
- int sad_count;
- int sample_rate;
- int word_length_bits;
- int channels;
-};
-
-struct mtk_dp_info {
- enum dp_pixelformat format;
- struct videomode vm;
- struct mtk_dp_audio_cfg audio_cur_cfg;
-};
-
struct mtk_dp_efuse_fmt {
unsigned short idx;
unsigned short shift;
@@ -98,44 +61,6 @@ struct mtk_dp_efuse_fmt {
unsigned short default_val;
};
-struct mtk_dp {
- bool enabled;
- bool need_debounce;
- int irq;
- u8 max_lanes;
- u8 max_linkrate;
- u8 rx_cap[DP_RECEIVER_CAP_SIZE];
- u32 cal_data[MTK_DP_CAL_MAX];
- u32 irq_thread_handle;
- /* irq_thread_lock is used to protect irq_thread_handle */
- spinlock_t irq_thread_lock;
-
- struct device *dev;
- struct drm_bridge bridge;
- struct drm_bridge *next_bridge;
- struct drm_connector *conn;
- struct drm_device *drm_dev;
- struct drm_dp_aux aux;
-
- const struct mtk_dp_data *data;
- struct mtk_dp_info info;
- struct mtk_dp_train_info train_info;
-
- struct platform_device *phy_dev;
- struct phy *phy;
- struct regmap *regs;
- struct timer_list debounce_timer;
-
- /* For audio */
- bool audio_enable;
- hdmi_codec_plugged_cb plugged_cb;
- struct platform_device *audio_pdev;
-
- struct device *codec_dev;
- /* protect the plugged_cb as it's used in both bridge ops and audio */
- struct mutex update_plugged_status_lock;
-};
-
struct mtk_dp_data {
int bridge_type;
unsigned int smc_cmd;
@@ -319,12 +244,24 @@ static struct regmap_config mtk_dp_regmap_config = {
.name = "mtk-dp-registers",
};
+u64 mtk_dp_get_system_time(void)
+{
+ return ktime_get_mono_fast_ns();
+}
+
+u64 mtk_dp_get_time_dif
[PATCH v3 3/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP1.x feature for DisplayPort
Changes in v3:
- remove useless code
- remove magic number
- refine the flow to do HDCP1.x authentication
per suggestion from the previous thread:
https://patchwork.kernel.org/project/linux-mediatek
/patch/20240205055055.25340-4-mac.s...@mediatek.com/
Signed-off-by: mac.shen
---
drivers/gpu/drm/mediatek/Makefile| 1 +
drivers/gpu/drm/mediatek/mtk_dp.c| 11 +
drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c | 577 +++
drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.h | 17 +
drivers/gpu/drm/mediatek/mtk_dp_reg.h| 3 +
5 files changed, 609 insertions(+)
create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.h
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index 19b7625ae573..a90c3294bfbe 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -28,6 +28,7 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
mtk-dp-objs := tlc_dp_hdcp.o \
+ mtk_dp_hdcp1x.o \
mtk_dp_hdcp2.o \
mtk_dp.o
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 12854a04622f..3925eb2be064 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -33,6 +33,7 @@
#include "mtk_dp.h"
#include "mtk_dp_reg.h"
+#include "mtk_dp_hdcp1x.h"
#include "mtk_dp_hdcp2.h"
#define MTK_DP_SIP_CONTROL_AARCH32 MTK_SIP_SMC_CMD(0x523)
@@ -1841,6 +1842,7 @@ static int mtk_dp_hpd_sink_event(struct mtk_dp *mtk_dp)
static void mtk_dp_hdcp_get_info(struct mtk_dp *mtk_dp)
{
dp_tx_hdcp2x_get_info(_dp->hdcp_info);
+ dp_tx_hdcp1x_get_info(_dp->hdcp_info);
}
static void mtk_dp_hdcp_disable(struct mtk_dp *mtk_dp)
@@ -1852,6 +1854,8 @@ static void mtk_dp_hdcp_disable(struct mtk_dp *mtk_dp)
if (mtk_dp->hdcp_info.auth_version == HDCP_VERSION_2X)
dp_tx_hdcp2x_disabel(_dp->hdcp_info);
+ else if (mtk_dp->hdcp_info.auth_version == HDCP_VERSION_1X)
+ dp_tx_hdcp1x_disabel(_dp->hdcp_info);
end:
cancel_delayed_work_sync(_dp->check_work);
@@ -1868,6 +1872,9 @@ static void mtk_dp_hdcp_check_work(struct work_struct
*work)
if (mtk_dp->hdcp_info.auth_version == HDCP_VERSION_2X &&
(!dp_tx_hdcp2x_check_link(_dp->hdcp_info))) {
schedule_delayed_work(_dp->check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
+ } else if (mtk_dp->hdcp_info.auth_version == HDCP_VERSION_1X &&
+ (!dp_tx_hdcp1x_check_link(_dp->hdcp_info))) {
+ schedule_delayed_work(_dp->check_work,
DRM_HDCP_CHECK_PERIOD_MS);
}
}
@@ -1890,6 +1897,10 @@ static void mtk_dp_hdcp_handle(struct work_struct *data)
check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
}
+ if (ret && mtk_dp->hdcp_info.hdcp1x_info.capable &&
+ mtk_dp->hdcp_info.hdcp_content_type != DRM_MODE_HDCP_CONTENT_TYPE1)
+ ret = dp_tx_hdcp1x_enable(_dp->hdcp_info);
+
if (!ret) {
schedule_delayed_work(_dp->check_work, check_link_interval);
mtk_dp_hdcp_update_value(mtk_dp,
DRM_MODE_CONTENT_PROTECTION_ENABLED);
diff --git a/drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c
b/drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c
new file mode 100644
index ..0fcf23c378df
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c
@@ -0,0 +1,577 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019-2024 MediaTek Inc.
+ */
+
+#include
+
+#include "mtk_dp_hdcp1x.h"
+#include "mtk_dp_reg.h"
+#include "mtk_dp.h"
+
+#define HDCP1X_R0_WDT 100
+#define HDCP1X_REP_RDY_WDT 5000
+
+static void dp_tx_hdcp1x_start_cipher(struct mtk_hdcp_info *hdcp_info, bool
enable)
+{
+ struct mtk_dp *mtk_dp = container_of(hdcp_info, struct mtk_dp,
hdcp_info);
+
+ if (enable) {
+ mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3480,
REQ_BLOCK_CIPHER_AUTH,
+ REQ_BLOCK_CIPHER_AUTH);
+ mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3480, KM_GENERATED,
KM_GENERATED);
+ } else {
+ mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3480, 0,
KM_GENERATED);
+ mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3480, 0,
REQ_BLOCK_CIPHER_AUTH);
+ }
+}
+
+static bool dp_tx_hdcp1x_get_r0_available(struct mtk_hdcp_info *hdcp_info)
+{
+ struct mtk_dp *mtk_dp = container_of(hdcp_info, struct mtk_dp,
hdcp_info);
+ bool R0_available;
+ u32 ret;
+
+ ret = mtk_dp_read(mtk_dp, MTK_DP_TRANS_P0_34A4);
+ if (ret & R0_AVAILABLE_DP_TRANS_P0)
+ R0_available = true;
+ else
+ R0_availabl
Subject: [PATCH] drm/panel : truly-nt35521: transition to mipi_dsi wrapped functions
Use functions introduced in 966e397e4f603 ("drm/mipi-dsi: Introduce
mipi_dsi_*_write_seq_multi()") and f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for the
sony tulip truly nt35521 panel.
Signed-off-by: Tejas Vipin
---
.../panel/panel-sony-tulip-truly-nt35521.c| 383 +-
1 file changed, 183 insertions(+), 200 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..13472c7c37f5 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,231 @@ 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;
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,
+ struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi };
+
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xf0, 0x55, 0xaa, 0x52,
0x08, 0x00);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xff, 0xaa, 0x55, 0xa5,
0x80);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0x6f, 0x11, 0x00);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xf7, 0x20, 0x00);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0x6f, 0x01);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb1, 0x21);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xbd, 0x01, 0xa0, 0x10,
0x08, 0x01);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb8, 0x01, 0x02, 0x0c,
0x02);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xbb, 0x11, 0x11);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xbc, 0x00, 0x00);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb6, 0x02);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xf0, 0x55, 0xaa, 0x52,
0x08, 0x01);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb0, 0x09, 0x09);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb1, 0x09, 0x09);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xbc, 0x8c, 0x00);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xbd, 0x8c, 0x00);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xca, 0x00);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xc0, 0x04);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xbe, 0xb5);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb3, 0x35, 0x35);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb4, 0x25, 0x25);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb9, 0x43, 0x43);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xba, 0x24, 0x24);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xf0, 0x55, 0xaa, 0x52,
0x08, 0x02);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xee, 0x03);
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb0,
0x00, 0xb2, 0x00, 0xb3, 0x00, 0xb6, 0x00,
0xc3,
0x00, 0xce, 0x00, 0xe1, 0x00, 0xf3, 0x01,
0x11);
- mipi_dsi_generic_write_seq(dsi, 0xb1,
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb1,
0x01, 0x2e, 0x01, 0x5c, 0x01, 0x82, 0x01,
0xc3,
0x01, 0xfe, 0x02, 0x00, 0x02, 0x37, 0x02,
0x77);
- mipi_dsi_generic_write_seq(dsi, 0xb2,
+ mipi_dsi_generic_write_seq_multi(_ctx, 0xb2,
0x02, 0xa1, 0x02, 0xd7, 0x02, 0xfe, 0x03,
0x2c,
[PATCH] drm/panel : himax-hx83102: fix incorrect argument to mipi_dsi_msleep
From: Tejas Vipin Subject: [PATCH] drm/panel : himax-hx83102: fix incorrect argument to mipi_dsi_msleep mipi_dsi_msleep expects struct mipi_dsi_multi_context to be passed as a value and not as a reference. Signed-off-by: Tejas Vipin --- drivers/gpu/drm/panel/panel-himax-hx83102.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c b/drivers/gpu/drm/panel/panel-himax-hx83102.c index 6009a3fe1b8f..ab00fd92cce0 100644 --- a/drivers/gpu/drm/panel/panel-himax-hx83102.c +++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c @@ -479,7 +479,7 @@ static int hx83102_disable(struct drm_panel *panel) mipi_dsi_dcs_set_display_off_multi(_ctx); mipi_dsi_dcs_enter_sleep_mode_multi(_ctx); - mipi_dsi_msleep(_ctx, 150); + mipi_dsi_msleep(dsi_ctx, 150); return dsi_ctx.accum_err; } -- 2.45.2
Re: [PATCH v4 08/13] drm/msm/dpu: add support for virtual planes
On 6/7/2024 5:57 PM, Dmitry Baryshkov wrote:
On Sat, 8 Jun 2024 at 02:55, Abhinav Kumar wrote:
On 6/7/2024 3:26 PM, Dmitry Baryshkov wrote:
On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar wrote:
On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV playback.
To solve this problem make all planes virtual. Each plane is registered
as if it supports all possible features, but then at the runtime during
the atomic_check phase the driver selects backing SSPP block for each
plane.
Note, this does not provide support for using two different SSPP blocks
for a single plane or using two rectangles of an SSPP to drive two
planes. Each plane still gets its own SSPP and can utilize either a solo
rectangle or both multirect rectangles depending on the resolution.
Note #2: By default support for virtual planes is turned off and the
driver still uses old code path with preallocated SSPP block for each
plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
kernel parameter.
I like the overall approach in this patch. Some comments below.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 230 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 19 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 77
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 28 +++
7 files changed, 390 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 88c2e51ab166..794c5643584f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1168,6 +1168,49 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
return false;
}
+static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct
drm_crtc_state *crtc_state)
+{
+ int total_planes = crtc->dev->mode_config.num_total_plane;
+ struct drm_atomic_state *state = crtc_state->state;
+ struct dpu_global_state *global_state;
+ struct drm_plane_state **states;
+ struct drm_plane *plane;
+ int ret;
+
+ global_state = dpu_kms_get_global_state(crtc_state->state);
+ if (IS_ERR(global_state))
+ return PTR_ERR(global_state);
+
+ dpu_rm_release_all_sspp(global_state, crtc);
+
Do we need to call dpu_rm_release_all_sspp() even in the
_dpu_plane_atomic_disable()?
It allows the driver to optimize the usage of the SSPP rectangles.
No, what I meant was that we should call dpu_rm_release_all_sspp() in
dpu_plane_atomic_update() as well because in the atomic_check() path where
its called today, its being called only for zpos_changed and planes_changed
but during disable we must call this for sure.
No. the dpu_rm_release_all_sspp() should only be called during check.
When dpu_plane_atomic_update() is called, the state should already be
finalised. The atomic_check() callback is called when a plane is going
to be disabled.
atomic_check() will be called when plane is disabled but
dpu_rm_release_all_sspp() may not be called as it is protected by
zpos_changed and planes_changed. OR you need to add a !visible check
here to call dpu_rm_release_all_sspp() that time. Thats whay I wrote
previously.
Unless I miss something, if a plane gets disabled, then obviously
planes_changed is true.
[trimmed]
Do you mean DRM fwk sets planes_changed correctly for this case?
Currently we have
if (!new_state->visible) {
_dpu_plane_atomic_disable(plane);
} else {
dpu_plane_sspp_atomic_update(plane);
}
So I wanted to ensure that when plane gets disabled, its SSPP is freed
too. If this is confirmed, I do not have any concerns.
This is the atomic_update() path, not the atomic_check()
Yes, I am aware.
Let me clarify my question here once again.
1) dpu_rm_release_all_sspp() gets called only in atomic_check() when
either planes_changed or zpos_changed is set
2) But even in _dpu_plane_atomic_disable(), we should call
dpu_rm_release_all_sspp() unconditionally. So for this, as you wrote,
the corresponding atomic_check() call of _dpu_plane_atomic_disable() is
supposed to do this. atomic
Re: [PATCH v4 08/13] drm/msm/dpu: add support for virtual planes
On Sat, 8 Jun 2024 at 02:55, Abhinav Kumar wrote:
>
>
>
> On 6/7/2024 3:26 PM, Dmitry Baryshkov wrote:
> > On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
> >>> On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
> >>>>
> >>>>
> >>>> On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
> >>>>> On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
> >>>>>> On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> >>>>>>> Only several SSPP blocks support such features as YUV output or
> >>>>>>> scaling,
> >>>>>>> thus different DRM planes have different features. Properly utilizing
> >>>>>>> all planes requires the attention of the compositor, who should
> >>>>>>> prefer simpler planes to YUV-supporting ones. Otherwise it is very
> >>>>>>> easy
> >>>>>>> to end up in a situation when all featureful planes are already
> >>>>>>> allocated for simple windows, leaving no spare plane for YUV playback.
> >>>>>>>
> >>>>>>> To solve this problem make all planes virtual. Each plane is
> >>>>>>> registered
> >>>>>>> as if it supports all possible features, but then at the runtime
> >>>>>>> during
> >>>>>>> the atomic_check phase the driver selects backing SSPP block for each
> >>>>>>> plane.
> >>>>>>>
> >>>>>>> Note, this does not provide support for using two different SSPP
> >>>>>>> blocks
> >>>>>>> for a single plane or using two rectangles of an SSPP to drive two
> >>>>>>> planes. Each plane still gets its own SSPP and can utilize either a
> >>>>>>> solo
> >>>>>>> rectangle or both multirect rectangles depending on the resolution.
> >>>>>>>
> >>>>>>> Note #2: By default support for virtual planes is turned off and the
> >>>>>>> driver still uses old code path with preallocated SSPP block for each
> >>>>>>> plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
> >>>>>>> kernel parameter.
> >>>>>>>
> >>>>>>
> >>>>>> I like the overall approach in this patch. Some comments below.
> >>>>>>
> >>>>>>> Signed-off-by: Dmitry Baryshkov
> >>>>>>> ---
> >>>>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 +
> >>>>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +-
> >>>>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
> >>>>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 230
> >>>>>>> +++---
> >>>>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 19 ++
> >>>>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 77
> >>>>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 28 +++
> >>>>>>> 7 files changed, 390 insertions(+), 28 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >>>>>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >>>>>>> index 88c2e51ab166..794c5643584f 100644
> >>>>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >>>>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >>>>>>> @@ -1168,6 +1168,49 @@ static bool dpu_crtc_needs_dirtyfb(struct
> >>>>>>> drm_crtc_state *cstate)
> >>>>>>>return false;
> >>>>>>> }
> >>>>>>> +static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct
> >>>>>>> drm_crtc_state *crtc_state)
> >>>>>>> +{
> >>>>>>> + int total_planes = crtc->dev->mode_config.num_total_plane;
> >>>>>>> + struct drm_atomic_state *state = crtc_state->state;
> >>>>>>> + struct dpu_global_state *global_state;
> >>>>>>> + struct d
Re: [PATCH v3 1/4] drm/sched: store the drm_device instead of the device
Hi Pierre-Eric,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.10-rc2 next-20240607]
[cannot apply to drm-xe/drm-xe-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Pierre-Eric-Pelloux-Prayer/drm-sched-store-the-drm_device-instead-of-the-device/20240606-211050
base: linus/master
patch link:
https://lore.kernel.org/r/20240606130629.214827-2-pierre-eric.pelloux-prayer%40amd.com
patch subject: [PATCH v3 1/4] drm/sched: store the drm_device instead of the
device
config: arm64-allmodconfig
(https://download.01.org/0day-ci/archive/20240608/202406080802.exih6nc2-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
d7d2d4f53fc79b4b58e8d8d08151b577c3699d4a)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240608/202406080802.exih6nc2-...@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/202406080802.exih6nc2-...@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/imagination/pvr_queue.c:8:
In file included from drivers/gpu/drm/imagination/pvr_context.h:17:
In file included from drivers/gpu/drm/imagination/pvr_device.h:9:
In file included from drivers/gpu/drm/imagination/pvr_fw.h:8:
In file included from drivers/gpu/drm/imagination/pvr_fw_trace.h:7:
In file included from include/drm/drm_file.h:39:
In file included from include/drm/drm_prime.h:37:
In file included from include/linux/scatterlist.h:8:
In file included from include/linux/mm.h:2253:
include/linux/vmstat.h:500:43: error: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Werror,-Wenum-enum-conversion]
500 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
501 |item];
|
include/linux/vmstat.h:507:43: error: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Werror,-Wenum-enum-conversion]
507 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
508 |NR_VM_NUMA_EVENT_ITEMS +
|~~
include/linux/vmstat.h:514:36: error: arithmetic between different
enumeration types ('enum node_stat_item' and 'enum lru_list')
[-Werror,-Wenum-enum-conversion]
514 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
| ~~~ ^ ~~~
include/linux/vmstat.h:519:43: error: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Werror,-Wenum-enum-conversion]
519 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
520 |NR_VM_NUMA_EVENT_ITEMS +
|~~
include/linux/vmstat.h:528:43: error: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Werror,-Wenum-enum-conversion]
528 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
529 |NR_VM_NUMA_EVENT_ITEMS +
|~~
>> drivers/gpu/drm/imagination/pvr_queue.c:807:10: error: incompatible pointer
>> types passing 'struct drm_device *' to parameter of type 'const struct
>> device *' [-Werror,-Wincompatible-pointer-types]
807 | dev_err(sched->dev, "Job timeout\n");
| ^~
include/linux/dev_printk.h:154:44: note: expanded from macro 'dev_err'
154 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt),
##__VA_ARGS__)
| ^~~
include/linux/dev_printk.h:110:11: note: expanded from macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
include/linux/dev_printk.h:50:36: note: passing argument to parameter 'dev'
here
50 | void _dev_err(const struct device *dev, const char *fmt, ...);
|^
6 errors generated.
vim +807 drivers/gpu/drm/imagi
Re: [PATCH v4 08/13] drm/msm/dpu: add support for virtual planes
On 6/7/2024 3:26 PM, Dmitry Baryshkov wrote:
On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar wrote:
On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV playback.
To solve this problem make all planes virtual. Each plane is registered
as if it supports all possible features, but then at the runtime during
the atomic_check phase the driver selects backing SSPP block for each
plane.
Note, this does not provide support for using two different SSPP blocks
for a single plane or using two rectangles of an SSPP to drive two
planes. Each plane still gets its own SSPP and can utilize either a solo
rectangle or both multirect rectangles depending on the resolution.
Note #2: By default support for virtual planes is turned off and the
driver still uses old code path with preallocated SSPP block for each
plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
kernel parameter.
I like the overall approach in this patch. Some comments below.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 230 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 19 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 77
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 28 +++
7 files changed, 390 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 88c2e51ab166..794c5643584f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1168,6 +1168,49 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
return false;
}
+static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct
drm_crtc_state *crtc_state)
+{
+ int total_planes = crtc->dev->mode_config.num_total_plane;
+ struct drm_atomic_state *state = crtc_state->state;
+ struct dpu_global_state *global_state;
+ struct drm_plane_state **states;
+ struct drm_plane *plane;
+ int ret;
+
+ global_state = dpu_kms_get_global_state(crtc_state->state);
+ if (IS_ERR(global_state))
+ return PTR_ERR(global_state);
+
+ dpu_rm_release_all_sspp(global_state, crtc);
+
Do we need to call dpu_rm_release_all_sspp() even in the
_dpu_plane_atomic_disable()?
It allows the driver to optimize the usage of the SSPP rectangles.
No, what I meant was that we should call dpu_rm_release_all_sspp() in
dpu_plane_atomic_update() as well because in the atomic_check() path where
its called today, its being called only for zpos_changed and planes_changed
but during disable we must call this for sure.
No. the dpu_rm_release_all_sspp() should only be called during check.
When dpu_plane_atomic_update() is called, the state should already be
finalised. The atomic_check() callback is called when a plane is going
to be disabled.
atomic_check() will be called when plane is disabled but
dpu_rm_release_all_sspp() may not be called as it is protected by
zpos_changed and planes_changed. OR you need to add a !visible check
here to call dpu_rm_release_all_sspp() that time. Thats whay I wrote
previously.
Unless I miss something, if a plane gets disabled, then obviously
planes_changed is true.
[trimmed]
Do you mean DRM fwk sets planes_changed correctly for this case?
Currently we have
if (!new_state->visible) {
_dpu_plane_atomic_disable(plane);
} else {
dpu_plane_sspp_atomic_update(plane);
}
So I wanted to ensure that when plane gets disabled, its SSPP is freed
too. If this is confirmed, I do not have any concerns.
@@ -1486,7 +1593,7 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
supported_rotations = DRM_MODE_REFLECT_MASK | DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_180;
- if (pipe_hw->cap->features & BIT(DPU_SSPP_INLINE_ROTATION))
+ if (inline_rotation)
supported_rotations |= DRM_MODE_ROTATE_MASK;
drm_plane_create_rotation_property(plane,
@@ -1494,10 +1601,81 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
drm_plane_enable_fb_damage_clips(plane);
- /* success! finalize initialization */
+ DPU_DEBUG("%s creat
Re: [RFC PATCH 7/8] rust: add firmware abstractions
On Fri, 7 Jun 2024 19:55:49 +0200 Danilo Krummrich wrote: > On Fri, Jun 07, 2024 at 05:41:11PM +0200, Greg KH wrote: >> On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote: >> > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: >> > > Anyway, that's all hand-wavy right now, sorry, to get back to the point >> > > here, again, let's take this, which will allow the firmware bindings to >> > > be resubmitted and hopefully accepted, and we can move forward from >> > > there to "real" things like a USB or PCI or even platform device and >> > > driver binding stuff. >> > >> > In order to continue I propose to send out the following series: >> > >> > 1) minimal device and firmware abstractions only >> >> Sounds good. > > Just a heads-up, I'll probably send this one quite a bit earlier than the > other > two to make sure to unblock Fujita on their PHY driver. Please. The sooner, the better. I need to send the PHY driver with these patchse to netdev. I'm not sure what the above "minimal device" means. If you send the original patch again instead of the patch that Greg already approved and the discussion continues, then I proceed with the approved patch.
Re: [PATCH v4 08/13] drm/msm/dpu: add support for virtual planes
On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar wrote:
>
>
>
> On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
> > On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
> >>
> >>
> >> On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
> >>> On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
> >>>> On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> >>>>> Only several SSPP blocks support such features as YUV output or scaling,
> >>>>> thus different DRM planes have different features. Properly utilizing
> >>>>> all planes requires the attention of the compositor, who should
> >>>>> prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
> >>>>> to end up in a situation when all featureful planes are already
> >>>>> allocated for simple windows, leaving no spare plane for YUV playback.
> >>>>>
> >>>>> To solve this problem make all planes virtual. Each plane is registered
> >>>>> as if it supports all possible features, but then at the runtime during
> >>>>> the atomic_check phase the driver selects backing SSPP block for each
> >>>>> plane.
> >>>>>
> >>>>> Note, this does not provide support for using two different SSPP blocks
> >>>>> for a single plane or using two rectangles of an SSPP to drive two
> >>>>> planes. Each plane still gets its own SSPP and can utilize either a solo
> >>>>> rectangle or both multirect rectangles depending on the resolution.
> >>>>>
> >>>>> Note #2: By default support for virtual planes is turned off and the
> >>>>> driver still uses old code path with preallocated SSPP block for each
> >>>>> plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
> >>>>> kernel parameter.
> >>>>>
> >>>>
> >>>> I like the overall approach in this patch. Some comments below.
> >>>>
> >>>>> Signed-off-by: Dmitry Baryshkov
> >>>>> ---
> >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 +
> >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +-
> >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
> >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 230
> >>>>> +++---
> >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 19 ++
> >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 77
> >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 28 +++
> >>>>> 7 files changed, 390 insertions(+), 28 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >>>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >>>>> index 88c2e51ab166..794c5643584f 100644
> >>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >>>>> @@ -1168,6 +1168,49 @@ static bool dpu_crtc_needs_dirtyfb(struct
> >>>>> drm_crtc_state *cstate)
> >>>>> return false;
> >>>>> }
> >>>>> +static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct
> >>>>> drm_crtc_state *crtc_state)
> >>>>> +{
> >>>>> + int total_planes = crtc->dev->mode_config.num_total_plane;
> >>>>> + struct drm_atomic_state *state = crtc_state->state;
> >>>>> + struct dpu_global_state *global_state;
> >>>>> + struct drm_plane_state **states;
> >>>>> + struct drm_plane *plane;
> >>>>> + int ret;
> >>>>> +
> >>>>> + global_state = dpu_kms_get_global_state(crtc_state->state);
> >>>>> + if (IS_ERR(global_state))
> >>>>> + return PTR_ERR(global_state);
> >>>>> +
> >>>>> + dpu_rm_release_all_sspp(global_state, crtc);
> >>>>> +
> >>>>
> >>>> Do we need to call dpu_rm_release_all_sspp() even in the
> >>>> _dpu_plane_atomic_disable()?
> >>>
> >>> It allows the driver to optimize the usage of the SSPP rectangles.
> >>>
> >>
> >> No, what I meant was that we should call dpu_rm_release_all_sspp() in
>
[PATCH v2] drm/nouveau: don't attempt to schedule hpd_work on headless cards
If the card doesn't have display hardware, hpd_work and hpd_lock are
left uninitialized which causes BUG when attempting to schedule hpd_work
on runtime PM resume.
Fix it by adding headless flag to DRM and skip any hpd if it's set.
Fixes: ae1aadb1eb8d ("nouveau: don't fail driver load if no display hw
present.")
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/337
Signed-off-by: Vasily Khoruzhick
---
v2: drop extra checks in nouveau_display_hpd_work() and
nouveau_connector_hpd()
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 +
4 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 13705c5f1497..4b7497a8755c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -68,7 +68,7 @@ nv04_display_fini(struct drm_device *dev, bool runtime, bool
suspend)
if (nv_two_heads(dev))
NVWriteCRTC(dev, 1, NV_PCRTC_INTR_EN_0, 0);
- if (!runtime)
+ if (!runtime && !drm->headless)
cancel_work_sync(>hpd_work);
if (!suspend)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 88728a0b2c25..674dc567e179 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2680,7 +2680,7 @@ nv50_display_fini(struct drm_device *dev, bool runtime,
bool suspend)
nv50_mstm_fini(nouveau_encoder(encoder));
}
- if (!runtime)
+ if (!runtime && !drm->headless)
cancel_work_sync(>hpd_work);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index aed5d5b51b43..d4725a968827 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -450,6 +450,9 @@ nouveau_display_hpd_resume(struct drm_device *dev)
{
struct nouveau_drm *drm = nouveau_drm(dev);
+ if (drm->headless)
+ return;
+
spin_lock_irq(>hpd_lock);
drm->hpd_pending = ~0;
spin_unlock_irq(>hpd_lock);
@@ -635,7 +638,7 @@ nouveau_display_fini(struct drm_device *dev, bool suspend,
bool runtime)
}
drm_connector_list_iter_end(_iter);
- if (!runtime)
+ if (!runtime && !drm->headless)
cancel_work_sync(>hpd_work);
drm_kms_helper_poll_disable(dev);
@@ -729,6 +732,7 @@ nouveau_display_create(struct drm_device *dev)
/* no display hw */
if (ret == -ENODEV) {
ret = 0;
+ drm->headless = true;
goto disp_create_err;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index e239c6bf4afa..25fca98a20bc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -276,6 +276,7 @@ struct nouveau_drm {
/* modesetting */
struct nvbios vbios;
struct nouveau_display *display;
+ bool headless;
struct work_struct hpd_work;
spinlock_t hpd_lock;
u32 hpd_pending;
--
2.45.2
Re: [PATCH v4 08/13] drm/msm/dpu: add support for virtual planes
On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV playback.
To solve this problem make all planes virtual. Each plane is registered
as if it supports all possible features, but then at the runtime during
the atomic_check phase the driver selects backing SSPP block for each
plane.
Note, this does not provide support for using two different SSPP blocks
for a single plane or using two rectangles of an SSPP to drive two
planes. Each plane still gets its own SSPP and can utilize either a solo
rectangle or both multirect rectangles depending on the resolution.
Note #2: By default support for virtual planes is turned off and the
driver still uses old code path with preallocated SSPP block for each
plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
kernel parameter.
I like the overall approach in this patch. Some comments below.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 230 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 19 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 77
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 28 +++
7 files changed, 390 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 88c2e51ab166..794c5643584f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1168,6 +1168,49 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
return false;
}
+static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct
drm_crtc_state *crtc_state)
+{
+ int total_planes = crtc->dev->mode_config.num_total_plane;
+ struct drm_atomic_state *state = crtc_state->state;
+ struct dpu_global_state *global_state;
+ struct drm_plane_state **states;
+ struct drm_plane *plane;
+ int ret;
+
+ global_state = dpu_kms_get_global_state(crtc_state->state);
+ if (IS_ERR(global_state))
+ return PTR_ERR(global_state);
+
+ dpu_rm_release_all_sspp(global_state, crtc);
+
Do we need to call dpu_rm_release_all_sspp() even in the
_dpu_plane_atomic_disable()?
It allows the driver to optimize the usage of the SSPP rectangles.
No, what I meant was that we should call dpu_rm_release_all_sspp() in
dpu_plane_atomic_update() as well because in the atomic_check() path where
its called today, its being called only for zpos_changed and planes_changed
but during disable we must call this for sure.
No. the dpu_rm_release_all_sspp() should only be called during check.
When dpu_plane_atomic_update() is called, the state should already be
finalised. The atomic_check() callback is called when a plane is going
to be disabled.
atomic_check() will be called when plane is disabled but
dpu_rm_release_all_sspp() may not be called as it is protected by
zpos_changed and planes_changed. OR you need to add a !visible check
here to call dpu_rm_release_all_sspp() that time. Thats whay I wrote
previously.
+ if (!crtc_state->enable)
+ return 0;
+
+ states = kcalloc(total_planes, sizeof(*states), GFP_KERNEL);
+ if (!states)
+ return -ENOMEM;
+
+ drm_atomic_crtc_state_for_each_plane(plane, crtc_state) {
+ struct drm_plane_state *plane_state =
+ drm_atomic_get_plane_state(state, plane);
+
+ if (IS_ERR(plane_state)) {
+ ret = PTR_ERR(plane_state);
+ goto done;
+ }
+
+ states[plane_state->normalized_zpos] = plane_state;
+ }
+
+ ret = dpu_assign_plane_resources(global_state, state, crtc, states,
total_planes);
+
+done:
+ kfree(states);
+ return ret;
+
+ return 0;
+}
+
static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -1183,6 +1226,13 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+ if (dpu_use_virtual_planes &&
+ (crtc_state->planes_change
Re: [PATCH v4 08/13] drm/msm/dpu: add support for virtual planes
On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
>
>
> On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
> > On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
> > > On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> > > > Only several SSPP blocks support such features as YUV output or scaling,
> > > > thus different DRM planes have different features. Properly utilizing
> > > > all planes requires the attention of the compositor, who should
> > > > prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
> > > > to end up in a situation when all featureful planes are already
> > > > allocated for simple windows, leaving no spare plane for YUV playback.
> > > >
> > > > To solve this problem make all planes virtual. Each plane is registered
> > > > as if it supports all possible features, but then at the runtime during
> > > > the atomic_check phase the driver selects backing SSPP block for each
> > > > plane.
> > > >
> > > > Note, this does not provide support for using two different SSPP blocks
> > > > for a single plane or using two rectangles of an SSPP to drive two
> > > > planes. Each plane still gets its own SSPP and can utilize either a solo
> > > > rectangle or both multirect rectangles depending on the resolution.
> > > >
> > > > Note #2: By default support for virtual planes is turned off and the
> > > > driver still uses old code path with preallocated SSPP block for each
> > > > plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
> > > > kernel parameter.
> > > >
> > >
> > > I like the overall approach in this patch. Some comments below.
> > >
> > > > Signed-off-by: Dmitry Baryshkov
> > > > ---
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 +
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +-
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 230
> > > > +++---
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 19 ++
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 77
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 28 +++
> > > >7 files changed, 390 insertions(+), 28 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > index 88c2e51ab166..794c5643584f 100644
> > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > @@ -1168,6 +1168,49 @@ static bool dpu_crtc_needs_dirtyfb(struct
> > > > drm_crtc_state *cstate)
> > > > return false;
> > > >}
> > > > +static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct
> > > > drm_crtc_state *crtc_state)
> > > > +{
> > > > + int total_planes = crtc->dev->mode_config.num_total_plane;
> > > > + struct drm_atomic_state *state = crtc_state->state;
> > > > + struct dpu_global_state *global_state;
> > > > + struct drm_plane_state **states;
> > > > + struct drm_plane *plane;
> > > > + int ret;
> > > > +
> > > > + global_state = dpu_kms_get_global_state(crtc_state->state);
> > > > + if (IS_ERR(global_state))
> > > > + return PTR_ERR(global_state);
> > > > +
> > > > + dpu_rm_release_all_sspp(global_state, crtc);
> > > > +
> > >
> > > Do we need to call dpu_rm_release_all_sspp() even in the
> > > _dpu_plane_atomic_disable()?
> >
> > It allows the driver to optimize the usage of the SSPP rectangles.
> >
>
> No, what I meant was that we should call dpu_rm_release_all_sspp() in
> dpu_plane_atomic_update() as well because in the atomic_check() path where
> its called today, its being called only for zpos_changed and planes_changed
> but during disable we must call this for sure.
No. the dpu_rm_release_all_sspp() should only be called during check.
When dpu_plane_atomic_update() is called, the state should already be
finalised. The atomic_check() callback is called when a plane is going
to be disabled.
>
> > >
> > > > + if (!crtc_state->enable)
> > > &g
Re: [PATCH] drm/msm/a6xx: request memory region
On Fri, Jun 07, 2024 at 10:00:04AM -0400, Kiarash Hajian wrote: > The driver's memory regions are currently just ioremap()ed, but not > reserved through a request. That's not a bug, but having the request is > a little more robust. > > Implement the region-request through the corresponding managed > devres-function. Please at least compile-test the patch before sending. > > Signed-off-by: Kiarash Hajian > --- > To: Rob Clark > To: Abhinav Kumar > To: Dmitry Baryshkov > To: Sean Paul > To: Marijn Suijten > To: David Airlie > To: Daniel Vetter > Cc: linux-arm-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: freedr...@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Kiarash Hajian > > Changes in v5: > - Fix errorhanlding problems. > - Link to v4: > https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v4-1-3881a6408...@gmail.com > > Changes in v4: > - Combine v3 commits into a singel commit > - Link to v3: > https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v3-0-0a728ad45...@gmail.com > > Changes in v3: > - Remove redundant devm_iounmap calls, relying on devres for automatic > resource cleanup. > > Changes in v2: > - update the subject prefix to "drm/msm/a6xx:", to match the majority of > other changes to this file. > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 33 +++-- > 1 file changed, 15 insertions(+), 18 deletions(-) > -- With best wishes Dmitry
Re: [PATCH] drm/radeon: remove load callback
no problem, thanks for your time. wu On Fri, Jun 7, 2024 at 1:35 PM Christian König wrote: > > In general thanks for looking into this, but when you don't have > hardware to at least briefly validate your work we probably can't accept > that. > > I can see if I can get anybody looking into this, but the odds that > somebody has time and hardware are pretty low. > > Christian. > > Am 07.06.24 um 16:15 schrieb Hoi Pok Wu: > > i do it because it is part of the todo list > > where the task is to remove load/unload callback > > there are only 2 drm_driver that still uses thats why > > i thought my amdgpu could test radeonsi but no, i still send it anyway > > > > regards, > > wu > > > > > > On Fri, Jun 7, 2024 at 3:51 AM Christian König > > wrote: > >> Am 07.06.24 um 03:14 schrieb wu hoi pok: > >>> this patch is to remove the load callback from the kms_driver, > >>> following closly to amdgpu, radeon_driver_load_kms and devm_drm_dev_alloc > >>> are used, most of the changes here are rdev->ddev to rdev_to_drm, > >>> which maps to adev_to_drm in amdgpu. however this patch is not tested on > >>> hardware, so if you are free and have a gcn1 gcn2 card please do so. > >> What is the motivation to do that? > >> > >> When the old interface is going to be removed the patch is probably > >> justified, but in general we don't really accept any larger changes like > >> this for radeon any more. > >> > >> Especially without some testing of it. > >> > >> Regards, > >> Christian. > >> > >>> Signed-off-by: wu hoi pok > >>> --- > >>>drivers/gpu/drm/radeon/atombios_encoders.c | 2 +- > >>>drivers/gpu/drm/radeon/cik.c | 14 ++-- > >>>drivers/gpu/drm/radeon/dce6_afmt.c | 2 +- > >>>drivers/gpu/drm/radeon/evergreen.c | 12 ++-- > >>>drivers/gpu/drm/radeon/ni.c| 2 +- > >>>drivers/gpu/drm/radeon/r100.c | 24 +++ > >>>drivers/gpu/drm/radeon/r300.c | 6 +- > >>>drivers/gpu/drm/radeon/r420.c | 6 +- > >>>drivers/gpu/drm/radeon/r520.c | 2 +- > >>>drivers/gpu/drm/radeon/r600.c | 12 ++-- > >>>drivers/gpu/drm/radeon/r600_cs.c | 2 +- > >>>drivers/gpu/drm/radeon/r600_dpm.c | 4 +- > >>>drivers/gpu/drm/radeon/r600_hdmi.c | 2 +- > >>>drivers/gpu/drm/radeon/radeon.h| 11 +++- > >>>drivers/gpu/drm/radeon/radeon_acpi.c | 10 +-- > >>>drivers/gpu/drm/radeon/radeon_agp.c| 2 +- > >>>drivers/gpu/drm/radeon/radeon_atombios.c | 2 +- > >>>drivers/gpu/drm/radeon/radeon_audio.c | 4 +- > >>>drivers/gpu/drm/radeon/radeon_combios.c| 12 ++-- > >>>drivers/gpu/drm/radeon/radeon_device.c | 17 ++--- > >>>drivers/gpu/drm/radeon/radeon_display.c| 74 +++--- > >>>drivers/gpu/drm/radeon/radeon_drv.c| 27 +--- > >>>drivers/gpu/drm/radeon/radeon_drv.h| 1 - > >>>drivers/gpu/drm/radeon/radeon_fbdev.c | 26 > >>>drivers/gpu/drm/radeon/radeon_fence.c | 8 +-- > >>>drivers/gpu/drm/radeon/radeon_gem.c| 2 +- > >>>drivers/gpu/drm/radeon/radeon_i2c.c| 2 +- > >>>drivers/gpu/drm/radeon/radeon_ib.c | 2 +- > >>>drivers/gpu/drm/radeon/radeon_irq_kms.c| 12 ++-- > >>>drivers/gpu/drm/radeon/radeon_kms.c| 16 ++--- > >>>drivers/gpu/drm/radeon/radeon_object.c | 2 +- > >>>drivers/gpu/drm/radeon/radeon_pm.c | 20 +++--- > >>>drivers/gpu/drm/radeon/radeon_ring.c | 2 +- > >>>drivers/gpu/drm/radeon/radeon_ttm.c| 6 +- > >>>drivers/gpu/drm/radeon/rs400.c | 6 +- > >>>drivers/gpu/drm/radeon/rs600.c | 14 ++-- > >>>drivers/gpu/drm/radeon/rs690.c | 2 +- > >>>drivers/gpu/drm/radeon/rv515.c | 4 +- > >>>drivers/gpu/drm/radeon/rv770.c | 2 +- > >>>drivers/gpu/drm/radeon/si.c| 4 +- > >>>40 files changed, 192 insertions(+), 188 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c > >>> b/drivers/gpu/drm/radeon/atombios_e
Re: [PATCH v7 00/13] Make PCI's devres API more consistent
On Wed, Jun 05, 2024 at 10:15:52AM +0200, Philipp Stanner wrote: > Hello Bjorn, > > I tried to meet your requests from the last feedback round as much as > possible. Especially, I removed a lot of code, made almost all > interfaces private and cut the series into smaller chunks where > possible. > > Splitting it even smaller is unfortunately not possible because of the > Linux kernel build chain's rule on dead / unused code. > > See also the changelog below. > > Please tell me if that's enough to move forward here. > > Regards, > P. > > > Changes in v7: > - Split the entire series in smaller, more atomic chunks / patches > (Bjorn) > - Remove functions (such as pcim_iomap_region_range()) that do not yet > have a user (Bjorn) > - Don't export interfaces publicly anymore, except for > pcim_iomap_range(), needed by vboxvideo (Bjorn) > - Mention the actual (vboxvideo) bug in "PCI: Warn users..." commit > (Bjorn) > - Drop docstring warnings on PCI-internal functions (Bjorn) > - Rework docstring warnings > - Fix spelling in a few places. Rewrapp paragraphs (Bjorn) > > Changes in v6: > - Restructure the cleanup in pcim_iomap_regions_request_all() so that > it doesn't trigger a (false positive) test robot warning. No > behavior change intended. (Dan Carpenter) > > Changes in v5: > - Add Hans's Reviewed-by to vboxvideo patch (Hans de Goede) > - Remove stable-kernel from CC in vboxvideo patch (Hans de Goede) > > Changes in v4: > - Rebase against linux-next > > Changes in v3: > - Use the term "PCI devres API" at some forgotten places. > - Fix more grammar errors in patch #3. > - Remove the comment advising to call (the outdated) pcim_intx() in pci.c > - Rename __pcim_request_region_range() flags-field "exclusive" to > "req_flags", since this is what the int actually represents. > - Remove the call to pcim_region_request() from patch #10. (Hans) > > Changes in v2: > - Make commit head lines congruent with PCI's style (Bjorn) > - Add missing error checks for devm_add_action(). (Andy) > - Repair the "Returns: " marks for docu generation (Andy) > - Initialize the addr_devres struct with memset(). (Andy) > - Make pcim_intx() a PCI-internal function so that new drivers won't > be encouraged to use the outdated pci_intx() mechanism. > (Andy / Philipp) > - Fix grammar and spelling (Bjorn) > - Be more precise on why pcim_iomap_table() is problematic (Bjorn) > - Provide the actual structs' and functions' names in the commit > messages (Bjorn) > - Remove redundant variable initializers (Andy) > - Regroup PM bitfield members in struct pci_dev (Andy) > - Make pcim_intx() visible only for the PCI subsystem so that new > drivers won't use this outdated API (Andy, Myself) > - Add a NOTE to pcim_iomap() to warn about this function being theonee > xception that does just return NULL. > - Consistently use the term "PCI devres API"; also in Patch #10 (Bjorn) > > > ¡Hola! > > PCI's devres API suffers several weaknesses: > > 1. There are functions prefixed with pcim_. Those are always managed >counterparts to never-managed functions prefixed with pci_ – or so one >would like to think. There are some apparently unmanaged functions >(all region-request / release functions, and pci_intx()) which > suddenly become managed once the user has initialized the device with >pcim_enable_device() instead of pci_enable_device(). This "sometimes >yes, sometimes no" nature of those functions is confusing and >therefore bug-provoking. In fact, it has already caused a bug in DRM. >The last patch in this series fixes that bug. > 2. iomappings: Instead of giving each mapping its own callback, the >existing API uses a statically allocated struct tracking one mapping >per bar. This is not extensible. Especially, you can't create >_ranged_ managed mappings that way, which many drivers want. > 3. Managed request functions only exist as "plural versions" with a >bit-mask as a parameter. That's quite over-engineered considering >that each user only ever mapps one, maybe two bars. > > This series: > - add a set of new "singular" devres functions that use devres the way > its intended, with one callback per resource. > - deprecates the existing iomap-table mechanism. > - deprecates the hybrid nature of pci_ functions. > - preserves backwards compatibility so that drivers using the existing > API won't notice any changes. > - adds documentation, especially some warning users about the >
Re: [PATCH v4 08/13] drm/msm/dpu: add support for virtual planes
On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV playback.
To solve this problem make all planes virtual. Each plane is registered
as if it supports all possible features, but then at the runtime during
the atomic_check phase the driver selects backing SSPP block for each
plane.
Note, this does not provide support for using two different SSPP blocks
for a single plane or using two rectangles of an SSPP to drive two
planes. Each plane still gets its own SSPP and can utilize either a solo
rectangle or both multirect rectangles depending on the resolution.
Note #2: By default support for virtual planes is turned off and the
driver still uses old code path with preallocated SSPP block for each
plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
kernel parameter.
I like the overall approach in this patch. Some comments below.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 230 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 19 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 77
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 28 +++
7 files changed, 390 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 88c2e51ab166..794c5643584f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1168,6 +1168,49 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
return false;
}
+static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct
drm_crtc_state *crtc_state)
+{
+ int total_planes = crtc->dev->mode_config.num_total_plane;
+ struct drm_atomic_state *state = crtc_state->state;
+ struct dpu_global_state *global_state;
+ struct drm_plane_state **states;
+ struct drm_plane *plane;
+ int ret;
+
+ global_state = dpu_kms_get_global_state(crtc_state->state);
+ if (IS_ERR(global_state))
+ return PTR_ERR(global_state);
+
+ dpu_rm_release_all_sspp(global_state, crtc);
+
Do we need to call dpu_rm_release_all_sspp() even in the
_dpu_plane_atomic_disable()?
It allows the driver to optimize the usage of the SSPP rectangles.
No, what I meant was that we should call dpu_rm_release_all_sspp() in
dpu_plane_atomic_update() as well because in the atomic_check() path
where its called today, its being called only for zpos_changed and
planes_changed but during disable we must call this for sure.
+ if (!crtc_state->enable)
+ return 0;
+
+ states = kcalloc(total_planes, sizeof(*states), GFP_KERNEL);
+ if (!states)
+ return -ENOMEM;
+
+ drm_atomic_crtc_state_for_each_plane(plane, crtc_state) {
+ struct drm_plane_state *plane_state =
+ drm_atomic_get_plane_state(state, plane);
+
+ if (IS_ERR(plane_state)) {
+ ret = PTR_ERR(plane_state);
+ goto done;
+ }
+
+ states[plane_state->normalized_zpos] = plane_state;
+ }
+
+ ret = dpu_assign_plane_resources(global_state, state, crtc, states,
total_planes);
+
+done:
+ kfree(states);
+ return ret;
+
+ return 0;
+}
+
static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -1183,6 +1226,13 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+ if (dpu_use_virtual_planes &&
+ (crtc_state->planes_changed || crtc_state->zpos_changed)) {
Here, I assume you are relying on DRM to set zpos_changed. But can you
please elaborate why we have to reassign planes when zpos_changes?
Because the SSPP might be split between two planes. If zpos has changed
we might have to break this split and use two different SSPPs for those
planes.
Got it. But that support has not been added yet so belongs to a later
patchset?
+ rc = dpu_crtc_reassign_planes(crtc, crtc_state);
+ if (rc < 0)
+ return rc;
+ }
+
if (!crtc_state->enable ||
!drm_ato
Re: [PATCH] drm/i915/gt/uc: Evaluate GuC priority within locks
On 6/5/2024 5:17 PM, Andi Shyti wrote:
The ce->guc_state.lock was made to protect guc_prio, which
indicates the GuC priority level.
But at the begnning of the function we perform some sanity check
of guc_prio outside its protected section. Move them within the
locked region.
Use this occasion to expand the if statement to make it clearer.
Fixes: ee242ca704d3 ("drm/i915/guc: Implement GuC priority management")
Signed-off-by: Andi Shyti
Cc: Matthew Brost
Cc: # v5.15+
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0eaa1064242c..1181043bc5e9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4267,13 +4267,18 @@ static void guc_bump_inflight_request_prio(struct
i915_request *rq,
u8 new_guc_prio = map_i915_prio_to_guc_prio(prio);
/* Short circuit function */
- if (prio < I915_PRIORITY_NORMAL ||
- rq->guc_prio == GUC_PRIO_FINI ||
- (rq->guc_prio != GUC_PRIO_INIT &&
-!new_guc_prio_higher(rq->guc_prio, new_guc_prio)))
+ if (prio < I915_PRIORITY_NORMAL)
return;
My understanding was that those checks are purposely done outside of the
lock to avoid taking it when not needed and that the early exit is not
racy. In particular:
- GUC_PRIO_FINI is the end state for the priority, so if we're there
that's not changing anymore and therefore the lock is not required.
- the priority only goes up with the bumping, so if
new_guc_prio_higher() is false that's not going to be changed by a
different thread running at the same time and increasing the priority
even more.
I think there is still a possible race is if new_guc_prio_higher() is
true when we check it outside the lock but then changes before we
execute the protected chunk inside, so a fix would still be required for
that.
All this said, I don't really have anything against moving the whole
thing inside the lock since this isn't on a critical path, just wanted
to point out that it's not all strictly required.
One nit on the code below.
spin_lock(>guc_state.lock);
+
+ if (rq->guc_prio == GUC_PRIO_FINI)
+ goto exit;
+
+ if (rq->guc_prio != GUC_PRIO_INIT &&
+ !new_guc_prio_higher(rq->guc_prio, new_guc_prio))
+ goto exit;
+
if (rq->guc_prio != GUC_PRIO_FINI) {
You're now checking for rq->guc_prio == GUC_PRIO_FINI inside the lock,
so no need to check it again here as it can't have changed.
Daniele
if (rq->guc_prio != GUC_PRIO_INIT)
sub_context_inflight_prio(ce, rq->guc_prio);
@@ -4281,6 +4286,8 @@ static void guc_bump_inflight_request_prio(struct
i915_request *rq,
add_context_inflight_prio(ce, rq->guc_prio);
update_context_prio(ce);
}
+
+exit:
spin_unlock(>guc_state.lock);
}
Re: [RFC PATCH 7/8] rust: add firmware abstractions
On Fri, Jun 07, 2024 at 05:41:11PM +0200, Greg KH wrote: > On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote: > > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > > > Anyway, that's all hand-wavy right now, sorry, to get back to the point > > > here, again, let's take this, which will allow the firmware bindings to > > > be resubmitted and hopefully accepted, and we can move forward from > > > there to "real" things like a USB or PCI or even platform device and > > > driver binding stuff. > > > > In order to continue I propose to send out the following series: > > > > 1) minimal device and firmware abstractions only > > Sounds good. Just a heads-up, I'll probably send this one quite a bit earlier than the other two to make sure to unblock Fujita on their PHY driver. > > But after this, I don't want to take ANY driver core rust code that is > not able to live in the "normal" part of the Linux kernel tree. It's > just unsustainable to have it all in one directory sorry. If this > deadline makes that kbuild work actually happen faster, all the more > reason to have it. If that kbuild work is somehow stalled due to other > issues, please let me know what that is. > > > 2) v2 of all other device / driver, devres and PCI driver abstractions > > I will be glad to review this. Glad to hear that! > > > 3) v2 of basic DRM driver abstractions and Nova > > I love it how one of the most complex driver subsystems we have (drm) is > attempting to be the "first real" driver use for the rust apis. Bold > move :) I'd argue that as one of the most complex driver subsystems we have a lot of need for the advantages Rust provides to us. :) > > > The v2 series would contain static driver allocation (in case of DRM even > > const) > > and quite a few more simplifications around `driver::Registration` and > > `device::Data`. > > > > Does that make sense? > > Yes, but note, I'm going to probably push back on the "driver::" stuff. That's OK, I'm happy to convince you of its usefulness. :) > But will do so with more constructive criticism as I want this to work > very much and I agree that I think we are both talking past each other > in different ways. Mostly probably due to my total lack of Rust > experience, my apologies, thanks for your patience with me for this. Very much appreciated! Please don't hesitate to ask for more explanation on certain things if they're unclear. I'm happy trying my best to provide useful answers. - Danilo > > thanks, > > greg k-h >
Re: [PATCH] drm/radeon: remove load callback
In general thanks for looking into this, but when you don't have
hardware to at least briefly validate your work we probably can't accept
that.
I can see if I can get anybody looking into this, but the odds that
somebody has time and hardware are pretty low.
Christian.
Am 07.06.24 um 16:15 schrieb Hoi Pok Wu:
i do it because it is part of the todo list
where the task is to remove load/unload callback
there are only 2 drm_driver that still uses thats why
i thought my amdgpu could test radeonsi but no, i still send it anyway
regards,
wu
On Fri, Jun 7, 2024 at 3:51 AM Christian König wrote:
Am 07.06.24 um 03:14 schrieb wu hoi pok:
this patch is to remove the load callback from the kms_driver,
following closly to amdgpu, radeon_driver_load_kms and devm_drm_dev_alloc
are used, most of the changes here are rdev->ddev to rdev_to_drm,
which maps to adev_to_drm in amdgpu. however this patch is not tested on
hardware, so if you are free and have a gcn1 gcn2 card please do so.
What is the motivation to do that?
When the old interface is going to be removed the patch is probably
justified, but in general we don't really accept any larger changes like
this for radeon any more.
Especially without some testing of it.
Regards,
Christian.
Signed-off-by: wu hoi pok
---
drivers/gpu/drm/radeon/atombios_encoders.c | 2 +-
drivers/gpu/drm/radeon/cik.c | 14 ++--
drivers/gpu/drm/radeon/dce6_afmt.c | 2 +-
drivers/gpu/drm/radeon/evergreen.c | 12 ++--
drivers/gpu/drm/radeon/ni.c| 2 +-
drivers/gpu/drm/radeon/r100.c | 24 +++
drivers/gpu/drm/radeon/r300.c | 6 +-
drivers/gpu/drm/radeon/r420.c | 6 +-
drivers/gpu/drm/radeon/r520.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 12 ++--
drivers/gpu/drm/radeon/r600_cs.c | 2 +-
drivers/gpu/drm/radeon/r600_dpm.c | 4 +-
drivers/gpu/drm/radeon/r600_hdmi.c | 2 +-
drivers/gpu/drm/radeon/radeon.h| 11 +++-
drivers/gpu/drm/radeon/radeon_acpi.c | 10 +--
drivers/gpu/drm/radeon/radeon_agp.c| 2 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 2 +-
drivers/gpu/drm/radeon/radeon_audio.c | 4 +-
drivers/gpu/drm/radeon/radeon_combios.c| 12 ++--
drivers/gpu/drm/radeon/radeon_device.c | 17 ++---
drivers/gpu/drm/radeon/radeon_display.c| 74 +++---
drivers/gpu/drm/radeon/radeon_drv.c| 27 +---
drivers/gpu/drm/radeon/radeon_drv.h| 1 -
drivers/gpu/drm/radeon/radeon_fbdev.c | 26
drivers/gpu/drm/radeon/radeon_fence.c | 8 +--
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/gpu/drm/radeon/radeon_i2c.c| 2 +-
drivers/gpu/drm/radeon/radeon_ib.c | 2 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c| 12 ++--
drivers/gpu/drm/radeon/radeon_kms.c| 16 ++---
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_pm.c | 20 +++---
drivers/gpu/drm/radeon/radeon_ring.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 6 +-
drivers/gpu/drm/radeon/rs400.c | 6 +-
drivers/gpu/drm/radeon/rs600.c | 14 ++--
drivers/gpu/drm/radeon/rs690.c | 2 +-
drivers/gpu/drm/radeon/rv515.c | 4 +-
drivers/gpu/drm/radeon/rv770.c | 2 +-
drivers/gpu/drm/radeon/si.c| 4 +-
40 files changed, 192 insertions(+), 188 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 7b11674f5d45..05f34efd7fd0 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2179,7 +2179,7 @@ int radeon_atom_pick_dig_encoder(struct drm_encoder
*encoder, int fe_idx)
void
radeon_atom_encoder_init(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_encoder *encoder;
list_for_each_entry(encoder, >mode_config.encoder_list, head) {
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index b5e96a8fc2c1..11a492f21157 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7585,7 +7585,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted irq
bit?\n");
if (rdev->irq.crtc_vblank_int[0]) {
- drm_handle_vblank(rdev->ddev, 0);
+ drm_handle_vblank(rdev_to_drm(rdev), 0);
rdev->pm.vblank_sync = true;
wake_up(>irq.vblank_queue);
}
@@ -7615,7 +7615,7 @@ int cik_irq_pro
Re: [PATCH] drm/radeon: remove load callback
i do it because it is part of the todo list
where the task is to remove load/unload callback
there are only 2 drm_driver that still uses thats why
i thought my amdgpu could test radeonsi but no, i still send it anyway
regards,
wu
On Fri, Jun 7, 2024 at 3:51 AM Christian König wrote:
>
> Am 07.06.24 um 03:14 schrieb wu hoi pok:
> > this patch is to remove the load callback from the kms_driver,
> > following closly to amdgpu, radeon_driver_load_kms and devm_drm_dev_alloc
> > are used, most of the changes here are rdev->ddev to rdev_to_drm,
> > which maps to adev_to_drm in amdgpu. however this patch is not tested on
> > hardware, so if you are free and have a gcn1 gcn2 card please do so.
>
> What is the motivation to do that?
>
> When the old interface is going to be removed the patch is probably
> justified, but in general we don't really accept any larger changes like
> this for radeon any more.
>
> Especially without some testing of it.
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: wu hoi pok
> > ---
> > drivers/gpu/drm/radeon/atombios_encoders.c | 2 +-
> > drivers/gpu/drm/radeon/cik.c | 14 ++--
> > drivers/gpu/drm/radeon/dce6_afmt.c | 2 +-
> > drivers/gpu/drm/radeon/evergreen.c | 12 ++--
> > drivers/gpu/drm/radeon/ni.c| 2 +-
> > drivers/gpu/drm/radeon/r100.c | 24 +++
> > drivers/gpu/drm/radeon/r300.c | 6 +-
> > drivers/gpu/drm/radeon/r420.c | 6 +-
> > drivers/gpu/drm/radeon/r520.c | 2 +-
> > drivers/gpu/drm/radeon/r600.c | 12 ++--
> > drivers/gpu/drm/radeon/r600_cs.c | 2 +-
> > drivers/gpu/drm/radeon/r600_dpm.c | 4 +-
> > drivers/gpu/drm/radeon/r600_hdmi.c | 2 +-
> > drivers/gpu/drm/radeon/radeon.h| 11 +++-
> > drivers/gpu/drm/radeon/radeon_acpi.c | 10 +--
> > drivers/gpu/drm/radeon/radeon_agp.c| 2 +-
> > drivers/gpu/drm/radeon/radeon_atombios.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_audio.c | 4 +-
> > drivers/gpu/drm/radeon/radeon_combios.c| 12 ++--
> > drivers/gpu/drm/radeon/radeon_device.c | 17 ++---
> > drivers/gpu/drm/radeon/radeon_display.c| 74 +++---
> > drivers/gpu/drm/radeon/radeon_drv.c| 27 +---
> > drivers/gpu/drm/radeon/radeon_drv.h| 1 -
> > drivers/gpu/drm/radeon/radeon_fbdev.c | 26
> > drivers/gpu/drm/radeon/radeon_fence.c | 8 +--
> > drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
> > drivers/gpu/drm/radeon/radeon_i2c.c| 2 +-
> > drivers/gpu/drm/radeon/radeon_ib.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_irq_kms.c| 12 ++--
> > drivers/gpu/drm/radeon/radeon_kms.c| 16 ++---
> > drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_pm.c | 20 +++---
> > drivers/gpu/drm/radeon/radeon_ring.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_ttm.c| 6 +-
> > drivers/gpu/drm/radeon/rs400.c | 6 +-
> > drivers/gpu/drm/radeon/rs600.c | 14 ++--
> > drivers/gpu/drm/radeon/rs690.c | 2 +-
> > drivers/gpu/drm/radeon/rv515.c | 4 +-
> > drivers/gpu/drm/radeon/rv770.c | 2 +-
> > drivers/gpu/drm/radeon/si.c| 4 +-
> > 40 files changed, 192 insertions(+), 188 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> > b/drivers/gpu/drm/radeon/atombios_encoders.c
> > index 7b11674f5d45..05f34efd7fd0 100644
> > --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> > +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> > @@ -2179,7 +2179,7 @@ int radeon_atom_pick_dig_encoder(struct drm_encoder
> > *encoder, int fe_idx)
> > void
> > radeon_atom_encoder_init(struct radeon_device *rdev)
> > {
> > - struct drm_device *dev = rdev->ddev;
> > + struct drm_device *dev = rdev_to_drm(rdev);
> > struct drm_encoder *encoder;
> >
> > list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> > index b5e96a8fc2c1..11a492f21157 100644
> > --- a/drivers/gpu/drm/radeon/cik.c
> > +++ b/drivers/gpu/drm/radeon/cik.c
> > @@ -7585,7 +7585,7 @@ int cik_irq_process(struct radeon_device *rdev)
> > DRM_DEBUG("IH: IH event w/o asserted
> > irq bit?\n&qu
[PATCH] drm/radeon: remove load callback
this patch is to remove the load callback from the kms_driver,
following closly to amdgpu, radeon_driver_load_kms and devm_drm_dev_alloc
are used, most of the changes here are rdev->ddev to rdev_to_drm,
which maps to adev_to_drm in amdgpu. however this patch is not tested on
hardware, so if you are free and have a gcn1 gcn2 card please do so.
Signed-off-by: wu hoi pok
---
drivers/gpu/drm/radeon/atombios_encoders.c | 2 +-
drivers/gpu/drm/radeon/cik.c | 14 ++--
drivers/gpu/drm/radeon/dce6_afmt.c | 2 +-
drivers/gpu/drm/radeon/evergreen.c | 12 ++--
drivers/gpu/drm/radeon/ni.c| 2 +-
drivers/gpu/drm/radeon/r100.c | 24 +++
drivers/gpu/drm/radeon/r300.c | 6 +-
drivers/gpu/drm/radeon/r420.c | 6 +-
drivers/gpu/drm/radeon/r520.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 12 ++--
drivers/gpu/drm/radeon/r600_cs.c | 2 +-
drivers/gpu/drm/radeon/r600_dpm.c | 4 +-
drivers/gpu/drm/radeon/r600_hdmi.c | 2 +-
drivers/gpu/drm/radeon/radeon.h| 11 +++-
drivers/gpu/drm/radeon/radeon_acpi.c | 10 +--
drivers/gpu/drm/radeon/radeon_agp.c| 2 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 2 +-
drivers/gpu/drm/radeon/radeon_audio.c | 4 +-
drivers/gpu/drm/radeon/radeon_combios.c| 12 ++--
drivers/gpu/drm/radeon/radeon_device.c | 17 ++---
drivers/gpu/drm/radeon/radeon_display.c| 74 +++---
drivers/gpu/drm/radeon/radeon_drv.c| 27 +---
drivers/gpu/drm/radeon/radeon_drv.h| 1 -
drivers/gpu/drm/radeon/radeon_fbdev.c | 26
drivers/gpu/drm/radeon/radeon_fence.c | 8 +--
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/gpu/drm/radeon/radeon_i2c.c| 2 +-
drivers/gpu/drm/radeon/radeon_ib.c | 2 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c| 12 ++--
drivers/gpu/drm/radeon/radeon_kms.c| 16 ++---
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_pm.c | 20 +++---
drivers/gpu/drm/radeon/radeon_ring.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 6 +-
drivers/gpu/drm/radeon/rs400.c | 6 +-
drivers/gpu/drm/radeon/rs600.c | 14 ++--
drivers/gpu/drm/radeon/rs690.c | 2 +-
drivers/gpu/drm/radeon/rv515.c | 4 +-
drivers/gpu/drm/radeon/rv770.c | 2 +-
drivers/gpu/drm/radeon/si.c| 4 +-
40 files changed, 192 insertions(+), 188 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 7b11674f5d45..05f34efd7fd0 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2179,7 +2179,7 @@ int radeon_atom_pick_dig_encoder(struct drm_encoder
*encoder, int fe_idx)
void
radeon_atom_encoder_init(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_encoder *encoder;
list_for_each_entry(encoder, >mode_config.encoder_list, head) {
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index b5e96a8fc2c1..11a492f21157 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7585,7 +7585,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[0]) {
- drm_handle_vblank(rdev->ddev, 0);
+ drm_handle_vblank(rdev_to_drm(rdev), 0);
rdev->pm.vblank_sync = true;
wake_up(>irq.vblank_queue);
}
@@ -7615,7 +7615,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[1]) {
- drm_handle_vblank(rdev->ddev, 1);
+ drm_handle_vblank(rdev_to_drm(rdev), 1);
rdev->pm.vblank_sync = true;
wake_up(>irq.vblank_queue);
}
@@ -7645,7 +7645,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[2]) {
- drm_handle_vblank(rdev->ddev, 2);
+ drm_handle_vblank(rdev_to_drm(rdev), 2);
rdev-&g
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On Fri, Jun 7, 2024 at 8:47 AM Pavel Begunkov wrote: > > On 6/7/24 16:42, Pavel Begunkov wrote: > > On 6/7/24 15:27, David Ahern wrote: > >> On 6/7/24 7:42 AM, Pavel Begunkov wrote: > >>> I haven't seen any arguments against from the (net) maintainers so > >>> far. Nor I see any objection against callbacks from them (considering > >>> that either option adds an if). > >> > >> I have said before I do not understand why the dmabuf paradigm is not > >> sufficient for both device memory and host memory. A less than ideal > >> control path to put hostmem in a dmabuf wrapper vs extra checks and > >> changes in the datapath. The former should always be preferred. > > > > If we're talking about types of memory specifically, I'm not strictly > > against wrapping into dmabuf in kernel, but that just doesn't give > > anything. > > And the reason I don't have too strong of an opinion on that is > mainly because it's just setup/cleanup path. > I agree wrapping io uring in dmabuf seems to be an unnecessary detour. I never understood the need or upside to do that, but it could be a lack of understanding on my part. However, the concern that David brings up may materialize. I've had to spend a lot of time minimizing or justifying checks to the code with page pool benchmarks that detect even 1 cycle regressions. You may be asked to run the same benchmarks and minimize similar overhead. The benchmark in question is Jesper's bench_page_pool_simple. I've forked it and applied it on top of net-next here: https://github.com/mina/linux/commit/927596f87ab5791a8a6ba8597ba2189747396e54 As io_uring ZC comes close to merging, I suspect it would be good to run this to understand the regression in the fast path, if any. If there are no to little regressions, I have no concerns over io uring memory not being wrapped in dmabufs, and David may agree as well. -- Thanks, Mina
Re: [PATCH] drm/nouveau: don't attempt to schedule hpd_work on headless cards
On Thu, Jun 6, 2024 at 6:37 PM Dave Airlie wrote:
>
> readding original poster
Thanks, Dave!
Ben, please keep me on CC, since I'm not subscribed to either nouveau
or dri-devel mailing lists.
> On Wed, 29 May 2024 at 09:57, Ben Skeggs wrote:
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> > > b/drivers/gpu/drm/nouveau/nouveau_connector.c
> > > index 856b3ef5edb8..b315a2ef5b28 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> > > @@ -1190,6 +1190,9 @@ nouveau_connector_hpd(struct nouveau_connector
> > > *nv_connector, u64 bits)
> > > u32 mask = drm_connector_mask(_connector->base);
> > > unsigned long flags;
> > >
> > > + if (drm->headless)
> > > + return;
> > > +
> >
> > You shouldn't need this change, the function can't be called if there's
> > no display.
You are right. I added it for extra safety in case if the code changes
in future and it somehow gets called, but I don't have a strong
preference, so I can drop it in v2.
> >
> > > spin_lock_irqsave(>hpd_lock, flags);
> > > if (!(drm->hpd_pending & mask)) {
> > > nv_connector->hpd_pending |= bits;
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> > > b/drivers/gpu/drm/nouveau/nouveau_display.c
> > > index aed5d5b51b43..1961ef665e97 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> > > @@ -450,6 +450,9 @@ nouveau_display_hpd_resume(struct drm_device *dev)
> > > {
> > > struct nouveau_drm *drm = nouveau_drm(dev);
> > >
> > > + if (drm->headless)
> > > + return;
> > > +
> > > spin_lock_irq(>hpd_lock);
> > > drm->hpd_pending = ~0;
> > > spin_unlock_irq(>hpd_lock);
> > > @@ -468,6 +471,11 @@ nouveau_display_hpd_work(struct work_struct *work)
> > > int changed = 0;
> > > struct drm_connector *first_changed_connector = NULL;
> > >
> > > + WARN_ON_ONCE(drm->headless);
> > > +
> > > + if (drm->headless)
> > > + return;
> > > +
> >
> > Same here.
Same comment, I'll drop it for v2.
Regards,
Vasily
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 6/7/24 16:42, Pavel Begunkov wrote: On 6/7/24 15:27, David Ahern wrote: On 6/7/24 7:42 AM, Pavel Begunkov wrote: I haven't seen any arguments against from the (net) maintainers so far. Nor I see any objection against callbacks from them (considering that either option adds an if). I have said before I do not understand why the dmabuf paradigm is not sufficient for both device memory and host memory. A less than ideal control path to put hostmem in a dmabuf wrapper vs extra checks and changes in the datapath. The former should always be preferred. If we're talking about types of memory specifically, I'm not strictly against wrapping into dmabuf in kernel, but that just doesn't give anything. And the reason I don't have too strong of an opinion on that is mainly because it's just setup/cleanup path. But the main reason for allocations there is the difference in approaches to the api. With io_uring the allocation callback is responsible for getting buffers back from the user (via a shared ring). No locking for the ring, and buffers are already in the context (napi) where they would be consumed from. Removes some headaches for the user (like batching before returning buffers), and should go better with smaller buffers and such. I also do not understand why the ifq cache I'm not sure what you mean by ifq cache. Can you elaborate? and overloading xdp functions Assuming it's about setup via xdp, it was marked for remaking in RFCs for longer than desired but it's gone now in our tree (but maybe not in the latest series). have stuck around; I always thought both were added by Jonathan to simplify kernel ports during early POC days. -- Pavel Begunkov
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 6/7/24 15:27, David Ahern wrote: On 6/7/24 7:42 AM, Pavel Begunkov wrote: I haven't seen any arguments against from the (net) maintainers so far. Nor I see any objection against callbacks from them (considering that either option adds an if). I have said before I do not understand why the dmabuf paradigm is not sufficient for both device memory and host memory. A less than ideal control path to put hostmem in a dmabuf wrapper vs extra checks and changes in the datapath. The former should always be preferred. If we're talking about types of memory specifically, I'm not strictly against wrapping into dmabuf in kernel, but that just doesn't give anything. But the main reason for allocations there is the difference in approaches to the api. With io_uring the allocation callback is responsible for getting buffers back from the user (via a shared ring). No locking for the ring, and buffers are already in the context (napi) where they would be consumed from. Removes some headaches for the user (like batching before returning buffers), and should go better with smaller buffers and such. I also do not understand why the ifq cache I'm not sure what you mean by ifq cache. Can you elaborate? and overloading xdp functions Assuming it's about setup via xdp, it was marked for remaking in RFCs for longer than desired but it's gone now in our tree (but maybe not in the latest series). have stuck around; I always thought both were added by Jonathan to simplify kernel ports during early POC days. -- Pavel Begunkov
Re: [RFC PATCH 7/8] rust: add firmware abstractions
On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote: > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > > Anyway, that's all hand-wavy right now, sorry, to get back to the point > > here, again, let's take this, which will allow the firmware bindings to > > be resubmitted and hopefully accepted, and we can move forward from > > there to "real" things like a USB or PCI or even platform device and > > driver binding stuff. > > In order to continue I propose to send out the following series: > > 1) minimal device and firmware abstractions only Sounds good. But after this, I don't want to take ANY driver core rust code that is not able to live in the "normal" part of the Linux kernel tree. It's just unsustainable to have it all in one directory sorry. If this deadline makes that kbuild work actually happen faster, all the more reason to have it. If that kbuild work is somehow stalled due to other issues, please let me know what that is. > 2) v2 of all other device / driver, devres and PCI driver abstractions I will be glad to review this. > 3) v2 of basic DRM driver abstractions and Nova I love it how one of the most complex driver subsystems we have (drm) is attempting to be the "first real" driver use for the rust apis. Bold move :) > The v2 series would contain static driver allocation (in case of DRM even > const) > and quite a few more simplifications around `driver::Registration` and > `device::Data`. > > Does that make sense? Yes, but note, I'm going to probably push back on the "driver::" stuff. But will do so with more constructive criticism as I want this to work very much and I agree that I think we are both talking past each other in different ways. Mostly probably due to my total lack of Rust experience, my apologies, thanks for your patience with me for this. thanks, greg k-h
Re: [PATCH] drm/i915/gt: debugfs: Evaluate forcewake usage within locks
On Fri, Jun 07, 2024 at 04:51:31PM +0200, Andi Shyti wrote: > The forcewake count and domains listing is multi process critical > and the uncore provides a spinlock for such cases. > > Lock the forcewake evaluation section in the fw_domains_show() > debugfs interface. > > Signed-off-by: Andi Shyti > --- > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > index 4fcba42cfe34..0437fd8217e0 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > @@ -71,6 +71,8 @@ static int fw_domains_show(struct seq_file *m, void *data) > struct intel_uncore_forcewake_domain *fw_domain; > unsigned int tmp; > > + spin_lock_irq(>lock); > + > seq_printf(m, "user.bypass_count = %u\n", > uncore->user_forcewake_count); > > @@ -79,6 +81,8 @@ static int fw_domains_show(struct seq_file *m, void *data) > intel_uncore_forcewake_domain_to_str(fw_domain->id), > READ_ONCE(fw_domain->wake_count)); > > + spin_unlock_irq(>lock); I was going to ask to move all of this to a function inside intel_uncore.c so we keep the lock access in there But then I noticed it is already spread all over :( Well, perhaps we should start from here to set the precedence and move things to its own component... but well, I won't block or make it hard, we do need this change and the overall uncore cleanup could be orthogonal. Reviewed-by: Rodrigo Vivi > + > return 0; > } > DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(fw_domains); > -- > 2.45.1 >
Re: [PATCH v4 0/5] drm/tiny: panel-mipi-dbi: Support 18 bits per color RGB666
On 6/4/24 15:20, Noralf Trønnes via B4 Relay wrote: > Hi, > > In this version I've fixed up a commit message that I had forgotten to > write before sending and improved a struct member name. > > See version 1 of the patchset for the full cover letter. > > Signed-off-by: Noralf Trønnes > --- Thanks a lot for reviewing the patches, applied to drm-misc-next. Noralf. > Changes in v4: > - Expand the commit message (Dmitry) > - s/emulation_format/pixel_format/ (Dmitry) > - Link to v3: > https://lore.kernel.org/r/20240603-panel-mipi-dbi-rgb666-v3-0-59ed53ca7...@tronnes.org > > Changes in v3: > - Added r-b's to patch 1 and 5 > - Link to v2: > https://lore.kernel.org/r/20240512-panel-mipi-dbi-rgb666-v2-0-49dd26632...@tronnes.org > > Changes in v2: > - binding: Use 'default: r5g6b5' (Rob) > - Link to v1: > https://lore.kernel.org/r/20240507-panel-mipi-dbi-rgb666-v1-0-6799234af...@tronnes.org > > --- > Noralf Trønnes (5): > dt-bindings: display: panel: mipi-dbi-spi: Add a pixel format property > drm/mipi-dbi: Remove mipi_dbi_machine_little_endian() > drm/mipi-dbi: Make bits per word configurable for pixel transfers > drm/mipi-dbi: Add support for DRM_FORMAT_RGB888 > drm/tiny: panel-mipi-dbi: Support the pixel format property > > .../bindings/display/panel/panel-mipi-dbi-spi.yaml | 30 + > drivers/gpu/drm/drm_mipi_dbi.c | 76 > +++--- > drivers/gpu/drm/tiny/panel-mipi-dbi.c | 55 +++- > include/drm/drm_mipi_dbi.h | 10 +++ > 4 files changed, 147 insertions(+), 24 deletions(-) > --- > base-commit: 0209df3b4731516fe77638bfc52ba2e9629c67cd > change-id: 20240405-panel-mipi-dbi-rgb666-4e033787d6c9 > > Best regards,
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On Fri, Jun 07, 2024 at 08:27:29AM -0600, David Ahern wrote: > On 6/7/24 7:42 AM, Pavel Begunkov wrote: > > I haven't seen any arguments against from the (net) maintainers so > > far. Nor I see any objection against callbacks from them (considering > > that either option adds an if). > > I have said before I do not understand why the dmabuf paradigm is not > sufficient for both device memory and host memory. A less than ideal > control path to put hostmem in a dmabuf wrapper vs extra checks and > changes in the datapath. The former should always be preferred. I think Pavel explained this - his project is principally to replace the lifetime policy of pages in the data plane. He wants to change when a page is considered available for re-allocation because userspace may continue to use the page after the netstack thinks it is done with it. It sounds like having a different source of the pages is the less important part. IMHO it seems to compose poorly if you can only use the io_uring lifecycle model with io_uring registered memory, and not with DMABUF memory registered through Mina's mechanism. Jason
[PATCH] drm/i915/gt: debugfs: Evaluate forcewake usage within locks
The forcewake count and domains listing is multi process critical and the uncore provides a spinlock for such cases. Lock the forcewake evaluation section in the fw_domains_show() debugfs interface. Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c index 4fcba42cfe34..0437fd8217e0 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c @@ -71,6 +71,8 @@ static int fw_domains_show(struct seq_file *m, void *data) struct intel_uncore_forcewake_domain *fw_domain; unsigned int tmp; + spin_lock_irq(>lock); + seq_printf(m, "user.bypass_count = %u\n", uncore->user_forcewake_count); @@ -79,6 +81,8 @@ static int fw_domains_show(struct seq_file *m, void *data) intel_uncore_forcewake_domain_to_str(fw_domain->id), READ_ONCE(fw_domain->wake_count)); + spin_unlock_irq(>lock); + return 0; } DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(fw_domains); -- 2.45.1
Re: [PATCH] drm: have config DRM_WERROR depend on !WERROR
On Fri, 07 Jun 2024, Javier Martinez Canillas wrote:
> Jani Nikula writes:
>
> Hello Jani,
>
>> If WERROR is already enabled, there's no point in enabling DRM_WERROR or
>> asking users about it.
>>
>> Reported-by: Linus Torvalds
>> Closes:
>> https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=veojn6gw8gk4j2v+biduntz...@mail.gmail.com
>> Fixes: f89632a9e5fa ("drm: Add CONFIG_DRM_WERROR")
>> Signed-off-by: Jani Nikula
>> ---
>
> The change makes sense to me.
>
> Reviewed-by: Javier Martinez Canillas
Thanks, pushed to drm-misc-fixes.
BR,
Jani.
--
Jani Nikula, Intel
Re: [PATCH RFC 7/8] drm/sun4i: de3: Implement AFBC support
On Fri, 7 Jun 2024 23:00:03 +1200
Ryan Walklin wrote:
Hi Ryan,
thanks for taking the time and posting those patches!
> Buffers, compressed with AFBC, are generally more efficient for memory
> transfers. Add support for them.
>
> Currently it's implemented only for VI layers, but vendor code and
> documentation suggest UI layers can have them too. However, I haven't
> observed any SoC with such feature.
>
> Signed-off-by: Jernej Skrabec
This signature suggests that it's indeed Jernej's patch, so it should
have his authorship, as in the other patches, indicated by a line starting
with "From:" before the commit message.
> Co-developed-by: Ryan Walklin
Is that really the case? I find an identical patch in Jernej's github,
committed end of February, created late last year. So it's entirely his
patch, then?
"Co-developed-by:" is only used if the patch really has two authors, both
having contributed significantly to the patch.
If you merely post a patch from someone else, then it just needs your
Signed-off-by, as you correctly do below.
That applies to the other patches as well.
Cheers,
Andre
> Signed-off-by: Ryan Walklin
> ---
> drivers/gpu/drm/sun4i/Makefile | 2 +-
> drivers/gpu/drm/sun4i/sun50i_afbc.c| 240 +
> drivers/gpu/drm/sun4i/sun50i_afbc.h| 87 +
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 84 +++--
> 4 files changed, 400 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun50i_afbc.c
> create mode 100644 drivers/gpu/drm/sun4i/sun50i_afbc.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 3f516329f51ee..78290f1660fbd 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -17,7 +17,7 @@ sun8i-drm-hdmi-y+= sun8i_hdmi_phy_clk.o
> sun8i-mixer-y+= sun8i_mixer.o sun8i_ui_layer.o \
> sun8i_vi_layer.o sun8i_ui_scaler.o \
> sun8i_vi_scaler.o sun8i_csc.o \
> -sun50i_fmt.o
> +sun50i_fmt.o sun50i_afbc.o
>
> sun4i-tcon-y += sun4i_crtc.o
> sun4i-tcon-y += sun4i_tcon_dclk.o
> diff --git a/drivers/gpu/drm/sun4i/sun50i_afbc.c
> b/drivers/gpu/drm/sun4i/sun50i_afbc.c
> new file mode 100644
> index 0..27a771608eef8
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun50i_afbc.c
> @@ -0,0 +1,240 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) Jernej Skrabec
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sun50i_afbc.h"
> +#include "sun8i_mixer.h"
> +
> +bool sun50i_afbc_format_mod_supported(struct sun8i_mixer *mixer,
> + u32 format, u64 modifier)
> +{
> + u64 mode;
> +
> + if (modifier == DRM_FORMAT_MOD_INVALID)
> + return false;
> +
> + if (modifier == DRM_FORMAT_MOD_LINEAR) {
> + if (format == DRM_FORMAT_YUV420_8BIT ||
> + format == DRM_FORMAT_YUV420_10BIT ||
> + format == DRM_FORMAT_Y210)
> + return false;
> + return true;
> + }
> +
> + if (!mixer->cfg->is_de3)
> + return false;
> +
> + mode = AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> +AFBC_FORMAT_MOD_SPARSE |
> +AFBC_FORMAT_MOD_SPLIT;
> +
> + switch (format) {
> + case DRM_FORMAT_RGBA:
> + case DRM_FORMAT_RGB888:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_RGBA:
> + case DRM_FORMAT_RGBA5551:
> + case DRM_FORMAT_RGBA1010102:
> + mode |= AFBC_FORMAT_MOD_YTR;
> + break;
> + case DRM_FORMAT_YUYV:
> + case DRM_FORMAT_Y210:
> + case DRM_FORMAT_YUV420_8BIT:
> + case DRM_FORMAT_YUV420_10BIT:
> + break;
> + default:
> + return false;
> + }
> +
> + return modifier == DRM_FORMAT_MOD_ARM_AFBC(mode);
> +}
> +
> +void sun50i_afbc_atomic_update(struct sun8i_mixer *mixer, unsigned int
> channel,
> +struct drm_plane *plane)
> +{
> + struct drm_plane_state *state = plane->state;
> + struct drm_framebuffer *fb = state->fb;
> + const struct drm_format_info *format = fb->format;
> + struct drm_gem_dma_object *gem;
> + u32 base, val, src_w, src_h;
> + u32 def_color0, def_color1;
> + struct regmap *regs;
> + dma_addr_t dma_addr;
> +
> + base = sun8i_channel_base(mixer, cha
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 6/7/24 7:42 AM, Pavel Begunkov wrote: > I haven't seen any arguments against from the (net) maintainers so > far. Nor I see any objection against callbacks from them (considering > that either option adds an if). I have said before I do not understand why the dmabuf paradigm is not sufficient for both device memory and host memory. A less than ideal control path to put hostmem in a dmabuf wrapper vs extra checks and changes in the datapath. The former should always be preferred. I also do not understand why the ifq cache and overloading xdp functions have stuck around; I always thought both were added by Jonathan to simplify kernel ports during early POC days.
Re: [PATCH RFC 1/8] dt-bindings: bus: allwinner: add H616 DE33 bindings
On Fri, Jun 07, 2024 at 10:59:57PM +1200, Ryan Walklin wrote: > The Allwinner H616 and variants have a new display engine revision > (DE33). > > Add display engine bus, clock and mixer bindings for the DE33. > > Signed-off-by: Ryan Walklin > --- > .../devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml| 1 + > .../devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml | 1 + > .../bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml | 1 + > 3 files changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml > b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml > index 9845a187bdf65..65f4522e79879 100644 > --- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml > +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml > @@ -25,6 +25,7 @@ properties: >- const: allwinner,sun50i-a64-de2 >- items: >- const: allwinner,sun50i-h6-de3 > + - const: allwinner,sun50i-h616-de33 >- const: allwinner,sun50i-a64-de2 This does not do what you think it does! It needs to be items: - enum: - h6 - h616 - const: a64 > >reg: > diff --git > a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml > b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml > index 70369bd633e40..7fcd55d468d49 100644 > --- > a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml > +++ > b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml > @@ -25,6 +25,7 @@ properties: >- const: allwinner,sun50i-a64-de2-clk >- const: allwinner,sun50i-h5-de2-clk >- const: allwinner,sun50i-h6-de3-clk > + - const: allwinner,sun50i-h616-de33-clk I think this is not right, as a corresponding driver change is missing. Either you're missing a clock driver patch or you didn't test your dts. Given the bus binding, I suspect that latter. >- items: >- const: allwinner,sun8i-r40-de2-clk >- const: allwinner,sun8i-h3-de2-clk > diff --git > a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml > > b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml > index b75c1ec686ad2..c37eb8ae1b8ee 100644 > --- > a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml > +++ > b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml > @@ -24,6 +24,7 @@ properties: >- allwinner,sun50i-a64-de2-mixer-0 >- allwinner,sun50i-a64-de2-mixer-1 >- allwinner,sun50i-h6-de3-mixer-0 > + - allwinner,sun50i-h616-de33-mixer-0 Your commit message should mention why a fallback is not suitable here. Thanks, Conor. signature.asc Description: PGP signature
[PATCH] drm/msm/a6xx: request memory region
The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.
Implement the region-request through the corresponding managed
devres-function.
Signed-off-by: Kiarash Hajian
---
To: Rob Clark
To: Abhinav Kumar
To: Dmitry Baryshkov
To: Sean Paul
To: Marijn Suijten
To: David Airlie
To: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Kiarash Hajian
Changes in v5:
- Fix errorhanlding problems.
- Link to v4:
https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v4-1-3881a6408...@gmail.com
Changes in v4:
- Combine v3 commits into a singel commit
- Link to v3:
https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v3-0-0a728ad45...@gmail.com
Changes in v3:
- Remove redundant devm_iounmap calls, relying on devres for automatic
resource cleanup.
Changes in v2:
- update the subject prefix to "drm/msm/a6xx:", to match the majority of
other changes to this file.
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 8bea8ef26f77..35323bf2d844 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -635,10 +635,12 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
a6xx_rpmh_stop(gmu);
err:
- if (!IS_ERR_OR_NULL(pdcptr))
- iounmap(pdcptr);
- if (!IS_ERR_OR_NULL(seqptr))
- iounmap(seqptr);
+ if (!IS_ERR_OR_NULL(pdcptr)){
+return ERR_PTR(-EINVAL);
+ }
+ if (!IS_ERR_OR_NULL(seqptr)){
+return ERR_PTR(-EINVAL);
+ }
}
/*
@@ -1503,7 +1505,7 @@ static void __iomem *a6xx_gmu_get_mmio(struct
platform_device *pdev,
return ERR_PTR(-EINVAL);
}
- ret = ioremap(res->start, resource_size(res));
+ ret = devm_ioremap_resource(>dev, res);
if (!ret) {
DRM_DEV_ERROR(>dev, "Unable to map the %s registers\n",
name);
return ERR_PTR(-EINVAL);
@@ -1613,13 +1615,13 @@ int a6xx_gmu_wrapper_init(struct a6xx_gpu *a6xx_gpu,
struct device_node *node)
gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
if (IS_ERR(gmu->mmio)) {
ret = PTR_ERR(gmu->mmio);
- goto err_mmio;
+ goto err_cleanup;
}
gmu->cxpd = dev_pm_domain_attach_by_name(gmu->dev, "cx");
if (IS_ERR(gmu->cxpd)) {
ret = PTR_ERR(gmu->cxpd);
- goto err_mmio;
+ goto err_cleanup;
}
if (!device_link_add(gmu->dev, gmu->cxpd, DL_FLAG_PM_RUNTIME)) {
@@ -1635,7 +1637,7 @@ int a6xx_gmu_wrapper_init(struct a6xx_gpu *a6xx_gpu,
struct device_node *node)
gmu->gxpd = dev_pm_domain_attach_by_name(gmu->dev, "gx");
if (IS_ERR(gmu->gxpd)) {
ret = PTR_ERR(gmu->gxpd);
- goto err_mmio;
+ goto err_cleanup;
}
gmu->initialized = true;
@@ -1645,9 +1647,7 @@ int a6xx_gmu_wrapper_init(struct a6xx_gpu *a6xx_gpu,
struct device_node *node)
detach_cxpd:
dev_pm_domain_detach(gmu->cxpd, false);
-err_mmio:
- iounmap(gmu->mmio);
-
+err_cleanup:
/* Drop reference taken in of_find_device_by_node */
put_device(gmu->dev);
@@ -1762,7 +1762,7 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
gmu->rscc = a6xx_gmu_get_mmio(pdev, "rscc");
if (IS_ERR(gmu->rscc)) {
ret = -ENODEV;
- goto err_mmio;
+ goto err_cleanup;
}
} else {
gmu->rscc = gmu->mmio + 0x23000;
@@ -1774,13 +1774,13 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0) {
ret = -ENODEV;
- goto err_mmio;
+ goto err_cleanup;
}
gmu->cxpd = dev_pm_domain_attach_by_name(gmu->dev, "cx");
if (IS_ERR(gmu->cxpd)) {
ret = PTR_ERR(gmu->cxpd);
- goto err_mmio;
+ goto err_cleanup;
}
link = device_link_add(gmu->dev, gmu->cxpd, DL_FLAG_PM_RUNTIME);
@@ -1824,10 +1824,7 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
detach_cxpd:
dev_pm_domain_detach(gmu->cxpd, false);
-err_mmio:
- iounmap(gmu->mmio);
- if (platform_get_resource_byname(pdev, IORESOURCE_MEM, "rscc"))
- iounmap(gmu->rscc);
+err_cleanup:
free_irq(gmu->gmu_irq, gmu);
free_irq(gmu->hfi_irq, gmu);
---
base-commit: 1b294a1f35616977caddaddf3e9d28e576a1adbc
Re: [PATCH v6 05/26] drm/display: Add missing Panel Replay Enable SU Region ET bit
On Wed, 2024-06-05 at 13:31 +0300, Jouni Högander wrote: > Add missing Panel Replay Enable SU Region ET bit defined in DP2.1 > specification. Hello drm-core maintainers, Could you please consider providing your ack on this patch? I'm planning to merge it via drm-intel tree. I have already r-b tag. BR, Jouni Högander > > Signed-off-by: Jouni Högander > --- > include/drm/display/drm_dp.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/drm/display/drm_dp.h > b/include/drm/display/drm_dp.h > index f246fa03a3cb..173548c6473a 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -743,6 +743,7 @@ > # define DP_PANEL_REPLAY_RFB_STORAGE_ERROR_EN (1 << 4) > # define DP_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR_EN (1 << 5) > # define DP_PANEL_REPLAY_SU_ENABLE (1 << 6) > +# define DP_PANEL_REPLAY_ENABLE_SU_REGION_ET (1 << 7) /* > DP 2.1 */ > > #define PANEL_REPLAY_CONFIG2 > 0x1b1 /* eDP 1.5 */ > # define DP_PANEL_REPLAY_SINK_REFRESH_RATE_UNLOCK_GRANTED (1 > << 0)
Re: [PATCH v3 1/4] drm/sched: store the drm_device instead of the device
Hi,
Le 06/06/2024 à 15:18, Christian König a écrit :
Am 06.06.24 um 15:06 schrieb Pierre-Eric Pelloux-Prayer:
When tracing is enabled, being able to identify which device is sending
events is useful; for this the next commit will extend events to include
drm_device::primary::index.
That sounds like a rather bad idea since the primary index is really
just an arbitrary number and not defined for all devices.
Why not use the device name instead? This way you don't need this change
in the first place.
Good point, it's indeed a better idea. I'll drop this patch and will
update the next one.
Thanks,
Pierre-Eric
Regards,
Christian.
Since the device member is only used in the drm_* log macros, we can
replace it by a drm_device pointer.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 +-
drivers/gpu/drm/imagination/pvr_queue.c | 2 +-
drivers/gpu/drm/lima/lima_sched.c | 2 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_sched.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/panthor/panthor_mmu.c | 2 +-
drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 26 +++---
drivers/gpu/drm/v3d/v3d_sched.c | 12 +-
drivers/gpu/drm/xe/xe_execlist.c | 2 +-
drivers/gpu/drm/xe/xe_gpu_scheduler.c | 2 +-
drivers/gpu/drm/xe/xe_gpu_scheduler.h | 2 +-
drivers/gpu/drm/xe/xe_guc_submit.c | 2 +-
include/drm/gpu_scheduler.h | 4 ++--
17 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 932dc93b2e63..7f2a68ad8034 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2738,7 +2738,7 @@ static int amdgpu_device_init_schedulers(struct
amdgpu_device *adev)
ring->num_hw_submission, 0,
timeout, adev->reset_domain->wq,
ring->sched_score, ring->name,
- adev->dev);
+ >ddev);
if (r) {
DRM_ERROR("Failed to create scheduler on ring %s.\n",
ring->name);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index c4b04b0dee16..c4345b68a51f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -138,7 +138,7 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
DRM_SCHED_PRIORITY_COUNT,
etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
msecs_to_jiffies(500), NULL, NULL,
- dev_name(gpu->dev), gpu->dev);
+ dev_name(gpu->dev), gpu->drm);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/imagination/pvr_queue.c
b/drivers/gpu/drm/imagination/pvr_queue.c
index 5ed9c98fb599..cdbb6c01e952 100644
--- a/drivers/gpu/drm/imagination/pvr_queue.c
+++ b/drivers/gpu/drm/imagination/pvr_queue.c
@@ -1287,7 +1287,7 @@ struct pvr_queue *pvr_queue_create(struct
pvr_context *ctx,
pvr_dev->sched_wq, 1, 64 * 1024, 1,
msecs_to_jiffies(500),
pvr_dev->sched_wq, NULL, "pvr-queue",
- pvr_dev->base.dev);
+ _dev->base);
if (err)
goto err_release_ufo;
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index bbf3f8feab94..db6ee7650468 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -526,7 +526,7 @@ int lima_sched_pipe_init(struct lima_sched_pipe
*pipe, const char *name)
1,
lima_job_hang_limit,
msecs_to_jiffies(timeout), NULL,
- NULL, name, pipe->ldev->dev);
+ NULL, name, pipe->ldev->ddev);
}
void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 9d6655f96f0c..3a4b3816f2c9 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -101,7 +101,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct
msm_gpu *gpu, int id,
ret = drm_sched_init(>sched, _sched_ops, NULL,
DRM_SCHED_PRIORITY_COUNT,
num_hw_submissions, 0, sched_timeout,
- NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev->dev);
+ NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev);
if (ret) {
goto fail;
}
diff --git
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 6/5/24 09:24, Christoph Hellwig wrote: On Mon, Jun 03, 2024 at 03:52:32PM +0100, Pavel Begunkov wrote: The question for Christoph is what exactly is the objection here? Why we would not be using well defined ops when we know there will be more users? The point is that there should be no more users. If you need another Does that "No more" stops after devmem tcp? Or after io_uring proposal? For the latter I explained why io_uring has to do it for good design and that's it's not even related to the memory type used. case you are doing something very wrong. That's not a very illuminating answer -- Pavel Begunkov
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 6/3/24 16:43, Mina Almasry wrote: On Mon, Jun 3, 2024 at 7:52 AM Pavel Begunkov wrote: On 6/3/24 15:17, Mina Almasry wrote: On Fri, May 31, 2024 at 10:35 PM Christoph Hellwig wrote: On Thu, May 30, 2024 at 08:16:01PM +, Mina Almasry wrote: I'm unsure if the discussion has been resolved yet. Sending the series anyway to get reviews/feedback on the (unrelated) rest of the series. As far as I'm concerned it is not. I've not seen any convincing argument for more than page/folio allocator including larger order / huge page and dmabuf. Thanks Christoph, this particular patch series adds dmabuf, so I assume no objection there. I assume the objection is that you want the generic, extensible hooks removed. To be honest, I don't think the hooks are an integral part of the design, and at this point I think we've argued for them enough. I think we can easily achieve the same thing with just raw if statements in a couple of places. We can always add the hooks if and only if we actually justify many memory providers. Any objections to me removing the hooks and directing to memory allocations via simple if statements? Something like (very rough draft, doesn't compile): The question for Christoph is what exactly is the objection here? Why we would not be using well defined ops when we know there will be more users? Repeating what I said in the last thread, for io_uring it's used to implement the flow of buffers from userspace to the kernel, the ABI, which is orthogonal to the issue of what memory type it is and how it came there. And even if you mandate unnecessary dmabuf condoms for user memory in one form or another IMHO for no clear reason, the callbacks (or yet another if-else) would still be needed. Sure, Mina can drop and hard code devmem path to easy the pain for him and delay the discussion, but then shortly after I will be re-sending same shit. You don't need to re-send the same ops again, right? You can add io uring support without ops. Something like: diff --git a/net/core/page_pool.c b/net/core/page_pool.c index 92be1aaf18ccc..2cc986455bce6 100644 --- a/net/core/page_pool.c +++ b/net/core/page_pool.c @@ -557,8 +557,8 @@ netmem_ref page_pool_alloc_netmem(struct page_pool *pool, gfp_t gfp) return netmem; /* Slow-path: cache empty, do real allocation */ - if (static_branch_unlikely(_pool_mem_providers) && pool->mp_ops) - netmem = pool->mp_ops->alloc_pages(pool, gfp); + if (unlikely(page_pool_is_dmabuf(pool))) + netmem = mp_dmabuf_devmem_alloc_pages(): + else if (unlikely(page_pool_is_iouring(pool))) + netmem = mp_io_uring_alloc_pages(): else netmem = __page_pool_alloc_pages_slow(pool, gfp); return netmem; So IMO, the ops themselves, which Christoph is repeatedly nacking, are not that important. I humbly think the energy should be spent convincing maintainers of the use case of io uring memory, not the ops. The ops are a cosmetic I haven't seen any arguments against from the (net) maintainers so far. Nor I see any objection against callbacks from them (considering that either option adds an if). And just not to confuse folks, it's just user pages, not some weird special io_uring memory. change to the code, and can be added later. Christoph is nacking the ops because it gives people too much rope [1]. Yes, it is cosmetic, just as much as removing it is a cosmetic change. You can apply same "too much rope" argument basically to anything. Take io_uring, nothing would change in the process, it'd still be sent to net and reviewed exactly same way, while being less clean, with poorer subsystem separation, allowing custom formats / argument list, etc. I think it's cleaner with callbacks, Mr. Christoph has other beliefs and keeps coercing to them, even though from time to time it backfires for the author, just personal experience. But if you disagree and think the ops themselves are important for a reason I missed, I'm happy waiting until agreement is reached here. Sorry, just voicing my 2 cents. [1] https://lore.kernel.org/netdev/zjjhuh1einpg1...@infradead.org/ -- Pavel Begunkov
Re: [PATCH] drm/v3d: Fix perfmon build error/warning
On 05/06/2024 08:19, Iago Toral wrote:
Thanks for looking at ixing this Tvrtko.
El mar, 04-06-2024 a las 17:02 +0100, Tvrtko Ursulin escribió:
From: Tvrtko Ursulin
Move static const array into the source file to fix the "defined but
not
used" errors.
The fix is perhaps not the prettiest due hand crafting the array
sizes
in v3d_performance_counters.h, but I did add some build time asserts
to
validate the counts look sensible, so hopefully it is good enough for
a
quick fix.
If we need this to go in ASAP I am fine with this patch as-is, so:
Reviewed-by: Iago Toral Quiroga
With that said, if we are still in time for a bit of iteration may I
suggest that instead of hard-coding the counters we instead add helper
functions in drivers/gpu/drm/v3d/v3d_perfmon.c that call ARRAY_SIZE on
the corresponding array based on v3d->ver? It is fine if we prefer to
merge this as-is and do this change later as a follow-up patch.
I agree it isn't pretty and I was (and am) planning to see if things can
be improved. The reason I gave up on a prettier solution in the original
attempt is the the fact one array is statically sized (at build time)
based on the max number of counters:
/* Number of perfmons required to handle all supported performance
counters */
#define V3D_MAX_PERFMONS DIV_ROUND_UP(V3D_MAX_COUNTERS, \
DRM_V3D_MAX_PERF_COUNTERS)
struct v3d_performance_query {
/* Performance monitor IDs for this query */
u32 kperfmon_ids[V3D_MAX_PERFMONS];
So need to see how to untangle that and then perhaps even go a step
further than the getters but move the whole perfmon init into v3d_perfmon.c.
Regards,
Tvrtko
Iago
Signed-off-by: Tvrtko Ursulin
Fixes: 3cbcbe016c31 ("drm/v3d: Add Performance Counters descriptions
for V3D 4.2 and 7.1")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202405211137.huefklkg-...@intel.com/Cc
: Maíra Canal
Cc: Iago Toral Quiroga
Cc: Jani Nikula
Cc: Ashutosh Dixit
---
drivers/gpu/drm/v3d/v3d_drv.c | 4 +-
drivers/gpu/drm/v3d/v3d_drv.h | 3 -
drivers/gpu/drm/v3d/v3d_perfmon.c | 204
+-
.../gpu/drm/v3d/v3d_performance_counters.h | 189 +---
4 files changed, 205 insertions(+), 195 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c
b/drivers/gpu/drm/v3d/v3d_drv.c
index f7477488b1cc..a47f00b443d3 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -299,9 +299,9 @@ static int v3d_platform_drm_probe(struct
platform_device *pdev)
WARN_ON(v3d->cores > 1); /* multicore not yet implemented */
if (v3d->ver >= 71)
- v3d->max_counters =
ARRAY_SIZE(v3d_v71_performance_counters);
+ v3d->max_counters = V3D_V71_NUM_PERFCOUNTERS;
else if (v3d->ver >= 42)
- v3d->max_counters =
ARRAY_SIZE(v3d_v42_performance_counters);
+ v3d->max_counters = V3D_V42_NUM_PERFCOUNTERS;
else
v3d->max_counters = 0;
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h
b/drivers/gpu/drm/v3d/v3d_drv.h
index 556cbb400ba0..099b962bdfde 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -351,9 +351,6 @@ struct v3d_timestamp_query {
struct drm_syncobj *syncobj;
};
-/* Maximum number of performance counters supported by any version
of V3D */
-#define V3D_MAX_COUNTERS ARRAY_SIZE(v3d_v71_performance_counters)
-
/* Number of perfmons required to handle all supported performance
counters */
#define V3D_MAX_PERFMONS DIV_ROUND_UP(V3D_MAX_COUNTERS, \
DRM_V3D_MAX_PERF_COUNTERS)
diff --git a/drivers/gpu/drm/v3d/v3d_perfmon.c
b/drivers/gpu/drm/v3d/v3d_perfmon.c
index 73e2bb8bdb7f..b7d0b02e1a95 100644
--- a/drivers/gpu/drm/v3d/v3d_perfmon.c
+++ b/drivers/gpu/drm/v3d/v3d_perfmon.c
@@ -9,6 +9,192 @@
#define V3D_PERFMONID_MIN 1
#define V3D_PERFMONID_MAX U32_MAX
+static const struct v3d_perf_counter_desc
v3d_v42_performance_counters[] = {
+ {"FEP", "FEP-valid-primitives-no-rendered-pixels", "[FEP]
Valid primitives that result in no rendered pixels, for all rendered
tiles"},
+ {"FEP", "FEP-valid-primitives-rendered-pixels", "[FEP] Valid
primitives for all rendered tiles (primitives may be counted in more
than one tile)"},
+ {"FEP", "FEP-clipped-quads", "[FEP] Early-Z/Near/Far clipped
quads"},
+ {"FEP", "FEP-valid-quads", "[FEP] Valid quads"},
+ {"TLB", "TLB-quads-not-passing-stencil-test", "[TLB] Quads
with no pixels passing the stencil test"},
+ {"TLB", "TLB-quads-not-passing-z-and-stencil-test", "[TLB]
Quads with no pixels passing the Z and stencil tests"},
+ {"TLB", "TL
[PATCH v13 13/13] gpu: ipu-v3: Use generic macro for rounding closest to specified value
Use generic macro round_closest_up() for rounding closest to specified value instead of using local macro round_closest(). There is no change from functionality point of view as round_closest_up() is functionally same as the previously used local macro round_closest(). Signed-off-by: Devarsh Thakkar --- V9-V13: No change V8: Update commit message V1->V7 : (No change, patch introduced in V7) drivers/gpu/ipu-v3/ipu-image-convert.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c b/drivers/gpu/ipu-v3/ipu-image-convert.c index 841316582ea9..5192a8b5c02c 100644 --- a/drivers/gpu/ipu-v3/ipu-image-convert.c +++ b/drivers/gpu/ipu-v3/ipu-image-convert.c @@ -477,8 +477,6 @@ static int calc_image_resize_coefficients(struct ipu_image_convert_ctx *ctx, return 0; } -#define round_closest(x, y) round_down((x) + (y)/2, (y)) - /* * Find the best aligned seam position for the given column / row index. * Rotation and image offsets are out of scope. @@ -565,7 +563,7 @@ static void find_best_seam(struct ipu_image_convert_ctx *ctx, * The closest input sample position that we could actually * start the input tile at, 19.13 fixed point. */ - in_pos_aligned = round_closest(in_pos, 8192U * in_align); + in_pos_aligned = round_closest_up(in_pos, 8192U * in_align); /* Convert 19.13 fixed point to integer */ in_pos_rounded = in_pos_aligned / 8192U; -- 2.39.1
Re: [RFC PATCH 7/8] rust: add firmware abstractions
On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > Anyway, that's all hand-wavy right now, sorry, to get back to the point > here, again, let's take this, which will allow the firmware bindings to > be resubmitted and hopefully accepted, and we can move forward from > there to "real" things like a USB or PCI or even platform device and > driver binding stuff. In order to continue I propose to send out the following series: 1) minimal device and firmware abstractions only 2) v2 of all other device / driver, devres and PCI driver abstractions 3) v2 of basic DRM driver abstractions and Nova The v2 series would contain static driver allocation (in case of DRM even const) and quite a few more simplifications around `driver::Registration` and `device::Data`. Does that make sense? - Danilo > > thanks, > > greg k-h >
[PATCH v13 12/13] media: imagination: Round to closest multiple for cropping region
If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
(V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
multiple of requested value while updating the crop rectangle coordinates.
Use the rounding macro which gives preference to rounding down in case two
nearest values (high and low) are possible to raise the probability of
cropping rectangle falling inside the bound region.
This complies with the VIDIOC_G_SELECTION, VIDIOC_S_SELECTION ioctl
description as documented in v4l uapi [1] which specifies that driver
should choose crop rectangle as close as possible if no flags are passed by
user-space, as quoted below :
"``0`` - The driver can adjust the rectangle size freely and shall choose a
crop/compose rectangle as close as possible to the requested
one."
Link:
https://www.kernel.org/doc/Documentation/userspace-api/media/v4l/vidioc-g-selection.rst
[1]
Signed-off-by: Devarsh Thakkar
---
V9->V13: No change
V8: Update commit message with specification reference
V1->V7 (No change, patch introduced in V7)
---
drivers/media/platform/imagination/e5010-jpeg-enc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/imagination/e5010-jpeg-enc.c
b/drivers/media/platform/imagination/e5010-jpeg-enc.c
index 4b6fbe99d5ff..ea96b1bc5315 100644
--- a/drivers/media/platform/imagination/e5010-jpeg-enc.c
+++ b/drivers/media/platform/imagination/e5010-jpeg-enc.c
@@ -517,10 +517,10 @@ static int e5010_s_selection(struct file *file, void *fh,
struct v4l2_selection
switch (s->flags) {
case 0:
- s->r.width = round_down(s->r.width,
queue->fmt->frmsize.step_width);
- s->r.height = round_down(s->r.height,
queue->fmt->frmsize.step_height);
- s->r.left = round_down(s->r.left,
queue->fmt->frmsize.step_width);
- s->r.top = round_down(s->r.top, 2);
+ s->r.width = round_closest_down(s->r.width,
queue->fmt->frmsize.step_width);
+ s->r.height = round_closest_down(s->r.height,
queue->fmt->frmsize.step_height);
+ s->r.left = round_closest_down(s->r.left,
queue->fmt->frmsize.step_width);
+ s->r.top = round_closest_down(s->r.top, 2);
if (s->r.left + s->r.width > queue->width)
s->r.width = round_down(s->r.width + s->r.left -
queue->width,
--
2.39.1
[PATCH v13 11/13] lib: math_kunit: Add tests for new macros related to rounding to nearest value
Add tests for round_closest_up/down and roundclosest macros which round
to nearest multiple of specified argument. These are tested with kunit
tool as shared here [1] :
Link: https://gist.github.com/devarsht/3f9042825be3da4e133b8f4eda067876 [1]
Signed-off-by: Devarsh Thakkar
Acked-by: Andy Shevchenko
---
V1->V13 (No change, patch introduced in V8)
lib/math/math_kunit.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/lib/math/math_kunit.c b/lib/math/math_kunit.c
index be27f2afb8e4..05022f010be6 100644
--- a/lib/math/math_kunit.c
+++ b/lib/math/math_kunit.c
@@ -70,6 +70,26 @@ static void round_down_test(struct kunit *test)
KUNIT_EXPECT_EQ(test, round_down((1 << 30) - 1, 1 << 29), 1 << 29);
}
+static void round_closest_up_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, round_closest_up(17, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_up(15, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_up(14, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_up((1 << 30) - 1, 1 << 30), 1 <<
30);
+ KUNIT_EXPECT_EQ(test, round_closest_up((1 << 30) + 1, 1 << 30), 1 <<
30);
+ KUNIT_EXPECT_EQ(test, round_closest_up((1 << 30) - 1, 2), 1 << 30);
+}
+
+static void round_closest_down_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, round_closest_down(17, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_down(15, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_down(14, 4), 12);
+ KUNIT_EXPECT_EQ(test, round_closest_down((1 << 30) - 1, 1 << 30), 1 <<
30);
+ KUNIT_EXPECT_EQ(test, round_closest_down((1 << 30) + 1, 1 << 30), 1 <<
30);
+ KUNIT_EXPECT_EQ(test, round_closest_down((1 << 30) - 1, 2), (1 << 30) -
2);
+}
+
/* These versions can round to numbers that aren't a power of two */
static void roundup_test(struct kunit *test)
{
@@ -95,6 +115,18 @@ static void rounddown_test(struct kunit *test)
KUNIT_EXPECT_EQ(test, rounddown(4, 3), 3);
}
+static void roundclosest_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, roundclosest(21, 5), 20);
+ KUNIT_EXPECT_EQ(test, roundclosest(19, 5), 20);
+ KUNIT_EXPECT_EQ(test, roundclosest(17, 5), 15);
+ KUNIT_EXPECT_EQ(test, roundclosest((1 << 30), 3), (1 << 30) - 1);
+ KUNIT_EXPECT_EQ(test, roundclosest((1 << 30) - 1, 1 << 29), 1 << 30);
+
+ KUNIT_EXPECT_EQ(test, roundclosest(4, 3), 3);
+ KUNIT_EXPECT_EQ(test, roundclosest(5, 3), 6);
+}
+
static void div_round_up_test(struct kunit *test)
{
KUNIT_EXPECT_EQ(test, DIV_ROUND_UP(0, 1), 0);
@@ -272,8 +304,11 @@ static struct kunit_case math_test_cases[] = {
KUNIT_CASE(int_sqrt_test),
KUNIT_CASE(round_up_test),
KUNIT_CASE(round_down_test),
+ KUNIT_CASE(round_closest_up_test),
+ KUNIT_CASE(round_closest_down_test),
KUNIT_CASE(roundup_test),
KUNIT_CASE(rounddown_test),
+ KUNIT_CASE(roundclosest_test),
KUNIT_CASE(div_round_up_test),
KUNIT_CASE(div_round_closest_test),
KUNIT_CASE_PARAM(gcd_test, gcd_gen_params),
--
2.39.1
[PATCH v13 10/13] lib: add basic KUnit test for lib/math
From: Daniel Latypov
Add basic test coverage for files that don't require any config options:
* part of math.h (what seem to be the most commonly used macros)
* gcd.c
* lcm.c
* int_sqrt.c
* reciprocal_div.c
(Ignored int_pow.c since it's a simple textbook algorithm.)
These tests aren't particularly interesting, but they
* provide short and simple examples of parameterized tests
* provide a place to add tests for any new files in this dir
* are written so adding new test cases to cover edge cases should be
easy
* looking at code coverage, we hit all the branches in the .c files
Signed-off-by: Daniel Latypov
Reviewed-by: David Gow
Reviewed-by: Andy Shevchenko
[devarsht: Rebase to 6.9, remove kernel.h, update Kconfig and change license to
GPL]
Signed-off-by: Devarsh Thakkar
---
Changes since v11:
* Add Reviewed-by tag
Changes since v10:
* Include headers per IWYU principle and add module description
Changes since v9:
* Added Kconfig dependency for KUNIT
Changes since v8:
* Remove unrequired header file linux/kernel.h
Changes since v7:
* Rebase to linux-next, change license to GPL as suggested by checkpatch.
Changes since v6:
* No change
Changes since v5:
* add in test cases for roundup/rounddown
* address misc comments from David
Changes since v4:
* add in test cases for some math.h macros (abs, round_up/round_down,
div_round_down/closest)
* use parameterized testing less to keep things terser
Changes since v3:
* fix `checkpatch.pl --strict` warnings
* add test cases for gcd(0,0) and lcm(0,0)
* minor: don't test both gcd(a,b) and gcd(b,a) when a == b
Changes since v2: mv math_test.c => math_kunit.c
Changes since v1:
* Rebase and rewrite to use the new parameterized testing support.
* misc: fix overflow in literal and inline int_sqrt format string.
* related: commit 1f0e943df68a ("Documentation: kunit: provide guidance
for testing many inputs") was merged explaining the patterns shown here.
* there's an in-flight patch to update it for parameterized testing.
---
lib/math/Kconfig | 14 ++
lib/math/Makefile | 1 +
lib/math/math_kunit.c | 294 ++
3 files changed, 309 insertions(+)
create mode 100644 lib/math/math_kunit.c
diff --git a/lib/math/Kconfig b/lib/math/Kconfig
index 0634b428d0cb..f738d8a433ea 100644
--- a/lib/math/Kconfig
+++ b/lib/math/Kconfig
@@ -15,3 +15,17 @@ config PRIME_NUMBERS
config RATIONAL
tristate
+
+config MATH_KUNIT_TEST
+ tristate "KUnit test for math helper functions"
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+
+ help
+ This builds unit test for math helper functions as defined in lib/math
+ and math.h.
+
+ For more information on KUNIT and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
diff --git a/lib/math/Makefile b/lib/math/Makefile
index 91fcdb0c9efe..dcf65d10dab2 100644
--- a/lib/math/Makefile
+++ b/lib/math/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_RATIONAL) += rational.o
obj-$(CONFIG_TEST_DIV64) += test_div64.o
obj-$(CONFIG_RATIONAL_KUNIT_TEST) += rational-test.o
+obj-$(CONFIG_MATH_KUNIT_TEST) += math_kunit.o
diff --git a/lib/math/math_kunit.c b/lib/math/math_kunit.c
new file mode 100644
index ..be27f2afb8e4
--- /dev/null
+++ b/lib/math/math_kunit.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Simple KUnit suite for math helper funcs that are always enabled.
+ *
+ * Copyright (C) 2020, Google LLC.
+ * Author: Daniel Latypov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void abs_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, abs((char)0), (char)0);
+ KUNIT_EXPECT_EQ(test, abs((char)42), (char)42);
+ KUNIT_EXPECT_EQ(test, abs((char)-42), (char)42);
+
+ /* The expression in the macro is actually promoted to an int. */
+ KUNIT_EXPECT_EQ(test, abs((short)0), 0);
+ KUNIT_EXPECT_EQ(test, abs((short)42), 42);
+ KUNIT_EXPECT_EQ(test, abs((short)-42), 42);
+
+ KUNIT_EXPECT_EQ(test, abs(0), 0);
+ KUNIT_EXPECT_EQ(test, abs(42), 42);
+ KUNIT_EXPECT_EQ(test, abs(-42), 42);
+
+ KUNIT_EXPECT_EQ(test, abs(0L), 0L);
+ KUNIT_EXPECT_EQ(test, abs(42L), 42L);
+ KUNIT_EXPECT_EQ(test, abs(-42L), 42L);
+
+ KUNIT_EXPECT_EQ(test, abs(0LL), 0LL);
+ KUNIT_EXPECT_EQ(test, abs(42LL), 42LL);
+ KUNIT_EXPECT_EQ(test, abs(-42LL), 42LL);
+
+ /* Unsigned types get casted to signed. */
+ KUNIT_EXPECT_EQ(test, abs(0ULL), 0LL);
+ KUNIT_EXPECT_EQ(test, abs(42ULL), 42LL);
+}
+
+static void int_sqrt_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, int_sqrt(0UL), 0UL);
+ KUNIT_EXPECT_EQ(test, int_sqrt(1UL), 1UL);
+ KUNIT_EXPECT_EQ(test, int_sqrt(4UL), 2UL);
+ KUNIT_EXPECT_EQ(test, int_sqrt(5UL), 2UL);
+ KUNIT_EXPECT_EQ(t
[PATCH v13 09/13] Documentation: core-api: Add math.h macros and functions
Add documentation for rounding, scaling, absolute value and 32-bit division related macros and functions exported by math.h header file. Signed-off-by: Devarsh Thakkar Reviewed-by: Andy Shevchenko --- V13: No change V12: Add Reviewed-by V11: Fix title for math function header V10: Patch introduced V1->V9 (No change) Documentation/core-api/kernel-api.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index ae92a2571388..7de494e76fa6 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -185,6 +185,12 @@ Division Functions .. kernel-doc:: lib/math/gcd.c :export: +Rounding, absolute value, division and 32-bit scaling functions +--- + +.. kernel-doc:: include/linux/math.h + :internal: + UUID/GUID - -- 2.39.1
[PATCH v13 07/13] math.h: Add macros for rounding to closest value
Add below rounding related macros: round_closest_up(x, y) : Rounds x to closest multiple of y where y is a power of 2, with a preference to round up in case two nearest values are possible. round_closest_down(x, y) : Rounds x to closest multiple of y where y is a power of 2, with a preference to round down in case two nearest values are possible. roundclosest(x, y) : Rounds x to closest multiple of y, this macro should generally be used only when y is not multiple of 2 as otherwise round_closest* macros should be used which are much faster. Examples: * round_closest_up(17, 4) = 16 * round_closest_up(15, 4) = 16 * round_closest_up(14, 4) = 16 * round_closest_down(17, 4) = 16 * round_closest_down(15, 4) = 16 * round_closest_down(14, 4) = 12 * roundclosest(21, 5) = 20 * roundclosest(19, 5) = 20 * roundclosest(17, 5) = 15 Signed-off-by: Devarsh Thakkar Acked-by: Andy Shevchenko --- NOTE: This patch is inspired from the Mentor Graphics IPU driver [1] which uses similar macro locally and which is updated in further patch in the series to use this generic macro instead along with other drivers having similar requirements. Link: https://elixir.bootlin.com/linux/v6.8.9/source/drivers/gpu/ipu-v3/ipu-image-convert.c#L480 [1] V13: - No change V12: - Add Acked-by V11: - Fix commenting style per review comments and remove extra whitespace V10: - Update example comment to fix formatting issues as observed with html docs V9: - No change V8: - Add new macro to round to nearest value for non-multiple of 2 - Update commit message as suggested: V1->V6 (No change, patch introduced in V7) include/linux/math.h | 63 1 file changed, 63 insertions(+) diff --git a/include/linux/math.h b/include/linux/math.h index dd4152711de7..79e3dfda77fc 100644 --- a/include/linux/math.h +++ b/include/linux/math.h @@ -34,6 +34,52 @@ */ #define round_down(x, y) ((x) & ~__round_mask(x, y)) +/** + * round_closest_up - round closest to be multiple of specified value (which is + *power of 2) with preference to rounding up + * @x: the value to round + * @y: multiple to round closest to (must be a power of 2) + * + * Rounds @x to closest multiple of @y (which must be a power of 2). + * The value can be either rounded up or rounded down depending upon rounded + * value's closeness to the specified value. If there are two closest possible + * values, i.e. the difference between the specified value and it's rounded up + * and rounded down values is same then preference is given to rounded up + * value. + * + * To perform arbitrary rounding to closest value (not multiple of 2), use + * roundclosest(). + * + * Examples: + * * round_closest_up(17, 4) = 16 + * * round_closest_up(15, 4) = 16 + * * round_closest_up(14, 4) = 16 + */ +#define round_closest_up(x, y) round_down((x) + (y) / 2, (y)) + +/** + * round_closest_down - round closest to be multiple of specified value (which + * is power of 2) with preference to rounding down + * @x: the value to round + * @y: multiple to round closest to (must be a power of 2) + * + * Rounds @x to closest multiple of @y (which must be a power of 2). + * The value can be either rounded up or rounded down depending upon rounded + * value's closeness to the specified value. If there are two closest possible + * values, i.e. the difference between the specified value and it's rounded up + * and rounded down values is same then preference is given to rounded up + * value. + * + * To perform arbitrary rounding to closest value (not multiple of 2), use + * roundclosest(). + * + * Examples: + * * round_closest_down(17, 4) = 16 + * * round_closest_down(15, 4) = 16 + * * round_closest_down(14, 4) = 12 + */ +#define round_closest_down(x, y) round_up((x) - (y) / 2, (y)) + #define DIV_ROUND_UP __KERNEL_DIV_ROUND_UP #define DIV_ROUND_DOWN_ULL(ll, d) \ @@ -77,6 +123,23 @@ } \ ) +/** + * roundclosest - round to nearest multiple + * @x: the value to round + * @y: multiple to round nearest to + * + * Rounds @x to nearest multiple of @y. + * The rounded value can be greater than or less than @x depending + * upon it's nearness to @x. If @y will always be a power of 2, consider + * using the faster round_closest_up() or round_closest_down(). + * + * Examples: + * * roundclosest(21, 5) = 20 + * * roundclosest(19, 5) = 20 + * * roundclosest(17, 5) = 15 + */ +#define roundclosest(x, y) rounddown((x) + (y) / 2, (y)) + /* * Divide positive or negative dividend by positive or negative divisor * and round to closest integer. Result is undefined for negative -- 2.39.1
Re: [PATCH v3 3/4] drm/sched: cleanup gpu_scheduler trace events
Hi,
Le 06/06/2024 à 15:19, Steven Rostedt a écrit :
On Thu, 6 Jun 2024 15:06:24 +0200
Pierre-Eric Pelloux-Prayer wrote:
Print identifiers instead of pointers:
* "fence=%p" is replaced by "fence=(context:%llu, seqno:%lld)" to have a
coherent way to print the fence. A possible follow up change would be
to use the same format in traces/../dma-fence.h.
* "entity=%p" is removed because the fence's context is already an
identifier of the job owner.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 27 ++-
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
index 0a19c121bda5..2d7f2252eb5d 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
@@ -58,9 +58,9 @@ DECLARE_EVENT_CLASS(drm_sched_job,
_job->sched->credit_count);
__entry->dev_index =
sched_job->sched->dev->primary->index;
),
- TP_printk("entity=%p, id=%llu, fence=%p, ring=%s, job count:%u, hw job
count:%d",
- __entry->entity, __entry->id,
- __entry->fence, __get_str(name),
+ TP_printk("id=%llu, fence=(context:%llu, seqno:%lld), ring=%s, job
count:%u, hw job count:%d",
+ __entry->id,
+ __entry->fence->context, __entry->fence->seqno,
__get_str(name),
__entry->job_count, __entry->hw_job_count)
);
@@ -72,9 +72,9 @@ DEFINE_EVENT(drm_sched_job, drm_sched_job,
DEFINE_EVENT_PRINT(drm_sched_job, drm_run_job,
TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
*entity),
TP_ARGS(sched_job, entity),
- TP_printk("dev_index=%d entity=%p id=%llu, fence=%p, ring=%s, job
count:%u, hw job count:%d",
- __entry->dev_index, __entry->entity, __entry->id,
- __entry->fence, __get_str(name),
+ TP_printk("dev_index=%d id=%llu, fence=(context:%llu, seqno:%lld),
ring=%s, job count:%u, hw job count:%d",
+ __entry->dev_index, __entry->id,
+ __entry->fence->context, __entry->fence->seqno,
__get_str(name),
__entry->job_count, __entry->hw_job_count)
NACK!
You can't dereference pointers from TP_printk(). This is called seconds,
minutes, hours, even days or months after that pointer was assigned. How do
you know that pointer still points to anything?
Now that you pointed it out, the problem is obvious indeed.
I have fixed it locally.
Thanks!
Pierre-Eric
-- Steve
);
@@ -88,7 +88,8 @@ TRACE_EVENT(drm_sched_process_job,
TP_fast_assign(
__entry->fence = >finished;
),
- TP_printk("fence=%p signaled", __entry->fence)
+ TP_printk("fence=(context:%llu, seqno:%lld) signaled",
+ __entry->fence->context, __entry->fence->seqno)
);
TRACE_EVENT(drm_sched_job_wait_dep,
@@ -96,23 +97,25 @@ TRACE_EVENT(drm_sched_job_wait_dep,
TP_ARGS(sched_job, fence),
TP_STRUCT__entry(
__string(name, sched_job->sched->name)
+__field(uint64_t, fence_context)
__field(uint64_t, id)
__field(struct dma_fence *, fence)
__field(uint64_t, ctx)
-__field(unsigned, seqno)
+__field(uint64_t, seqno)
),
TP_fast_assign(
__assign_str(name);
+ /* Store the hw exec fence context. */
+ __entry->fence_context =
sched_job->entity->fence_context + 1;
__entry->id = sched_job->id;
__entry->fence = fence;
__entry->ctx = fence->context;
__entry->seqno = fence->seqno;
),
- TP_printk("job ring=%s, id=%llu, depends fence=%p, context=%llu,
seq=%u",
- __get_str(name), __entry->id,
- __entry->fence, __entry->ctx,
- __entry->seqno)
+ TP_printk("job ring=%s, fence_context=%llu, id=%llu, depends
fence=(context:%llu, seqno:%lld)",
+ __get_str(name), __entry->fence_context, __entry->id,
+ __entry->ctx, __entry->seqno)
);
#endif
[PATCH v5 7/9] drm/msm/hdmi: get rid of hdmi_mode
Use connector->display_info.is_hdmi instead of manually using
drm_detect_hdmi_monitor().
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 2 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 2 --
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 11 ---
3 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 2279e09fd2de..8c6c9dd6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -25,7 +25,7 @@ void msm_hdmi_set_mode(struct hdmi *hdmi, bool power_on)
spin_lock_irqsave(>reg_lock, flags);
if (power_on) {
ctrl |= HDMI_CTRL_ENABLE;
- if (!hdmi->hdmi_mode) {
+ if (!hdmi->connector->display_info.is_hdmi) {
ctrl |= HDMI_CTRL_HDMI;
hdmi_write(hdmi, REG_HDMI_CTRL, ctrl);
ctrl &= ~HDMI_CTRL_HDMI;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 0ac034eaaf0f..b7fc1c5f1d1e 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -67,8 +67,6 @@ struct hdmi {
/* the encoder we are hooked to (outside of hdmi block) */
struct drm_encoder *encoder;
- bool hdmi_mode; /* are we in hdmi mode? */
-
int irq;
struct workqueue_struct *workq;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 9eecc9960e75..9258d3100042 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -346,17 +346,6 @@ static const struct drm_edid
*msm_hdmi_bridge_edid_read(struct drm_bridge *bridg
hdmi_write(hdmi, REG_HDMI_CTRL, hdmi_ctrl);
- if (drm_edid) {
- /*
-* FIXME: This should use connector->display_info.is_hdmi from a
-* path that has read the EDID and called
-* drm_edid_connector_update().
-*/
- const struct edid *edid = drm_edid_raw(drm_edid);
-
- hdmi->hdmi_mode = drm_detect_hdmi_monitor(edid);
- }
-
return drm_edid;
}
--
2.39.2
[PATCH v5 9/9] drm/msm/hdmi: also send the SPD and HDMI Vendor Specific InfoFrames
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
that requires manual repacking in the driver, while GENERIC0 doesn't
have such format requirements. The msm-4.4 kernel uses GENERIC0 to send
HDR InfoFrame which we do not at this point anyway.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 93 ++
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 9258d3100042..ad6258a2017a 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -69,6 +69,8 @@ static void power_off(struct drm_bridge *bridge)
}
#define AVI_IFRAME_LINE_NUMBER 1
+#define SPD_IFRAME_LINE_NUMBER 1
+#define VENSPEC_IFRAME_LINE_NUMBER 3
static int msm_hdmi_config_avi_infoframe(struct hdmi *hdmi,
const u8 *buffer, size_t len)
@@ -142,6 +144,74 @@ static int msm_hdmi_config_audio_infoframe(struct hdmi
*hdmi,
return 0;
}
+static int msm_hdmi_config_spd_infoframe(struct hdmi *hdmi,
+const u8 *buffer, size_t len)
+{
+ u32 buf[7] = {};
+ u32 val;
+ int i;
+
+ if (len != HDMI_INFOFRAME_SIZE(SPD) || len - 3 > sizeof(buf)) {
+ DRM_DEV_ERROR(>pdev->dev,
+ "failed to configure SPD infoframe\n");
+ return -EINVAL;
+ }
+
+ /* checksum gets written together with the body of the frame */
+ hdmi_write(hdmi, REG_HDMI_GENERIC1_HDR,
+ buffer[0] |
+ buffer[1] << 8 |
+ buffer[2] << 16);
+
+ memcpy(buf, [3], len - 3);
+
+ for (i = 0; i < ARRAY_SIZE(buf); i++)
+ hdmi_write(hdmi, REG_HDMI_GENERIC1(i), buf[i]);
+
+ val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
+ val |= HDMI_GEN_PKT_CTRL_GENERIC1_SEND |
+HDMI_GEN_PKT_CTRL_GENERIC1_CONT |
+HDMI_GEN_PKT_CTRL_GENERIC1_LINE(SPD_IFRAME_LINE_NUMBER);
+ hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
+
+ return 0;
+}
+
+static int msm_hdmi_config_hdmi_infoframe(struct hdmi *hdmi,
+ const u8 *buffer, size_t len)
+{
+ u32 buf[7] = {};
+ u32 val;
+ int i;
+
+ if (len < HDMI_INFOFRAME_HEADER_SIZE + HDMI_VENDOR_INFOFRAME_SIZE ||
+ len - 3 > sizeof(buf)) {
+ DRM_DEV_ERROR(>pdev->dev,
+ "failed to configure HDMI infoframe\n");
+ return -EINVAL;
+ }
+
+ /* checksum gets written together with the body of the frame */
+ hdmi_write(hdmi, REG_HDMI_GENERIC0_HDR,
+ buffer[0] |
+ buffer[1] << 8 |
+ buffer[2] << 16);
+
+ memcpy(buf, [3], len - 3);
+
+ for (i = 0; i < ARRAY_SIZE(buf); i++)
+ hdmi_write(hdmi, REG_HDMI_GENERIC0(i), buf[i]);
+
+ val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
+ val |= HDMI_GEN_PKT_CTRL_GENERIC0_SEND |
+HDMI_GEN_PKT_CTRL_GENERIC0_CONT |
+HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE |
+HDMI_GEN_PKT_CTRL_GENERIC0_LINE(VENSPEC_IFRAME_LINE_NUMBER);
+ hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
+
+ return 0;
+}
+
static int msm_hdmi_bridge_clear_infoframe(struct drm_bridge *bridge,
enum hdmi_infoframe_type type)
{
@@ -176,6 +246,25 @@ static int msm_hdmi_bridge_clear_infoframe(struct
drm_bridge *bridge,
break;
+ case HDMI_INFOFRAME_TYPE_SPD:
+ val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
+ val &= ~(HDMI_GEN_PKT_CTRL_GENERIC1_SEND |
+HDMI_GEN_PKT_CTRL_GENERIC1_CONT |
+HDMI_GEN_PKT_CTRL_GENERIC1_LINE__MASK);
+ hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
+
+ break;
+
+ case HDMI_INFOFRAME_TYPE_VENDOR:
+ val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
+ val &= ~(HDMI_GEN_PKT_CTRL_GENERIC0_SEND |
+HDMI_GEN_PKT_CTRL_GENERIC0_CONT |
+HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE |
+HDMI_GEN_PKT_CTRL_GENERIC0_LINE__MASK);
+ hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
+
+ break;
+
default:
drm_dbg_driver(hdmi_bridge->base.dev, "Unsupported infoframe
type %x\n", type);
}
@@ -197,6 +286,10 @@ static int msm_hdmi_bridge_write_infoframe(struct
drm_bridge *bridge,
return msm_hdmi_config_avi_infoframe(hdmi, buffer, len);
case HDMI_INFOFRAME_TYPE_AUDIO:
return msm_hdmi_config_audio_infoframe(hdmi, buffer, len);
+ case
[PATCH v5 2/9] drm/bridge-connector: switch to using drmm allocations
Turn drm_bridge_connector to using drmm_kzalloc() and
drmm_connector_init() and drop the custom destroy function. The
drm_connector_unregister() and fwnode_handle_put() are already handled
by the drm_connector_cleanup() and so are safe to be dropped.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index 982552c9f92c..e093fc8928dc 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -193,19 +194,6 @@ drm_bridge_connector_detect(struct drm_connector
*connector, bool force)
return status;
}
-static void drm_bridge_connector_destroy(struct drm_connector *connector)
-{
- struct drm_bridge_connector *bridge_connector =
- to_drm_bridge_connector(connector);
-
- drm_connector_unregister(connector);
- drm_connector_cleanup(connector);
-
- fwnode_handle_put(connector->fwnode);
-
- kfree(bridge_connector);
-}
-
static void drm_bridge_connector_debugfs_init(struct drm_connector *connector,
struct dentry *root)
{
@@ -224,7 +212,6 @@ static const struct drm_connector_funcs
drm_bridge_connector_funcs = {
.reset = drm_atomic_helper_connector_reset,
.detect = drm_bridge_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = drm_bridge_connector_destroy,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.debugfs_init = drm_bridge_connector_debugfs_init,
@@ -328,7 +315,7 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
int connector_type;
int ret;
- bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
+ bridge_connector = drmm_kzalloc(drm, sizeof(*bridge_connector),
GFP_KERNEL);
if (!bridge_connector)
return ERR_PTR(-ENOMEM);
@@ -383,9 +370,9 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
return ERR_PTR(-EINVAL);
}
- ret = drm_connector_init_with_ddc(drm, connector,
- _bridge_connector_funcs,
- connector_type, ddc);
+ ret = drmm_connector_init(drm, connector,
+ _bridge_connector_funcs,
+ connector_type, ddc);
if (ret) {
kfree(bridge_connector);
return ERR_PTR(ret);
--
2.39.2
[PATCH v5 8/9] drm/msm/hdmi: update HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE definition
The GENERIC0_UPDATE field is a single bit. Redefine it as boolean to simplify its usage in the driver. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/registers/display/hdmi.xml b/drivers/gpu/drm/msm/registers/display/hdmi.xml index 6c81581016c7..fc711a842363 100644 --- a/drivers/gpu/drm/msm/registers/display/hdmi.xml +++ b/drivers/gpu/drm/msm/registers/display/hdmi.xml @@ -131,7 +131,7 @@ xsi:schemaLocation="https://gitlab.freedesktop.org/freedreno/ rules-fd.xsd"> --> - + -- 2.39.2
[PATCH v5 6/9] drm/msm/hdmi: make use of the drm_connector_hdmi framework
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig| 2 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 45 ++---
drivers/gpu/drm/msm/hdmi/hdmi.h| 16 +---
drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 74 --
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 170 -
5 files changed, 160 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1931ecf73e32..b5c78c1dd744 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -164,6 +164,8 @@ config DRM_MSM_HDMI
bool "Enable HDMI support in MSM DRM driver"
depends on DRM_MSM
default y
+ select DRM_DISPLAY_HDMI_HELPER
+ select DRM_DISPLAY_HDMI_STATE_HELPER
help
Compile in support for the HDMI output MSM DRM driver. It can
be a primary or a secondary display on device. Note that this is used
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 24abcb7254cc..2279e09fd2de 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include "hdmi.h"
@@ -165,8 +166,6 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi,
hdmi->dev = dev;
hdmi->encoder = encoder;
- hdmi_audio_infoframe_init(>audio.infoframe);
-
ret = msm_hdmi_bridge_init(hdmi);
if (ret) {
DRM_DEV_ERROR(dev->dev, "failed to create HDMI bridge: %d\n",
ret);
@@ -254,40 +253,12 @@ static int msm_hdmi_audio_hw_params(struct device *dev,
void *data,
struct hdmi_codec_params *params)
{
struct hdmi *hdmi = dev_get_drvdata(dev);
- unsigned int chan;
- unsigned int channel_allocation = 0;
unsigned int rate;
- unsigned int level_shift = 0; /* 0dB */
- bool down_mix = false;
+ int ret;
DRM_DEV_DEBUG(dev, "%u Hz, %d bit, %d channels\n", params->sample_rate,
params->sample_width, params->cea.channels);
- switch (params->cea.channels) {
- case 2:
- /* FR and FL speakers */
- channel_allocation = 0;
- chan = MSM_HDMI_AUDIO_CHANNEL_2;
- break;
- case 4:
- /* FC, LFE, FR and FL speakers */
- channel_allocation = 0x3;
- chan = MSM_HDMI_AUDIO_CHANNEL_4;
- break;
- case 6:
- /* RR, RL, FC, LFE, FR and FL speakers */
- channel_allocation = 0x0B;
- chan = MSM_HDMI_AUDIO_CHANNEL_6;
- break;
- case 8:
- /* FRC, FLC, RR, RL, FC, LFE, FR and FL speakers */
- channel_allocation = 0x1F;
- chan = MSM_HDMI_AUDIO_CHANNEL_8;
- break;
- default:
- return -EINVAL;
- }
-
switch (params->sample_rate) {
case 32000:
rate = HDMI_SAMPLE_RATE_32KHZ;
@@ -316,9 +287,12 @@ static int msm_hdmi_audio_hw_params(struct device *dev,
void *data,
return -EINVAL;
}
- msm_hdmi_audio_set_sample_rate(hdmi, rate);
- msm_hdmi_audio_info_setup(hdmi, 1, chan, channel_allocation,
- level_shift, down_mix);
+ ret =
drm_atomic_helper_connector_hdmi_update_audio_infoframe(hdmi->connector,
+
>cea);
+ if (ret)
+ return ret;
+
+ msm_hdmi_audio_info_setup(hdmi, rate, params->cea.channels);
return 0;
}
@@ -327,7 +301,8 @@ static void msm_hdmi_audio_shutdown(struct device *dev,
void *data)
{
struct hdmi *hdmi = dev_get_drvdata(dev);
- msm_hdmi_audio_info_setup(hdmi, 0, 0, 0, 0, 0);
+
drm_atomic_helper_connector_hdmi_disable_audio_infoframe(hdmi->connector);
+ msm_hdmi_audio_disable(hdmi);
}
static const struct hdmi_codec_ops msm_hdmi_audio_codec_ops = {
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 4586baf36415..0ac034eaaf0f 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -24,8 +24,8 @@ struct hdmi_platform_config;
struct hdmi_audio {
bool enabled;
- struct hdmi_audio_infoframe infoframe;
int rate;
+ int channels;
};
struct hdmi_hdcp_ctrl;
@@ -199,12 +199,6 @@ static inline int msm_hdmi_pll_8996_init(struct
platform_device *pdev)
/*
* audio:
*/
-/* Supported HDMI Audio channels and rates */
-#defineMSM_HDMI_AUDIO_CHANNEL_20
-#defineMSM_HDMI_AUDIO_CHANNEL_41
-#defineMSM_HDMI_AUDIO_CHANNEL_62
-#defineMSM_HDMI_AUDIO_CHANNEL_83
-
#define
[PATCH v5 5/9] drm/msm/hdmi: turn mode_set into atomic_enable
The mode_set callback is deprecated, it doesn't get the
drm_bridge_state, just mode-related argumetns. Turn it into the
atomic_enable callback as suggested by the documentation.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index d839c71091dc..f259d6268c0f 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -129,12 +129,25 @@ static void msm_hdmi_config_avi_infoframe(struct hdmi
*hdmi)
static void msm_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
struct drm_bridge_state
*old_bridge_state)
{
+ struct drm_atomic_state *state = old_bridge_state->base.state;
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
struct hdmi_phy *phy = hdmi->phy;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc_state *crtc_state;
+ const struct drm_display_mode *mode;
DBG("power up");
+ connector = drm_atomic_get_new_connector_for_encoder(state, encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+ mode = _state->adjusted_mode;
+
+ hdmi->pixclock = mode->clock * 1000;
+
if (!hdmi->power_on) {
msm_hdmi_phy_resource_enable(phy);
msm_hdmi_power_on(bridge);
@@ -177,18 +190,24 @@ static void msm_hdmi_bridge_atomic_post_disable(struct
drm_bridge *bridge,
}
}
-static void msm_hdmi_bridge_mode_set(struct drm_bridge *bridge,
-const struct drm_display_mode *mode,
-const struct drm_display_mode *adjusted_mode)
+static void msm_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
+ struct drm_atomic_state *state = old_bridge_state->base.state;
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc_state *crtc_state;
+ const struct drm_display_mode *mode;
int hstart, hend, vstart, vend;
uint32_t frame_ctrl;
- mode = adjusted_mode;
-
- hdmi->pixclock = mode->clock * 1000;
+ connector = drm_atomic_get_new_connector_for_encoder(state, encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+ mode = _state->adjusted_mode;
hstart = mode->htotal - mode->hsync_start;
hend = mode->htotal - mode->hsync_start + mode->hdisplay;
@@ -305,8 +324,8 @@ static const struct drm_bridge_funcs msm_hdmi_bridge_funcs
= {
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_pre_enable = msm_hdmi_bridge_atomic_pre_enable,
+ .atomic_enable = msm_hdmi_bridge_atomic_enable,
.atomic_post_disable = msm_hdmi_bridge_atomic_post_disable,
- .mode_set = msm_hdmi_bridge_mode_set,
.mode_valid = msm_hdmi_bridge_mode_valid,
.edid_read = msm_hdmi_bridge_edid_read,
.detect = msm_hdmi_bridge_detect,
--
2.39.2
[PATCH v5 1/9] drm/connector: hdmi: allow disabling Audio Infoframe
Add drm_atomic_helper_connector_hdmi_disable_audio_infoframe(), an API
to allow the driver disable sending the Audio Infoframe. This is to be
used by the drivers if setup of the infoframes is not tightly coupled
with the audio functionality and just disabling the audio playback
doesn't stop the HDMI hardware from sending the Infoframe.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 36 +
include/drm/display/drm_hdmi_state_helper.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index ce96837eea65..731873b3bdf2 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -714,3 +714,39 @@
drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *co
return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_update_audio_infoframe);
+
+/**
+ * drm_atomic_helper_connector_hdmi_disable_audio_infoframe - Stop sending the
Audio Infoframe
+ * @connector: A pointer to the HDMI connector
+ *
+ * This function is meant for HDMI connector drivers to stop sending their
+ * audio infoframe. It will typically be used in one of the ALSA hooks
+ * (most likely shutdown).
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int
+drm_atomic_helper_connector_hdmi_disable_audio_infoframe(struct drm_connector
*connector)
+{
+ struct drm_connector_hdmi_infoframe *infoframe =
+ >hdmi.infoframes.audio;
+ struct drm_display_info *info = >display_info;
+ int ret;
+
+ if (!info->is_hdmi)
+ return 0;
+
+ mutex_lock(>hdmi.infoframes.lock);
+
+ infoframe->set = false;
+
+ ret = clear_infoframe(connector, infoframe);
+
+ memset(>data, 0, sizeof(infoframe->data));
+
+ mutex_unlock(>hdmi.infoframes.lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_disable_audio_infoframe);
diff --git a/include/drm/display/drm_hdmi_state_helper.h
b/include/drm/display/drm_hdmi_state_helper.h
index fbf86ff9cdfb..c3d23725f0b8 100644
--- a/include/drm/display/drm_hdmi_state_helper.h
+++ b/include/drm/display/drm_hdmi_state_helper.h
@@ -16,6 +16,7 @@ int drm_atomic_helper_connector_hdmi_check(struct
drm_connector *connector,
int drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct
drm_connector *connector,
struct
hdmi_audio_infoframe *frame);
+int drm_atomic_helper_connector_hdmi_disable_audio_infoframe(struct
drm_connector *connector);
int drm_atomic_helper_connector_hdmi_update_infoframes(struct drm_connector
*connector,
struct drm_atomic_state
*state);
--
2.39.2
[PATCH v5 4/9] drm/msm/hdmi: switch to atomic bridge callbacks
Change MSM HDMI bridge to use atomic_* callbacks in preparation to
enablign the HDMI connector support.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 4a5b5112227f..d839c71091dc 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -126,7 +126,8 @@ static void msm_hdmi_config_avi_infoframe(struct hdmi *hdmi)
hdmi_write(hdmi, REG_HDMI_INFOFRAME_CTRL1, val);
}
-static void msm_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
@@ -152,7 +153,8 @@ static void msm_hdmi_bridge_pre_enable(struct drm_bridge
*bridge)
msm_hdmi_hdcp_on(hdmi->hdcp_ctrl);
}
-static void msm_hdmi_bridge_post_disable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
@@ -299,8 +301,11 @@ static enum drm_mode_status
msm_hdmi_bridge_mode_valid(struct drm_bridge *bridge
}
static const struct drm_bridge_funcs msm_hdmi_bridge_funcs = {
- .pre_enable = msm_hdmi_bridge_pre_enable,
- .post_disable = msm_hdmi_bridge_post_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_pre_enable = msm_hdmi_bridge_atomic_pre_enable,
+ .atomic_post_disable = msm_hdmi_bridge_atomic_post_disable,
.mode_set = msm_hdmi_bridge_mode_set,
.mode_valid = msm_hdmi_bridge_mode_valid,
.edid_read = msm_hdmi_bridge_edid_read,
--
2.39.2
[PATCH v5 3/9] drm/bridge-connector: implement glue code for HDMI connector
In order to let bridge chains implement HDMI connector infrastructure,
add necessary glue code to the drm_bridge_connector. In case there is a
bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register
itself as a HDMI connector and provide proxy drm_connector_hdmi_funcs
implementation.
Note, to simplify implementation, there can be only one bridge in a
chain that sets DRM_BRIDGE_OP_HDMI. Setting more than one is considered
an error. This limitation can be lifted later, if the need arises.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 94 --
drivers/gpu/drm/drm_debugfs.c | 2 +
include/drm/drm_bridge.h | 81 +
3 files changed, 174 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index e093fc8928dc..0869b663f17e 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
/**
* DOC: overview
@@ -87,6 +88,13 @@ struct drm_bridge_connector {
* connector modes detection, if any (see _BRIDGE_OP_MODES).
*/
struct drm_bridge *bridge_modes;
+ /**
+* @bridge_hdmi:
+*
+* The bridge in the chain that implements necessary support for the
+* HDMI connector infrastructure, if any (see _BRIDGE_OP_HDMI).
+*/
+ struct drm_bridge *bridge_hdmi;
};
#define to_drm_bridge_connector(x) \
@@ -287,6 +295,60 @@ static const struct drm_connector_helper_funcs
drm_bridge_connector_helper_funcs
.disable_hpd = drm_bridge_connector_disable_hpd,
};
+static enum drm_mode_status
+drm_bridge_connector_tmds_char_rate_valid(const struct drm_connector
*connector,
+ const struct drm_display_mode *mode,
+ unsigned long long tmds_rate)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(connector);
+ struct drm_bridge *bridge;
+
+ bridge = bridge_connector->bridge_hdmi;
+ if (!bridge)
+ return MODE_ERROR;
+
+ if (bridge->funcs->hdmi_tmds_char_rate_valid)
+ return bridge->funcs->hdmi_tmds_char_rate_valid(bridge, mode,
tmds_rate);
+ else
+ return MODE_OK;
+}
+
+static int drm_bridge_connector_clear_infoframe(struct drm_connector
*connector,
+ enum hdmi_infoframe_type type)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(connector);
+ struct drm_bridge *bridge;
+
+ bridge = bridge_connector->bridge_hdmi;
+ if (!bridge)
+ return -EINVAL;
+
+ return bridge->funcs->hdmi_clear_infoframe(bridge, type);
+}
+
+static int drm_bridge_connector_write_infoframe(struct drm_connector
*connector,
+ enum hdmi_infoframe_type type,
+ const u8 *buffer, size_t len)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(connector);
+ struct drm_bridge *bridge;
+
+ bridge = bridge_connector->bridge_hdmi;
+ if (!bridge)
+ return -EINVAL;
+
+ return bridge->funcs->hdmi_write_infoframe(bridge, type, buffer, len);
+}
+
+static const struct drm_connector_hdmi_funcs drm_bridge_connector_hdmi_funcs =
{
+ .tmds_char_rate_valid = drm_bridge_connector_tmds_char_rate_valid,
+ .clear_infoframe = drm_bridge_connector_clear_infoframe,
+ .write_infoframe = drm_bridge_connector_write_infoframe,
+};
+
/*
-
* Bridge Connector Initialisation
*/
@@ -312,6 +374,8 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
struct drm_connector *connector;
struct i2c_adapter *ddc = NULL;
struct drm_bridge *bridge, *panel_bridge = NULL;
+ unsigned int supported_formats = BIT(HDMI_COLORSPACE_RGB);
+ unsigned int max_bpc = 8;
int connector_type;
int ret;
@@ -348,6 +412,20 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
bridge_connector->bridge_detect = bridge;
if (bridge->ops & DRM_BRIDGE_OP_MODES)
bridge_connector->bridge_modes = bridge;
+ if (bridge->ops & DRM_BRIDGE_OP_HDMI) {
+ if (bridge_connector->bridge_hdmi)
+ return ERR_PTR(-EBUSY);
+ if (!bridge->funcs->hdmi_write_infoframe ||
+ !bridge->funcs->hdmi_clear_infoframe)
+ return ERR_PTR(-EINVAL);
+
+
[PATCH v5 0/9] drm/msm: make use of the HDMI connector infrastructure
This patchset sits on top Maxime's HDMI connector patchset ([1]). Currently this is an RFC exploring the interface between HDMI bridges and HDMI connector code. This has been lightly verified on the Qualcomm DB820c, which has native HDMI output. If this approach is considered to be acceptable, I'll finish MSM HDMI bridge conversion (reworking the Audio Infoframe code). Other bridges can follow the same approach (we have lt9611 / lt9611uxc / adv7511 on Qualcomm hardware). [1] https://patchwork.freedesktop.org/series/122421/ Signed-off-by: Dmitry Baryshkov --- Changes in v5: - Made drm_bridge_funcs::hdmi_clear_infoframe() callback mandatory for DRM_BRIDGE_OP_HDMI bridges (Maxime) - Added drm_atomic_helper_connector_hdmi_disable_audio_infoframe() instead of passing NULL frame to drm_atomic_helper_connector_hdmi_update_audio_infoframe() (Maxime) - Disable Audio Infoframe in MSM HDMI driver on audio shutdown. - Link to v4: https://lore.kernel.org/r/20240531-bridge-hdmi-connector-v4-0-5110f7943...@linaro.org Changes in v4: - Reworked drm_bridge_connector functions to remove ternary operators and to reduce indentation level (Maxime) - Added hdmi_ prefix to all HDMI-related drm_bridge_funcs calls (Maxime) - Made vendor and product mandatory to the HDMI bridges (Maxime) - Documented that max_bpc can be 8, 10 or 12 (Maxime) - Changed hdmi->pixclock to be set using tmds_char_rate instead of calculating that manually (Maxime) - Changed mode_valid to use helper function instead of manually doing mode->clock * 1000 - Removed hdmi_mode in favour of connector->display_info.is_hdmi - Link to v3: https://lore.kernel.org/r/20240530-bridge-hdmi-connector-v3-0-a1d184d68...@linaro.org Changes in v3: - Rebased on top of the merged HDMI connector patchset. - Changed drm_bridge_connector to use drmm_connector_init() (Maxime) - Added a check that write_infoframe callback is present if BRIDGE_OP_HDMI is set. - Moved drm_atomic_helper_connector_hdmi_check() call from drm_bridge_connector to the HDMI bridge driver to remove dependency from drm_kms_helpers on the optional HDMI state helpers. - Converted Audio InfoFrame handling code. - Added support for HDMI Vendor Specific and SPD InfoFrames. - Link to v2: https://lore.kernel.org/r/20240309-bridge-hdmi-connector-v2-0-1380bea3e...@linaro.org Changes in v2: - Dropped drm_connector_hdmi_setup(). Instead added drm_connector_hdmi_init() to be used by drm_bridge_connector. - Changed the drm_bridge_connector to act as a proxy for the HDMI connector infrastructure. This removes most of the logic from the bridge drivers. - Link to v1: https://lore.kernel.org/r/20240308-bridge-hdmi-connector-v1-0-90b693550...@linaro.org --- Dmitry Baryshkov (9): drm/connector: hdmi: allow disabling Audio Infoframe drm/bridge-connector: switch to using drmm allocations drm/bridge-connector: implement glue code for HDMI connector drm/msm/hdmi: switch to atomic bridge callbacks drm/msm/hdmi: turn mode_set into atomic_enable drm/msm/hdmi: make use of the drm_connector_hdmi framework drm/msm/hdmi: get rid of hdmi_mode drm/msm/hdmi: update HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE definition drm/msm/hdmi: also send the SPD and HDMI Vendor Specific InfoFrames drivers/gpu/drm/display/drm_hdmi_state_helper.c | 36 +++ drivers/gpu/drm/drm_bridge_connector.c | 107 ++-- drivers/gpu/drm/drm_debugfs.c | 2 + drivers/gpu/drm/msm/Kconfig | 2 + drivers/gpu/drm/msm/hdmi/hdmi.c | 47 +--- drivers/gpu/drm/msm/hdmi/hdmi.h | 18 +- drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 74 ++ drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 310 +++- drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +- include/drm/display/drm_hdmi_state_helper.h | 1 + include/drm/drm_bridge.h| 81 +++ 11 files changed, 496 insertions(+), 184 deletions(-) --- base-commit: 222d50ef3700aefb694e55a7a1f03d3fe2cb67f9 change-id: 20240307-bridge-hdmi-connector-7e3754e661d0 Best regards, -- Dmitry Baryshkov
[PATCH v13 00/13] Add V4L2 M2M Driver for E5010 JPEG Encoder
This adds support for V4L2 M2M based driver for E5010 JPEG Encoder which is a stateful JPEG encoder from Imagination technologies and is present in TI AM62A SoC. While adding support for it, following additional framework changes were made: - Moved reference quantization and huffman tables provided in ITU-T-REC-T.81 to v4l2-jpeg.c as suggested in mailing list [1]. - Add macros to round to closest integer (either higher or lower) while rounding in order of 2. - Add KUnit tests for math functions. v4l2-compliance test : Link: https://gist.github.com/devarsht/1f039c631ca953a57f405cfce1b69e49 E5010 JPEG Encoder Manual tests : Performance: Link: https://gist.github.com/devarsht/c40672944fd71c9a53ab55adbfd9e28b Functionality: Link: https://gist.github.com/devarsht/8e88fcaabff016bb2bac83d89c9d23ce Compression Quality: Link: https://gist.github.com/devarsht/cbcc7cd97e8c48ba1486caa2b7884655 Multi Instance: Link: https://gist.github.com/devarsht/22c2fca08cd3441fb40f2c7a4cebc95a Crop support: Link: https://gist.github.com/devarsht/de6f5142f678bb1a5338abfd9f814abd Runtime PM: Link: https://gist.github.com/devarsht/70cd95d4440ddc678489d93885ddd4dd Math lib KUnit tests: Link: https://gist.github.com/devarsht/3f9042825be3da4e133b8f4eda067876 [1]: https://lore.kernel.org/all/de46aefe-36da-4e1a-b4fa-b375b2749...@xs4all.nl/ Changelog: V13: - Fix smatch/sparse related warnings V12: - Fix documentation and enable kernel-doc rendering for math.h and jpeg helpers - Add Reviewed-by and Acked-by tags V10->V11: - Fix commenting for math.h, include headers per IWYU principle in math_kunit, update title for math.h kernel-doc V9->V10: - Update commenting style in math.h and add notes for new jpeg header macros - Add KUnit dependency for math_kunit V8->V9: - Remove kernel.h header file - Remove stale filler data on jpeg header in E5010 jpeg driver V7->V8: - Add KUnit tests for math functions - Add roundclosest() for supporting rounding for non-multiple of 2 - Update commit message as suggested - Add Reviewed-by and Acked-by tags to patches as received V6->V7: - Fix cropping support - Move reference huffman and quantization tables to v4l2-jpeg.c - Fix suspend/resume use-case - Add Reviewed-by V5->V6: - Fix sparse warnings V4->V5: - Sort the #includes in driver file alphabetically - Rename huffman and quantization tables to not use '_' - Add Reviewed-by tag V3->V4: - Use ti-specific compatible ti,am62a-jpeg-enc as secondary one in dt-binding - Remove clock-names as only single clock in dt-binding - Fix issue with default params setting - Correct v4l2 error prints - Simplify register write functions with single statement return values - Remove unrequired error checks from get_queue() - Drop explicit device_caps setting as it is already taken care by v4l2 core - Remove unrequired multiplanar checks and memset from s_fmt, g_fmt callback functions - Fix try_fmt callback to not update the queues - Remove unrequired contiguous format attribute from queue_init - Use dynamic allocation for video_device and remove unrequired assignments in probe() - Remove unrequired checks from queue_setup function - Return queued buffers back if start_streaming fails - Use ARRAY_SIZE in place of hard-coding - Use huffman and quantization tables from reference header file V2->V3: - Add DONOTMERGE patches for dts and defconfig - Update driver with below changes : - Correct license headers - Use more generic name core instead of jasper for base registers - Add Comment for forward declarations - Simplify quantization table calculations - Use v4l2_apply_frmsize_constraints for updating framesize and remove unrequired functions - Place TODO at top of file and in commit message too - Use dev_err_probe helper in probe function - Fix return value checking for failure scenarios in probe function - Use v4l2_err/info/warn helpers instead of dev_err/info/warn helpers - Fix unexpected indentation - Correct commit message - Update dt-bindings with below changes : - Add vendor specific compatible - Fix commit title and message - Update reg names - Update clocks to 1 - Fix dts example with proper naming V1->V2: - Send dt-bindings and driver together Patch-Diff between the series : V12->V13 Range diff : https://gist.github.com/devarsht/0bd2e90b7352ed4831252a7962fff65d V11->V12 Range diff : https://gist.github.com/devarsht/18455f1744b6b6b8f33dd505a4ca2651 V10->V11 Range diff : https://gist.github.com/devarsht/cd76372bff7c125f75d06ba009264b75 V9->V10 Range diff : https://gist.github.com/devarsht/b446acee460b8c65fb577d06b7bbc1da V8->V9 Range diff : https://gist.github.com/devarsht/3fd6c4e8031ab114248f93d01c8dfc74 V6->V7 Range diff : https://gist.github.com/devarsht/1db185b1e187eaf397e9e4c37066777e V5->V6 Range diff : https://gist.github.com/devarsht/c89180ac2b0d2814614f2b59d0705c19 V4->V5 Range diff : https://gis
Re: [RFC PATCH 7/8] rust: add firmware abstractions
On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote: > > Hi, > > > > On Fri, 31 May 2024 11:59:47 +0200 > > Danilo Krummrich wrote: > > > > > Once we get to a conclusion I can send a series with only the device and > > > firmare > > > abstractions such that we can get them in outside of the scope of the > > > reset of > > > both series to get your driver going. > > > > Since your discussion with Greg seems to continue for a while, let me > > include the following patch that Greg approved with the next version > > of the PHY driver patchset. > > Yes, please take this one now. We can build on it from there. This patch still contains the points *you* are discussing on the original one. Why do I spend my time on this discussion if those points don't seem to matter for you now? Also, why would we want to have this patch (and the firmware one) in two separate submissions? If we urgently want to land the firmware abstractions I can send a separate series with just the device and firmware abstraction patches. > > I had a meeting yesterday with a lot of rust kernel and userspace people > at Microsoft and talked a bunch about this and how to move forward. I > think we need to take much smaller "steps" and even encourage most > drivers to start out as a mix of c and rust as there is no real > "requirement" that a driver be "pure" rust at all. This should both > make the interface logic simpler to start with, AND provide a base so > that people can just write the majority of their driver logic in rust, > which is where the language "safety" issues are most needed, not in the > lifecycle rules involving the internal driver model infrastructure. What do you mean by "drivers to start out as mix of C and Rust". I don' think this is desireable. Writing abstractions for C core infrastructure already is a lot of effort and sometimes rather difficult in certain aspects, (e.g. align lifetimes). An immediate concern I have is that this is an invitation for drivers to write their own abstractions, as in interfacing with C core infrastructure in C and and do a driver specific abstraction. > > Anyway, that's all hand-wavy right now, sorry, to get back to the point > here, again, let's take this, which will allow the firmware bindings to > be resubmitted and hopefully accepted, and we can move forward from > there to "real" things like a USB or PCI or even platform device and > driver binding stuff. The abstractions for that are on the list and in the sense of what you say above for "smaller steps, they are quite minimal. I don't see how we could break this down even further. > > thanks, > > greg k-h >
Re: [RFC PATCH 7/8] rust: add firmware abstractions
On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote:
> Hi,
>
> On Fri, 31 May 2024 11:59:47 +0200
> Danilo Krummrich wrote:
>
> > Once we get to a conclusion I can send a series with only the device and
> > firmare
> > abstractions such that we can get them in outside of the scope of the reset
> > of
> > both series to get your driver going.
>
> Since your discussion with Greg seems to continue for a while, let me
> include the following patch that Greg approved with the next version
> of the PHY driver patchset.
This all doesn't make a lot of sense. If that's the case, Greg approved
something the he keeps arguing about in the discussion of the original patch.
Please see the discussion about the NULL pointer check [1].
Besides that, I really don't think it's the correct approach to just (partially)
pick up a patch from the mailing list that is actively discussed and submit
versions that are slightly altered in the points that are actively discussed.
This really just complicates the situation and does not help getting to an
agreement.
>
> You have the new version of the firmware patch? The unused functions
> will not be merged so only request_firmware() and release_firmware()
> can be included. If not, I can include my firmware patch that I wrote
> before.
>
Please find the updated firmware patch in [2].
However, I propose to just send a new series with just the device abstraction
and this firmware patch and proceed from there.
[1] https://lore.kernel.org/rust-for-linux/Zl8_bXqK-T24y1kp@cassiopeiae/
[2]
https://gitlab.freedesktop.org/drm/nova/-/commit/0683e186929c4922d565e5315525925aa2d8d686
NAK for the patch below, for the reasons above.
Please also see comments inline.
> =
> From: Danilo Krummrich
> Date: Fri, 7 Jun 2024 20:14:59 +0900
> Subject: [PATCH] add abstraction for struct device
>
> Add abstraction for struct device. This implements only the minimum
> necessary functions required for the abstractions of firmware API;
> that is, wrapping C's pointer to a device object with Rust struct only
> during a caller knows the pointer is valid (e.g., the probe callback).
>
> Co-developed-by: Wedson Almeida Filho
> Signed-off-by: Wedson Almeida Filho
> Signed-off-by: Danilo Krummrich
> Co-developed-by: FUJITA Tomonori
> Signed-off-by: FUJITA Tomonori
> Acked-by: Greg Kroah-Hartman
> ---
> rust/kernel/device.rs | 31 +++
> rust/kernel/lib.rs| 1 +
> 2 files changed, 32 insertions(+)
> create mode 100644 rust/kernel/device.rs
>
> diff --git a/rust/kernel/device.rs b/rust/kernel/device.rs
> new file mode 100644
> index ..55ec4f364628
> --- /dev/null
> +++ b/rust/kernel/device.rs
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Generic devices that are part of the kernel's driver model.
> +//!
> +//! C header: [`include/linux/device.h`](srctree/include/linux/device.h)
> +
> +use crate::types::Opaque;
> +
> +/// Wraps the kernel's `struct task_struct`.
> +#[repr(transparent)]
> +pub struct Device(Opaque);
> +
> +impl Device {
> + /// Creates a new [`Device`] instance from a raw pointer.
> +///
> +/// # Safety
> +///
> +/// For the duration of 'a, the pointer must point at a valid `device`.
The original patch says: "Callers must ensure that `ptr` is valid, non-null, and
has a non-zero reference count for the entire duration when the returned
reference exists."
This is way more precise than just saying "For the duration of 'a, the pointer
must point at a valid `device`.", hence we should keep the original comment.
> +pub unsafe fn from_raw<'a>(ptr: *mut bindings::device) -> &'a Self {
> +// CAST: `Self` is a `repr(transparent)` wrapper around
> `bindings::device`.
> +let ptr = ptr.cast::();
> +// SAFETY: by the function requirements the pointer is valid and we
> have unique access for
> +// the duration of `'a`.
> +unsafe { *ptr }
Why not just
+// SAFETY: Guaranteed by the safety requirements of the function.
+unsafe { &*ptr.cast() }
as in the original commit?
> +}
> +
> +/// Returns the raw pointer to the device.
> +pub(crate) fn as_raw() -> *mut bindings::device {
> +self.0.get()
> +}
> +}
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index fbd91a48ff8b..dd1207f1a873 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -28,6 +28,7 @@
>
> pub mod alloc;
> mod build_assert;
> +pub mod device;
> pub mod error;
> pub mod init;
> pub mod ioctl;
> --
> 2.34.1
>
Re: [PATCH v2 2/4] drm/panel: kd101ne3: add new panel driver
Am 07.06.24 um 14:01 schrieb Dmitry Baryshkov:
On Fri, Jun 07, 2024 at 07:44:33PM +0800, zhaoxiong lv wrote:
hi Alex Bee
I compared these two drivers. Although the control IC is the same, the
panel is different, and the init_cmd and timing are also slightly
different, so I added a separate driver.
But it obviously uses the same structure as the panel-jadard. Please
use existing driver instead of creating a completely new one (which you
happily overload with an unrelated panel).
+1
panel-jadard already supports different panels with different
init-sequences and they can be set per panel-type (compatible). If you need
different reset-/enable timings (what I doubt) you'll have to extend struct
jadard_panel_desc. In any case you'll have to put dsi->mode_flags in there
as your panel uses MIPI_DSI_MODE_LPM what the currently supported don't
need.
Alex.
thanks
On Sun, Jun 2, 2024 at 1:07 PM Alex Bee wrote:
Am 01.06.24 um 10:45 schrieb Zhaoxiong Lv:
Hi Zhaoxiong,
The bias IC of this kindisplay-kd101ne3 panel is placed
on the panel side, so when the panel is powered on,
there is no need to control AVDD and AVEE in the driver,
only 3.3v and reset are needed.
Signed-off-by: Zhaoxiong Lv
---
Chage since V2:
- 1. Use the new mipi_dsi_dcs_write_seq_multi() function.
- 2. Modify Move mipi_dsi_dcs_set_display_off() and
mipi_dsi_dcs_enter_sleep_mode() to disable(),
- and drop kingdisplay_panel_enter_sleep_mode().
- 3. If prepare fails, disable GPIO before regulators.
- 4. This function drm_connector_set_panel_orientation() is no longer used.
Delete it.
- 5. Drop ".shutdown = kingdisplay_panel_shutdown".
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-kingdisplay-kd101ne3.c| 533 ++
3 files changed, 543 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index e54f6f5604ed..71669e990e8e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -297,6 +297,15 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_KINGDISPLAY_KD101NE3
+ tristate "Kingdisplay kd101ne3 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the kingdisplay kd101ne3
+ 4-lane 800x1280 MIPI DSI panel.
+
config DRM_PANEL_LEADTEK_LTK050H3146W
tristate "Leadtek LTK050H3146W panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f0203f6e02f4..4576c9fe33d9 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LPM102A188A) +=
panel-jdi-lpm102a188a.o
obj-$(CONFIG_DRM_PANEL_JDI_R63452) += panel-jdi-fhd-r63452.o
obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD101NE3) += panel-kingdisplay-kd101ne3.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
b/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
new file mode 100644
index ..8994a1c9afb5
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Panels based on the JD9365DA display controller.
+ * Author: Zhaoxiong Lv
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct kingdisplay_panel;
+
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+
+ /**
+ * @width_mm: width of the panel's active display area
+ * @height_mm: height of the panel's active display area
+ */
+ struct {
+ unsigned int width_mm;
+ unsigned int height_mm;
+ } size;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
+ int (*init)(struct kingdisplay_panel *kingdisplay);
+ unsigned int lanes;
+ bool discharge_on_disable;
+ bool lp11_before_reset;
+};
+
+struct kingdisplay_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ const struct panel_desc *desc;
+
+ enum drm_panel_orientation orientation;
+ struct regulator *pp3300;
+ struct gpio_desc *enable_gpio;
+};
+
+static int kingdisplay_kd101ne3_init(struct kingdisplay_panel *kingdisplay)
+{
+
Re: [PATCH] drm: have config DRM_WERROR depend on !WERROR
Jani Nikula writes:
Hello Jani,
> If WERROR is already enabled, there's no point in enabling DRM_WERROR or
> asking users about it.
>
> Reported-by: Linus Torvalds
> Closes:
> https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=veojn6gw8gk4j2v+biduntz...@mail.gmail.com
> Fixes: f89632a9e5fa ("drm: Add CONFIG_DRM_WERROR")
> Signed-off-by: Jani Nikula
> ---
The change makes sense to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [RFC PATCH 7/8] rust: add firmware abstractions
On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote: > Hi, > > On Fri, 31 May 2024 11:59:47 +0200 > Danilo Krummrich wrote: > > > Once we get to a conclusion I can send a series with only the device and > > firmare > > abstractions such that we can get them in outside of the scope of the reset > > of > > both series to get your driver going. > > Since your discussion with Greg seems to continue for a while, let me > include the following patch that Greg approved with the next version > of the PHY driver patchset. Yes, please take this one now. We can build on it from there. I had a meeting yesterday with a lot of rust kernel and userspace people at Microsoft and talked a bunch about this and how to move forward. I think we need to take much smaller "steps" and even encourage most drivers to start out as a mix of c and rust as there is no real "requirement" that a driver be "pure" rust at all. This should both make the interface logic simpler to start with, AND provide a base so that people can just write the majority of their driver logic in rust, which is where the language "safety" issues are most needed, not in the lifecycle rules involving the internal driver model infrastructure. Anyway, that's all hand-wavy right now, sorry, to get back to the point here, again, let's take this, which will allow the firmware bindings to be resubmitted and hopefully accepted, and we can move forward from there to "real" things like a USB or PCI or even platform device and driver binding stuff. thanks, greg k-h
Re: [PATCH net-next v10 06/14] page_pool: convert to use netmem
On 6/6/24 02:48, Steven Rostedt wrote:
On Thu, 30 May 2024 20:16:05 +
Mina Almasry wrote:
@@ -42,51 +42,52 @@ TRACE_EVENT(page_pool_release,
TRACE_EVENT(page_pool_state_release,
TP_PROTO(const struct page_pool *pool,
-const struct page *page, u32 release),
+netmem_ref netmem, u32 release),
- TP_ARGS(pool, page, release),
+ TP_ARGS(pool, netmem, release),
TP_STRUCT__entry(
__field(const struct page_pool *, pool)
- __field(const struct page *,page)
+ __field(netmem_ref, netmem)
Why make this of type "netmem_ref" and not just "unsigned long"?
__field(u32,release)
__field(unsigned long, pfn)
),
TP_fast_assign(
__entry->pool= pool;
- __entry->page= page;
+ __entry->netmem = netmem;
You could have this be:
__entry->netmem = (__force unsigned long)netmem;
__entry->release = release;
- __entry->pfn = page_to_pfn(page);
+ __entry->pfn = netmem_to_pfn(netmem);
),
- TP_printk("page_pool=%p page=%p pfn=0x%lx release=%u",
- __entry->pool, __entry->page, __entry->pfn, __entry->release)
+ TP_printk("page_pool=%p netmem=%lu pfn=0x%lx release=%u",
+ __entry->pool, (__force unsigned long)__entry->netmem,
And not have to expose the above text to user space (look at the format
file it produces).
It being of type "netmem_ref" in the ring buffer is useless.
netmem is a pointer with one bit serving as a flag, considering
mangling it might be better to %p it and perhaps also print its
type (page* vs iov) separately.
--
Pavel Begunkov
Re: [PATCH] drm: have config DRM_WERROR depend on !WERROR
On Thu, 16 May 2024, Jani Nikula wrote:
> If WERROR is already enabled, there's no point in enabling DRM_WERROR or
> asking users about it.
Ping. Any comments? (Besides the one snark.)
BR,
Jani.
>
> Reported-by: Linus Torvalds
> Closes:
> https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=veojn6gw8gk4j2v+biduntz...@mail.gmail.com
> Fixes: f89632a9e5fa ("drm: Add CONFIG_DRM_WERROR")
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 026444eeb5c6..d0aa277fc3bf 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -450,6 +450,7 @@ config DRM_PRIVACY_SCREEN
> config DRM_WERROR
> bool "Compile the drm subsystem with warnings as errors"
> depends on DRM && EXPERT
> + depends on !WERROR
> default n
> help
> A kernel build should not cause any compiler warnings, and this
--
Jani Nikula, Intel
Re: [RFC PATCH 7/8] rust: add firmware abstractions
Hi,
On Fri, 31 May 2024 11:59:47 +0200
Danilo Krummrich wrote:
> Once we get to a conclusion I can send a series with only the device and
> firmare
> abstractions such that we can get them in outside of the scope of the reset of
> both series to get your driver going.
Since your discussion with Greg seems to continue for a while, let me
include the following patch that Greg approved with the next version
of the PHY driver patchset.
You have the new version of the firmware patch? The unused functions
will not be merged so only request_firmware() and release_firmware()
can be included. If not, I can include my firmware patch that I wrote
before.
=
From: Danilo Krummrich
Date: Fri, 7 Jun 2024 20:14:59 +0900
Subject: [PATCH] add abstraction for struct device
Add abstraction for struct device. This implements only the minimum
necessary functions required for the abstractions of firmware API;
that is, wrapping C's pointer to a device object with Rust struct only
during a caller knows the pointer is valid (e.g., the probe callback).
Co-developed-by: Wedson Almeida Filho
Signed-off-by: Wedson Almeida Filho
Signed-off-by: Danilo Krummrich
Co-developed-by: FUJITA Tomonori
Signed-off-by: FUJITA Tomonori
Acked-by: Greg Kroah-Hartman
---
rust/kernel/device.rs | 31 +++
rust/kernel/lib.rs| 1 +
2 files changed, 32 insertions(+)
create mode 100644 rust/kernel/device.rs
diff --git a/rust/kernel/device.rs b/rust/kernel/device.rs
new file mode 100644
index ..55ec4f364628
--- /dev/null
+++ b/rust/kernel/device.rs
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Generic devices that are part of the kernel's driver model.
+//!
+//! C header: [`include/linux/device.h`](srctree/include/linux/device.h)
+
+use crate::types::Opaque;
+
+/// Wraps the kernel's `struct task_struct`.
+#[repr(transparent)]
+pub struct Device(Opaque);
+
+impl Device {
+/// Creates a new [`Device`] instance from a raw pointer.
+///
+/// # Safety
+///
+/// For the duration of 'a, the pointer must point at a valid `device`.
+pub unsafe fn from_raw<'a>(ptr: *mut bindings::device) -> &'a Self {
+// CAST: `Self` is a `repr(transparent)` wrapper around
`bindings::device`.
+let ptr = ptr.cast::();
+// SAFETY: by the function requirements the pointer is valid and we
have unique access for
+// the duration of `'a`.
+unsafe { *ptr }
+}
+
+/// Returns the raw pointer to the device.
+pub(crate) fn as_raw() -> *mut bindings::device {
+self.0.get()
+}
+}
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index fbd91a48ff8b..dd1207f1a873 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -28,6 +28,7 @@
pub mod alloc;
mod build_assert;
+pub mod device;
pub mod error;
pub mod init;
pub mod ioctl;
--
2.34.1
Re: [PATCH v2 4/4] drm/panel: starry: add new panel driver
On Fri, 7 Jun 2024 at 14:51, zhaoxiong lv wrote: > > hi Dmitry > > These two panels are not the same IC but their timing is the same, > only the init cmd and panel parameters are different, so I made it > compatible on the kingdisplay driver. We usually merge drivers by the driver IC, not by the timings. Please stop top-posting. > > Similar to this driver: panel-boe-tv101wum-nl6.c > > thanks > > On Sun, Jun 2, 2024 at 12:26 AM Dmitry Baryshkov > wrote: > > > > On Sat, Jun 01, 2024 at 04:45:28PM +0800, Zhaoxiong Lv wrote: > > > This Starry panel has the same timing as the Kingdisplay panel, > > > so add starry configuration in the Kingdisplay driver. > > > > Do these two panels share the same driver IC? Programming sequences do > > not seem common, so it might be better to have a separate driver for > > this panel. -- With best wishes Dmitry
Re: [PATCH v3 07/10] media: intel: Add Displayport RX IP driver
On 04/06/2024 14:32, Paweł Anikiel wrote:
> On Mon, Jun 3, 2024 at 10:37 AM Hans Verkuil wrote:
>>
>> On 07/05/2024 17:54, Paweł Anikiel wrote:
>>> Add v4l2 subdev driver for the Intel Displayport receiver FPGA IP.
>>> It is a part of the DisplayPort Intel FPGA IP Core, and supports
>>> DisplayPort 1.4, HBR3 video capture and Multi-Stream Transport.
>>>
>>> Signed-off-by: Paweł Anikiel
>>> ---
>>> drivers/media/platform/intel/Kconfig | 12 +
>>> drivers/media/platform/intel/Makefile |1 +
>>> drivers/media/platform/intel/intel-dprx.c | 2283 +
>>> 3 files changed, 2296 insertions(+)
>>> create mode 100644 drivers/media/platform/intel/intel-dprx.c
>>>
>>> +static int dprx_probe(struct platform_device *pdev)
>>> +{
>>> + struct dprx *dprx;
>>> + int irq;
>>> + int res;
>>> + int i;
>>> +
>>> + dprx = devm_kzalloc(>dev, sizeof(*dprx), GFP_KERNEL);
>>> + if (!dprx)
>>> + return -ENOMEM;
>>> + dprx->dev = >dev;
>>> + platform_set_drvdata(pdev, dprx);
>>> +
>>> + dprx->iobase = devm_platform_ioremap_resource(pdev, 0);
>>> + if (IS_ERR(dprx->iobase))
>>> + return PTR_ERR(dprx->iobase);
>>> +
>>> + irq = platform_get_irq(pdev, 0);
>>> + if (irq < 0)
>>> + return irq;
>>> +
>>> + res = devm_request_irq(dprx->dev, irq, dprx_isr, 0, "intel-dprx",
>>> dprx);
>>> + if (res)
>>> + return res;
>>> +
>>> + res = dprx_parse_fwnode(dprx);
>>> + if (res)
>>> + return res;
>>> +
>>> + dprx_init_caps(dprx);
>>> +
>>> + dprx->subdev.owner = THIS_MODULE;
>>> + dprx->subdev.dev = >dev;
>>> + v4l2_subdev_init(>subdev, _subdev_ops);
>>> + v4l2_set_subdevdata(>subdev, >dev);
>>> + snprintf(dprx->subdev.name, sizeof(dprx->subdev.name), "%s %s",
>>> + KBUILD_MODNAME, dev_name(>dev));
>>> + dprx->subdev.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
>>> +
>>> + dprx->subdev.entity.function = MEDIA_ENT_F_DV_DECODER;
>>> + dprx->subdev.entity.ops = _entity_ops;
>>> +
>>> + v4l2_ctrl_handler_init(>ctrl_handler, 1);
>>> + v4l2_ctrl_new_std(>ctrl_handler, NULL,
>>> + V4L2_CID_DV_RX_POWER_PRESENT, 0, 1, 0, 0);
>>
>> You are creating this control, but it is never set to 1 when the driver
>> detects
>> that a source is connected. I am wondering if POWER_PRESENT makes sense for a
>> DisplayPort connector. Is there a clean way for a sink driver to detect if a
>> source is connected? For HDMI it detects the 5V pin, but it is not clear if
>> there is an equivalent to that in the DP spec.
>
> The DP spec says the source can be detected using the AUX lines:
>
> "The Downstream devices must very weakly pull up AUX+ line and very
> weakly pull down AUX- line with 1MΩ (+/-5%) resistors between the
> Downstream device Connector and the AC-coupling capacitors. When AUX+
> line DC voltage is L level, it means a DisplayPort Upstream device is
> connected. When AUX- line DC voltage is H level, it means that a
> powered DisplayPort Upstream device is connected."
>
> This exact IP has two input signals: rx_cable_detect, and
> rx_pwr_detect, which are meant to be connected to the AUX+/AUX- lines
> via 10k resistors (or rather that's what the reference design does).
> They're exposed to software via status registers, but there's no way
> to get interrupts from them, so it wouldn't be possible to set the
> control exactly when a source gets plugged in.
>
>>
>> If there is no good way to detect if a source is connected, then it might be
>> better to drop POWER_PRESENT support.
>>
>> This control is supposed to signal that a source is connected as early as
>> possible,
>> ideally before link training etc. starts.
>>
>> It helps the software detect that there is a source, and report an error if
>> a source
>> is detected, but you never get a stable signal (e.g. link training fails).
>
> This poses another problem, because the chameleon board doesn't have
> this detection circuitry, and instead sets the rx_cable_detect and
> rx_pwr_detect signals to always logical high. That would make the
> control read "always plugged in", which IIUC is not desired.
OK, so it is best to drop support for this control.
I recommend adding a comment in the source code explaining why it is not
supported.
And in the cover letter you can mention this as well as an explanation of why
there is a v4l2-compliance warning.
Regards,
Hans
Re: [PATCH v2 2/4] drm/panel: kd101ne3: add new panel driver
On Fri, Jun 07, 2024 at 07:44:33PM +0800, zhaoxiong lv wrote:
> hi Alex Bee
>
> I compared these two drivers. Although the control IC is the same, the
> panel is different, and the init_cmd and timing are also slightly
> different, so I added a separate driver.
But it obviously uses the same structure as the panel-jadard. Please
use existing driver instead of creating a completely new one (which you
happily overload with an unrelated panel).
>
> thanks
>
> On Sun, Jun 2, 2024 at 1:07 PM Alex Bee wrote:
> >
> > Am 01.06.24 um 10:45 schrieb Zhaoxiong Lv:
> >
> > Hi Zhaoxiong,
> >
> > > The bias IC of this kindisplay-kd101ne3 panel is placed
> > > on the panel side, so when the panel is powered on,
> > > there is no need to control AVDD and AVEE in the driver,
> > > only 3.3v and reset are needed.
> > >
> > > Signed-off-by: Zhaoxiong Lv
> > > ---
> > >
> > > Chage since V2:
> > >
> > > - 1. Use the new mipi_dsi_dcs_write_seq_multi() function.
> > > - 2. Modify Move mipi_dsi_dcs_set_display_off() and
> > > mipi_dsi_dcs_enter_sleep_mode() to disable(),
> > > - and drop kingdisplay_panel_enter_sleep_mode().
> > > - 3. If prepare fails, disable GPIO before regulators.
> > > - 4. This function drm_connector_set_panel_orientation() is no longer
> > > used. Delete it.
> > > - 5. Drop ".shutdown = kingdisplay_panel_shutdown".
> > >
> > > ---
> > > drivers/gpu/drm/panel/Kconfig | 9 +
> > > drivers/gpu/drm/panel/Makefile| 1 +
> > > .../drm/panel/panel-kingdisplay-kd101ne3.c| 533 ++
> > > 3 files changed, 543 insertions(+)
> > > create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
> > >
> > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > > index e54f6f5604ed..71669e990e8e 100644
> > > --- a/drivers/gpu/drm/panel/Kconfig
> > > +++ b/drivers/gpu/drm/panel/Kconfig
> > > @@ -297,6 +297,15 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
> > > 24 bit RGB per pixel. It provides a MIPI DSI interface to
> > > the host and has a built-in LED backlight.
> > >
> > > +config DRM_PANEL_KINGDISPLAY_KD101NE3
> > > + tristate "Kingdisplay kd101ne3 panel"
> > > + depends on OF
> > > + depends on DRM_MIPI_DSI
> > > + depends on BACKLIGHT_CLASS_DEVICE
> > > + help
> > > + Say Y here if you want to enable support for the kingdisplay
> > > kd101ne3
> > > + 4-lane 800x1280 MIPI DSI panel.
> > > +
> > > config DRM_PANEL_LEADTEK_LTK050H3146W
> > > tristate "Leadtek LTK050H3146W panel"
> > > depends on OF
> > > diff --git a/drivers/gpu/drm/panel/Makefile
> > > b/drivers/gpu/drm/panel/Makefile
> > > index f0203f6e02f4..4576c9fe33d9 100644
> > > --- a/drivers/gpu/drm/panel/Makefile
> > > +++ b/drivers/gpu/drm/panel/Makefile
> > > @@ -30,6 +30,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LPM102A188A) +=
> > > panel-jdi-lpm102a188a.o
> > > obj-$(CONFIG_DRM_PANEL_JDI_R63452) += panel-jdi-fhd-r63452.o
> > > obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
> > > obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) +=
> > > panel-kingdisplay-kd097d04.o
> > > +obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD101NE3) +=
> > > panel-kingdisplay-kd101ne3.o
> > > obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) +=
> > > panel-leadtek-ltk050h3146w.o
> > > obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) +=
> > > panel-leadtek-ltk500hd1829.o
> > > obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> > > diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
> > > b/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
> > > new file mode 100644
> > > index ..8994a1c9afb5
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
> > > @@ -0,0 +1,533 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/* Panels based on the JD9365DA display controller.
> > > + * Author: Zhaoxiong Lv
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +
> > > +struct kingdisplay_panel;
> > > +
> > > +struct panel_desc {
> > > + const struct drm_display_mode *modes;
> > > + unsigned int bpc;
> > > +
> > > + /**
> > > + * @width_mm: width of the panel's active display area
> > > + * @height_mm: height of the panel's active display area
> > > + */
> > > + struct {
> > > + unsigned int width_mm;
> > > + unsigned int height_mm;
> > > + } size;
> > > +
> > > + unsigned long mode_flags;
> > > + enum mipi_dsi_pixel_format format;
> > > + const struct panel_init_cmd *init_cmds;
> > > + int (*init)(struct kingdisplay_panel *kingdisplay);
> > > + unsigned int lanes;
> > > + bool discharge_on_disable;
> > > + bool lp11_before_reset;
> > > +};
> > > +
> > > +struct kingdisplay_panel {
> > > + struct drm_panel base;
> > >
Re: [PATCH v2 0/3] Move blender setup from individual planes to crtc commit in sun4i-drm
Hi Maxime, On Sun, Apr 21, 2024 at 09:52:58PM GMT, Jernej Škrabec wrote: > Dne petek, 19. april 2024 ob 15:36:17 GMT +2 je Ondřej Jirman napisal(a): > > Hi, > > > > On Sat, Feb 24, 2024 at 04:05:57PM GMT, megi xff wrote: > > > From: Ondrej Jirman > > > > > > This series refactors blender setup from individual planes to a common > > > place where it can be performed at once and is easier to reason about. > > > > > > In the process this fixes a few bugs that allowed blender pipes to be > > > disabled while corresponding DRM planes were requested to be enabled. > > > > > > Please take a look. :) > > > > > > v2: > > > - use regmap_write where possible > > > - add review tags > > > > It would be nice to have this applied. > > Maxime, > > do you mind applying? Pretty please :) It would be nice if this did not miss another merge cycle. Maxime, this is the solution you hinted at back in 2019: https://lore.kernel.org/all/20191003113802.tyecgkb6r3piin35@gilmour/ Let's get this fixed. Or anyone else who can pull this to DRM tree. Thanks and kind regards, o. > Best regards, > Jernej > > > > > Kind regards, > > o. > > > > > Thank you very much, > > > Ondřej Jirman > > > > > > Ondrej Jirman (3): > > > drm/sun4i: Unify sun8i_*_layer structs > > > drm/sun4i: Add more parameters to sunxi_engine commit callback > > > drm/sun4i: Fix layer zpos change/atomic modesetting > > > > > > drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +- > > > drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 +- > > > drivers/gpu/drm/sun4i/sun8i_mixer.c| 70 - > > > drivers/gpu/drm/sun4i/sun8i_mixer.h| 20 ++ > > > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 85 +++-- > > > drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 20 ++ > > > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 86 +++--- > > > drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 20 ++ > > > drivers/gpu/drm/sun4i/sunxi_engine.h | 13 +++- > > > 9 files changed, 125 insertions(+), 195 deletions(-) > > > > > > > > >
Re: [PATCH v2 4/4] drm/panel: starry: add new panel driver
s_write_seq_multi(_ctx, 0xf0, 0x12, 0x03, 0x20, 0x00,
> > 0xff);
> > + mipi_dsi_dcs_write_seq_multi(_ctx, 0xf3, 0x00);
> > + if (dsi_ctx.accum_err)
> > + return dsi_ctx.accum_err;
> > +
> > + mipi_dsi_dcs_write_seq_multi(_ctx, MIPI_DCS_EXIT_SLEEP_MODE);
> > + if (dsi_ctx.accum_err)
> > + return dsi_ctx.accum_err;
> > +
> > + msleep(120);
> > +
> > + mipi_dsi_dcs_write_seq_multi(_ctx, MIPI_DCS_SET_DISPLAY_ON);
> > + if (dsi_ctx.accum_err)
> > + return dsi_ctx.accum_err;
> > +
> > + msleep(20);
>
> Most of the comments from the patch 2 apply:
> - drop conditions
> - use mipi_dsi_dcs_set_display_on_multi(),
> mipi_dsi_dcs_exit_sleep_mode_multi() and mipi_dsi_msleep().
>
> > +
> > + return 0;
> > +};
> > +
> > static inline struct kingdisplay_panel *to_kingdisplay_panel(struct
> > drm_panel *panel)
> > {
> > return container_of(panel, struct kingdisplay_panel, base);
> > @@ -391,6 +452,34 @@ static const struct panel_desc
> > kingdisplay_kd101ne3_40ti_desc = {
> > .lp11_before_reset = true,
> > };
> >
> > +static const struct drm_display_mode starry_er88577_default_mode = {
> > + .clock = 77380,
> > + .hdisplay = 800,
> > + .hsync_start = 800 + 80,
> > + .hsync_end = 800 + 80 + 20,
> > + .htotal = 800 + 80 + 20 + 80,
> > + .vdisplay = 1280,
> > + .vsync_start = 1280 + 20,
> > + .vsync_end = 1280 + 20 + 4,
> > + .vtotal = 1280 + 20 + 4 + 12,
> > + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> > +};
> > +
> > +static const struct panel_desc starry_er88577_desc = {
> > + .modes = _er88577_default_mode,
> > + .bpc = 8,
> > + .size = {
> > + .width_mm = 135,
> > + .height_mm = 216,
> > + },
> > + .lanes = 4,
> > + .format = MIPI_DSI_FMT_RGB888,
> > + .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> > + MIPI_DSI_MODE_LPM,
> > + .init = starry_er88577_init,
> > + .lp11_before_reset = true,
> > +};
> > +
> > static int kingdisplay_panel_get_modes(struct drm_panel *panel,
> > struct drm_connector *connector)
> > {
> > @@ -514,6 +603,9 @@ static const struct of_device_id kingdisplay_of_match[]
> > = {
> > { .compatible = "kingdisplay,kd101ne3-40ti",
> > .data = _kd101ne3_40ti_desc
> > },
> > + { .compatible = "starry,er88577",
> > + .data = _er88577_desc
> > + },
> > { /* sentinel */ }
> > };
> > MODULE_DEVICE_TABLE(of, kingdisplay_of_match);
> > --
> > 2.17.1
> >
>
> --
> With best wishes
> Dmitry
Re: [PATCH v2 1/4] dt-bindings: display: panel: Add KD101NE3-40TI support
On Fri, 7 Jun 2024 at 14:38, zhaoxiong lv
wrote:
>
> hi Dmitry Baryshkov
>
> Because this is a separate mipi dsi driver, I did not put it in
> panel-sample-dsi.yaml.
Driver and bindings are two separate things. Bindings describe the
hardware. If there is no other reason to have a separate bindings
document, please use panel-simple-dsi.yaml.
Also please don't top-post in public mailing lists.
>
>
> On Sun, Jun 2, 2024 at 12:28 AM Dmitry Baryshkov
> wrote:
> >
> > On Sat, Jun 01, 2024 at 04:45:25PM +0800, Zhaoxiong Lv wrote:
> > > Create a new dt-scheam for the kd101ne3-40ti.
> > > The bias IC of this kindisplay-kd101ne3 panel is placed
> > > on the panel side, so when the panel is powered on,
> > > there is no need to control AVDD and AVEE in the driver.
> > >
> > > Signed-off-by: Zhaoxiong Lv
> > > ---
> > >
> > > Chage since V2:
> > >
> > > - Drop some properties that have already been defined in panel-common.
> > > - The header file 'dt-bindings/gpio/gpio.h' is not used, delete it
> > >
> > > V1:
> > > https://lore.kernel.org/all/20240418081548.12160-2-lvzhaoxi...@huaqin.corp-partner.google.com/
> > >
> > > ---
> > > .../panel/kingdisplay,kd101ne3-40ti.yaml | 59 +++
> > > 1 file changed, 59 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/display/panel/kingdisplay,kd101ne3-40ti.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd101ne3-40ti.yaml
> > >
> > > b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd101ne3-40ti.yaml
> > > new file mode 100644
> > > index ..b0cf12bb727d
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd101ne3-40ti.yaml
> > > @@ -0,0 +1,59 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/display/panel/kingdisplay,kd101ne3-40ti.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Kingdisplay KD101NE3-40TI based MIPI-DSI panels
> > > +
> > > +maintainers:
> > > + - Zhaoxiong Lv
> >
> > Any reason for using a separate bindings instead of extending
> > panel-simple-dsi.yaml ?
> >
> > > +
> > > +allOf:
> > > + - $ref: panel-common.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > +items:
> > > + - enum:
> > > + - kingdisplay,kd101ne3-40ti
> > > +
> > > + reg:
> > > +description: the virtual channel number of a DSI peripheral
> > > +
> > > + pp3300-supply:
> > > +description: core voltage supply
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - pp3300-supply
> > > + - enable-gpios
> > > + - backlight
> > > + - port
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +examples:
> > > + - |
> > > +dsi {
> > > +#address-cells = <1>;
> > > +#size-cells = <0>;
> > > +panel: panel@0 {
> > > +compatible = "kingdisplay,kd101ne3-40ti";
> > > +reg = <0>;
> > > +enable-gpios = < 98 0>;
> > > +pinctrl-names = "default";
> > > +pinctrl-0 = <_pins_default>;
> > > +pp3300-supply = <_pp6000_mipi_disp>;
> > > +backlight = <_lcd0>;
> > > +rotation = <90>;
> > > +port {
> > > +panel_in: endpoint {
> > > +remote-endpoint = <_out>;
> > > +};
> > > +};
> > > +};
> > > +};
> > > +
> > > +...
> > > --
> > > 2.17.1
> > >
> >
> > --
> > With best wishes
> > Dmitry
--
With best wishes
Dmitry
Re: [PATCH v2 2/4] drm/panel: kd101ne3: add new panel driver
hi Alex Bee
I compared these two drivers. Although the control IC is the same, the
panel is different, and the init_cmd and timing are also slightly
different, so I added a separate driver.
thanks
On Sun, Jun 2, 2024 at 1:07 PM Alex Bee wrote:
>
> Am 01.06.24 um 10:45 schrieb Zhaoxiong Lv:
>
> Hi Zhaoxiong,
>
> > The bias IC of this kindisplay-kd101ne3 panel is placed
> > on the panel side, so when the panel is powered on,
> > there is no need to control AVDD and AVEE in the driver,
> > only 3.3v and reset are needed.
> >
> > Signed-off-by: Zhaoxiong Lv
> > ---
> >
> > Chage since V2:
> >
> > - 1. Use the new mipi_dsi_dcs_write_seq_multi() function.
> > - 2. Modify Move mipi_dsi_dcs_set_display_off() and
> > mipi_dsi_dcs_enter_sleep_mode() to disable(),
> > - and drop kingdisplay_panel_enter_sleep_mode().
> > - 3. If prepare fails, disable GPIO before regulators.
> > - 4. This function drm_connector_set_panel_orientation() is no longer
> > used. Delete it.
> > - 5. Drop ".shutdown = kingdisplay_panel_shutdown".
> >
> > ---
> > drivers/gpu/drm/panel/Kconfig | 9 +
> > drivers/gpu/drm/panel/Makefile| 1 +
> > .../drm/panel/panel-kingdisplay-kd101ne3.c| 533 ++
> > 3 files changed, 543 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index e54f6f5604ed..71669e990e8e 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -297,6 +297,15 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
> > 24 bit RGB per pixel. It provides a MIPI DSI interface to
> > the host and has a built-in LED backlight.
> >
> > +config DRM_PANEL_KINGDISPLAY_KD101NE3
> > + tristate "Kingdisplay kd101ne3 panel"
> > + depends on OF
> > + depends on DRM_MIPI_DSI
> > + depends on BACKLIGHT_CLASS_DEVICE
> > + help
> > + Say Y here if you want to enable support for the kingdisplay
> > kd101ne3
> > + 4-lane 800x1280 MIPI DSI panel.
> > +
> > config DRM_PANEL_LEADTEK_LTK050H3146W
> > tristate "Leadtek LTK050H3146W panel"
> > depends on OF
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index f0203f6e02f4..4576c9fe33d9 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -30,6 +30,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LPM102A188A) +=
> > panel-jdi-lpm102a188a.o
> > obj-$(CONFIG_DRM_PANEL_JDI_R63452) += panel-jdi-fhd-r63452.o
> > obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
> > obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) +=
> > panel-kingdisplay-kd097d04.o
> > +obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD101NE3) +=
> > panel-kingdisplay-kd101ne3.o
> > obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) +=
> > panel-leadtek-ltk050h3146w.o
> > obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) +=
> > panel-leadtek-ltk500hd1829.o
> > obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> > diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
> > b/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
> > new file mode 100644
> > index ..8994a1c9afb5
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd101ne3.c
> > @@ -0,0 +1,533 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Panels based on the JD9365DA display controller.
> > + * Author: Zhaoxiong Lv
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +struct kingdisplay_panel;
> > +
> > +struct panel_desc {
> > + const struct drm_display_mode *modes;
> > + unsigned int bpc;
> > +
> > + /**
> > + * @width_mm: width of the panel's active display area
> > + * @height_mm: height of the panel's active display area
> > + */
> > + struct {
> > + unsigned int width_mm;
> > + unsigned int height_mm;
> > + } size;
> > +
> > + unsigned long mode_flags;
> > + enum mipi_dsi_pixel_format format;
> > + const struct panel_init_cmd *init_cmds;
> > + int (*init)(struct kingdisplay_panel *kingdisplay);
> > + unsigned int lanes;
> > + bool discharge_on_disable;
> > + bool lp11_before_reset;
> > +};
> > +
> > +struct kingdisplay_panel {
> > + struct drm_panel base;
> > + struct mipi_dsi_device *dsi;
> > +
> > + const struct panel_desc *desc;
> > +
> > + enum drm_panel_orientation orientation;
> > + struct regulator *pp3300;
> > + struct gpio_desc *enable_gpio;
> > +};
> > +
> > +static int kingdisplay_kd101ne3_init(struct kingdisplay_panel *kingdisplay)
> > +{
> > + struct mipi_dsi_multi_context dsi_ctx = { .dsi = kingdisplay->dsi };
> > +
> > + /* T5:HWreset to init_code >= 50ms */
> > + msleep(50);
> > +
> > +
Re: [PATCH v2 1/4] dt-bindings: display: panel: Add KD101NE3-40TI support
hi Dmitry Baryshkov
Because this is a separate mipi dsi driver, I did not put it in
panel-sample-dsi.yaml.
On Sun, Jun 2, 2024 at 12:28 AM Dmitry Baryshkov
wrote:
>
> On Sat, Jun 01, 2024 at 04:45:25PM +0800, Zhaoxiong Lv wrote:
> > Create a new dt-scheam for the kd101ne3-40ti.
> > The bias IC of this kindisplay-kd101ne3 panel is placed
> > on the panel side, so when the panel is powered on,
> > there is no need to control AVDD and AVEE in the driver.
> >
> > Signed-off-by: Zhaoxiong Lv
> > ---
> >
> > Chage since V2:
> >
> > - Drop some properties that have already been defined in panel-common.
> > - The header file 'dt-bindings/gpio/gpio.h' is not used, delete it
> >
> > V1:
> > https://lore.kernel.org/all/20240418081548.12160-2-lvzhaoxi...@huaqin.corp-partner.google.com/
> >
> > ---
> > .../panel/kingdisplay,kd101ne3-40ti.yaml | 59 +++
> > 1 file changed, 59 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/kingdisplay,kd101ne3-40ti.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd101ne3-40ti.yaml
> >
> > b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd101ne3-40ti.yaml
> > new file mode 100644
> > index ..b0cf12bb727d
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd101ne3-40ti.yaml
> > @@ -0,0 +1,59 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > http://devicetree.org/schemas/display/panel/kingdisplay,kd101ne3-40ti.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Kingdisplay KD101NE3-40TI based MIPI-DSI panels
> > +
> > +maintainers:
> > + - Zhaoxiong Lv
>
> Any reason for using a separate bindings instead of extending
> panel-simple-dsi.yaml ?
>
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - enum:
> > + - kingdisplay,kd101ne3-40ti
> > +
> > + reg:
> > +description: the virtual channel number of a DSI peripheral
> > +
> > + pp3300-supply:
> > +description: core voltage supply
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - pp3300-supply
> > + - enable-gpios
> > + - backlight
> > + - port
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > +dsi {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +panel: panel@0 {
> > +compatible = "kingdisplay,kd101ne3-40ti";
> > +reg = <0>;
> > +enable-gpios = < 98 0>;
> > +pinctrl-names = "default";
> > +pinctrl-0 = <_pins_default>;
> > +pp3300-supply = <_pp6000_mipi_disp>;
> > +backlight = <_lcd0>;
> > +rotation = <90>;
> > +port {
> > +panel_in: endpoint {
> > +remote-endpoint = <_out>;
> > +};
> > +};
> > +};
> > +};
> > +
> > +...
> > --
> > 2.17.1
> >
>
> --
> With best wishes
> Dmitry
[PATCH RFC 8/8] drm: sun4i: add Display Engine 3.3 (DE33) support
The DE33 is a newer version of the Allwinner Display Engine IP block,
found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
supported by the mainline driver.
Notable features (from the H616 datasheet and implemented):
- 4096 x 2048 (4K) output support
- AFBC ARM Frame Buffer Compression support
- YUV420 input support
Extend the driver to support the DE33.
Signed-off-by: Jernej Skrabec
Co-developed-by: Ryan Walklin
Signed-off-by: Ryan Walklin
---
drivers/clk/sunxi-ng/Makefile | 2 +-
drivers/clk/sunxi-ng/sun8i-de33.c | 185 +
drivers/clk/sunxi-ng/sun8i-de33.h | 19 +++
drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 +
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
drivers/gpu/drm/sun4i/sun50i_afbc.c | 16 +-
drivers/gpu/drm/sun4i/sun50i_fmt.c | 75 ++---
drivers/gpu/drm/sun4i/sun50i_fmt.h | 21 ++-
drivers/gpu/drm/sun4i/sun8i_csc.c | 98 ++-
drivers/gpu/drm/sun4i/sun8i_csc.h | 3 +
drivers/gpu/drm/sun4i/sun8i_mixer.c | 209 +++-
drivers/gpu/drm/sun4i/sun8i_mixer.h | 31 +++-
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 36 ++--
drivers/gpu/drm/sun4i/sun8i_ui_scaler.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 33 ++--
drivers/gpu/drm/sun4i/sun8i_vi_scaler.c | 115 -
drivers/gpu/drm/sun4i/sun8i_vi_scaler.h | 3 +-
17 files changed, 703 insertions(+), 150 deletions(-)
create mode 100644 drivers/clk/sunxi-ng/sun8i-de33.c
create mode 100644 drivers/clk/sunxi-ng/sun8i-de33.h
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 6b3ae2b620db6..fce8a1ce61137 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -68,7 +68,7 @@ sun8i-a83t-ccu-y += ccu-sun8i-a83t.o
sun8i-h3-ccu-y += ccu-sun8i-h3.o
sun8i-r40-ccu-y+= ccu-sun8i-r40.o
sun8i-v3s-ccu-y+= ccu-sun8i-v3s.o
-sun8i-de2-ccu-y+= ccu-sun8i-de2.o
+sun8i-de2-ccu-y+= ccu-sun8i-de2.o sun8i-de33.o
sun8i-r-ccu-y += ccu-sun8i-r.o
sun9i-a80-ccu-y+= ccu-sun9i-a80.o
sun9i-a80-de-ccu-y += ccu-sun9i-a80-de.o
diff --git a/drivers/clk/sunxi-ng/sun8i-de33.c
b/drivers/clk/sunxi-ng/sun8i-de33.c
new file mode 100644
index 0..4287dafbc26e4
--- /dev/null
+++ b/drivers/clk/sunxi-ng/sun8i-de33.c
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2017 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ccu_common.h"
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_reset.h"
+
+#include "sun8i-de33.h"
+
+static SUNXI_CCU_GATE(bus_mixer0_clk, "bus-mixer0", "bus-de",
+ 0x04, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_mixer1_clk, "bus-mixer1", "bus-de",
+ 0x04, BIT(1), 0);
+static SUNXI_CCU_GATE(bus_wb_clk, "bus-wb", "bus-de",
+ 0x04, BIT(2), 0);
+
+static SUNXI_CCU_GATE(mixer0_clk, "mixer0", "mixer0-div",
+ 0x00, BIT(0), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(mixer1_clk, "mixer1", "mixer1-div",
+ 0x00, BIT(1), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(wb_clk, "wb", "wb-div",
+ 0x00, BIT(2), CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4,
+ CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de", 0x0c, 4, 4,
+ CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4,
+ CLK_SET_RATE_PARENT);
+
+static struct ccu_common *sun50i_h616_de33_clks[] = {
+ _clk.common,
+ _clk.common,
+ _clk.common,
+
+ _mixer0_clk.common,
+ _mixer1_clk.common,
+ _wb_clk.common,
+
+ _div_clk.common,
+ _div_clk.common,
+ _div_clk.common,
+};
+
+static struct clk_hw_onecell_data sun50i_h616_de33_hw_clks = {
+ .hws= {
+ [CLK_MIXER0]= _clk.common.hw,
+ [CLK_MIXER1]= _clk.common.hw,
+ [CLK_WB]= _clk.common.hw,
+
+ [CLK_BUS_MIXER0]= _mixer0_clk.common.hw,
+ [CLK_BUS_MIXER1]= _mixer1_clk.common.hw,
+ [CLK_BUS_WB]= _wb_clk.common.hw,
+
+ [CLK_MIXER0_DIV]= _div_clk.common.hw,
+ [CLK_MIXER1_DIV]= _div_clk.common.hw,
+ [CLK_WB_DIV]= _div_clk.common.hw,
+ },
+ .num= CLK_NUMBER,
+};
+
+static struct ccu_reset_map sun50i_h616_de33_resets[] = {
+ [RST_MIXER0]= { 0x08, BIT(0) },
+ [RST_MIXER1]= { 0x08, BIT(1) },
+ [RST_WB]= { 0x08, BIT(2) },
+};
+
+static const struct sunxi_ccu_desc
[PATCH RFC 7/8] drm/sun4i: de3: Implement AFBC support
Buffers, compressed with AFBC, are generally more efficient for memory
transfers. Add support for them.
Currently it's implemented only for VI layers, but vendor code and
documentation suggest UI layers can have them too. However, I haven't
observed any SoC with such feature.
Signed-off-by: Jernej Skrabec
Co-developed-by: Ryan Walklin
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/sun4i/Makefile | 2 +-
drivers/gpu/drm/sun4i/sun50i_afbc.c| 240 +
drivers/gpu/drm/sun4i/sun50i_afbc.h| 87 +
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 84 +++--
4 files changed, 400 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun50i_afbc.c
create mode 100644 drivers/gpu/drm/sun4i/sun50i_afbc.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 3f516329f51ee..78290f1660fbd 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -17,7 +17,7 @@ sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
sun8i_vi_scaler.o sun8i_csc.o \
- sun50i_fmt.o
+ sun50i_fmt.o sun50i_afbc.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_tcon_dclk.o
diff --git a/drivers/gpu/drm/sun4i/sun50i_afbc.c
b/drivers/gpu/drm/sun4i/sun50i_afbc.c
new file mode 100644
index 0..27a771608eef8
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun50i_afbc.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) Jernej Skrabec
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sun50i_afbc.h"
+#include "sun8i_mixer.h"
+
+bool sun50i_afbc_format_mod_supported(struct sun8i_mixer *mixer,
+ u32 format, u64 modifier)
+{
+ u64 mode;
+
+ if (modifier == DRM_FORMAT_MOD_INVALID)
+ return false;
+
+ if (modifier == DRM_FORMAT_MOD_LINEAR) {
+ if (format == DRM_FORMAT_YUV420_8BIT ||
+ format == DRM_FORMAT_YUV420_10BIT ||
+ format == DRM_FORMAT_Y210)
+ return false;
+ return true;
+ }
+
+ if (!mixer->cfg->is_de3)
+ return false;
+
+ mode = AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
+ AFBC_FORMAT_MOD_SPARSE |
+ AFBC_FORMAT_MOD_SPLIT;
+
+ switch (format) {
+ case DRM_FORMAT_RGBA:
+ case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_RGBA:
+ case DRM_FORMAT_RGBA5551:
+ case DRM_FORMAT_RGBA1010102:
+ mode |= AFBC_FORMAT_MOD_YTR;
+ break;
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_YUV420_8BIT:
+ case DRM_FORMAT_YUV420_10BIT:
+ break;
+ default:
+ return false;
+ }
+
+ return modifier == DRM_FORMAT_MOD_ARM_AFBC(mode);
+}
+
+void sun50i_afbc_atomic_update(struct sun8i_mixer *mixer, unsigned int channel,
+ struct drm_plane *plane)
+{
+ struct drm_plane_state *state = plane->state;
+ struct drm_framebuffer *fb = state->fb;
+ const struct drm_format_info *format = fb->format;
+ struct drm_gem_dma_object *gem;
+ u32 base, val, src_w, src_h;
+ u32 def_color0, def_color1;
+ struct regmap *regs;
+ dma_addr_t dma_addr;
+
+ base = sun8i_channel_base(mixer, channel) + SUN50I_AFBC_CH_OFFSET;
+ regs = mixer->engine.regs;
+
+ src_w = drm_rect_width(>src) >> 16;
+ src_h = drm_rect_height(>src) >> 16;
+
+ val = SUN50I_FBD_SIZE_HEIGHT(src_h);
+ val |= SUN50I_FBD_SIZE_WIDTH(src_w);
+ regmap_write(regs, SUN50I_FBD_SIZE(base), val);
+
+ val = SUN50I_FBD_BLK_SIZE_HEIGHT(DIV_ROUND_UP(src_h, 16));
+ val = SUN50I_FBD_BLK_SIZE_WIDTH(DIV_ROUND_UP(src_w, 16));
+ regmap_write(regs, SUN50I_FBD_BLK_SIZE(base), val);
+
+ val = SUN50I_FBD_SRC_CROP_TOP(0);
+ val |= SUN50I_FBD_SRC_CROP_LEFT(0);
+ regmap_write(regs, SUN50I_FBD_SRC_CROP(base), val);
+
+ val = SUN50I_FBD_LAY_CROP_TOP(state->src.y1 >> 16);
+ val |= SUN50I_FBD_LAY_CROP_LEFT(state->src.x1 >> 16);
+ regmap_write(regs, SUN50I_FBD_LAY_CROP(base), val);
+
+ /*
+* Default color is always set to white, in colorspace and bitness
+* that coresponds to used format. If it is actually used or not
+* depends on AFBC buffer. At least in Cedrus it can be turned on
+* or off.
+* NOTE: G and B channels are off by 1 (up). It's unclear if this
+* is because HW need such value or it is due to good enough code
+* in vendor driver and HW clips the value anyway.
+
[PATCH RFC 6/8] drm/sun4i: de3: Add support for YUV420 output
Signed-off-by: Jernej Skrabec
Co-developed-by: Ryan Walklin
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/drm_atomic_state_helper.c | 7 +
drivers/gpu/drm/sun4i/Makefile| 3 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c| 26 +++-
drivers/gpu/drm/sun4i/sun50i_fmt.c| 74 ++
drivers/gpu/drm/sun4i/sun50i_fmt.h| 30
drivers/gpu/drm/sun4i/sun8i_csc.c | 172 +-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 52 ++-
drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 +
drivers/gpu/drm/sun4i/sunxi_engine.h | 34 +
9 files changed, 384 insertions(+), 16 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun50i_fmt.c
create mode 100644 drivers/gpu/drm/sun4i/sun50i_fmt.h
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 519228eb10953..57e2c4e788303 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -430,7 +430,14 @@ void
__drm_atomic_helper_connector_state_reset(struct drm_connector_state
*conn_state,
struct drm_connector *connector)
{
+ struct drm_property *prop;
+
conn_state->connector = connector;
+ prop = connector->max_bpc_property;
+ if (prop) {
+ conn_state->max_bpc = prop->values[1];
+ conn_state->max_requested_bpc = prop->values[1];
+ }
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_state_reset);
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index bad7497a0d11e..3f516329f51ee 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -16,7 +16,8 @@ sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
- sun8i_vi_scaler.o sun8i_csc.o
+ sun8i_vi_scaler.o sun8i_csc.o \
+ sun50i_fmt.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_tcon_dclk.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index a1a2c845ade0c..e39926e9f0b5d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -598,14 +598,26 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
const struct drm_display_mode *mode)
{
- unsigned int bp, hsync, vsync, vtotal;
+ unsigned int bp, hsync, vsync, vtotal, div;
+ struct sun4i_crtc *scrtc = tcon->crtc;
+ struct sunxi_engine *engine = scrtc->engine;
u8 clk_delay;
u32 val;
WARN_ON(!tcon->quirks->has_channel_1);
+ switch (engine->format) {
+ case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+ case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+ div = 2;
+ break;
+ default:
+ div = 1;
+ break;
+ }
+
/* Configure the dot clock */
- clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
+ clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000 / div);
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
@@ -624,17 +636,17 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
/* Set the input resolution */
regmap_write(tcon->regs, SUN4I_TCON1_BASIC0_REG,
-SUN4I_TCON1_BASIC0_X(mode->crtc_hdisplay) |
+SUN4I_TCON1_BASIC0_X(mode->crtc_hdisplay / div) |
SUN4I_TCON1_BASIC0_Y(mode->crtc_vdisplay));
/* Set the upscaling resolution */
regmap_write(tcon->regs, SUN4I_TCON1_BASIC1_REG,
-SUN4I_TCON1_BASIC1_X(mode->crtc_hdisplay) |
+SUN4I_TCON1_BASIC1_X(mode->crtc_hdisplay / div) |
SUN4I_TCON1_BASIC1_Y(mode->crtc_vdisplay));
/* Set the output resolution */
regmap_write(tcon->regs, SUN4I_TCON1_BASIC2_REG,
-SUN4I_TCON1_BASIC2_X(mode->crtc_hdisplay) |
+SUN4I_TCON1_BASIC2_X(mode->crtc_hdisplay / div) |
SUN4I_TCON1_BASIC2_Y(mode->crtc_vdisplay));
/* Set horizontal display timings */
@@ -642,8 +654,8 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch %d\n",
mode->htotal, bp);
regmap_write(tcon->regs, SUN4I_TCON1_BASIC3_REG,
-SUN4I_TCON1_BASIC3_H_TOTAL(mode->crtc_htotal) |
-SUN4I_TCON1_BASIC3_H_BACKPORCH(bp));
+SUN4I_TCON1_BASIC3_H_TOTAL(mode->crtc_htotal / div) |
+SUN4I_TCON1_BASIC3_H_BACKPORCH(bp / div));
bp =
[PATCH RFC 5/8] drm/sun4i: de2: Initialize layer fields earlier
From: Jernej Skrabec
drm_universal_plane_init() can already call some callbacks, like
format_mod_supported, during initialization. Because of that, fields
should be initialized beforehand.
Signed-off-by: Jernej Skrabec
Co-developed-by: Ryan Walklin
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 7 ---
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index 884abe3cf773a..91781b5ce 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -365,6 +365,10 @@ struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct
drm_device *drm,
if (!layer)
return ERR_PTR(-ENOMEM);
+ layer->mixer = mixer;
+ layer->channel = channel;
+ layer->overlay = 0;
+
if (index == 0)
type = DRM_PLANE_TYPE_PRIMARY;
@@ -395,9 +399,6 @@ struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct
drm_device *drm,
}
drm_plane_helper_add(>plane, _ui_layer_helper_funcs);
- layer->mixer = mixer;
- layer->channel = channel;
- layer->overlay = 0;
return layer;
}
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 6ee3790a2a812..329e8bf8cd20d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -549,6 +549,10 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
drm_device *drm,
if (!layer)
return ERR_PTR(-ENOMEM);
+ layer->mixer = mixer;
+ layer->channel = index;
+ layer->overlay = 0;
+
if (mixer->cfg->is_de3) {
formats = sun8i_vi_layer_de3_formats;
format_count = ARRAY_SIZE(sun8i_vi_layer_de3_formats);
@@ -607,9 +611,6 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
drm_device *drm,
}
drm_plane_helper_add(>plane, _vi_layer_helper_funcs);
- layer->mixer = mixer;
- layer->channel = index;
- layer->overlay = 0;
return layer;
}
--
2.45.2
[PATCH RFC 4/8] drm/sun4i: de2/de3: call csc setup also for UI layer
From: Jernej Skrabec
Currently, only VI layer calls CSC setup function. This comes from DE2
limitation, which doesn't have CSC unit for UI layers. However, DE3 has
separate CSC units for each layer. This allows display pipeline to make
output signal in different color spaces. To support both use cases, add
a call to CSC setup function also in UI layer code. For DE2, this will
be a no-op, but it will allow DE3 to output signal in multiple formats.
Signed-off-by: Jernej Skrabec
Co-developed-by: Ryan Walklin
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/sun4i/sun8i_csc.c | 8 +---
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 6 ++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
b/drivers/gpu/drm/sun4i/sun8i_csc.c
index 0dcbc0866ae82..68d955c63b05b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_csc.c
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
@@ -209,8 +209,10 @@ void sun8i_csc_set_ccsc(struct sun8i_mixer *mixer, int
layer,
return;
}
- base = ccsc_base[mixer->cfg->ccsc][layer];
+ if (layer < mixer->cfg->vi_num) {
+ base = ccsc_base[mixer->cfg->ccsc][layer];
- sun8i_csc_setup(mixer->engine.regs, base,
- fmt_type, encoding, range);
+ sun8i_csc_setup(mixer->engine.regs, base,
+ fmt_type, encoding, range);
+ }
}
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index ca75ca0835a63..884abe3cf773a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -20,6 +20,7 @@
#include
#include
+#include "sun8i_csc.h"
#include "sun8i_mixer.h"
#include "sun8i_ui_layer.h"
#include "sun8i_ui_scaler.h"
@@ -184,6 +185,11 @@ static int sun8i_ui_layer_update_formats(struct
sun8i_mixer *mixer, int channel,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base, overlay),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK, val);
+ /* Note: encoding and range arguments are ignored for RGB */
+ sun8i_csc_set_ccsc(mixer, channel, FORMAT_TYPE_RGB,
+ DRM_COLOR_YCBCR_BT601,
+ DRM_COLOR_YCBCR_FULL_RANGE);
+
return 0;
}
--
2.45.2
