[PATCH] drm/vc4: Fix pm_runtime_get_sync() error checking
If the device is already in a runtime PM enabled state
pm_runtime_get_sync() will return 1, so a test for negative
value should be used to check for errors.
Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/vc4/vc4_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 752f921735c6..26aa7d1fa421 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -847,7 +847,7 @@ static void vc4_dsi_encoder_enable(struct drm_encoder
*encoder)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret) {
+ if (ret < 0) {
DRM_ERROR("Failed to runtime PM enable on DSI%d\n",
dsi->variant->port);
return;
}
--
2.17.1
[PATCH 5.16 256/285] drm/nouveau/pmu: Add missing callbacks for Tegra devices
From: Karol Herbst
commit 38d4e5cf5b08798f093374e53c2f4609d5382dd5 upstream.
Fixes a crash booting on those platforms with nouveau.
Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset
sequence")
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v5.17+
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220322124800.2605463-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c |2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h |1 +
4 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -216,6 +216,7 @@ gm20b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gf100_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
@@ -23,7 +23,7 @@
*/
#include "priv.h"
-static void
+void
gp102_pmu_reset(struct nvkm_pmu *pmu)
{
struct nvkm_device *device = pmu->subdev.device;
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
@@ -83,6 +83,7 @@ gp10b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gp102_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
@@ -41,6 +41,7 @@ int gt215_pmu_send(struct nvkm_pmu *, u3
bool gf100_pmu_enabled(struct nvkm_pmu *);
void gf100_pmu_reset(struct nvkm_pmu *);
+void gp102_pmu_reset(struct nvkm_pmu *pmu);
void gk110_pmu_pgob(struct nvkm_pmu *, bool);
[PATCH 5.16 257/285] drm/amdkfd: Create file descriptor after client is added to smi_clients list
From: Lee Jones
commit e79a2398e1b2d47060474dca291542368183bc0f upstream.
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
@@ -270,15 +270,6 @@ int kfd_smi_event_open(struct kfd_dev *d
return ret;
}
- ret = anon_inode_getfd(kfd_smi_name, &kfd_smi_ev_fops, (void *)client,
- O_RDWR);
- if (ret < 0) {
- kfifo_free(&client->fifo);
- kfree(client);
- return ret;
- }
- *fd = ret;
-
init_waitqueue_head(&client->wait_queue);
spin_lock_init(&client->lock);
client->events = 0;
@@ -288,5 +279,20 @@ int kfd_smi_event_open(struct kfd_dev *d
list_add_rcu(&client->list, &dev->smi_clients);
spin_unlock(&dev->smi_lock);
+ ret = anon_inode_getfd(kfd_smi_name, &kfd_smi_ev_fops, (void *)client,
+ O_RDWR);
+ if (ret < 0) {
+ spin_lock(&dev->smi_lock);
+ list_del_rcu(&client->list);
+ spin_unlock(&dev->smi_lock);
+
+ synchronize_rcu();
+
+ kfifo_free(&client->fifo);
+ kfree(client);
+ return ret;
+ }
+ *fd = ret;
+
return 0;
}
[PATCH 5.16 249/285] fbdev: Fix unregistering of framebuffers without device
From: Thomas Zimmermann
commit 0f525289ff0ddeb380813bd81e0f9bdaaa1c9078 upstream.
OF framebuffers do not have an underlying device in the Linux
device hierarchy. Do a regular unregister call instead of hot
unplugging such a non-existing device. Fixes a NULL dereference.
An example error message on ppc64le is shown below.
BUG: Kernel NULL pointer dereference on read at 0x0060
Faulting instruction address: 0xc080dfa4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[...]
CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1
NIP: c080dfa4 LR: c080df9c CTR: c0797430
REGS: c4132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365)
MSR: 82009033 CR: 28228282 XER: 2000
CFAR: c000c80c DAR: 0060 DSISR: 4000 IRQMASK: 0
GPR00: c080df9c c4133280 c169d200 0029
GPR04: efff c4132f90 c4132f88
GPR08: c15658f8 c15cd200 c14f57d0 48228283
GPR12: c0003fffe300 2000
GPR16: 000113fc4a40 0005 000113fcfb80
GPR20: 01000f7283b0 c0e4a588 c0e4a5b0
GPR24: 0001 000a c00800db0168 c21f6ec0
GPR28: c16d65a8 c4b36460 c16d64b0
NIP [c080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0
[c4133280] [c080df9c]
do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)
[c4133350] [c080e4d0]
remove_conflicting_framebuffers+0x60/0x150
[c41333a0] [c080e6f4]
remove_conflicting_pci_framebuffers+0x134/0x1b0
[c4133450] [c00800e70438]
drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]
[c4133490] [c00800da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]
[...]
[c4133db0] [c002aaa0] system_call_exception+0x170/0x2d0
[c4133e10] [c000c3cc] system_call_common+0xec/0x250
The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug
firmware fb devices on forced removal"). Most firmware framebuffers
have an underlying platform device, which can be hot-unplugged
before loading the native graphics driver. OF framebuffers do not
(yet) have that device. Fix the code by unregistering the framebuffer
as before without a hot unplug.
Tested with 5.17 on qemu ppc64le emulation.
Signed-off-by: Thomas Zimmermann
Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
Reported-by: Sudip Mukherjee
Reviewed-by: Daniel Vetter
Reviewed-by: Javier Martinez Canillas
Tested-by: Sudip Mukherjee
Cc: Zack Rusin
Cc: Javier Martinez Canillas
Cc: Hans de Goede
Cc: sta...@vger.kernel.org # v5.11+
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Zheyu Ma
Cc: Xiyu Yang
Cc: Zhen Lei
Cc: Matthew Wilcox
Cc: Alex Deucher
Cc: Tetsuo Handa
Cc: Guenter Roeck
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1]
Link:
https://patchwork.freedesktop.org/patch/msgid/20220404194402.29974-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/video/fbdev/core/fbmem.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1581,7 +1581,14 @@ static void do_remove_conflicting_frameb
* If it's not a platform device, at least print a
warning. A
* fix would add code to remove the device from the
system.
*/
- if (dev_is_platform(device)) {
+ if (!device) {
+ /* TODO: Represent each OF framebuffer as its
own
+* device in the device hierarchy. For now, offb
+* doesn't have such a device, so unregister the
+* framebuffer as before without warning.
+*/
+ do_unregister_framebuffer(registered_fb[i]);
+ } else if (dev_is_platform(device)) {
registered_fb[i]->forced_out = true;
platform_device_unregister(to_platform_device(device));
} else {
Re: [PATCH v2 1/5] dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> The current compatible strings for SSD130x I2C controllers contain both an
> "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
> and also that are for devices that can be accessed over an I2C bus.
>
> But a DT is supposed to describe the hardware and not Linux implementation
> details. So let's deprecate those compatible strings and add new ones that
> only contain the vendor and device name, without any of these suffixes.
>
> These will just describe the device and can be matched by both I2C and SPI
> DRM drivers.
>
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 2/5] dt-bindings: display: ssd1307fb: Extend schema for SPI controllers
Hi Javier,
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
> add to the schema the properties and examples for OLED devices under SPI.
>
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Mark Brown
> ---
>
> Changes in v2:
> - Don't add compatible strings with an "-spi" suffix (Geert Uytterhoeven).
Thanks for the update!
> --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> @@ -39,9 +39,14 @@ properties:
>reset-gpios:
> maxItems: 1
>
> + dc-gpios:
> +maxItems: 1
> +
Perhaps add a description, and clarify this is for SPI only?
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/5] drm/solomon: Add ssd130x new compatible strings and deprecate old ones.
Hi Javier,
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> The current compatible strings for SSD130x I2C controllers contain an "fb"
> and "-i2c" suffixes. These have been deprecated and more correct ones were
> added, that don't encode a subsystem or bus used to interface the devices.
>
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Mark Brown
> ---
>
> (no changes since v1)
That's not really true ;-)
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 5.17 302/343] fbdev: Fix unregistering of framebuffers without device
From: Thomas Zimmermann
commit 0f525289ff0ddeb380813bd81e0f9bdaaa1c9078 upstream.
OF framebuffers do not have an underlying device in the Linux
device hierarchy. Do a regular unregister call instead of hot
unplugging such a non-existing device. Fixes a NULL dereference.
An example error message on ppc64le is shown below.
BUG: Kernel NULL pointer dereference on read at 0x0060
Faulting instruction address: 0xc080dfa4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[...]
CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1
NIP: c080dfa4 LR: c080df9c CTR: c0797430
REGS: c4132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365)
MSR: 82009033 CR: 28228282 XER: 2000
CFAR: c000c80c DAR: 0060 DSISR: 4000 IRQMASK: 0
GPR00: c080df9c c4133280 c169d200 0029
GPR04: efff c4132f90 c4132f88
GPR08: c15658f8 c15cd200 c14f57d0 48228283
GPR12: c0003fffe300 2000
GPR16: 000113fc4a40 0005 000113fcfb80
GPR20: 01000f7283b0 c0e4a588 c0e4a5b0
GPR24: 0001 000a c00800db0168 c21f6ec0
GPR28: c16d65a8 c4b36460 c16d64b0
NIP [c080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0
[c4133280] [c080df9c]
do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)
[c4133350] [c080e4d0]
remove_conflicting_framebuffers+0x60/0x150
[c41333a0] [c080e6f4]
remove_conflicting_pci_framebuffers+0x134/0x1b0
[c4133450] [c00800e70438]
drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]
[c4133490] [c00800da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]
[...]
[c4133db0] [c002aaa0] system_call_exception+0x170/0x2d0
[c4133e10] [c000c3cc] system_call_common+0xec/0x250
The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug
firmware fb devices on forced removal"). Most firmware framebuffers
have an underlying platform device, which can be hot-unplugged
before loading the native graphics driver. OF framebuffers do not
(yet) have that device. Fix the code by unregistering the framebuffer
as before without a hot unplug.
Tested with 5.17 on qemu ppc64le emulation.
Signed-off-by: Thomas Zimmermann
Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
Reported-by: Sudip Mukherjee
Reviewed-by: Daniel Vetter
Reviewed-by: Javier Martinez Canillas
Tested-by: Sudip Mukherjee
Cc: Zack Rusin
Cc: Javier Martinez Canillas
Cc: Hans de Goede
Cc: sta...@vger.kernel.org # v5.11+
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Zheyu Ma
Cc: Xiyu Yang
Cc: Zhen Lei
Cc: Matthew Wilcox
Cc: Alex Deucher
Cc: Tetsuo Handa
Cc: Guenter Roeck
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1]
Link:
https://patchwork.freedesktop.org/patch/msgid/20220404194402.29974-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/video/fbdev/core/fbmem.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1583,7 +1583,14 @@ static void do_remove_conflicting_frameb
* If it's not a platform device, at least print a
warning. A
* fix would add code to remove the device from the
system.
*/
- if (dev_is_platform(device)) {
+ if (!device) {
+ /* TODO: Represent each OF framebuffer as its
own
+* device in the device hierarchy. For now, offb
+* doesn't have such a device, so unregister the
+* framebuffer as before without warning.
+*/
+ do_unregister_framebuffer(registered_fb[i]);
+ } else if (dev_is_platform(device)) {
registered_fb[i]->forced_out = true;
platform_device_unregister(to_platform_device(device));
} else {
[PATCH 5.17 309/343] drm/nouveau/pmu: Add missing callbacks for Tegra devices
From: Karol Herbst
commit 38d4e5cf5b08798f093374e53c2f4609d5382dd5 upstream.
Fixes a crash booting on those platforms with nouveau.
Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset
sequence")
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v5.17+
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220322124800.2605463-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c |2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h |1 +
4 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -216,6 +216,7 @@ gm20b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gf100_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
@@ -23,7 +23,7 @@
*/
#include "priv.h"
-static void
+void
gp102_pmu_reset(struct nvkm_pmu *pmu)
{
struct nvkm_device *device = pmu->subdev.device;
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
@@ -83,6 +83,7 @@ gp10b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gp102_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
@@ -41,6 +41,7 @@ int gt215_pmu_send(struct nvkm_pmu *, u3
bool gf100_pmu_enabled(struct nvkm_pmu *);
void gf100_pmu_reset(struct nvkm_pmu *);
+void gp102_pmu_reset(struct nvkm_pmu *pmu);
void gk110_pmu_pgob(struct nvkm_pmu *, bool);
[PATCH 5.17 310/343] drm/amdkfd: Create file descriptor after client is added to smi_clients list
From: Lee Jones
commit e79a2398e1b2d47060474dca291542368183bc0f upstream.
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
@@ -268,15 +268,6 @@ int kfd_smi_event_open(struct kfd_dev *d
return ret;
}
- ret = anon_inode_getfd(kfd_smi_name, &kfd_smi_ev_fops, (void *)client,
- O_RDWR);
- if (ret < 0) {
- kfifo_free(&client->fifo);
- kfree(client);
- return ret;
- }
- *fd = ret;
-
init_waitqueue_head(&client->wait_queue);
spin_lock_init(&client->lock);
client->events = 0;
@@ -286,5 +277,20 @@ int kfd_smi_event_open(struct kfd_dev *d
list_add_rcu(&client->list, &dev->smi_clients);
spin_unlock(&dev->smi_lock);
+ ret = anon_inode_getfd(kfd_smi_name, &kfd_smi_ev_fops, (void *)client,
+ O_RDWR);
+ if (ret < 0) {
+ spin_lock(&dev->smi_lock);
+ list_del_rcu(&client->list);
+ spin_unlock(&dev->smi_lock);
+
+ synchronize_rcu();
+
+ kfifo_free(&client->fifo);
+ kfree(client);
+ return ret;
+ }
+ *fd = ret;
+
return 0;
}
Re: AMD Display Core (DC) patches (was: [PATCH 13/16] drm/amd/display: Revert FEC check in validation)
On Tue, Apr 12, 2022 at 08:52:11AM +0200, Paul Menzel wrote: > > Reviewed-by: George Shen > > Acked-by: Alex Hung > > Signed-off-by: Martin Leung > > Shouldn’t the Signed-off-by line by the author go first? No, this is the correct order. thanks, greg k-h
Re: [PATCH v2 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
Hi Javier,
Thanks for your patch!
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> These are declared in the ssd130x-i2c transport driver but the information
> is not I2C specific, and could be used by other SSD130x transport drivers.
>
> Move them to the ssd130x core driver and just set the OF device entries to
> an ID that could be used to lookup the correct device info from an array.
>
> While being there, also move the SSD130X_DATA and SSD130X_COMMAND control
> bytes. Since even though are used by the I2C interface, it could also be
though they are ... they could
> useful for other transport protocols such as SPI.
>
> Suggested-by: Chen-Yu Tsai
> Signed-off-by: Javier Martinez Canillas
> --- a/drivers/gpu/drm/solomon/ssd130x.c
> +++ b/drivers/gpu/drm/solomon/ssd130x.c
> @@ -860,7 +890,14 @@ struct ssd130x_device *ssd130x_probe(struct device *dev,
> struct regmap *regmap)
>
> ssd130x->dev = dev;
> ssd130x->regmap = regmap;
> - ssd130x->device_info = device_get_match_data(dev);
> +
> + variant = (enum ssd130x_variants)device_get_match_data(dev);
(uintptr_t), to avoid a cast from pointer to integer of different
size warning.
> +
Please drop the blank line.
> + if (variant >= NR_SSD130X_VARIANTS)
> + return ERR_PTR(dev_err_probe(dev, -EINVAL,
> +"Invalid SSD130x variant\n"));
> +
> + ssd130x->device_info = &ssd130x_variants[variant];
>
> if (ssd130x->device_info->page_mode_only)
> ssd130x->page_address_mode = 1;
With the above fixed:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
Hi Javier,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20220411]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next tegra-drm/drm/tegra/for-next linus/master linux/master
v5.18-rc2]
[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]
url:
https://github.com/intel-lab-lkp/linux/commits/Javier-Martinez-Canillas/drm-solomon-Add-SSD130x-OLED-displays-SPI-support/20220412-051518
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a001-20220411
(https://download.01.org/0day-ci/archive/20220412/202204121542.au2biyxn-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
fe2478d44e4f7f191c43fef629ac7a23d0251e72)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/ac5a07cda8a0f8d4948e6a01d0b3bb6ce9fe7830
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Javier-Martinez-Canillas/drm-solomon-Add-SSD130x-OLED-displays-SPI-support/20220412-051518
git checkout ac5a07cda8a0f8d4948e6a01d0b3bb6ce9fe7830
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/solomon/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/solomon/ssd130x.c:894:12: warning: cast to smaller integer
>> type 'enum ssd130x_variants' from 'const void *'
>> [-Wvoid-pointer-to-enum-cast]
variant = (enum ssd130x_variants)device_get_match_data(dev);
^
1 warning generated.
vim +894 drivers/gpu/drm/solomon/ssd130x.c
874
875 struct ssd130x_device *ssd130x_probe(struct device *dev, struct regmap
*regmap)
876 {
877 struct ssd130x_device *ssd130x;
878 enum ssd130x_variants variant;
879 struct backlight_device *bl;
880 struct drm_device *drm;
881 int ret;
882
883 ssd130x = devm_drm_dev_alloc(dev, &ssd130x_drm_driver,
884 struct ssd130x_device, drm);
885 if (IS_ERR(ssd130x))
886 return ERR_PTR(dev_err_probe(dev, PTR_ERR(ssd130x),
887 "Failed to allocate DRM
device\n"));
888
889 drm = &ssd130x->drm;
890
891 ssd130x->dev = dev;
892 ssd130x->regmap = regmap;
893
> 894 variant = (enum ssd130x_variants)device_get_match_data(dev);
895
896 if (variant >= NR_SSD130X_VARIANTS)
897 return ERR_PTR(dev_err_probe(dev, -EINVAL,
898 "Invalid SSD130x
variant\n"));
899
900 ssd130x->device_info = &ssd130x_variants[variant];
901
902 if (ssd130x->device_info->page_mode_only)
903 ssd130x->page_address_mode = 1;
904
905 ssd130x_parse_properties(ssd130x);
906
907 ret = ssd130x_get_resources(ssd130x);
908 if (ret)
909 return ERR_PTR(ret);
910
911 bl = devm_backlight_device_register(dev, dev_name(dev), dev,
ssd130x,
912 &ssd130xfb_bl_ops, NULL);
913 if (IS_ERR(bl))
914 return ERR_PTR(dev_err_probe(dev, PTR_ERR(bl),
915 "Unable to register
backlight device\n"));
916
917 bl->props.brightness = ssd130x->contrast;
918 bl->props.max_brightness = MAX_CONTRAST;
919 ssd130x->bl_dev = bl;
920
921 ret = ssd130x_init_modeset(ssd130x);
922 if (ret)
923 return ERR_PTR(ret);
924
925 ret = drm_dev_register(drm, 0);
926 if (ret)
927 return ERR_PTR(dev_err_probe(dev, ret, "DRM device
register failed\n"));
928
929 drm_fbdev_generic_setup(drm, 0);
930
931 return ssd130x;
932 }
933 EXPORT_SYMBOL_GPL(ssd130x_probe);
934
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [PATCH v3 11/15] drm/shmem-helper: Add generic memory shrinker
Hi Dmitry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20220411]
[cannot apply to drm/drm-next v5.18-rc2 v5.18-rc1 v5.17 v5.18-rc2]
[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]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Osipenko/Add-generic-memory-shrinker-to-VirtIO-GPU-and-Panfrost-DRM-drivers/20220412-060325
base:d12d7e1cfe38e0c36d28c7a9fbbc436ad0d17c14
config: i386-randconfig-a005-20220411
(https://download.01.org/0day-ci/archive/20220412/202204121523.qvmxovzg-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
fe2478d44e4f7f191c43fef629ac7a23d0251e72)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/683ba8a9d72ba7770a61a9266a2b33949f3874f2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Dmitry-Osipenko/Add-generic-memory-shrinker-to-VirtIO-GPU-and-Panfrost-DRM-drivers/20220412-060325
git checkout 683ba8a9d72ba7770a61a9266a2b33949f3874f2
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_gem_shmem_helper.c:289:11: warning: variable 'new_state'
>> is used uninitialized whenever 'if' condition is false
>> [-Wsometimes-uninitialized]
else if (shmem->madv < 0)
^~~
drivers/gpu/drm/drm_gem_shmem_helper.c:292:46: note: uninitialized use
occurs here
drm_gem_shmem_set_pages_state_locked(shmem, new_state);
^
drivers/gpu/drm/drm_gem_shmem_helper.c:289:7: note: remove the 'if' if its
condition is always true
else if (shmem->madv < 0)
^~~~
drivers/gpu/drm/drm_gem_shmem_helper.c:278:2: note: variable 'new_state' is
declared here
enum drm_gem_shmem_pages_state new_state;
^
1 warning generated.
vim +289 drivers/gpu/drm/drm_gem_shmem_helper.c
273
274 static void drm_gem_shmem_update_pages_state_locked(struct
drm_gem_shmem_object *shmem)
275 {
276 struct drm_gem_object *obj = &shmem->base;
277 struct drm_gem_shmem_shrinker *gem_shrinker =
obj->dev->shmem_shrinker;
278 enum drm_gem_shmem_pages_state new_state;
279
280 if (!gem_shrinker || obj->import_attach)
281 return;
282
283 mutex_lock(&gem_shrinker->lock);
284
285 if (!shmem->madv)
286 new_state = DRM_GEM_SHMEM_PAGES_STATE_ACTIVE;
287 else if (shmem->madv > 0)
288 new_state = DRM_GEM_SHMEM_PAGES_STATE_PURGEABLE;
> 289 else if (shmem->madv < 0)
290 new_state = DRM_GEM_SHMEM_PAGES_STATE_PURGED;
291
292 drm_gem_shmem_set_pages_state_locked(shmem, new_state);
293
294 mutex_unlock(&gem_shrinker->lock);
295 }
296
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [PATCH v3 11/15] drm/shmem-helper: Add generic memory shrinker
Hi Dmitry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20220411]
[cannot apply to drm/drm-next v5.18-rc2 v5.18-rc1 v5.17 v5.18-rc2]
[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]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Osipenko/Add-generic-memory-shrinker-to-VirtIO-GPU-and-Panfrost-DRM-drivers/20220412-060325
base:d12d7e1cfe38e0c36d28c7a9fbbc436ad0d17c14
config: hexagon-randconfig-r045-20220411
(https://download.01.org/0day-ci/archive/20220412/202204121504.glr3fhqe-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
fe2478d44e4f7f191c43fef629ac7a23d0251e72)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/683ba8a9d72ba7770a61a9266a2b33949f3874f2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Dmitry-Osipenko/Add-generic-memory-shrinker-to-VirtIO-GPU-and-Panfrost-DRM-drivers/20220412-060325
git checkout 683ba8a9d72ba7770a61a9266a2b33949f3874f2
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_gem_shmem_helper.c:289:11: warning: variable 'new_state'
>> is used uninitialized whenever 'if' condition is false
>> [-Wsometimes-uninitialized]
else if (shmem->madv < 0)
^~~
drivers/gpu/drm/drm_gem_shmem_helper.c:292:46: note: uninitialized use
occurs here
drm_gem_shmem_set_pages_state_locked(shmem, new_state);
^
drivers/gpu/drm/drm_gem_shmem_helper.c:289:7: note: remove the 'if' if its
condition is always true
else if (shmem->madv < 0)
^~~~
drivers/gpu/drm/drm_gem_shmem_helper.c:278:2: note: variable 'new_state' is
declared here
enum drm_gem_shmem_pages_state new_state;
^
1 warning generated.
vim +289 drivers/gpu/drm/drm_gem_shmem_helper.c
273
274 static void drm_gem_shmem_update_pages_state_locked(struct
drm_gem_shmem_object *shmem)
275 {
276 struct drm_gem_object *obj = &shmem->base;
277 struct drm_gem_shmem_shrinker *gem_shrinker =
obj->dev->shmem_shrinker;
278 enum drm_gem_shmem_pages_state new_state;
279
280 if (!gem_shrinker || obj->import_attach)
281 return;
282
283 mutex_lock(&gem_shrinker->lock);
284
285 if (!shmem->madv)
286 new_state = DRM_GEM_SHMEM_PAGES_STATE_ACTIVE;
287 else if (shmem->madv > 0)
288 new_state = DRM_GEM_SHMEM_PAGES_STATE_PURGEABLE;
> 289 else if (shmem->madv < 0)
290 new_state = DRM_GEM_SHMEM_PAGES_STATE_PURGED;
291
292 drm_gem_shmem_set_pages_state_locked(shmem, new_state);
293
294 mutex_unlock(&gem_shrinker->lock);
295 }
296
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [PATCH v2 5/5] drm/solomon: Add SSD130x OLED displays SPI support
Hi Javier,
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over SPI.
>
> There is a difference in the communication protocol when using 4-wire SPI
> instead of I2C. For the latter, a control byte that contains a D/C# field
> has to be sent. This field tells the controller whether the data has to be
> written to the command register or to the graphics display data memory.
>
> But for 4-wire SPI that control byte is not used, instead a real D/C# line
> must be pulled HIGH for commands data and LOW for graphics display data.
>
> For this reason the standard SPI regmap can't be used and a custom .write
> bus handler is needed.
>
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Mark Brown
Thanks for your patch!
> --- /dev/null
> +++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
> +static struct gpio_desc *ssd130x_spi_get_dc(struct device *dev)
> +{
> + struct gpio_desc *dc = devm_gpiod_get(dev, "dc", GPIOD_OUT_LOW);
> +
> + if (IS_ERR(dc))
> + return ERR_PTR(dev_err_probe(dev, PTR_ERR(dc), "Failed to get
> dc gpio\n"));
> +
> + return dc;
> +}
> +
> +static int ssd130x_spi_probe(struct spi_device *spi)
> +{
> + struct ssd130x_spi_transport *t;
> + struct ssd130x_device *ssd130x;
> + struct regmap *regmap;
> + struct device *dev = &spi->dev;
> +
> + t = devm_kzalloc(dev, sizeof(*t), GFP_KERNEL);
> + if (!t)
> + return dev_err_probe(dev, -ENOMEM,
> +"Failed to allocate SPI transport
> data\n");
> +
> + t->spi = spi;
> +
> + t->dc = ssd130x_spi_get_dc(&spi->dev);
> + if (IS_ERR(t->dc))
> + return PTR_ERR(t->dc);
This can be simplified (no need for the PTR_ERR(ERR_PTR(...) dance)
by open-coding ssd130x_spi_get_dc() here.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
On Mon, Apr 11, 2022 at 01:07:56PM +0200, Piotr Oniszczuk wrote:
> this is DRI state when there is no any Qt.vars overwrites.
> (so all is autodetected/setup like in other working SoCs; VOP2 gives here
> black screen UI):
>
> 2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49
> Connector id:51 Atomic: 1
> 2022-04-08 17:47:57.035806 I /dev/dri/card0: Authenticated
> 2022-04-08 17:47:57.145447 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
> 2022-04-08 17:47:57.145469 I /dev/dri/card0: Selected Plane #37 Overlay for
> video
> 2022-04-08 17:47:57.145515 I /dev/dri/card0: Supported DRM video formats:
> NV12,NV16,NV24,YVYU,VYUY
> 2022-04-08 17:47:57.145523 I /dev/dri/card0: Selected Plane #43 Overlay for
> GUI
> 2022-04-08 17:47:57.145567 I /dev/dri/card0: DRM device retrieved from Qt
> 2022-04-08 17:47:57.145574 I /dev/dri/card0: Multi-plane setup: Requested: 1
> Setup: 1
>
> plane[31]: Smart0-win0
> crtc=video_port0
> fb=53
> allocated by = [fbcon]
> refcount=2
> format=XR24 little-endian (0x34325258)
> modifier=0x0
> size=1920x1080
> layers:
> size[0]=1920x1080
> pitch[0]=7680
> offset[0]=0
> obj[0]:
> name=0
> refcount=3
> start=
> size=8294400
> imported=no
> crtc-pos=1920x1080+0+0
> src-pos=1920.00x1080.00+0.00+0.00
> rotation=1
> normalized-zpos=0
> color-encoding=ITU-R BT.601 YCbCr
> color-range=YCbCr limited range
> plane[37]: Esmart0-win0
> crtc=(null)
> fb=0
> crtc-pos=0x0+0+0
> src-pos=0.00x0.00+0.00+0.00
> rotation=1
> normalized-zpos=0
> color-encoding=ITU-R BT.601 YCbCr
> color-range=YCbCr limited range
> plane[43]: Cluster0-win0
> crtc=video_port0
> fb=58
> allocated by = mythfrontend
> refcount=2
> format=AR24 little-endian (0x34325241)
Here is your problem. The cluster windows only allow AFBC compressed
formats. AR24 is supported by the cluster windows, but not by the GPU,
see panfrost_afbc_format() in Mesa:
> enum pipe_format
> panfrost_afbc_format(const struct panfrost_device *dev, enum pipe_format
> format)
> {
> /* Don't allow swizzled formats on v7 */
> switch (format) {
> case PIPE_FORMAT_B8G8R8A8_UNORM:
> case PIPE_FORMAT_B8G8R8X8_UNORM:
> case PIPE_FORMAT_A8R8G8B8_UNORM:
> case PIPE_FORMAT_X8R8G8B8_UNORM:
> case PIPE_FORMAT_X8B8G8R8_UNORM:
> case PIPE_FORMAT_A8B8G8R8_UNORM:
> case PIPE_FORMAT_B8G8R8_UNORM:
> case PIPE_FORMAT_B5G6R5_UNORM:
> if (dev->arch >= 7)
> return PIPE_FORMAT_NONE;
>
> break;
> default:
> break;
> }
>
Somehow negotiation of the format goes wrong. Applications shouldn't
pick these formats when the GPU is used for rendering. I don't know how
and where this should be fixed properly, but your application should use
DRM_FORMAT_ABGR aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
DRM_FORMAT_ARGB aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.
Could you try the following patch? It removed the formats in question
from the list of supported formats in the hope that your application
then picks one of the supported formats.
Sascha
---8<-
>From 7427109cfd16803902b55cd5536b9212abd09665 Mon Sep 17 00:00:00 2001
From: Sascha Hauer
Date: Tue, 12 Apr 2022 09:42:32 +0200
Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
The cluster windows only allow AFBC compressed formats. Not all of the
offered formats are supported by the GPU though. Applications pick one
of the formats and assume that this is also supported by the GPU they
use to render on them, but this is not the case for all formats.
Particularly DRM_FORMAT_XRGB and DRM_FORMAT_ARGB are not
supported by the GPU and choosing them results in a black screen.
Drop these formats for now.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index 9bf0637bf8e26..38412766e3659 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -16,8 +16,6 @@
#include "rockchip_drm_vop2.h"
static const uint32_t formats_win_full_10bit[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
DRM_FORMAT_ABGR,
DRM_FORMA
Re: [PATCH v2 2/5] dt-bindings: display: ssd1307fb: Extend schema for SPI controllers
Hello Geert, On 4/12/22 09:16, Geert Uytterhoeven wrote: > Hi Javier, > > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas > wrote: >> The Solomon SSD130x OLED displays can either have an I2C or SPI interface, >> add to the schema the properties and examples for OLED devices under SPI. >> >> Signed-off-by: Javier Martinez Canillas >> Acked-by: Mark Brown >> --- >> >> Changes in v2: >> - Don't add compatible strings with an "-spi" suffix (Geert Uytterhoeven). > > Thanks for the update! > You are welcome and thanks for your prompt review and feedback! >> --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml >> +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml >> @@ -39,9 +39,14 @@ properties: >>reset-gpios: >> maxItems: 1 >> >> + dc-gpios: >> +maxItems: 1 >> + > > Perhaps add a description, and clarify this is for SPI only? > I wondered how to make it required for SPI but couldn't find another binding that did the same and I'm not that familiar with DT schemas to figure it out. Before, when I had compatible strings just for SPI I could do the following: - if: properties: compatible: contains: enum: - sinowealth,sh1106-spi - solomon,ssd1305-spi - solomon,ssd1306-spi - solomon,ssd1307-spi - solomon,ssd1309-spi then: required: - spi-max-frequency - dc-gpios but now that we are using the same compatible strings for I2C and SPI, the compatible string can't be used anymore as an indication to make required. Do you have any hints here on how I should enforce this in the schema ? Or if you think that a comment is enough, then I will add it in v3. > Reviewed-by: Geert Uytterhoeven > Thanks! -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v2 3/5] drm/solomon: Add ssd130x new compatible strings and deprecate old ones.
On 4/12/22 09:19, Geert Uytterhoeven wrote: > Hi Javier, > > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas > wrote: >> The current compatible strings for SSD130x I2C controllers contain an "fb" >> and "-i2c" suffixes. These have been deprecated and more correct ones were >> added, that don't encode a subsystem or bus used to interface the devices. >> >> Signed-off-by: Javier Martinez Canillas >> Acked-by: Mark Brown >> --- >> >> (no changes since v1) > > That's not really true ;-) > Ups, I did indeed update the compatible strings to drop the "-i2c" as you asked. I'll add that in the patch history for v2 when posting v3. > Reviewed-by: Geert Uytterhoeven > Thanks! -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v2 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
On 4/12/22 09:23, Geert Uytterhoeven wrote: > Hi Javier, > > Thanks for your patch! > > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas > wrote: >> These are declared in the ssd130x-i2c transport driver but the information >> is not I2C specific, and could be used by other SSD130x transport drivers. >> >> Move them to the ssd130x core driver and just set the OF device entries to >> an ID that could be used to lookup the correct device info from an array. >> >> While being there, also move the SSD130X_DATA and SSD130X_COMMAND control >> bytes. Since even though are used by the I2C interface, it could also be > > though they are ... they could > Right, will fix it. >> useful for other transport protocols such as SPI. >> >> Suggested-by: Chen-Yu Tsai >> Signed-off-by: Javier Martinez Canillas > >> --- a/drivers/gpu/drm/solomon/ssd130x.c >> +++ b/drivers/gpu/drm/solomon/ssd130x.c > >> @@ -860,7 +890,14 @@ struct ssd130x_device *ssd130x_probe(struct device >> *dev, struct regmap *regmap) >> >> ssd130x->dev = dev; >> ssd130x->regmap = regmap; >> - ssd130x->device_info = device_get_match_data(dev); >> + >> + variant = (enum ssd130x_variants)device_get_match_data(dev); > > (uintptr_t), to avoid a cast from pointer to integer of different > size warning. > Indeed. The kernel test robot reported the same. >> + > > Please drop the blank line. > Ok. >> + if (variant >= NR_SSD130X_VARIANTS) >> + return ERR_PTR(dev_err_probe(dev, -EINVAL, >> +"Invalid SSD130x variant\n")); >> + >> + ssd130x->device_info = &ssd130x_variants[variant]; >> >> if (ssd130x->device_info->page_mode_only) >> ssd130x->page_address_mode = 1; > > With the above fixed: > Reviewed-by: Geert Uytterhoeven > Thanks! -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v2 2/5] dt-bindings: display: ssd1307fb: Extend schema for SPI controllers
Hi Javier,
On Tue, Apr 12, 2022 at 10:01 AM Javier Martinez Canillas
wrote:
> On 4/12/22 09:16, Geert Uytterhoeven wrote:
> > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> > wrote:
> >> The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
> >> add to the schema the properties and examples for OLED devices under SPI.
> >>
> >> Signed-off-by: Javier Martinez Canillas
> >> --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> >> +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> >> @@ -39,9 +39,14 @@ properties:
> >>reset-gpios:
> >> maxItems: 1
> >>
> >> + dc-gpios:
> >> +maxItems: 1
> >> +
> >
> > Perhaps add a description, and clarify this is for SPI only?
>
> I wondered how to make it required for SPI but couldn't find another binding
> that did the same and I'm not that familiar with DT schemas to figure it out.
>
> Before, when I had compatible strings just for SPI I could do the following:
>
> - if:
> properties:
> compatible:
> contains:
> enum:
> - sinowealth,sh1106-spi
> - solomon,ssd1305-spi
> - solomon,ssd1306-spi
> - solomon,ssd1307-spi
> - solomon,ssd1309-spi
> then:
> required:
> - spi-max-frequency
> - dc-gpios
>
> but now that we are using the same compatible strings for I2C and SPI, the
> compatible string can't be used anymore as an indication to make required.
>
> Do you have any hints here on how I should enforce this in the schema ?
>
> Or if you think that a comment is enough, then I will add it in v3.
I don't know how to make it required for SPI, if possible at all.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 5/5] drm/solomon: Add SSD130x OLED displays SPI support
On 4/12/22 09:31, Geert Uytterhoeven wrote: [snip] >> + >> + t->spi = spi; >> + >> + t->dc = ssd130x_spi_get_dc(&spi->dev); >> + if (IS_ERR(t->dc)) >> + return PTR_ERR(t->dc); > > This can be simplified (no need for the PTR_ERR(ERR_PTR(...) dance) > by open-coding ssd130x_spi_get_dc() here. > Right, that will be better indeed. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
Am Dienstag, dem 12.04.2022 um 09:50 +0200 schrieb Sascha Hauer:
> On Mon, Apr 11, 2022 at 01:07:56PM +0200, Piotr Oniszczuk wrote:
> > this is DRI state when there is no any Qt.vars overwrites.
> > (so all is autodetected/setup like in other working SoCs; VOP2 gives here
> > black screen UI):
> >
> > 2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49
> > Connector id:51 Atomic: 1
> > 2022-04-08 17:47:57.035806 I /dev/dri/card0: Authenticated
> > 2022-04-08 17:47:57.145447 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
> > 2022-04-08 17:47:57.145469 I /dev/dri/card0: Selected Plane #37 Overlay for
> > video
> > 2022-04-08 17:47:57.145515 I /dev/dri/card0: Supported DRM video formats:
> > NV12,NV16,NV24,YVYU,VYUY
> > 2022-04-08 17:47:57.145523 I /dev/dri/card0: Selected Plane #43 Overlay for
> > GUI
> > 2022-04-08 17:47:57.145567 I /dev/dri/card0: DRM device retrieved from Qt
> > 2022-04-08 17:47:57.145574 I /dev/dri/card0: Multi-plane setup: Requested:
> > 1 Setup: 1
> >
> > plane[31]: Smart0-win0
> > crtc=video_port0
> > fb=53
> > allocated by = [fbcon]
> > refcount=2
> > format=XR24 little-endian (0x34325258)
> > modifier=0x0
> > size=1920x1080
> > layers:
> > size[0]=1920x1080
> > pitch[0]=7680
> > offset[0]=0
> > obj[0]:
> > name=0
> > refcount=3
> > start=
> > size=8294400
> > imported=no
> > crtc-pos=1920x1080+0+0
> > src-pos=1920.00x1080.00+0.00+0.00
> > rotation=1
> > normalized-zpos=0
> > color-encoding=ITU-R BT.601 YCbCr
> > color-range=YCbCr limited range
> > plane[37]: Esmart0-win0
> > crtc=(null)
> > fb=0
> > crtc-pos=0x0+0+0
> > src-pos=0.00x0.00+0.00+0.00
> > rotation=1
> > normalized-zpos=0
> > color-encoding=ITU-R BT.601 YCbCr
> > color-range=YCbCr limited range
> > plane[43]: Cluster0-win0
> > crtc=video_port0
> > fb=58
> > allocated by = mythfrontend
> > refcount=2
> > format=AR24 little-endian (0x34325241)
>
> Here is your problem. The cluster windows only allow AFBC compressed
> formats. AR24 is supported by the cluster windows, but not by the GPU,
> see panfrost_afbc_format() in Mesa:
>
> > enum pipe_format
> > panfrost_afbc_format(const struct panfrost_device *dev, enum pipe_format
> > format)
> > {
> > /* Don't allow swizzled formats on v7 */
> > switch (format) {
> > case PIPE_FORMAT_B8G8R8A8_UNORM:
> > case PIPE_FORMAT_B8G8R8X8_UNORM:
> > case PIPE_FORMAT_A8R8G8B8_UNORM:
> > case PIPE_FORMAT_X8R8G8B8_UNORM:
> > case PIPE_FORMAT_X8B8G8R8_UNORM:
> > case PIPE_FORMAT_A8B8G8R8_UNORM:
> > case PIPE_FORMAT_B8G8R8_UNORM:
> > case PIPE_FORMAT_B5G6R5_UNORM:
> > if (dev->arch >= 7)
> > return PIPE_FORMAT_NONE;
> >
> > break;
> > default:
> > break;
> > }
> >
>
> Somehow negotiation of the format goes wrong. Applications shouldn't
> pick these formats when the GPU is used for rendering. I don't know how
> and where this should be fixed properly, but your application should use
> DRM_FORMAT_ABGR aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
> DRM_FORMAT_ARGB aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.
>
This could be both a Mesa/Panfrost or application issue. The
application is supposed to try to allocate with a arbitrary chosen
format and the valid modifiers queried from the plane it wants to put
the surface on. However I'm not sure if all applications have a
fallback path in place to try another format swizzling if the surface
allocation fails. Now there are two possible failures here:
1. The application feeds a wrong modifier list to the GBM
implementation, as it may have queried another plane in the assumption
that supported modifiers are uniform across all planes.
2. The GBM implementation (Panfrost) actually allocates a surface
instead of failing the allocation, even if it does not support any
combination of the provided format and modifier list.
Regards,
Lucas
> Could you try the following patch? It removed the formats in question
> from the list of supported formats in the hope that your application
> then picks one of the supported formats.
>
> Sascha
>
> ---8<-
>
> From 7427109cfd16803902b55cd5536b9212abd09665 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer
> Date: Tue, 12 Apr 2022 09:42:32 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add V
Re: [PATCH v2 2/5] dt-bindings: display: ssd1307fb: Extend schema for SPI controllers
On 4/12/22 10:07, Geert Uytterhoeven wrote: > Hi Javier, [snip] >> >> Do you have any hints here on how I should enforce this in the schema ? >> >> Or if you think that a comment is enough, then I will add it in v3. > > I don't know how to make it required for SPI, if possible at all. > I see. Let's go with a comment then and we can later enforce it, if someone knows if is possible / how to do it. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v2 5/5] drm/solomon: Add SSD130x OLED displays SPI support
Hi Javier,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20220412]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next tegra-drm/drm/tegra/for-next linus/master linux/master
airlied/drm-next v5.18-rc2]
[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]
url:
https://github.com/intel-lab-lkp/linux/commits/Javier-Martinez-Canillas/drm-solomon-Add-SSD130x-OLED-displays-SPI-support/20220412-051518
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: hexagon-allyesconfig
(https://download.01.org/0day-ci/archive/20220412/202204121654.38utab7q-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
fe2478d44e4f7f191c43fef629ac7a23d0251e72)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/46bbef7fc1afeb9bc8241fe7636e77b5096e3d22
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Javier-Martinez-Canillas/drm-solomon-Add-SSD130x-OLED-displays-SPI-support/20220412-051518
git checkout 46bbef7fc1afeb9bc8241fe7636e77b5096e3d22
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/solomon/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/solomon/ssd130x-spi.c:161:35: warning: unused variable
>> 'ssd130x_spi_table' [-Wunused-const-variable]
static const struct spi_device_id ssd130x_spi_table[] = {
^
1 warning generated.
vim +/ssd130x_spi_table +161 drivers/gpu/drm/solomon/ssd130x-spi.c
152
153 /*
154 * The SPI core always reports a MODALIAS uevent of the form
"spi:", even
155 * if the device was registered via OF. This means that the module will
not be
156 * auto loaded, unless it contains an alias that matches the MODALIAS
reported.
157 *
158 * To workaround this issue, add a SPI device ID table. Even when this
should
159 * not be needed for this driver to match the registered SPI devices.
160 */
> 161 static const struct spi_device_id ssd130x_spi_table[] = {
162 { "sh1106", SH1106_ID },
163 { "ssd1305", SSD1305_ID },
164 { "ssd1306", SSD1306_ID },
165 { "ssd1307", SSD1307_ID },
166 { "ssd1309", SSD1309_ID },
167 { /* sentinel */ }
168 };
169 MODULE_DEVICE_TABLE(spi, ssd130x_spi_table);
170
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [igt-dev] [PATCH i-g-t v2] tests/drm_buddy: Add drm buddy test cases
On Mon, 11 Apr 2022 at 19:51, Arunpravin Paneer Selvam
wrote:
>
> Add a set of drm buddy test cases to validate the
> drm/drm_buddy.c memory allocator.
>
> v2: sorted in alphabetical order
>
> Signed-off-by: Arunpravin Paneer Selvam
> Reviewed-by: Matthew Auld
Tests look to be passing in CI sharded runs. Pushed. Thanks.
> ---
> tests/drm_buddy.c | 14 ++
> tests/meson.build | 1 +
> 2 files changed, 15 insertions(+)
> create mode 100644 tests/drm_buddy.c
>
> diff --git a/tests/drm_buddy.c b/tests/drm_buddy.c
> new file mode 100644
> index ..06876e0c
> --- /dev/null
> +++ b/tests/drm_buddy.c
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#include "igt.h"
> +#include "igt_kmod.h"
> +
> +IGT_TEST_DESCRIPTION("Basic sanity check of DRM's buddy allocator (struct
> drm_buddy)");
> +
> +igt_main
> +{
> + igt_kselftests("test-drm_buddy", NULL, NULL, NULL);
> +}
> diff --git a/tests/meson.build b/tests/meson.build
> index b0eab3d6..7261e9aa 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -8,6 +8,7 @@ test_progs = [
> 'debugfs_test',
> 'dmabuf',
> 'device_reset',
> + 'drm_buddy',
> 'drm_import_export',
> 'drm_mm',
> 'drm_read',
> --
> 2.25.1
>
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Tue, Apr 12, 2022 at 3:48 AM James Hilliard wrote: > > On Mon, Apr 11, 2022 at 3:27 AM Patrik Jakobsson > wrote: > > > > On Sun, Apr 10, 2022 at 10:05 PM James Hilliard > > wrote: > > > > > > On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson > > > wrote: > > > > > > > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard > > > > wrote: > > > > > > > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > > > > > wrote: > > > > > > > > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > > > > > wrote: > > > > > > > > > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > > > > > > > > > This appears to be needed for video output to function correctly. > > > > > > > > > > > > > > Signed-off-by: James Hilliard > > > > > > > > > > > > Hi James, > > > > > > EFI_FB is its own driver and not needed by gma500 to drive its > > > > > > hardware. What makes you think it's required? > > > > > > > > > > I wasn't getting any HDMI video output without it enabled for some > > > > > reason, > > > > > I assume it is doing some sort of initialization needed by gma500 > > > > > during startup. > > > > > > > > Then it sounds like you might just be using EFI_FB and not gma500. Can > > > > you provide the kernel log with drm.debug=0x1f set on kernel > > > > command-line. > > > > > > Seems efifb loads first and then hands off to gma500 > > > > That is how it normally works but efifb shouldn't change the state of > > the currently set mode so shouldn't affect gma500. > > From the logs I can see that you have LVDS (internal panel), HDMI and > > DP (3 displays in total) connected. This sounds wrong. Your version of > > gma500 (Cedarview) doesn't support more than 2 crtcs/pipes. This might > > be a problem. > > Yeah, there's a bug there with the connector status, only DVI-D-1 is actually > connected, I have DP-2 and LVDS-1 turned off in weston. Ok, but are the connectors physically connected to anything? Regardless of what you do in Weston, the connectors shouldn't be getting modes if they aren't used. LVDS might be from VBIOS but I'm not sure where the DP modes come from. It would help if you also provide kernel logs with drm.debug=0x1f when the outputs doesn't work so I have something to compare with.
Re: [PATCH v9 04/22] drm/edid: Convert cea_sad helper struct to kernelDoc
On Mon, 28 Mar 2022 10:04, AngeloGioacchino Del Regno
wrote:
>Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
>> Signed-off-by: Guillaume Ranquet
>> ---
>> include/drm/drm_edid.h | 11 ---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>> index 144c495b99c4..5d4d840b9904 100644
>> --- a/include/drm/drm_edid.h
>> +++ b/include/drm/drm_edid.h
>> @@ -359,12 +359,17 @@ struct edid {
>>
>> #define EDID_PRODUCT_ID(e) ((e)->prod_code[0] | ((e)->prod_code[1] << 8))
>>
>> -/* Short Audio Descriptor */
>
>Hello Guillaume,
>
>> +/* struct cea_sad - Short Audio Descriptor.
>> +@format: See HDMI_AUDIO_CODING_TYPE_*.
>> +@channels: max number of channels - 1.
>> +@freq: See CEA_SAD_FREQ_*.
>> +@byte2: meaning depends on format.
>> +*/
>
>I appreciate the effort, but this is not valid kerneldoc.
>
>Please refer to https://docs.kernel.org/doc-guide/kernel-doc.html
>
>Regards,
>Angelo
Hello Angelo,
Thx for your review.
I'm sorry I posted this v9 in a bit of a rush...
but I promise we will get there... eventually :D
Thx,
Guillaume.
Re: [PATCH v9 06/22] video/hdmi: Add audio_infoframe packing for DP
On Mon, 28 Mar 2022 10:09, AngeloGioacchino Del Regno wrote: >Il 28/03/22 00:39, Guillaume Ranquet ha scritto: >> From: Markus Schneider-Pargmann >> >> Similar to HDMI, DP uses audio infoframes as well which are structured >> very similar to the HDMI ones. >> >> This patch adds a helper function to pack the HDMI audio infoframe for >> DP, called hdmi_audio_infoframe_pack_for_dp(). >> hdmi_audio_infoframe_pack_only() is split into two parts. One of them >> packs the payload only and can be used for HDMI and DP. >> >> Signed-off-by: Markus Schneider-Pargmann >> Signed-off-by: Guillaume Ranquet >> --- >> drivers/video/hdmi.c | 82 ++ >> include/drm/dp/drm_dp_helper.h | 2 + >> include/linux/hdmi.h | 7 ++- >> 3 files changed, 71 insertions(+), 20 deletions(-) >> >> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c >> index 947be761dfa4..5f50237554ed 100644 >> --- a/drivers/video/hdmi.c >> +++ b/drivers/video/hdmi.c >> @@ -21,6 +21,7 @@ >>* DEALINGS IN THE SOFTWARE. >>*/ >> >> +#include >> #include >> #include >> #include >> @@ -381,12 +382,34 @@ static int hdmi_audio_infoframe_check_only(const >> struct hdmi_audio_infoframe *fr >>* >>* Returns 0 on success or a negative error code on failure. >>*/ >> -int hdmi_audio_infoframe_check(struct hdmi_audio_infoframe *frame) >> +int hdmi_audio_infoframe_check(const struct hdmi_audio_infoframe *frame) > >I agree with this change, as hdmi_audio_infoframe_check_only()'s param is a >const, >but you really should mention that you're constifying this one in your commit >description, or do that in a separate commit. > >Either of the two is fine. > >Regards, >Angelo Noted, I'll add it to the commit message. Thx, Guillaume.
Re: [PATCH v9 17/22] phy: phy-mtk-dp: Add driver for DP phy
On Mon, 28 Mar 2022 10:20, AngeloGioacchino Del Regno
wrote:
>Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
>> From: Markus Schneider-Pargmann
>>
>> This is a new driver that supports the integrated DisplayPort phy for
>> mediatek SoCs, especially the mt8195. The phy is integrated into the
>> DisplayPort controller and will be created by the mtk-dp driver. This
>> driver expects a struct regmap to be able to work on the same registers
>> as the DisplayPort controller. It sets the device data to be the struct
>> phy so that the DisplayPort controller can easily work with it.
>>
>> The driver does not have any devicetree bindings because the datasheet
>> does not list the controller and the phy as distinct units.
>>
>> The interaction with the controller can be covered by the configure
>> callback of the phy framework and its displayport parameters.
>>
>> Signed-off-by: Markus Schneider-Pargmann
>> Signed-off-by: Guillaume Ranquet
>> ---
>> MAINTAINERS | 1 +
>> drivers/phy/mediatek/Kconfig | 8 ++
>> drivers/phy/mediatek/Makefile | 1 +
>> drivers/phy/mediatek/phy-mtk-dp.c | 201 ++
>> 4 files changed, 211 insertions(+)
>> create mode 100644 drivers/phy/mediatek/phy-mtk-dp.c
>>
>
>..snip..
>
>> diff --git a/drivers/phy/mediatek/phy-mtk-dp.c
>> b/drivers/phy/mediatek/phy-mtk-dp.c
>> new file mode 100644
>> index ..e5c5494f3636
>> --- /dev/null
>> +++ b/drivers/phy/mediatek/phy-mtk-dp.c
>
>..snip..
>
>> +
>> +static int mtk_dp_phy_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = &pdev->dev;
>> +struct mtk_dp_phy *dp_phy;
>> +struct phy *phy;
>> +struct regmap *regs;
>> +
>> +regs = syscon_regmap_lookup_by_phandle(dev->of_node,
>> "mediatek,dp-syscon");
>> +
>
>Please drop this blank line
>
>> +if (IS_ERR(regs))
>> +return PTR_ERR(regs);
>> +
>> +dp_phy = devm_kzalloc(dev, sizeof(*dp_phy), GFP_KERNEL);
>> +if (!dp_phy)
>> +return -ENOMEM;
>> +
>> +dp_phy->regs = regs;
>> +
>> +phy = devm_phy_create(dev, NULL, &mtk_dp_phy_dev_ops);
>> +
>
>Same here
>
>> +if (IS_ERR(phy))
>> +return dev_err_probe(dev, PTR_ERR(phy), "Failed to create DP
>> PHY: %ld\n", PTR_ERR(phy));
>> +
>
>Using dev_err_probe automates printing the error, so the correct usage is:
>
>return dev_err_probe(dev, PTR_ERR(phy), "Failed to create DP PHY\n");
>
>> +phy_set_drvdata(phy, dp_phy);
>> +
>> +return 0;
>> +}
>> +
>> +struct platform_driver mtk_dp_phy_driver = {
>> +.probe = mtk_dp_phy_probe,
>> +.driver = {
>> +.name = "mediatek-dp-phy",
>> +},
>> +};
>> +module_platform_driver(mtk_dp_phy_driver);
>
>Also, in your dt-binding, you mention a compatible for this driver, but I
>don't see
>any, here. This means that you do know what to do, so please do it.
>
Following the comments from rob [1], I'll revert back to using
platform_device_register_data() from v8.
[1]
https://lore.kernel.org/linux-mediatek/ykopb5w7uxkoc72...@robh.at.kernel.org/
>Regards,
>Angelo
>
>> +
>> +MODULE_AUTHOR("Markus Schneider-Pargmann ");
>> +MODULE_DESCRIPTION("MediaTek DP PHY Driver");
>> +MODULE_LICENSE("GPL");
>
Re: [PATCH v9 15/22] drm/mediatek: dpi: Add dpintf support
On Mon, 28 Mar 2022 10:38, Rex-BC Chen wrote:
>Hello Guillaume,
>
>Thanks for your patch, but I have some questions for this patch:
>
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> dpintf is the displayport interface hardware unit. This unit is
>> similar
>> to dpi and can reuse most of the code.
>>
>> This patch adds support for mt8195-dpintf to this dpi driver. Main
>> differences are:
>> - Some features/functional components are not available for dpintf
>>which are now excluded from code execution once is_dpintf is set
>> - dpintf can and needs to choose between different clockdividers
>> based
>>on the clockspeed. This is done by choosing a different clock
>> parent.
>> - There are two additional clocks that need to be managed. These are
>>only set for dpintf and will be set to NULL if not supplied. The
>>clk_* calls handle these as normal clocks then.
>> - Some register contents differ slightly between the two components.
>> To
>>work around this I added register bits/masks with a DPINTF_ prefix
>>and use them where different.
>>
>> Based on a separate driver for dpintf created by
>> Jason-JH.Lin .
>>
>> Signed-off-by: Markus Schneider-Pargmann
>> Signed-off-by: Guillaume Ranquet
>> Reviewed-by: AngeloGioacchino Del Regno <
>> angelogioacchino.delre...@collabora.com>
>> ---
>> drivers/gpu/drm/mediatek/mtk_dpi.c | 78 ++-
>> --
>> drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 38 ++
>> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +++
>> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +-
>> include/linux/soc/mediatek/mtk-mmsys.h | 2 +
>> 6 files changed, 120 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> index eb969c5c5c2e..8198d3cf23ac 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> @@ -126,6 +126,7 @@ struct mtk_dpi_conf {
>> const u32 *output_fmts;
>> u32 num_output_fmts;
>> bool is_ck_de_pol;
>> +bool is_dpintf;
>> bool swap_input_support;
>> /* Mask used for HWIDTH, HPORCH, VSYNC_WIDTH and VSYNC_PORCH
>> (no shift) */
>> u32 dimension_mask;
>> @@ -498,11 +499,11 @@ static int mtk_dpi_set_display_mode(struct
>> mtk_dpi *dpi,
>>
>> vm.pixelclock = pll_rate / factor;
>> if ((dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_LE) ||
>> -(dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_BE))
>> + (dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_BE)) {
>> clk_set_rate(dpi->pixel_clk, vm.pixelclock * 2);
>> -else
>> +} else {
>> clk_set_rate(dpi->pixel_clk, vm.pixelclock);
>> -
>> +}
>>
>> vm.pixelclock = clk_get_rate(dpi->pixel_clk);
>>
>> @@ -515,9 +516,15 @@ static int mtk_dpi_set_display_mode(struct
>> mtk_dpi *dpi,
>> MTK_DPI_POLARITY_FALLING :
>> MTK_DPI_POLARITY_RISING;
>> dpi_pol.vsync_pol = vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ?
>> MTK_DPI_POLARITY_FALLING :
>> MTK_DPI_POLARITY_RISING;
>> -hsync.sync_width = vm.hsync_len;
>> -hsync.back_porch = vm.hback_porch;
>> -hsync.front_porch = vm.hfront_porch;
>> +if (dpi->conf->is_dpintf) {
>> +hsync.sync_width = vm.hsync_len / 4;
>> +hsync.back_porch = vm.hback_porch / 4;
>> +hsync.front_porch = vm.hfront_porch / 4;
>> +} else {
>> +hsync.sync_width = vm.hsync_len;
>> +hsync.back_porch = vm.hback_porch;
>> +hsync.front_porch = vm.hfront_porch;
>> +}
>> hsync.shift_half_line = false;
>> vsync_lodd.sync_width = vm.vsync_len;
>> vsync_lodd.back_porch = vm.vback_porch;
>> @@ -559,13 +566,20 @@ static int mtk_dpi_set_display_mode(struct
>> mtk_dpi *dpi,
>> mtk_dpi_config_channel_limit(dpi);
>> mtk_dpi_config_bit_num(dpi, dpi->bit_num);
>> mtk_dpi_config_channel_swap(dpi, dpi->channel_swap);
>> -mtk_dpi_config_yc_map(dpi, dpi->yc_map);
>> mtk_dpi_config_color_format(dpi, dpi->color_format);
>> -mtk_dpi_config_2n_h_fre(dpi);
>> -mtk_dpi_dual_edge(dpi);
>> -mtk_dpi_config_disable_edge(dpi);
>> +if (dpi->conf->is_dpintf) {
>> +mtk_dpi_mask(dpi, DPI_CON, DPINTF_INPUT_2P_EN,
>> + DPINTF_INPUT_2P_EN);
>> +} else {
>> +mtk_dpi_config_yc_map(dpi, dpi->yc_map);
>> +mtk_dpi_config_2n_h_fre(dpi);
>> +mtk_dpi_dual_edge(dpi);
>> +mtk_dpi_config_disable_edge(dpi);
>> +}
>> mtk_dpi_sw_reset(dpi, false);
>>
>> +mtk_dpi_enable(dpi);
>
>Why do we need to add mtk_dpi_enable() here?
>Will this change the power on sequence?
>
I have been told that this is to avoid artifacts on screen, the
mtk_dpi_enable() is done
in mtk_dpi_set_display_mode() instead of mtk_dpi_power_on();
I will try to convey that explanation
Re: [PATCH v9 15/22] drm/mediatek: dpi: Add dpintf support
On Tue, 29 Mar 2022 05:16, Rex-BC Chen wrote:
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> dpintf is the displayport interface hardware unit. This unit is
>> similar
>> to dpi and can reuse most of the code.
>>
>> This patch adds support for mt8195-dpintf to this dpi driver. Main
>> differences are:
>> - Some features/functional components are not available for dpintf
>>which are now excluded from code execution once is_dpintf is set
>> - dpintf can and needs to choose between different clockdividers
>> based
>>on the clockspeed. This is done by choosing a different clock
>> parent.
>> - There are two additional clocks that need to be managed. These are
>>only set for dpintf and will be set to NULL if not supplied. The
>>clk_* calls handle these as normal clocks then.
>> - Some register contents differ slightly between the two components.
>> To
>>work around this I added register bits/masks with a DPINTF_ prefix
>>and use them where different.
>>
>> Based on a separate driver for dpintf created by
>> Jason-JH.Lin .
>>
>> Signed-off-by: Markus Schneider-Pargmann
>> Signed-off-by: Guillaume Ranquet
>> Reviewed-by: AngeloGioacchino Del Regno <
>> angelogioacchino.delre...@collabora.com>
>> ---
>> drivers/gpu/drm/mediatek/mtk_dpi.c | 78 ++-
>> --
>> drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 38 ++
>> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +++
>> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +-
>> include/linux/soc/mediatek/mtk-mmsys.h | 2 +
>> 6 files changed, 120 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> index eb969c5c5c2e..8198d3cf23ac 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> @@ -126,6 +126,7 @@ struct mtk_dpi_conf {
>> const u32 *output_fmts;
>> u32 num_output_fmts;
>> bool is_ck_de_pol;
>> +bool is_dpintf;
>> bool swap_input_support;
>> /* Mask used for HWIDTH, HPORCH, VSYNC_WIDTH and VSYNC_PORCH
>> (no shift) */
>> u32 dimension_mask;
>> @@ -498,11 +499,11 @@ static int mtk_dpi_set_display_mode(struct
>> mtk_dpi *dpi,
>>
>> vm.pixelclock = pll_rate / factor;
>> if ((dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_LE) ||
>> -(dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_BE))
>> + (dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_BE)) {
>> clk_set_rate(dpi->pixel_clk, vm.pixelclock * 2);
>> -else
>> +} else {
>> clk_set_rate(dpi->pixel_clk, vm.pixelclock);
>> -
>> +}
>>
>> vm.pixelclock = clk_get_rate(dpi->pixel_clk);
>>
>> @@ -515,9 +516,15 @@ static int mtk_dpi_set_display_mode(struct
>> mtk_dpi *dpi,
>> MTK_DPI_POLARITY_FALLING :
>> MTK_DPI_POLARITY_RISING;
>> dpi_pol.vsync_pol = vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ?
>> MTK_DPI_POLARITY_FALLING :
>> MTK_DPI_POLARITY_RISING;
>> -hsync.sync_width = vm.hsync_len;
>> -hsync.back_porch = vm.hback_porch;
>> -hsync.front_porch = vm.hfront_porch;
>> +if (dpi->conf->is_dpintf) {
>> +hsync.sync_width = vm.hsync_len / 4;
>> +hsync.back_porch = vm.hback_porch / 4;
>> +hsync.front_porch = vm.hfront_porch / 4;
>> +} else {
>> +hsync.sync_width = vm.hsync_len;
>> +hsync.back_porch = vm.hback_porch;
>> +hsync.front_porch = vm.hfront_porch;
>> +}
>> hsync.shift_half_line = false;
>> vsync_lodd.sync_width = vm.vsync_len;
>> vsync_lodd.back_porch = vm.vback_porch;
>> @@ -559,13 +566,20 @@ static int mtk_dpi_set_display_mode(struct
>> mtk_dpi *dpi,
>> mtk_dpi_config_channel_limit(dpi);
>> mtk_dpi_config_bit_num(dpi, dpi->bit_num);
>> mtk_dpi_config_channel_swap(dpi, dpi->channel_swap);
>> -mtk_dpi_config_yc_map(dpi, dpi->yc_map);
>> mtk_dpi_config_color_format(dpi, dpi->color_format);
>> -mtk_dpi_config_2n_h_fre(dpi);
>> -mtk_dpi_dual_edge(dpi);
>> -mtk_dpi_config_disable_edge(dpi);
>> +if (dpi->conf->is_dpintf) {
>> +mtk_dpi_mask(dpi, DPI_CON, DPINTF_INPUT_2P_EN,
>> + DPINTF_INPUT_2P_EN);
>> +} else {
>> +mtk_dpi_config_yc_map(dpi, dpi->yc_map);
>> +mtk_dpi_config_2n_h_fre(dpi);
>> +mtk_dpi_dual_edge(dpi);
>> +mtk_dpi_config_disable_edge(dpi);
>> +}
>> mtk_dpi_sw_reset(dpi, false);
>>
>> +mtk_dpi_enable(dpi);
>> +
>> return 0;
>> }
>>
>> @@ -642,7 +656,10 @@ static int mtk_dpi_bridge_atomic_check(struct
>> drm_bridge *bridge,
>> dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
>> dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
>> dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
>> -dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
>> +if (out_bus_format == MEDIA
[PATCH] drm/vmwgfx: remove bogus NULL check
The IS_ERR_OR_NULL() check in vmw_translate_mob_ptr() should just be
an IS_ERR() check.
The NULL check is confusing because vmw_user_bo_noref_lookup() can never
return NULL. A NULL return here would only lead to bugs and crashing.
For example, Smatch complains that it would lead to an uninitialized
variable in the caller.
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:1314 vmw_cmd_dx_bind_query()
error: uninitialized symbol 'vmw_bo'.
So clean this code up and silence then static checker warnings by
removing the bogus NULL check.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index d49de4905efa..8072c053be97 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1172,7 +1172,7 @@ static int vmw_translate_mob_ptr(struct vmw_private
*dev_priv,
vmw_validation_preload_bo(sw_context->ctx);
vmw_bo = vmw_user_bo_noref_lookup(sw_context->filp, handle);
- if (IS_ERR_OR_NULL(vmw_bo)) {
+ if (IS_ERR(vmw_bo)) {
VMW_DEBUG_USER("Could not find or use MOB buffer.\n");
return PTR_ERR(vmw_bo);
}
--
2.20.1
Re: [PATCH v2 0/5] drm/ttm: Introduce TTM res manager debugfs helpers
Hi Zack, Reviewed-by: Christian König for the entire series. One nit pick is that I want to get rid of using ttm_manager_type() in drivers and use pointers to the members directly. But that's something for a later cleanup anyway. Thanks, Christian. Am 12.04.22 um 05:35 schrieb Zack Rusin: From: Zack Rusin v2: Switch to using ttm_resource_manager's directly in the debugfs callbacks This series introduces generic TTM resource manager debugfs helpers and refactors TTM drivers which have been using hand rolled out versions of those to use the new code. Zack Rusin (5): drm/ttm: Add common debugfs code for resource managers drm/vmwgfx: Add debugfs entries for various ttm resource managers drm/amdgpu: Use TTM builtin resource manager debugfs code drm/qxl: Use TTM builtin resource manager debugfs code drm/radeon: Use TTM builtin resource manager debugfs code drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 86 + drivers/gpu/drm/qxl/qxl_ttm.c | 39 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 36 ++- drivers/gpu/drm/ttm/ttm_resource.c | 34 ++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 18 ++ include/drm/ttm/ttm_resource.h | 4 ++ 6 files changed, 84 insertions(+), 133 deletions(-)
Re: [PATCH v0 00/10] i.MX8MP HDMI support
Hello Lucas, Am Mittwoch, 6. April 2022, 18:01:13 CEST schrieb Lucas Stach: > Hi all, > > this adds support for the HDMI output pipeline on the i.MX8MP. > It currently depends on the i.MX8MP HDMI power domain series [1] > and support for the new LCDIF [2] in the i.MX8MP. I guess the > implementation presented here also still has some warts that > require fixing and the individual patches most likely need to go > through different maintainer trees, so I don't expect this series > to be applied right away. > > However this complete series should allow people to test it more > easily and provide feedback on the implementation with the full > picture available. > > Compared to downstream this implementation actually allows to > power down the separate HDMI PHY power domain when the display > is inactive or no HDMI cable is connected. Thanks for these patches. I tried using them on my imx8mp based board (TQMa8MPxL + MBa8MPxL) but failed to get the display showing anything. I noticed several things though: * For some reason the HDMI PHY PLL does not lock. I get the error > fsl-samsung-hdmi-phy 32fdff00.phy: PLL failed to lock Increasing timeout does not change anything. * The HDMI bridge wants to use bus format 0x200f which is not supported by lcdif. > lcdif 32fc6000.display-controller: Unknown media bus format 0x200f I wonder which part in the DRM chain choses to use this. But even hard limiting to 0x100a the screen stayed in suspend * If the drivers are built as modules I get a hard lockup during boot. Using built-in drivers or 'clk_ignore_unused' workarounds this. * DDC does actually work. The display is detected and EDID can be read. * Sometimes I get the following error: [ cut here ] [CRTC:33:crtc-0] vblank wait timed out WARNING: CPU: 2 PID: 151 at drivers/gpu/drm/drm_atomic_helper.c:1529 drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc Modules linked in: caamhash_desc caamalg_desc crypto_engine rng_core mcp320x dw_hdmi_cec authenc libdes dw100 videobuf2_dma_contig lcdif crct10dif_ce phy_fsl_samsung_hdmi v4l2_mem2mem imx_sdma flexcan imx8mm_thermal can_dev caam error pwm_fan fuse ipv6 CPU: 2 PID: 151 Comm: kworker/u8:7 Not tainted 5.18.0-rc2-next-20220412+ #165 d226098cac46ded24901c7090f909ca8f5098eb0 Hardware name: TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MPxL (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc lr : drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc sp : 8a133430 x29: 8a133430 x28: x27: x26: x25: 0001 x24: 8935f030 x23: 0433e000 x22: 029e7000 x21: 0001 x20: 02e7fb48 x19: x18: 0001 x17: 4d554e5145530065 x16: 6c75646f6d3d4d45 x15: 5453595342555300 x14: x13: 0a74756f2064656d x12: 6974207469617720 x11: x10: 003a x9 : 8a133430 x8 : x7 : 6974207469617720 x6 : 6b6e616c6276205d x5 : 7fb91b00 x4 : x3 : 0027 x2 : 0023 x1 : x0 : Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc drm_atomic_helper_commit_tail_rpm+0x80/0xa0 commit_tail+0xcc/0x1f0 drm_atomic_helper_commit+0x13c/0x370 drm_atomic_commit+0xa4/0xe0 drm_client_modeset_commit_atomic+0x1fc/0x250 drm_client_modeset_commit_locked+0x58/0xa0 drm_client_modeset_commit+0x2c/0x50 __drm_fb_helper_restore_fbdev_mode_unlocked+0xec/0x140 drm_fb_helper_set_par+0x38/0x6c fbcon_init+0x264/0x5e4 visual_init+0xc8/0x15c do_bind_con_driver.isra.0+0x20c/0x470 do_take_over_console+0x44/0x60 do_fbcon_takeover+0x80/0x140 fbcon_fb_registered+0x1c4/0x260 do_register_framebuffer+0x1e0/0x2d0 register_framebuffer+0x2c/0x50 __drm_fb_helper_initial_config_and_unlock+0x9c/0x130 drm_fbdev_client_hotplug+0x1a8/0x20c drm_fbdev_generic_setup+0xc0/0x1d0 lcdif_probe+0x7c/0xa0 [lcdif e756925430e957a7bc9e6376ad5964e4b1cb143e] platform_probe+0x64/0x100 call_driver_probe+0x28/0x130 really_probe+0x178/0x310 __driver_probe_device+0xfc/0x144 driver_probe_device+0x38/0x12c __device_attach_driver+0xd4/0x180 bus_for_each_drv+0x74/0xc4 __device_attach+0xd8/0x1e0 device_initial_probe+0x10/0x20 bus_probe_device+0x90/0xa0 deferred_probe_work_func+0x9c/0xf0 process_one_work+0x1d0/0x330 worker_thread+0x68/0x390 kthread+0xec/0xfc ret_from_fork+0x10/0x20 ---[ end trace ]--- But given that the PLL did not lock I assume this is not too surprising. Best regards, Alexander
Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
> Wiadomość napisana przez Sascha Hauer w dniu
> 12.04.2022, o godz. 09:50:
>
>
> Somehow negotiation of the format goes wrong. Applications shouldn't
> pick these formats when the GPU is used for rendering. I don't know how
> and where this should be fixed properly, but your application should use
> DRM_FORMAT_ABGR aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
> DRM_FORMAT_ARGB aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.
>
Applied :-)
Results: pls see below
> Could you try the following patch? It removed the formats in question
> from the list of supported formats in the hope that your application
> then picks one of the supported formats.
>
> Sascha
>
> ---8<-
>
> From 7427109cfd16803902b55cd5536b9212abd09665 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer
> Date: Tue, 12 Apr 2022 09:42:32 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
>
> The cluster windows only allow AFBC compressed formats. Not all of the
> offered formats are supported by the GPU though. Applications pick one
> of the formats and assume that this is also supported by the GPU they
> use to render on them, but this is not the case for all formats.
> Particularly DRM_FORMAT_XRGB and DRM_FORMAT_ARGB are not
> supported by the GPU and choosing them results in a black screen.
> Drop these formats for now.
>
> Signed-off-by: Sascha Hauer
> ---
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 9bf0637bf8e26..38412766e3659 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -16,8 +16,6 @@
> #include "rockchip_drm_vop2.h"
>
> static const uint32_t formats_win_full_10bit[] = {
> - DRM_FORMAT_XRGB,
> - DRM_FORMAT_ARGB,
> DRM_FORMAT_XBGR,
> DRM_FORMAT_ABGR,
> DRM_FORMAT_RGB888,
> --
>
With above patch app select expected format (i think):
1970-01-01 01:00:31.074643 I /dev/dri/card0: Authenticated
1970-01-01 01:00:31.189420 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
1970-01-01 01:00:31.189444 I /dev/dri/card0: Selected Plane #37 Overlay for
video
1970-01-01 01:00:31.189528 I /dev/dri/card0: Supported DRM video formats:
NV12,NV16,NV24,YVYU,VYUY
1970-01-01 01:00:31.189536 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
1970-01-01 01:00:31.190279 I Wrote
/home/minimyth/.mythtv/eglfs_kms_config.json:
{
"device": "/dev/dri/card0",
"outputs": [ { "name": "HDMI1", "format": "abgr", "mode": "current" } ]
}
(file eglfs_kms_config.json is generated by app to configure Qt; it is steep
(b) in yesterday's email)
I see format abgr is now selected by app (this is expected t think)
but later Qt says:
1970-01-01 01:00:34.985215 I Qt: EGL Error : Could not create the egl surface:
error = 0x3009
Handling Aborted
Aborted
I suspect Qt tries with this format talk to GLES provider - but it wasn't
somehow accepted by underlying EGL provider (mesa GLES)?
Re: [PATCH v9 16/22] drm/meditek: dpi: Add matrix_sel helper
On Mon, 28 Mar 2022 10:49, Rex-BC Chen wrote:
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> Add a mtk_dpi_matrix_sel() helper to update the DPI_MATRIX_SET
>> register depending on the color format.
>>
>> Signed-off-by: Guillaume Ranquet
>> ---
>> drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> index 8198d3cf23ac..82f97c687652 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> @@ -385,6 +385,25 @@ static void mtk_dpi_config_disable_edge(struct
>> mtk_dpi *dpi)
>> mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0,
>> EDGE_SEL_EN);
>> }
>>
>> +static void mtk_dpi_matrix_sel(struct mtk_dpi *dpi, enum
>> mtk_dpi_out_color_format format)
>> +{
>> +u32 matrix_sel = 0;
>> +
>> +switch (format) {
>> +case MTK_DPI_COLOR_FORMAT_YCBCR_422:
>> +case MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL:
>> +case MTK_DPI_COLOR_FORMAT_YCBCR_444:
>> +case MTK_DPI_COLOR_FORMAT_YCBCR_444_FULL:
>> +case MTK_DPI_COLOR_FORMAT_XV_YCC:
>> +if (dpi->mode.hdisplay <= 720)
>> +matrix_sel = 0x2;
>> +break;
>> +default:
>> +break;
>> +}
>> +mtk_dpi_mask(dpi, DPI_MATRIX_SET, matrix_sel,
>> INT_MATRIX_SEL_MASK);
>> +}
>> +
>> static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
>> enum mtk_dpi_out_color_format
>> format)
>> {
>> @@ -392,6 +411,7 @@ static void mtk_dpi_config_color_format(struct
>> mtk_dpi *dpi,
>> (format == MTK_DPI_COLOR_FORMAT_YCBCR_444_FULL)) {
>> mtk_dpi_config_yuv422_enable(dpi, false);
>> mtk_dpi_config_csc_enable(dpi, true);
>> +mtk_dpi_matrix_sel(dpi, format);
>> if (dpi->conf->swap_input_support)
>> mtk_dpi_config_swap_input(dpi, false);
>> mtk_dpi_config_channel_swap(dpi,
>> MTK_DPI_OUT_CHANNEL_SWAP_BGR);
>> @@ -399,6 +419,7 @@ static void mtk_dpi_config_color_format(struct
>> mtk_dpi *dpi,
>> (format == MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL)) {
>> mtk_dpi_config_yuv422_enable(dpi, true);
>> mtk_dpi_config_csc_enable(dpi, true);
>> +mtk_dpi_matrix_sel(dpi, format);
>> if (dpi->conf->swap_input_support)
>> mtk_dpi_config_swap_input(dpi, true);
>> mtk_dpi_config_channel_swap(dpi,
>> MTK_DPI_OUT_CHANNEL_SWAP_RGB);
>
>Hello Guillaume,
>
>Thanks for your patch.
>I have one question:
>Do this setting affect the dpi for previous SoCs?
>(8183, 8192, or 8186)
>If we can confirm the original register setting for this offset in
>8183/8192/8186, I think we can clarify this question.
>
I've checked in the datasheet I have (8365/8385) that this register
and setting exists.
So yes, it will affect other platforms.
>BRs,
>Rex
>
Re: [PATCH v0 00/10] i.MX8MP HDMI support
Hi Alexander, Am Dienstag, dem 12.04.2022 um 11:18 +0200 schrieb Alexander Stein: > Hello Lucas, > > Am Mittwoch, 6. April 2022, 18:01:13 CEST schrieb Lucas Stach: > > Hi all, > > > > this adds support for the HDMI output pipeline on the i.MX8MP. > > It currently depends on the i.MX8MP HDMI power domain series [1] > > and support for the new LCDIF [2] in the i.MX8MP. I guess the > > implementation presented here also still has some warts that > > require fixing and the individual patches most likely need to go > > through different maintainer trees, so I don't expect this series > > to be applied right away. > > > > However this complete series should allow people to test it more > > easily and provide feedback on the implementation with the full > > picture available. > > > > Compared to downstream this implementation actually allows to > > power down the separate HDMI PHY power domain when the display > > is inactive or no HDMI cable is connected. > > Thanks for these patches. > I tried using them on my imx8mp based board (TQMa8MPxL + MBa8MPxL) but failed > to get the display showing anything. I noticed several things though: > > * For some reason the HDMI PHY PLL does not lock. I get the error > > fsl-samsung-hdmi-phy 32fdff00.phy: PLL failed to lock > Increasing timeout does not change anything. > > * The HDMI bridge wants to use bus format 0x200f which is not supported by > lcdif. > > lcdif 32fc6000.display-controller: Unknown media bus format 0x200f > I wonder which part in the DRM chain choses to use this. Do have a 4k HDMI display connected that wants to do YUV input? That's something I have to admit I didn't test yet and would be likely to cause this bus format selection. > But even hard limiting to 0x100a the screen stayed in suspend > > * If the drivers are built as modules I get a hard lockup during boot. Using > built-in drivers or 'clk_ignore_unused' workarounds this. > > * DDC does actually work. The display is detected and EDID can be read. > > * Sometimes I get the following error: > [ cut here ] > [CRTC:33:crtc-0] vblank wait timed out > WARNING: CPU: 2 PID: 151 at drivers/gpu/drm/drm_atomic_helper.c:1529 > drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc > Modules linked in: caamhash_desc caamalg_desc crypto_engine rng_core mcp320x > dw_hdmi_cec authenc libdes dw100 videobuf2_dma_contig lcdif crct10dif_ce > phy_fsl_samsung_hdmi v4l2_mem2mem imx_sdma flexcan imx8mm_thermal can_dev > caam > error pwm_fan fuse ipv6 > CPU: 2 PID: 151 Comm: kworker/u8:7 Not tainted 5.18.0-rc2-next-20220412+ #165 > d226098cac46ded24901c7090f909ca8f5098eb0 > Hardware name: TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MPxL (DT) > Workqueue: events_unbound deferred_probe_work_func > pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc > lr : drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc > sp : 8a133430 > x29: 8a133430 x28: x27: > x26: x25: 0001 x24: 8935f030 > x23: 0433e000 x22: 029e7000 x21: 0001 > x20: 02e7fb48 x19: x18: 0001 > x17: 4d554e5145530065 x16: 6c75646f6d3d4d45 x15: 5453595342555300 > x14: x13: 0a74756f2064656d x12: 6974207469617720 > x11: x10: 003a x9 : 8a133430 > x8 : x7 : 6974207469617720 x6 : 6b6e616c6276205d > x5 : 7fb91b00 x4 : x3 : 0027 > x2 : 0023 x1 : x0 : > Call trace: > drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc > drm_atomic_helper_commit_tail_rpm+0x80/0xa0 > commit_tail+0xcc/0x1f0 > drm_atomic_helper_commit+0x13c/0x370 > drm_atomic_commit+0xa4/0xe0 > drm_client_modeset_commit_atomic+0x1fc/0x250 > drm_client_modeset_commit_locked+0x58/0xa0 > drm_client_modeset_commit+0x2c/0x50 > __drm_fb_helper_restore_fbdev_mode_unlocked+0xec/0x140 > drm_fb_helper_set_par+0x38/0x6c > fbcon_init+0x264/0x5e4 > visual_init+0xc8/0x15c > do_bind_con_driver.isra.0+0x20c/0x470 > do_take_over_console+0x44/0x60 > do_fbcon_takeover+0x80/0x140 > fbcon_fb_registered+0x1c4/0x260 > do_register_framebuffer+0x1e0/0x2d0 > register_framebuffer+0x2c/0x50 > __drm_fb_helper_initial_config_and_unlock+0x9c/0x130 > drm_fbdev_client_hotplug+0x1a8/0x20c > drm_fbdev_generic_setup+0xc0/0x1d0 > lcdif_probe+0x7c/0xa0 [lcdif e756925430e957a7bc9e6376ad5964e4b1cb143e] > platform_probe+0x64/0x100 > call_driver_probe+0x28/0
Re: [PATCH 01/11] drm: bridge: Add Samsung DSIM bridge driver
Hi Jagan,
On 08.04.2022 18:20, Jagan Teki wrote:
> Samsung MIPI DSIM controller is common DSI IP that can be used in various
> SoCs like Exynos, i.MX8M Mini/Nano.
>
> In order to access this DSI controller between various platform SoCs, the
> ideal way to incorporate this in the drm stack is via the drm bridge driver.
>
> This patch is trying to differentiate platform-specific and bridge driver
> code and keep maintaining the exynos_drm_dsi.c code as platform-specific
> glue code and samsung-dsim.c as a common bridge driver code.
>
> - Exynos specific glue code is exynos specific te_irq, host_attach, and
>detach code along with conventional component_ops.
>
> - Samsung DSIM is a bridge driver which is common across all platforms and
>the respective platform-specific glue will initialize at the end of the
>probe. The platform-specific operations and other glue calls will invoke
>on associate code areas.
>
> Updated MAINTAINERS file for this bridge with exynos drm maintainers along
> with Andrzej as he is the original author.
>
> Tomasz Figa has been not included in MAINTAINERS as he is not available via
> samsung.com.
>
> v1:
> * Don't maintain component_ops in bridge driver
> * Don't maintain platform glue code in bridge driver
> * Add platform-specific glue code and make a common bridge
>
> Signed-off-by: Jagan Teki
Well, it took me a while to make this working on Exynos. I'm not really
happy of the design, although I didn't spent much time thinking how to
improve it and clarify some ambiguities. It doesn't even look that one
has compiled the Exynos code after this conversion.
The following changes are needed to get it to the same working state as
before this patch (the next patches however break it even further):
commit e358ee6239305744062713c5aa2e8d44f740b81a (HEAD)
Author: Marek Szyprowski
Date: Tue Apr 12 11:30:26 2022 +0200
drm: exynos: dsi: fixup driver after conversion
Signed-off-by: Marek Szyprowski
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index ee5d7e5518a6..8e0064282ce6 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -17,7 +17,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 97167c5ffc78..bbfacb22d99d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
@@ -25,17 +26,19 @@ struct exynos_dsi {
struct samsung_dsim_plat_data pdata;
};
-static void exynos_dsi_enable_irq(void *priv)
+static void exynos_dsi_enable_irq(struct samsung_dsim *priv)
{
- struct exynos_dsi *dsi = priv;
+ const struct samsung_dsim_plat_data *pdata = priv->plat_data;
+ struct exynos_dsi *dsi = container_of(pdata, struct exynos_dsi,
pdata);
if (dsi->te_gpio)
enable_irq(gpiod_to_irq(dsi->te_gpio));
}
-static void exynos_dsi_disable_irq(void *priv)
+static void exynos_dsi_disable_irq(struct samsung_dsim *priv)
{
- struct exynos_dsi *dsi = priv;
+ const struct samsung_dsim_plat_data *pdata = priv->plat_data;
+ struct exynos_dsi *dsi = container_of(pdata, struct exynos_dsi,
pdata);
if (dsi->te_gpio)
disable_irq(gpiod_to_irq(dsi->te_gpio));
@@ -92,15 +95,15 @@ static void exynos_dsi_unregister_te_irq(struct
exynos_dsi *dsi)
}
}
-static int exynos_dsi_host_attach(void *priv, struct mipi_dsi_device
*device)
+static int exynos_dsi_host_attach(struct samsung_dsim *priv, struct
mipi_dsi_device *device)
{
- struct exynos_dsi *dsi = priv;
- struct samsung_dsim *_priv = dsi->priv;
+ const struct samsung_dsim_plat_data *pdata = priv->plat_data;
+ struct exynos_dsi *dsi = container_of(pdata, struct exynos_dsi,
pdata);
struct drm_encoder *encoder = &dsi->encoder;
struct drm_device *drm = encoder->dev;
int ret;
- drm_bridge_attach(encoder, &_priv->bridge, NULL, 0);
+ drm_bridge_attach(encoder, &priv->bridge, NULL, 0);
/*
* This is a temporary solution and should be made by more
generic way.
@@ -116,11 +119,11 @@ static int exynos_dsi_host_attach(void *priv,
struct mipi_dsi_device *device)
mutex_lock(&drm->mode_config.mutex);
- _priv->lanes = device->lanes;
- _priv->format = device->format;
- _priv->mode_flags = device->mode_flags;
+ priv->lanes = device->lanes;
+ priv->format = device->format;
+ priv->mode_flags = device->mode_flags;
exynos_drm_crtc_get_by_type(drm,
EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
- !(_priv->mode_flags & MIPI_DSI_MODE_VIDEO);
+ !(priv->mode_flags & MIPI_DSI_MODE_VIDEO);
mutex_unlock(&drm->mode_config.mutex);
@@ -130,9 +
Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
On Mon, 28 Mar 2022 11:14, AngeloGioacchino Del Regno
wrote:
>Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
>> From: Markus Schneider-Pargmann
>>
>> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>>
>> It supports the mt8195, the embedded DisplayPort units. It offers
>> DisplayPort 1.4 with up to 4 lanes.
>>
>> The driver shares its iomap range with the mtk-dp-phy driver using
>> the regmap/syscon facility.
>>
>> This driver is based on an initial version by
>> Jason-JH.Lin .
>>
>> Signed-off-by: Markus Schneider-Pargmann
>> Signed-off-by: Guillaume Ranquet
>> Reported-by: kernel test robot
>
>Hello Guillaume,
>as you know, there's some more work to do on this driver.
>
>I will also mention here, not on the code, that at this point, your
>mtk_dp_aux_transfer() function has something VERY similar to function
>drm_dp_dpcd_access(), so I really believe that you can instead use
>functions drm_dp_dpcd_read() and drm_dp_dpcd_write(), avoiding code
>duplication around.
>
>Please check drivers/gpu/drm/dp/drm_dp.c.
>
This is already in my TODO list as this has been suggested by Rex earlier.
>> ---
>> drivers/gpu/drm/mediatek/Kconfig |8 +
>> drivers/gpu/drm/mediatek/Makefile |2 +
>> drivers/gpu/drm/mediatek/mtk_dp.c | 2221
>> drivers/gpu/drm/mediatek/mtk_dp_reg.h | 568 ++
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 +
>> drivers/gpu/drm/mediatek/mtk_drm_drv.h |1 +
>> 6 files changed, 2801 insertions(+)
>> create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
>> create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
>>
>> diff --git a/drivers/gpu/drm/mediatek/Kconfig
>> b/drivers/gpu/drm/mediatek/Kconfig
>> index 2976d21e9a34..03ffa9b896c3 100644
>> --- a/drivers/gpu/drm/mediatek/Kconfig
>> +++ b/drivers/gpu/drm/mediatek/Kconfig
>> @@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
>> select PHY_MTK_HDMI
>> help
>>DRM/KMS HDMI driver for Mediatek SoCs
>> +
>> +config MTK_DPTX_SUPPORT
>
>Actually, I think that the best would be DRM_MEDIATEK_DP_TX or
>DRM_MEDIATEK_DP...
>...also, ordering is important, please!
>
I will update the name.
What do you mean by ordering? do you expect the configs to be ordered
alphabetically?
>> +tristate "DRM DPTX Support for Mediatek SoCs"
>> +depends on DRM_MEDIATEK
>> +select PHY_MTK_DP
>> +select DRM_DP_HELPER
>> +help
>> + DRM/KMS Display Port driver for Mediatek SoCs.
>> diff --git a/drivers/gpu/drm/mediatek/Makefile
>> b/drivers/gpu/drm/mediatek/Makefile
>> index 29098d7c8307..d86a6406055e 100644
>> --- a/drivers/gpu/drm/mediatek/Makefile
>> +++ b/drivers/gpu/drm/mediatek/Makefile
>> @@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
>>mtk_hdmi_ddc.o
>>
>> obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
>> +
>> +obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
>> b/drivers/gpu/drm/mediatek/mtk_dp.c
>> new file mode 100644
>> index ..7cd8459cf719
>> --- /dev/null
>> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
>> @@ -0,0 +1,2221 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2019 MediaTek Inc.
>> + * Copyright (c) 2021 BayLibre
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "mtk_dp_reg.h"
>> +
>> +#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
>> +#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
>> +
>> +//TODO: platform/device data or dts?
>
>Assuming that your TODO is about the maximum number of lanes,
>{ .compatible = "mediatek,mt8195-edp-tx", .data = &some_const_structure },
Yes, exactly that, it'll be in v10.
>
>> +#define MTK_DP_MAX_LANES 4
>> +#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3
>
>..snip..
>
>> +
>> +static int mtk_dp_bulk_16bit_write(struct mtk_dp *mtk_dp, u32 offset, u8
>> *buf,
>> + size_t length)
>> +{
>> +int i;
>> +int ret = 0;
>> +int num_regs = (length + 1) / 2;
>> +
>> +/* 2 bytes per register */
>> +for (i = 0; i < num_regs; i++) {
>> +u32 val = buf[i * 2] |
>> + (i * 2 + 1 < length ? buf[i * 2 + 1] << 8 : 0);
>> +
>> +ret = mtk_dp_write(mtk_dp, offset + i * 4, val);
>> +if (ret)
>> +goto out;
>
>if (ret)
> return ret;
>
>> +}
>> +
>> +out:
>
>Remove this label.
>
>> +return ret;
>> +}
>> +
>> +static unsigned long mtk_dp_sip_atf_call(unsigned int cmd, unsigned int
>> para)
>> +{
>> +struct arm_smccc_res res;
>> +
>> +arm_smccc_smc(MTK_DP_SIP_CONTROL_AARCH32, cmd, para, 0, 0, 0, 0, 0,
>> + &res);
>> +
>> +pr_
Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
On Tue, 29 Mar 2022 05:34, Rex-BC Chen wrote:
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> From: Markus Schneider-Pargmann
>>
>> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>>
>> It supports the mt8195, the embedded DisplayPort units. It offers
>> DisplayPort 1.4 with up to 4 lanes.
>>
>> The driver shares its iomap range with the mtk-dp-phy driver using
>> the regmap/syscon facility.
>>
>> This driver is based on an initial version by
>> Jason-JH.Lin .
>>
>> Signed-off-by: Markus Schneider-Pargmann
>> Signed-off-by: Guillaume Ranquet
>> Reported-by: kernel test robot
>> ---
>> drivers/gpu/drm/mediatek/Kconfig |8 +
>> drivers/gpu/drm/mediatek/Makefile |2 +
>> drivers/gpu/drm/mediatek/mtk_dp.c | 2221
>>
>> drivers/gpu/drm/mediatek/mtk_dp_reg.h | 568 ++
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 +
>> drivers/gpu/drm/mediatek/mtk_drm_drv.h |1 +
>> 6 files changed, 2801 insertions(+)
>> create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
>> create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
>>
>> diff --git a/drivers/gpu/drm/mediatek/Kconfig
>> b/drivers/gpu/drm/mediatek/Kconfig
>> index 2976d21e9a34..03ffa9b896c3 100644
>> --- a/drivers/gpu/drm/mediatek/Kconfig
>> +++ b/drivers/gpu/drm/mediatek/Kconfig
>> @@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
>> select PHY_MTK_HDMI
>> help
>>DRM/KMS HDMI driver for Mediatek SoCs
>> +
>> +config MTK_DPTX_SUPPORT
>> +tristate "DRM DPTX Support for Mediatek SoCs"
>> +depends on DRM_MEDIATEK
>> +select PHY_MTK_DP
>> +select DRM_DP_HELPER
>> +help
>> + DRM/KMS Display Port driver for Mediatek SoCs.
>> diff --git a/drivers/gpu/drm/mediatek/Makefile
>> b/drivers/gpu/drm/mediatek/Makefile
>> index 29098d7c8307..d86a6406055e 100644
>> --- a/drivers/gpu/drm/mediatek/Makefile
>> +++ b/drivers/gpu/drm/mediatek/Makefile
>> @@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
>>mtk_hdmi_ddc.o
>>
>> obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
>> +
>> +obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
>> b/drivers/gpu/drm/mediatek/mtk_dp.c
>> new file mode 100644
>> index ..7cd8459cf719
>> --- /dev/null
>> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
>> @@ -0,0 +1,2221 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2019 MediaTek Inc.
>> + * Copyright (c) 2021 BayLibre
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>>
>
>...snip...
>
>> +
>> +static SIMPLE_DEV_PM_OPS(mtk_dp_pm_ops, mtk_dp_suspend,
>> mtk_dp_resume);
>> +
>> +static const struct of_device_id mtk_dp_of_match[] = {
>> +{ .compatible = "mediatek,mt8195-edp-tx", },
>> +{},
>> +};
>> +MODULE_DEVICE_TABLE(of, mtk_dp_of_match);
>> +
>> +struct platform_driver mtk_dp_driver = {
>> +.probe = mtk_dp_probe,
>> +.remove = mtk_dp_remove,
>> +.driver = {
>> +.name = "mediatek-drm-dp",
>> +.of_match_table = mtk_dp_of_match,
>> +.pm = &mtk_dp_pm_ops,
>> +},
>> +};
>> +
>> +MODULE_AUTHOR("Jason-JH.Lin ");
>
>Hello Guillaume,
>
>I think the module author is not Jason-JH Lin.
>He is the owner of 8195 DRM.
>The owner should be Jitao Shi
>
>BRs,
>Rex
Hi Rex,
We kept the original author from the vendor tree.
I'll update for v10.
Thx,
Guillaume.
>> +MODULE_AUTHOR("Markus Schneider-Pargmann ");
>> +MODULE_DESCRIPTION("MediaTek DisplayPort Driver");
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dp_reg.h
>> b/drivers/gpu/drm/mediatek/mtk_dp_reg.h
>> new file mode 100644
>> index ..c446eef18169
>> --- /dev/null
>> +++ b/drivers/gpu/drm/mediatek/mtk_dp_reg.h
>> @@ -0,0 +1,568 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) 2019 MediaTek Inc.
>> + * Copyright (c) 2021 BayLibre
>> + */
>> +#ifndef _MTK_DP_REG_H_
>> +#define _MTK_DP_REG_H_
>> +
>> +#define MTK_DP_SIP_CONTROL_AARCH32 (BIT(0) | BIT(1) | BIT(5) |
>> BIT(8) | BIT(10) | BIT(25) | BIT(31))
>> +#define MTK_DP_SIP_ATF_VIDEO_UNMUTE (BIT(5))
>> +#define MTK_DP_SIP_ATF_EDP_VIDEO_UNMUTE (BIT(0) | BIT(5))
>> +
>> +#define DP_PHY_GLB_BIAS_GEN_00 0
>> +#define RG_XTP_GLB_BIAS_INTR_CTRL GENMASK(20, 16)
>> +
>> +#define DP_PHY_GLB_DPAUX_TX (BIT(3))
>> +#define RG_CKM_PT0_CKTX_IMPSEL GENMASK(23, 20)
>> +
>> +#define DP_PHY_LANE_TX_0 (BIT(2) | BIT(8))
>> +#define RG_XTP_LN0_TX_IMPSEL_PMOS GENMASK(15, 12)
>> +#define RG_XTP_LN0_TX_IMPSEL_NMOS GENMASK(19, 16)
>> +
>> +#define DP_PHY_LANE_TX_1 (BIT(2) | BIT(9))
>> +#define RG_XTP_LN1_TX_IMPSEL_PMOS GENMASK(15, 12)
>> +#define RG_XTP_LN1_
Re: [PATCH 02/11] drm: bridge: samsung-dsim: Handle platform init via driver_data
On 08.04.2022 18:20, Jagan Teki wrote:
> In order to make a common Samsung DSIM bridge driver some platform specific
> glue code needs to maintain separately as it is hard to maintain platform
> specific glue and conventional component_ops on the drm bridge drivers side.
>
> This patch is trying to support that glue code initialization and invocation
> in the form of platform_init flag in driver_data.
>
> So, the platforms which enable platform_init flags will handle all platform
> specific initialization via samsung_dsim_plat_probe.
>
> The Platform probe is responsible to
> - initialize samsung_dsim_plat_data and install hooks
> - initialize component_ops
> - preserve samsung_dsim structure pointer
>
> v1:
> * use platform_init instead of exynos_specific
> * handle component_ops in glue code
>
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 20
> include/drm/bridge/samsung-dsim.h | 1 +
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index ee5d7e5518a6..0e6a5d1c7e4e 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -370,6 +370,7 @@ static const struct samsung_dsim_driver_data
> exynos3_dsi_driver_data = {
> .wait_for_reset = 1,
> .num_bits_resol = 11,
> .reg_values = reg_values,
> + .platform_init = true,
> };
>
> static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
> @@ -382,6 +383,7 @@ static const struct samsung_dsim_driver_data
> exynos4_dsi_driver_data = {
> .wait_for_reset = 1,
> .num_bits_resol = 11,
> .reg_values = reg_values,
> + .platform_init = true,
> };
>
> static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
> @@ -392,6 +394,7 @@ static const struct samsung_dsim_driver_data
> exynos5_dsi_driver_data = {
> .wait_for_reset = 1,
> .num_bits_resol = 11,
> .reg_values = reg_values,
> + .platform_init = true,
> };
>
> static const struct samsung_dsim_driver_data exynos5433_dsi_driver_data = {
> @@ -403,6 +406,7 @@ static const struct samsung_dsim_driver_data
> exynos5433_dsi_driver_data = {
> .wait_for_reset = 0,
> .num_bits_resol = 12,
> .reg_values = exynos5433_reg_values,
> + .platform_init = true,
> };
>
> static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
> @@ -414,6 +418,7 @@ static const struct samsung_dsim_driver_data
> exynos5422_dsi_driver_data = {
> .wait_for_reset = 1,
> .num_bits_resol = 12,
> .reg_values = exynos5422_reg_values,
> + .platform_init = true,
> };
>
> static const struct of_device_id samsung_dsim_of_match[] = {
> @@ -1565,12 +1570,16 @@ static int samsung_dsim_probe(struct platform_device
> *pdev)
> dsi->bridge.of_node = dev->of_node;
> dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
>
> - dsi->plat_data = samsung_dsim_plat_probe(dsi);
> - if (IS_ERR(dsi->plat_data)) {
> + if (dsi->driver_data->platform_init) {
> + dsi->plat_data = samsung_dsim_plat_probe(dsi);
> ret = PTR_ERR(dsi->plat_data);
ret = IS_ERR(dsi->plat_data) ? PTR_ERR(dsi->plat_data) : 0;
otherwise it always fails.
> - goto err_disable_runtime;
> + } else {
> + ret = mipi_dsi_host_register(&dsi->dsi_host);
> }
>
> + if (ret)
> + goto err_disable_runtime;
> +
> return 0;
>
> err_disable_runtime:
> @@ -1585,7 +1594,10 @@ static int samsung_dsim_remove(struct platform_device
> *pdev)
>
> pm_runtime_disable(&pdev->dev);
>
> - samsung_dsim_plat_remove(dsi);
> + if (dsi->driver_data->platform_init)
> + samsung_dsim_plat_remove(dsi);
> + else
> + mipi_dsi_host_unregister(&dsi->dsi_host);
>
> return 0;
> }
> diff --git a/include/drm/bridge/samsung-dsim.h
> b/include/drm/bridge/samsung-dsim.h
> index 59a43f9c4477..eca7eacb5910 100644
> --- a/include/drm/bridge/samsung-dsim.h
> +++ b/include/drm/bridge/samsung-dsim.h
> @@ -39,6 +39,7 @@ struct samsung_dsim_driver_data {
> unsigned int wait_for_reset;
> unsigned int num_bits_resol;
> const unsigned int *reg_values;
> + bool platform_init;
> };
>
> struct samsung_dsim_host_ops {
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH 04/10] drm/sun4i: Allow building the driver on RISC-V
Hi Samuel,
I love your patch! Yet something to improve:
[auto build test ERROR on sunxi/sunxi/for-next]
[also build test ERROR on drm/drm-next linus/master v5.18-rc2 next-20220412]
[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]
url:
https://github.com/intel-lab-lkp/linux/commits/Samuel-Holland/drm-sun4i-Allwinner-D1-Display-Engine-2-0-Support/20220411-123701
base: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
sunxi/for-next
config: hexagon-allyesconfig
(https://download.01.org/0day-ci/archive/20220412/202204121758.qeuxjkuh-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
c6e83f560f06cdfe8aa47b248d8bdc58f947274b)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/829dac8ee2cbb6d1b7bda1c513cc2ad1939fca53
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Samuel-Holland/drm-sun4i-Allwinner-D1-Display-Engine-2-0-Support/20220411-123701
git checkout 829dac8ee2cbb6d1b7bda1c513cc2ad1939fca53
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=hexagon SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c:59:3: error: implicit declaration of
>> function 'readsb' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
readsb(hdmi->base + hdmi->variant->ddc_fifo_reg, buf, len);
^
drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c:59:3: note: did you mean 'readb'?
arch/hexagon/include/asm/io.h:83:18: note: 'readb' declared here
static inline u8 readb(const volatile void __iomem *addr)
^
>> drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c:61:3: error: implicit declaration of
>> function 'writesb' is invalid in C99
>> [-Werror,-Wimplicit-function-declaration]
writesb(hdmi->base + hdmi->variant->ddc_fifo_reg, buf, len);
^
drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c:61:3: note: did you mean 'writeb'?
arch/hexagon/include/asm/io.h:122:20: note: 'writeb' declared here
static inline void writeb(u8 data, volatile void __iomem *addr)
^
2 errors generated.
vim +/readsb +59 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
f0a3dd33ba685b Jonathan Liu 2017-07-02 24
f0a3dd33ba685b Jonathan Liu 2017-07-02 25 static int fifo_transfer(struct
sun4i_hdmi *hdmi, u8 *buf, int len, bool read)
f0a3dd33ba685b Jonathan Liu 2017-07-02 26 {
f0a3dd33ba685b Jonathan Liu 2017-07-02 27 /*
f0a3dd33ba685b Jonathan Liu 2017-07-02 28 * 1 byte takes 9 clock cycles
(8 bits + 1 ACK) = 90 us for 100 kHz
f0a3dd33ba685b Jonathan Liu 2017-07-02 29 * clock. As clock rate is
fixed, just round it up to 100 us.
f0a3dd33ba685b Jonathan Liu 2017-07-02 30 */
f0a3dd33ba685b Jonathan Liu 2017-07-02 31 const unsigned long
byte_time_ns = 100;
f0a3dd33ba685b Jonathan Liu 2017-07-02 32 const u32 mask =
SUN4I_HDMI_DDC_INT_STATUS_ERROR_MASK |
f0a3dd33ba685b Jonathan Liu 2017-07-02 33
SUN4I_HDMI_DDC_INT_STATUS_FIFO_REQUEST |
f0a3dd33ba685b Jonathan Liu 2017-07-02 34
SUN4I_HDMI_DDC_INT_STATUS_TRANSFER_COMPLETE;
f0a3dd33ba685b Jonathan Liu 2017-07-02 35 u32 reg;
939d749ad6649c Chen-Yu Tsai 2017-10-10 36 /*
939d749ad6649c Chen-Yu Tsai 2017-10-10 37 * If threshold is inclusive,
then the FIFO may only have
939d749ad6649c Chen-Yu Tsai 2017-10-10 38 * RX_THRESHOLD number of
bytes, instead of RX_THRESHOLD + 1.
939d749ad6649c Chen-Yu Tsai 2017-10-10 39 */
939d749ad6649c Chen-Yu Tsai 2017-10-10 40 int read_len = RX_THRESHOLD +
939d749ad6649c Chen-Yu Tsai 2017-10-10 41
(hdmi->variant->ddc_fifo_thres_incl ? 0 : 1);
f0a3dd33ba685b Jonathan Liu 2017-07-02 42
939d749ad6649c Chen-Yu Tsai 2017-10-10 43 /*
939d749ad6649c Chen-Yu Tsai 2017-10-10 44 * Limit transfer length by
FIFO threshold or FIFO size.
939d749ad6649c Chen-Yu Tsai 2017-10-10 45 * For TX the threshold is for
an empty FIFO.
939d749ad6649c Chen-Yu Tsai 2017-10-10 46 */
939d749ad6649c Chen-Yu Tsai 2017-10-10 47 len = min_t(int, len, read ?
read_len : SUN4I_HDMI_DDC_FIFO_SIZE);
f0a3dd33ba685b Jonathan Liu 2017-07-02 48
f0a3dd33ba685b Jonathan Liu 2017-07-02 49 /* Wait until error, FIFO
Re: [PATCH v2 1/7] dt-bindings: display: renesas,du: Document r9a07g044l bindings
Hi Biju,
On Wed, Mar 16, 2022 at 2:11 PM Biju Das wrote:
> Extend the Renesas DU display bindings to support the r9a07g044l
> DU module found on RZ/G2L LCDC.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/display/renesas,du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> @@ -40,6 +40,7 @@ properties:
>- renesas,du-r8a77990 # for R-Car E3 compatible DU
>- renesas,du-r8a77995 # for R-Car D3 compatible DU
>- renesas,du-r8a779a0 # for R-Car V3U compatible DU
> + - renesas,du-r9a07g044l # for RZ/G2L compatible DU
"renesas,du-r9a07g044"? Both RZ/G2L and RZ/G2LC have an LCDC.
I believe the lack of parallel data support on RZ/G2LC is just a
limitation of the package?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
On Tue, 29 Mar 2022 07:41, Rex-BC Chen wrote:
>Hello Guillaume,
>
>Thanks for your patch.
>I add some comments below:
>
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> From: Markus Schneider-Pargmann
>>
>> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>>
>> It supports the mt8195, the embedded DisplayPort units. It offers
>> DisplayPort 1.4 with up to 4 lanes.
>>
>> The driver shares its iomap range with the mtk-dp-phy driver using
>> the regmap/syscon facility.
>>
>> This driver is based on an initial version by
>> Jason-JH.Lin .
>>
>> Signed-off-by: Markus Schneider-Pargmann
>> Signed-off-by: Guillaume Ranquet
>> Reported-by: kernel test robot
>> ---
>> drivers/gpu/drm/mediatek/Kconfig |8 +
>> drivers/gpu/drm/mediatek/Makefile |2 +
>> drivers/gpu/drm/mediatek/mtk_dp.c | 2221
>>
>> drivers/gpu/drm/mediatek/mtk_dp_reg.h | 568 ++
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 +
>> drivers/gpu/drm/mediatek/mtk_drm_drv.h |1 +
>> 6 files changed, 2801 insertions(+)
>> create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
>> create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
>>
>> diff --git a/drivers/gpu/drm/mediatek/Kconfig
>> b/drivers/gpu/drm/mediatek/Kconfig
>> index 2976d21e9a34..03ffa9b896c3 100644
>> --- a/drivers/gpu/drm/mediatek/Kconfig
>> +++ b/drivers/gpu/drm/mediatek/Kconfig
>> @@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
>> select PHY_MTK_HDMI
>> help
>>DRM/KMS HDMI driver for Mediatek SoCs
>> +
>> +config MTK_DPTX_SUPPORT
>> +tristate "DRM DPTX Support for Mediatek SoCs"
>> +depends on DRM_MEDIATEK
>> +select PHY_MTK_DP
>> +select DRM_DP_HELPER
>> +help
>> + DRM/KMS Display Port driver for Mediatek SoCs.
>> diff --git a/drivers/gpu/drm/mediatek/Makefile
>> b/drivers/gpu/drm/mediatek/Makefile
>> index 29098d7c8307..d86a6406055e 100644
>> --- a/drivers/gpu/drm/mediatek/Makefile
>> +++ b/drivers/gpu/drm/mediatek/Makefile
>> @@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
>>mtk_hdmi_ddc.o
>>
>> obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
>> +
>> +obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
>> b/drivers/gpu/drm/mediatek/mtk_dp.c
>> new file mode 100644
>> index ..7cd8459cf719
>> --- /dev/null
>> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
>> @@ -0,0 +1,2221 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2019 MediaTek Inc.
>> + * Copyright (c) 2021 BayLibre
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "mtk_dp_reg.h"
>> +
>> +#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
>> +#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
>> +
>> +//TODO: platform/device data or dts?
>> +#define MTK_DP_MAX_LANES 4
>> +#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3
>> +
>> +#define MTK_DP_TBC_BUF_READ_START_ADDR 0x08
>> +
>> +#define MTK_DP_TRAIN_RETRY_LIMIT 8
>> +#define MTK_DP_TRAIN_MAX_ITERATIONS 5
>> +
>> +#define MTK_DP_AUX_WRITE_READ_WAIT_TIME_US 20
>> +
>> +#define MTK_DP_DP_VERSION_11 0x11
>> +
>> +enum mtk_dp_state {
>> +MTK_DP_STATE_INITIAL,
>> +MTK_DP_STATE_IDLE,
>> +MTK_DP_STATE_PREPARE,
>> +MTK_DP_STATE_NORMAL,
>> +};
>> +
>>
>
>snif...
>
>> +
>> +static int mtk_dp_msa_bypass_disable(struct mtk_dp *mtk_dp)
>> +{
>> +const u16 bits_to_set =
>> +BIT(HTOTAL_SEL_DP_ENC0_P0_SHIFT) |
>> +BIT(VTOTAL_SEL_DP_ENC0_P0_SHIFT) |
>> +BIT(HSTART_SEL_DP_ENC0_P0_SHIFT) |
>> +BIT(VSTART_SEL_DP_ENC0_P0_SHIFT) |
>> +BIT(HWIDTH_SEL_DP_ENC0_P0_SHIFT) |
>> +BIT(VHEIGHT_SEL_DP_ENC0_P0_SHIFT) |
>> +BIT(HSP_SEL_DP_ENC0_P0_SHIFT) |
>> BIT(HSW_SEL_DP_ENC0_P0_SHIFT) |
>> +BIT(VSP_SEL_DP_ENC0_P0_SHIFT) |
>> BIT(VSW_SEL_DP_ENC0_P0_SHIFT);
>> +return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3030,
>> bits_to_set,
>> + bits_to_set);
>> +}
>> +
>> +#define MTK_UPD_BITS_OR_OUT(mtk_dp, offset, val, mask, ret, label) \
>> +do {\
>> +ret = mtk_dp_update_bits(mtk_dp, offset, val, mask); \
>> +if (ret) \
>> +goto label; \
>> +} while (0)
>> +
>> +static int mtk_dp_set_msa(struct mtk_dp *mtk_dp)
>> +{
>> +int ret;
>> +struct mtk_dp_timings *timings = &mtk_dp->info.timings;
>> +
>> +MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC0_P0_3010, timings-
>> >htotal,
>> +HTOTAL_SW_DP_ENC0_P0_MASK, ret, out);
>> +MTK_UPD_BITS_OR_OUT(mtk_dp, MTK_DP_ENC0_P0_3018,
>> +timings->vm.hsync_len + timings-
>> >vm.hback_p
Re: [PATCH v9 03/22] dt-bindings: mediatek,dp_phy: Add Display Port PHY binding
On Wed, 30 Mar 2022 00:58, Rob Herring wrote:
>On Mon, Mar 28, 2022 at 12:39:08AM +0200, Guillaume Ranquet wrote:
>> This phy controller is embedded in the Display Port Controller on mt8195
>> SoCs.
>
>Sorry, but I think you need to go back to what you had in v8. While yes,
>the phy and controller IP often do change independently, this h/w looks
>pretty interwined.
Understood, I'll revert back to v8.
>
>You could make the controller a phy provider to itself if you wanted.
Not sure I follow, could you point me to an example?
Thx,
Guillaume.
>
>>
>> Signed-off-by: Guillaume Ranquet
>> ---
>> .../bindings/phy/mediatek,dp-phy.yaml | 43 +++
>> 1 file changed, 43 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/mediatek,dp-phy.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/phy/mediatek,dp-phy.yaml
>> b/Documentation/devicetree/bindings/phy/mediatek,dp-phy.yaml
>> new file mode 100644
>> index ..1f5ffca4e140
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/mediatek,dp-phy.yaml
>> @@ -0,0 +1,43 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (c) 2022 MediaTek
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/mediatek,dp-phy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: MediaTek Display Port PHY
>> +
>> +maintainers:
>> + - CK Hu
>> + - Jitao shi
>> +
>> +description: |
>> + Device tree bindings for the Mediatek (embedded) Display Port PHY
>> + present on some Mediatek SoCs.
>> +
>> +properties:
>> + compatible:
>> +enum:
>> + - mediatek,mt8195-dp-phy
>> +
>> + mediatek,dp-syscon:
>> +$ref: /schemas/types.yaml#/definitions/phandle
>> +description: Phandle to the Display Port node.
>> +
>> + "#phy-cells":
>> +const: 0
>> +
>> +required:
>> + - compatible
>> + - mediatek,dp-syscon
>> + - "#phy-cells"
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +dp_phy: dp-phy {
>> + compatible = "mediatek,mt8195-dp-phy";
>> + mediatek,dp-syscon = <&dp_tx>;
>> + #phy-cells = <0>;
>> +};
>> --
>> 2.34.1
>>
>>
Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
> Wiadomość napisana przez Lucas Stach w dniu > 12.04.2022, o godz. 10:10: > > This could be both a Mesa/Panfrost or application issue. The > application is supposed to try to allocate with a arbitrary chosen > format and the valid modifiers queried from the plane it wants to put > the surface on. However I'm not sure if all applications have a > fallback path in place to try another format swizzling if the surface > allocation fails. This is good remark imho. I think we have this fallback. I'll try verify this. Generalising a bit - I think we my consider following cases: a\ format is correctly negotiated and signalled to consumer/provider but we don't see expected results (=correct screen seen by user) b\ format was correctly negotiated but consumer/provider failed using signalled format (i.e. due bug in implementation) c\ consumer or provider advertising - in reality unsupported format (false positive) - so negotiation resulting with signalling efficiently non-working format Sascha says (in today's email): "Here is your problem. The cluster windows only allow AFBC compressed formats. AR24 is supported by the cluster windows, but not by the GPU, see panfrost_afbc_format() in Mesa:" I'm reading this as case c\ as Sascha said "negotiated format is not supported by GPU" but this format was negotiated. ..but for sure Sascha is much better than me here in subject - so i'm might be wrong here > Now there are two possible failures here: > > 1. The application feeds a wrong modifier list to the GBM > implementation, as it may have queried another plane in the assumption > that supported modifiers are uniform across all planes. > This will be cardinal design error. (keeping in mind we have multiple producers (GPU/video decoder) and multiple consumers (base & overlay DRM planes) > 2. The GBM implementation (Panfrost) actually allocates a surface > instead of failing the allocation, even if it does not support any > combination of the provided format and modifier list. > Testing Sacha patch (see today's email from Sascha) i'm getting Qt: EGL Error : Could not create the egl surface: error = 0x3009 i'm reading this as: Qt tries allocate EGL surface and EGL returns error. or i'm wrong?
Re: [PATCH] dma-buf-map: remove renamed header file
On 2022-04-11 15:44, Karol Herbst wrote:
> commit 7938f4218168 ("dma-buf-map: Rename to iosys-map") already renamed
> this file, but it got brought back by a merge.
>
> Delete it for real this time.
>
> Fixes: 30424ebae8df ("Merge tag 'drm-intel-gt-next-2022-02-17' of
> git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next")
> Cc: Rodrigo Vivi
> Cc: Lucas De Marchi
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Karol Herbst
> ---
> include/linux/dma-buf-map.h | 266
> 1 file changed, 266 deletions(-)
> delete mode 100644 include/linux/dma-buf-map.h
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
RE: [PATCH v2 1/7] dt-bindings: display: renesas,du: Document r9a07g044l bindings
Hi Geert, Thanks for the feedback > Subject: Re: [PATCH v2 1/7] dt-bindings: display: renesas,du: Document > r9a07g044l bindings > > Hi Biju, > > On Wed, Mar 16, 2022 at 2:11 PM Biju Das > wrote: > > Extend the Renesas DU display bindings to support the r9a07g044l DU > > module found on RZ/G2L LCDC. > > > > Signed-off-by: Biju Das > > Thanks for your patch! > > > --- a/Documentation/devicetree/bindings/display/renesas,du.yaml > > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml > > @@ -40,6 +40,7 @@ properties: > >- renesas,du-r8a77990 # for R-Car E3 compatible DU > >- renesas,du-r8a77995 # for R-Car D3 compatible DU > >- renesas,du-r8a779a0 # for R-Car V3U compatible DU > > + - renesas,du-r9a07g044l # for RZ/G2L compatible DU > > "renesas,du-r9a07g044"? Both RZ/G2L and RZ/G2LC have an LCDC. > I believe the lack of parallel data support on RZ/G2LC is just a > limitation of the package? From the block diagram 24-bit video data from DU is connected to both DSI and parallel interface. However, SoC packaging wise RZ/G2LC supports only DSI interface. RZ/G2L supports both DSI and parallel interface RZ/G2LC supports only DSI interface OK, we could use "renesas,du-r9a07g044" as well. Regards, Biju
Re: [PATCH v2 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote: > On 4/12/22 09:23, Geert Uytterhoeven wrote: > > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas > > wrote: ... > >> - ssd130x->device_info = device_get_match_data(dev); > >> + > >> + variant = (enum ssd130x_variants)device_get_match_data(dev); > > > > (uintptr_t), to avoid a cast from pointer to integer of different > > size warning. > > > > Indeed. The kernel test robot reported the same. Not only because of this, but also with the non-NULL pointers I prefer the old style without ugly castings. Instead, you may export the array (in the driver's namespace) and use &info[ID] pointer for the specific device info. -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
On Tue, Apr 12, 2022 at 02:21:08PM +0300, Andy Shevchenko wrote: > On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote: > > On 4/12/22 09:23, Geert Uytterhoeven wrote: > > > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas > > > wrote: ... > > >> - ssd130x->device_info = device_get_match_data(dev); > > >> + > > >> + variant = (enum ssd130x_variants)device_get_match_data(dev); > > > > > > (uintptr_t), to avoid a cast from pointer to integer of different > > > size warning. > > > > > > > Indeed. The kernel test robot reported the same. > > Not only because of this, but also with the non-NULL pointers I prefer the old > style without ugly castings. > > Instead, you may export the array (in the driver's namespace) and use > &info[ID] pointer for the specific device info. Note that device_get_match_data() has no clue if the data is absent or data == (void *)0. -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 1/5] dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings
On Mon, Apr 11, 2022 at 11:12:39PM +0200, Javier Martinez Canillas wrote: > The current compatible strings for SSD130x I2C controllers contain both an > "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver > and also that are for devices that can be accessed over an I2C bus. > > But a DT is supposed to describe the hardware and not Linux implementation > details. So let's deprecate those compatible strings and add new ones that > only contain the vendor and device name, without any of these suffixes. > > These will just describe the device and can be matched by both I2C and SPI > DRM drivers. > > Signed-off-by: Javier Martinez Canillas > Acked-by: Mark Brown > --- > > Changes in v2: > - Drop the -i2c suffixes from the compatible strings too (Geert Uytterhoeven). > > .../bindings/display/solomon,ssd1307fb.yaml | 37 --- > 1 file changed, 24 insertions(+), 13 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > index ade61d502edd..6b9d0c72739a 100644 > --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > @@ -12,12 +12,23 @@ maintainers: > > properties: >compatible: > -enum: > - - sinowealth,sh1106-i2c > - - solomon,ssd1305fb-i2c > - - solomon,ssd1306fb-i2c > - - solomon,ssd1307fb-i2c > - - solomon,ssd1309fb-i2c > +oneOf: > + # Deprecated compatible strings > + - items: > + - enum: > + - sinowealth,sh1106-i2c > + - solomon,ssd1305fb-i2c > + - solomon,ssd1306fb-i2c > + - solomon,ssd1307fb-i2c > + - solomon,ssd1309fb-i2c > +deprecated: true > + - items: > + - enum: > + - sinowealth,sh1106 > + - solomon,ssd1305 > + - solomon,ssd1306 > + - solomon,ssd1307 > + - solomon,ssd1309 > >reg: > maxItems: 1 > @@ -136,7 +147,7 @@ allOf: >properties: > compatible: >contains: > -const: sinowealth,sh1106-i2c > +const: sinowealth,sh1106 I think we should have both in the condition here, but it looks good otherwise. Maxime
Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
On Tue, 12 Apr 2022 at 11:14, Piotr Oniszczuk wrote: > > Wiadomość napisana przez Lucas Stach w dniu > > 12.04.2022, o godz. 10:10: > > 1. The application feeds a wrong modifier list to the GBM > > implementation, as it may have queried another plane in the assumption > > that supported modifiers are uniform across all planes. > > This will be cardinal design error. > (keeping in mind we have multiple producers (GPU/video decoder) and multiple > consumers (base & overlay DRM planes) > > > > 2. The GBM implementation (Panfrost) actually allocates a surface > > instead of failing the allocation, even if it does not support any > > combination of the provided format and modifier list. > > Testing Sacha patch (see today's email from Sascha) i'm getting > > Qt: EGL Error : Could not create the egl surface: error = 0x3009 > > i'm reading this as: Qt tries allocate EGL surface and EGL returns error. > or i'm wrong? Correct, that's EGL_BAD_MATCH. There are very few ways that can happen; by far the most likely is that Qt has chosen an EGLConfig which does not correctly correspond to the format. (If it was an impossible format/modifier combination, then this would be already caught when allocating the gbm_surface.) Either way, it seems quite clear that the VOP2 driver is totally fine here, and that you have a Qt (likely) or Mesa (tbh less likely) issue to debug to get the app working. Cheers, Daniel
Re: [PATCH v2 1/5] dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings
On Tue, Apr 12, 2022 at 5:12 AM Javier Martinez Canillas wrote: > > The current compatible strings for SSD130x I2C controllers contain both an > "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver > and also that are for devices that can be accessed over an I2C bus. > > But a DT is supposed to describe the hardware and not Linux implementation > details. So let's deprecate those compatible strings and add new ones that > only contain the vendor and device name, without any of these suffixes. > > These will just describe the device and can be matched by both I2C and SPI > DRM drivers. > > Signed-off-by: Javier Martinez Canillas > Acked-by: Mark Brown > --- > > Changes in v2: > - Drop the -i2c suffixes from the compatible strings too (Geert Uytterhoeven). > > .../bindings/display/solomon,ssd1307fb.yaml | 37 --- > 1 file changed, 24 insertions(+), 13 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > index ade61d502edd..6b9d0c72739a 100644 > --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > @@ -12,12 +12,23 @@ maintainers: > > properties: >compatible: > -enum: > - - sinowealth,sh1106-i2c > - - solomon,ssd1305fb-i2c > - - solomon,ssd1306fb-i2c > - - solomon,ssd1307fb-i2c > - - solomon,ssd1309fb-i2c > +oneOf: > + # Deprecated compatible strings > + - items: > + - enum: > + - sinowealth,sh1106-i2c I think you can just drop this one, since it was just merged and isn't part of any release yet. It's not even in -rc. ChenYu
Re: [PATCH] drm/ttm: stop passing NULL fence in ttm_bo_move_sync_cleanup
On 11/04/2022 13:39, Christian König wrote:
Am 11.04.22 um 10:56 schrieb Matthew Auld:
If we hit the sync case, like when skipping clearing for kernel internal
objects, or when falling back to cpu clearing, like in i915, we end up
trying to add a NULL fence, but with some recent changes in this area
this now just results in NULL deref in dma_resv_add_fence:
<1>[ 5.466383] BUG: kernel NULL pointer dereference, address:
0008
<1>[ 5.466384] #PF: supervisor read access in kernel mode
<1>[ 5.466385] #PF: error_code(0x) - not-present page
<6>[ 5.466386] PGD 0 P4D 0
<4>[ 5.466387] Oops: [#1] PREEMPT SMP NOPTI
<4>[ 5.466389] CPU: 5 PID: 267 Comm: modprobe Not tainted
5.18.0-rc2-CI-CI_DRM_11481+ #1
<4>[ 5.466391] RIP: 0010:dma_resv_add_fence+0x63/0x260
<4>[ 5.466395] Code: 38 85 c0 0f 84 df 01 00 00 0f 88 e8 01 00 00
83 c0 01 0f 88 df 01 00 00 8b 05 35 89 10 01 49 8d 5e 68 85 c0 0f 85
45 01 00 00 <48> 8b 45 08 48 3d c0 a5 0a 82 0f 84 5c 01 00 00 48 3d 60
a5 0a 82
<4>[ 5.466396] RSP: 0018:c9e974f8 EFLAGS: 00010202
<4>[ 5.466397] RAX: 0001 RBX: 888123e88b28 RCX:
<4>[ 5.466398] RDX: 0001 RSI: 822e4f50 RDI:
8233f087
<4>[ 5.466399] RBP: R08: 8881313dbc80 R09:
0001
<4>[ 5.466399] R10: 0001 R11: da354294 R12:
<4>[ 5.466400] R13: 88810927dc58 R14: 888123e88ac0 R15:
88810a88d600
<4>[ 5.466401] FS: 7f5fa1193540()
GS:88845d88() knlGS:
<4>[ 5.466402] CS: 0010 DS: ES: CR0: 80050033
<4>[ 5.466402] CR2: 0008 CR3: 000106dd6003 CR4:
003706e0
<4>[ 5.466403] DR0: DR1: DR2:
<4>[ 5.466404] DR3: DR6: fffe0ff0 DR7:
0400
<4>[ 5.466404] Call Trace:
<4>[ 5.466405]
<4>[ 5.466406] ttm_bo_move_accel_cleanup+0x62/0x270 [ttm]
<4>[ 5.466411] ? i915_rsgt_from_buddy_resource+0x185/0x1e0 [i915]
<4>[ 5.466529] i915_ttm_move+0xfd/0x430 [i915]
<4>[ 5.466833] ? dma_resv_reserve_fences+0x4e/0x320
<4>[ 5.466836] ? ttm_bo_add_move_fence.constprop.20+0xf7/0x140 [ttm]
<4>[ 5.466841] ttm_bo_handle_move_mem+0xa1/0x140 [ttm]
<4>[ 5.466845] ttm_bo_validate+0xee/0x160 [ttm]
<4>[ 5.466849] __i915_ttm_get_pages+0x4f/0x210 [i915]
<4>[ 5.466976] i915_ttm_get_pages+0xad/0x140 [i915]
<4>[ 5.467094] i915_gem_object_get_pages+0x32/0xf0 [i915]
<4>[ 5.467210] __i915_gem_object_get_pages+0x89/0xa0 [i915]
<4>[ 5.467323] i915_vma_get_pages+0x114/0x1d0 [i915]
<4>[ 5.467446] i915_vma_pin_ww+0xd3/0xa90 [i915]
<4>[ 5.467570] i915_vma_pin.constprop.10+0x119/0x1b0 [i915]
<4>[ 5.467700] ? __mutex_unlock_slowpath+0x3e/0x2b0
<4>[ 5.467704] intel_alloc_initial_plane_obj.isra.6+0x1a9/0x390
[i915]
<4>[ 5.467833] intel_crtc_initial_plane_config+0x83/0x340 [i915]
In the ttm_bo_move_sync_cleanup() case it seems we only really care
about calling ttm_bo_wait_free_node(), so let's instead just call that
directly.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Cc: Lucas De Marchi
Cc: Nirmoy Das
Ideally we wouldn't export that to drivers, but that's a different problem.
Reviewed-by: Christian König
Thanks. Would you be able to merge this?
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 +++
include/drm/ttm/ttm_bo_driver.h | 11 +++
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index bc5190340b9c..1cbfb00c1d65 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -572,6 +572,21 @@ int ttm_bo_move_accel_cleanup(struct
ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
+void ttm_bo_move_sync_cleanup(struct ttm_buffer_object *bo,
+ struct ttm_resource *new_mem)
+{
+ struct ttm_device *bdev = bo->bdev;
+ struct ttm_resource_manager *man = ttm_manager_type(bdev,
new_mem->mem_type);
+ int ret;
+
+ ret = ttm_bo_wait_free_node(bo, man->use_tt);
+ if (WARN_ON(ret))
+ return;
+
+ ttm_bo_assign_mem(bo, new_mem);
+}
+EXPORT_SYMBOL(ttm_bo_move_sync_cleanup);
+
/**
* ttm_bo_pipeline_gutting - purge the contents of a bo
* @bo: The buffer object
diff --git a/include/drm/ttm/ttm_bo_driver.h
b/include/drm/ttm/ttm_bo_driver.h
index 059a595e14e5..897b88f0bd59 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -245,7 +245,7 @@ int ttm_bo_move_accel_cleanup(struct
ttm_buffer_object *bo,
struct ttm_resource *new_mem);
/**
- * ttm_bo_move_accel_cleanup.
+ * ttm_bo_move_sync_cleanup.
*
* @bo: A pointer to a struct ttm_buffer_object.
* @new_mem: struct ttm_resource indicating where to move.
@@ -253,13 +253
Re: [PATCH v6 0/6] drm: exynos: dsi: Convert drm bridge
Dear All,
On 07.04.2022 13:24, Marek Szyprowski wrote:
> On 31.03.2022 16:22, Robert Foss wrote:
>> On Fri, 25 Mar 2022 at 17:04, Adam Ford wrote:
>>> On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski
>>> wrote:
On 03.03.2022 17:36, Jagan Teki wrote:
> Updated series about drm bridge conversion of exynos dsi.
>
> Previous version can be accessible, here [1].
>
> Patch 1: tc358764 panel_bridge API
>
> Patch 2: connector reset
>
> Patch 3: bridge attach in MIC
>
> Patch 4: panel_bridge API
>
> Patch 5: bridge conversion
>
> Patch 6: atomic functions
>
>
>
> Any inputs?
I'm really sorry for the delay on my side. I was really busy with
other
things and I was not able to check the display of the boards with
remote
access.
Finally, this patchset works properly on all my Exynos-based test
systems:
1. Exynos4210 Trats with Samsung s6e8aa0 DSI panel
2. Exynos4412 Trats2 with Samsung s6e8aa0 DSI panel
3. Exynos5250 Arndale with TC358764 DSI-LVDS bridge and LVDS panel
4. Exynos5433 TM2e with Samsung s6e3hf2 DSI panel and internal Exynos
MIC bridge
I will post my acked-by and tested-by tags for each patch.
>>> Thank you so much! I think a lot of people will celebrate when this
>>> gets approved and merged. ;-)
>>>
>>>
>> Applied to drm-misc-next.
>
>
> Thanks for merging this. Today (once the patches landed in linux-next)
> I found that there is one more issue left to fix.
>
> On the Exynos4210-based Trats board I get the following error:
>
> # ./modetest -c -Mexynos
> could not get connector 56: No such file or directory
> Segmentation fault
>
> #
>
> Surprisingly, all other boards, even Exynos4412-based Trats2 with
> exactly the same DSI controller and panel works fine:
>
> # ./modetest -c -Mexynos
> Connectors:
> id encoder status name size (mm) modes encoders
> 71 70 connected DSI-1 58x103 1 70
This is related to the asynchronous DSI driver registration and DSI
device probe.
If the DSI driver has been registered before the DRM component device
bind, everything is fine: the DRM connector is created by
panel_bridge_attach() and then that connector is registered to userspace
by the drm_modeset_register_all() in the last steps of initializing the
compound DRM device.
However, when DSI driver is not yet registered during the DRM component
bind, the DRM device finishes registration without any connector
('exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes' message).
Then, when DSI driver gets registered, the connector is created by
panel_brige_attach(), but there is no code, which would call
drm_connector_register() to make it available for userspace.
Exactly the same issue has been earlier fixed by the commit deee3284cba3
("drm/exynos/dsi: register connector if it is created after drm bind").
The following patch fixes this with the current code:
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index ff1c37b2e6e5..2165f38989f1 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -86,6 +86,9 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
if (connector->funcs->reset)
connector->funcs->reset(connector);
+ if (bridge->dev->registered)
+ drm_connector_register(connector);
+
return 0;
}
If this is okay, I will send it as a proper patch, tagged as a fix for
934aef885f9d ("drm: bridge: panel: Reset the connector state pointer").
> modes:
> name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
> 720x1280 60 720 725 730 735 1280 1293 1295 1296 57153 flags: ; type:
> preferred, driver
> props:
> 1 EDID:
> flags: immutable blob
> blobs:
>
> value:
> 2 DPMS:
> flags: enum
> enums: On=0 Standby=1 Suspend=2 Off=3
> value: 0
> 5 link-status:
> flags: enum
> enums: Good=0 Bad=1
> value: 0
> 6 non-desktop:
> flags: immutable range
> values: 0 1
> value: 0
> 4 TILE:
> flags: immutable blob
> blobs:
>
> value:
> 20 CRTC_ID:
> flags: object
> value: 54
> 73 0 connected HDMI-A-1 0x0 0 72
> props:
> 1 EDID:
> flags: immutable blob
> blobs:
>
> value:
> 2 DPMS:
> flags: enum
> enums: On=0 Standby=1 Suspend=2 Off=3
> value: 0
> 5 link-status:
> flags: enum
> enums: Good=0 Bad=1
> value: 0
> 6 non-deskt
Re: [PATCH v2 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
Hello Andy, Thanks for your feedback. On 4/12/22 13:21, Andy Shevchenko wrote: > On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote: >> On 4/12/22 09:23, Geert Uytterhoeven wrote: >>> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas >>> wrote: > > ... > - ssd130x->device_info = device_get_match_data(dev); + + variant = (enum ssd130x_variants)device_get_match_data(dev); >>> >>> (uintptr_t), to avoid a cast from pointer to integer of different >>> size warning. >>> >> >> Indeed. The kernel test robot reported the same. > > Not only because of this, but also with the non-NULL pointers I prefer the old > style without ugly castings. > > Instead, you may export the array (in the driver's namespace) and use > &info[ID] pointer for the specific device info. > That's a great idea! I'll do that in v3. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v2 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
On 4/12/22 13:22, Andy Shevchenko wrote: > On Tue, Apr 12, 2022 at 02:21:08PM +0300, Andy Shevchenko wrote: >> On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote: >>> On 4/12/22 09:23, Geert Uytterhoeven wrote: On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas wrote: > > ... > > - ssd130x->device_info = device_get_match_data(dev); > + > + variant = (enum ssd130x_variants)device_get_match_data(dev); (uintptr_t), to avoid a cast from pointer to integer of different size warning. >>> >>> Indeed. The kernel test robot reported the same. >> >> Not only because of this, but also with the non-NULL pointers I prefer the >> old >> style without ugly castings. >> >> Instead, you may export the array (in the driver's namespace) and use >> &info[ID] pointer for the specific device info. > > Note that device_get_match_data() has no clue if the data is absent or > data == (void *)0. > Yep, we could make the enum start at 1 and check for !variant but that's something that will also be prevented by your suggestion to just use the &info[ID] instead. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v2 1/5] dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings
Hello Maxime, On 4/12/22 13:28, Maxime Ripard wrote: > On Mon, Apr 11, 2022 at 11:12:39PM +0200, Javier Martinez Canillas wrote: [snip] >> >>reg: >> maxItems: 1 >> @@ -136,7 +147,7 @@ allOf: >>properties: >> compatible: >>contains: >> -const: sinowealth,sh1106-i2c >> +const: sinowealth,sh1106 > > I think we should have both in the condition here, but it looks good > otherwise. > Right, we want to keep enforcing for the deprecated compatible strings. > Maxime > -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v2 1/5] dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings
Hello Chen-Yu, On 4/12/22 14:07, Chen-Yu Tsai wrote: > On Tue, Apr 12, 2022 at 5:12 AM Javier Martinez Canillas > wrote: [snip] > > I think you can just drop this one, since it was just merged and isn't > part of any release yet. It's not even in -rc. > I believe you are correct and we could just drop that one. > ChenYu > -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v5 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
On Mon, Apr 11, 2022 at 08:47:30PM +, Sean Paul wrote:
> From: Sean Paul
>
> This patch moves the hdcp atomic check from i915 to drm_hdcp so other
> drivers can use it. No functional changes, just cleaned up some of the
> code when moving it over.
Reviewed-by: Rodrigo Vivi
>
> Acked-by: Jani Nikula
> Acked-by: Jani Nikula
> Reviewed-by: Abhinav Kumar
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-2-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-2-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-2-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-2-s...@poorly.run
> #v4
>
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> ---
> drivers/gpu/drm/drm_hdcp.c | 71 -
> drivers/gpu/drm/i915/display/intel_atomic.c | 4 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 47 --
> drivers/gpu/drm/i915/display/intel_hdcp.h | 3 -
> include/drm/drm_hdcp.h | 3 +
> 5 files changed, 75 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index ca9b8f697202..522326b03e66 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -13,13 +13,14 @@
> #include
> #include
>
> +#include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> -#include
>
> #include "drm_internal.h"
>
> @@ -421,3 +422,71 @@ void drm_hdcp_update_content_protection(struct
> drm_connector *connector,
>dev->mode_config.content_protection_property);
> }
> EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> +
> +/**
> + * drm_hdcp_atomic_check - Helper for drivers to call during
> connector->atomic_check
> + *
> + * @state: pointer to the atomic state being checked
> + * @connector: drm_connector on which content protection state needs an
> update
> + *
> + * This function can be used by display drivers to perform an atomic check
> on the
> + * hdcp state elements. If hdcp state has changed, this function will set
> + * mode_changed on the crtc driving the connector so it can update its
> hardware
> + * to match the hdcp state.
> + */
> +void drm_hdcp_atomic_check(struct drm_connector *connector,
> +struct drm_atomic_state *state)
> +{
> + struct drm_connector_state *new_conn_state, *old_conn_state;
> + struct drm_crtc_state *new_crtc_state;
> + u64 old_hdcp, new_hdcp;
> +
> + old_conn_state = drm_atomic_get_old_connector_state(state, connector);
> + old_hdcp = old_conn_state->content_protection;
> +
> + new_conn_state = drm_atomic_get_new_connector_state(state, connector);
> + new_hdcp = new_conn_state->content_protection;
> +
> + if (!new_conn_state->crtc) {
> + /*
> + * If the connector is being disabled with CP enabled, mark it
> + * desired so it's re-enabled when the connector is brought back
> + */
> + if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
> + new_conn_state->content_protection =
> + DRM_MODE_CONTENT_PROTECTION_DESIRED;
> + return;
> + }
> +
> + new_crtc_state = drm_atomic_get_new_crtc_state(state,
> +new_conn_state->crtc);
> + /*
> + * Fix the HDCP uapi content protection state in case of modeset.
> + * FIXME: As per HDCP content protection property uapi doc, an uevent()
> + * need to be sent if there is transition from ENABLED->DESIRED.
> + */
> + if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> + new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> + new_conn_state->content_protection =
> + DRM_MODE_CONTENT_PROTECTION_DESIRED;
> +
> + /*
> + * Nothing to do if content type is unchanged and one of:
> + * - state didn't change
> + * - HDCP was activated since the last commit
> + * - attempting to set to desired while already enabled
> + */
> + if (old_hdcp == new_hdcp ||
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> + new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> + new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> + if (old_conn_state->hdcp_content_type ==
> + new_conn_state->hdcp_content_type)
> + return;
> + }
> +
> + new_crtc_state->mode_changed = true;
> +}
> +EXPORT_SYMBOL(drm_hdcp_atomic_check);
> diff --git a/drivers/gpu/dr
Re: [PATCH v5 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check
On Mon, Apr 11, 2022 at 08:47:31PM +, Sean Paul wrote:
> From: Sean Paul
>
> Instead of forcing a modeset in the hdcp atomic check, simply return
> true if the content protection value is changing and let the driver
> decide whether a modeset is required or not.
>
> Acked-by: Jani Nikula
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-3-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-3-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-3-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-3-s...@poorly.run
> #v4
>
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> ---
> drivers/gpu/drm/drm_hdcp.c | 33 +++--
> drivers/gpu/drm/i915/display/intel_atomic.c | 5 ++--
> include/drm/drm_hdcp.h | 2 +-
> 3 files changed, 27 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index 522326b03e66..dd8fa91c51d6 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -430,11 +430,14 @@ EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> * @connector: drm_connector on which content protection state needs an
> update
> *
> * This function can be used by display drivers to perform an atomic check
> on the
> - * hdcp state elements. If hdcp state has changed, this function will set
> - * mode_changed on the crtc driving the connector so it can update its
> hardware
> - * to match the hdcp state.
> + * hdcp state elements. If hdcp state has changed in a manner which requires
> the
> + * driver to enable or disable content protection, this function will return
> + * true.
> + *
> + * Returns:
> + * true if the driver must enable/disable hdcp, false otherwise
> */
> -void drm_hdcp_atomic_check(struct drm_connector *connector,
> +bool drm_hdcp_atomic_check(struct drm_connector *connector,
> struct drm_atomic_state *state)
> {
> struct drm_connector_state *new_conn_state, *old_conn_state;
> @@ -452,10 +455,12 @@ void drm_hdcp_atomic_check(struct drm_connector
> *connector,
>* If the connector is being disabled with CP enabled, mark it
>* desired so it's re-enabled when the connector is brought back
>*/
> - if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
> + if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> new_conn_state->content_protection =
> DRM_MODE_CONTENT_PROTECTION_DESIRED;
> - return;
> + return true;
> + }
> + return false;
> }
>
> new_crtc_state = drm_atomic_get_new_crtc_state(state,
> @@ -467,9 +472,19 @@ void drm_hdcp_atomic_check(struct drm_connector
> *connector,
> */
> if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
> (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> - new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> + new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) {
> new_conn_state->content_protection =
> DRM_MODE_CONTENT_PROTECTION_DESIRED;
> + return true;
> + }
> +
> + /*
> + * Coming back from disable or changing CRTC with DESIRED state requires
> + * that the driver try CP enable.
> + */
> + if (new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> + new_conn_state->crtc != old_conn_state->crtc)
> + return true;
I'm with the feeling that this chunk should deserve a separated patch.
But the reason looks correct so anyway
Reviewed-by: Rodrigo Vivi
>
> /*
>* Nothing to do if content type is unchanged and one of:
> @@ -484,9 +499,9 @@ void drm_hdcp_atomic_check(struct drm_connector
> *connector,
>new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> if (old_conn_state->hdcp_content_type ==
> new_conn_state->hdcp_content_type)
> - return;
> + return false;
> }
>
> - new_crtc_state->mode_changed = true;
> + return true;
> }
> EXPORT_SYMBOL(drm_hdcp_atomic_check);
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index b301a4d1017e..6d24b3450399 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -124,8 +124,6 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> to_intel_digital_connector_state(old_state);
> struct drm_crtc_state *crtc_state;
>
> - drm_hdcp_atomic_check(conn, state);
> -
> if (!new_stat
Re: [PATCH 3/6] drm/sun4i: sun8i-hdmi-phy: Used device-managed clocks/resets
Hi,
On Mon, Apr 11, 2022 at 11:35:08PM -0500, Samuel Holland wrote:
> Now that the HDMI PHY is using a platform driver, it can use device-
> managed resources. Use these, as well as the dev_err_probe helper, to
> simplify the probe function and get rid of the remove function.
>
> Signed-off-by: Samuel Holland
> ---
>
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 100 -
> 1 file changed, 30 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> index 1effa30bfe62..1351e633d485 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> @@ -673,10 +673,8 @@ int sun8i_hdmi_phy_get(struct sun8i_dw_hdmi *hdmi,
> struct device_node *node)
> static int sun8i_hdmi_phy_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *node = dev->of_node;
> struct sun8i_hdmi_phy *phy;
> void __iomem *regs;
> - int ret;
>
> phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
> if (!phy)
> @@ -686,88 +684,50 @@ static int sun8i_hdmi_phy_probe(struct platform_device
> *pdev)
> phy->dev = dev;
>
> regs = devm_platform_ioremap_resource(pdev, 0);
> - if (IS_ERR(regs)) {
> - dev_err(dev, "Couldn't map the HDMI PHY registers\n");
> - return PTR_ERR(regs);
> - }
> + if (IS_ERR(regs))
> + return dev_err_probe(dev, PTR_ERR(regs),
> + "Couldn't map the HDMI PHY registers\n");
>
> phy->regs = devm_regmap_init_mmio(dev, regs,
> &sun8i_hdmi_phy_regmap_config);
> - if (IS_ERR(phy->regs)) {
> - dev_err(dev, "Couldn't create the HDMI PHY regmap\n");
> - return PTR_ERR(phy->regs);
> - }
> + if (IS_ERR(phy->regs))
> + return dev_err_probe(dev, PTR_ERR(phy->regs),
> + "Couldn't create the HDMI PHY regmap\n");
>
> - phy->clk_bus = of_clk_get_by_name(node, "bus");
> - if (IS_ERR(phy->clk_bus)) {
> - dev_err(dev, "Could not get bus clock\n");
> - return PTR_ERR(phy->clk_bus);
> - }
> -
> - phy->clk_mod = of_clk_get_by_name(node, "mod");
> - if (IS_ERR(phy->clk_mod)) {
> - dev_err(dev, "Could not get mod clock\n");
> - ret = PTR_ERR(phy->clk_mod);
> - goto err_put_clk_bus;
> - }
> + phy->clk_bus = devm_clk_get(dev, "bus");
> + if (IS_ERR(phy->clk_bus))
> + return dev_err_probe(dev, PTR_ERR(phy->clk_bus),
> + "Could not get bus clock\n");
>
> - if (phy->variant->has_phy_clk) {
> - phy->clk_pll0 = of_clk_get_by_name(node, "pll-0");
> - if (IS_ERR(phy->clk_pll0)) {
> - dev_err(dev, "Could not get pll-0 clock\n");
> - ret = PTR_ERR(phy->clk_pll0);
> - goto err_put_clk_mod;
> - }
> -
> - if (phy->variant->has_second_pll) {
> - phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
> - if (IS_ERR(phy->clk_pll1)) {
> - dev_err(dev, "Could not get pll-1 clock\n");
> - ret = PTR_ERR(phy->clk_pll1);
> - goto err_put_clk_pll0;
> - }
> - }
> - }
> + phy->clk_mod = devm_clk_get(dev, "mod");
> + if (IS_ERR(phy->clk_mod))
> + return dev_err_probe(dev, PTR_ERR(phy->clk_mod),
> + "Could not get mod clock\n");
>
> - phy->rst_phy = of_reset_control_get_shared(node, "phy");
> - if (IS_ERR(phy->rst_phy)) {
> - dev_err(dev, "Could not get phy reset control\n");
> - ret = PTR_ERR(phy->rst_phy);
> - goto err_put_clk_pll1;
> - }
> + if (phy->variant->has_phy_clk)
> + phy->clk_pll0 = devm_clk_get(dev, "pll-0");
> + if (IS_ERR(phy->clk_pll0))
> + return dev_err_probe(dev, PTR_ERR(phy->clk_pll0),
> + "Could not get pll-0 clock\n");
> +
> + if (phy->variant->has_second_pll)
> + phy->clk_pll1 = devm_clk_get(dev, "pll-1");
> + if (IS_ERR(phy->clk_pll1))
> + return dev_err_probe(dev, PTR_ERR(phy->clk_pll1),
> + "Could not get pll-1 clock\n");
> +
> + phy->rst_phy = devm_reset_control_get_shared(dev, "phy");
> + if (IS_ERR(phy->rst_phy))
> + return dev_err_probe(dev, PTR_ERR(phy->rst_phy),
> + "Could not get phy reset control\n");
I find the old construct clearer with the imbricated blocks.
Otherwise, the rest of the series looks fine, thanks!
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v5 03/10] drm/hdcp: Update property value on content type and user changes
On Mon, Apr 11, 2022 at 08:47:32PM +, Sean Paul wrote:
> From: Sean Paul
>
> This patch updates the connector's property value in 2 cases which were
> previously missed:
>
> 1- Content type changes. The value should revert back to DESIRED from
>ENABLED in case the driver must re-authenticate the link due to the
>new content type.
>
> 2- Userspace sets value to DESIRED while ENABLED. In this case, the
>value should be reset immediately to ENABLED since the link is
>actively being encrypted.
>
> To accommodate these changes, I've split up the conditionals to make
> things a bit more clear (as much as one can with this mess of state).
>
> Acked-by: Jani Nikula
> Reviewed-by: Abhinav Kumar
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-4-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-4-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-4-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-4-s...@poorly.run
> #v4
>
> Changes in v2:
> -None
> Changes in v3:
> -Fixed indentation issue identified by 0-day
> Changes in v4:
> -None
> Changes in v5:
> -None
> ---
> drivers/gpu/drm/drm_hdcp.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index dd8fa91c51d6..8c851d40cd45 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -487,21 +487,29 @@ bool drm_hdcp_atomic_check(struct drm_connector
> *connector,
> return true;
>
> /*
> - * Nothing to do if content type is unchanged and one of:
> - * - state didn't change
> + * Content type changes require an HDCP disable/enable cycle.
> + */
> + if (new_conn_state->hdcp_content_type !=
> old_conn_state->hdcp_content_type) {
shouldn't we add some && ( old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
here?
> + new_conn_state->content_protection =
> + DRM_MODE_CONTENT_PROTECTION_DESIRED;
> + return true;
> + }
> +
> + /*
> + * Ignore meaningless state changes:
>* - HDCP was activated since the last commit
> - * - attempting to set to desired while already enabled
> + * - Attempting to set to desired while already enabled
>*/
> - if (old_hdcp == new_hdcp ||
> - (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> + if ((old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
>new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
>new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> - if (old_conn_state->hdcp_content_type ==
> - new_conn_state->hdcp_content_type)
> - return false;
> + new_conn_state->content_protection =
> + DRM_MODE_CONTENT_PROTECTION_ENABLED;
> + return false;
> }
>
> - return true;
> + /* Finally, if state changes, we need action */
> + return old_hdcp != new_hdcp;
> }
> EXPORT_SYMBOL(drm_hdcp_atomic_check);
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
Re: [PATCH v5 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
On Mon, Apr 11, 2022 at 08:47:35PM +, Sean Paul wrote:
> From: Sean Paul
>
> The shim functions return error codes, but they are discarded in
> intel_hdcp.c. This patch plumbs the return codes through so they are
> properly handled.
Reviewed-by: Rodrigo Vivi
>
> Acked-by: Jani Nikula
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-7-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-7-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-7-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-7-s...@poorly.run
> #v4
>
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> ---
> .../drm/i915/display/intel_display_debugfs.c | 9 +++-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
> 3 files changed, 37 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 452d773fd4e3..f18b4bec4dd4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -489,6 +489,7 @@ static void intel_panel_info(struct seq_file *m,
> static void intel_hdcp_info(struct seq_file *m,
> struct intel_connector *intel_connector)
> {
> + int ret;
> bool hdcp_cap, hdcp2_cap;
>
> if (!intel_connector->hdcp.shim) {
> @@ -496,8 +497,12 @@ static void intel_hdcp_info(struct seq_file *m,
> goto out;
> }
>
> - hdcp_cap = intel_hdcp_capable(intel_connector);
> - hdcp2_cap = intel_hdcp2_capable(intel_connector);
> + ret = intel_hdcp_capable(intel_connector, &hdcp_cap);
> + if (ret)
> + hdcp_cap = false;
> + ret = intel_hdcp2_capable(intel_connector, &hdcp2_cap);
> + if (ret)
> + hdcp2_cap = false;
>
> if (hdcp_cap)
> seq_puts(m, "HDCP1.4 ");
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 6bb5a3971ed9..771e94fa8dff 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -154,50 +154,49 @@ int intel_hdcp_read_valid_bksv(struct
> intel_digital_port *dig_port,
> }
>
> /* Is HDCP1.4 capable on Platform and Sink */
> -bool intel_hdcp_capable(struct intel_connector *connector)
> +int intel_hdcp_capable(struct intel_connector *connector, bool *capable)
> {
> struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> - bool capable = false;
> u8 bksv[5];
>
> + *capable = false;
> +
> if (!shim)
> - return capable;
> + return 0;
>
> - if (shim->hdcp_capable) {
> - shim->hdcp_capable(dig_port, &capable);
> - } else {
> - if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
> - capable = true;
> - }
> + if (shim->hdcp_capable)
> + return shim->hdcp_capable(dig_port, capable);
> +
> + if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
> + *capable = true;
>
> - return capable;
> + return 0;
> }
>
> /* Is HDCP2.2 capable on Platform and Sink */
> -bool intel_hdcp2_capable(struct intel_connector *connector)
> +int intel_hdcp2_capable(struct intel_connector *connector, bool *capable)
> {
> struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = &connector->hdcp;
> - bool capable = false;
> +
> + *capable = false;
>
> /* I915 support for HDCP2.2 */
> if (!hdcp->hdcp2_supported)
> - return false;
> + return 0;
>
> /* MEI interface is solid */
> mutex_lock(&dev_priv->hdcp_comp_mutex);
> if (!dev_priv->hdcp_comp_added || !dev_priv->hdcp_master) {
> mutex_unlock(&dev_priv->hdcp_comp_mutex);
> - return false;
> + return 0;
> }
> mutex_unlock(&dev_priv->hdcp_comp_mutex);
>
> /* Sink's capability for HDCP2.2 */
> - hdcp->shim->hdcp_2_2_capable(dig_port, &capable);
> -
> - return capable;
> + return hdcp->shim->hdcp_2_2_capable(dig_port, capable);
> }
>
> static bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
> @@ -2332,6 +2331,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
> struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> struct intel_hdcp *hdcp = &connector->hdcp;
> unsigned long check_link_interva
Re: [PATCH v5 05/10] drm/i915/hdcp: Consolidate HDCP setup/state cache
On Mon, Apr 11, 2022 at 08:47:34PM +, Sean Paul wrote:
> From: Sean Paul
>
> Stick all of the setup for HDCP into a dedicated function. No functional
> change, but this will facilitate moving HDCP logic into helpers.
Reviewed-by: Rodrigo Vivi
>
> Acked-by: Jani Nikula
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-6-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-6-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-6-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-6-s...@poorly.run
> #v4
>
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
> 1 file changed, 35 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 861c550b5bd6..6bb5a3971ed9 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -2167,6 +2167,37 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum
> transcoder cpu_transcoder)
> }
> }
>
> +static int
> +_intel_hdcp_setup(struct intel_connector *connector,
> + const struct intel_crtc_state *pipe_config, u8 content_type)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + int ret = 0;
> +
> + if (!connector->encoder) {
> + drm_err(&dev_priv->drm, "[%s:%d] encoder is not initialized\n",
> + connector->base.name, connector->base.base.id);
> + return -ENODEV;
> + }
> +
> + hdcp->content_type = content_type;
> +
> + if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
> + hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
> + hdcp->stream_transcoder = pipe_config->cpu_transcoder;
> + } else {
> + hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
> + hdcp->stream_transcoder = INVALID_TRANSCODER;
> + }
> +
> + if (DISPLAY_VER(dev_priv) >= 12)
> + dig_port->hdcp_port_data.fw_tc =
> intel_get_mei_fw_tc(hdcp->cpu_transcoder);
> +
> + return ret;
> +}
> +
> static int initialize_hdcp_port_data(struct intel_connector *connector,
>struct intel_digital_port *dig_port,
>const struct intel_hdcp_shim *shim)
> @@ -2306,28 +2337,14 @@ int intel_hdcp_enable(struct intel_connector
> *connector,
> if (!hdcp->shim)
> return -ENOENT;
>
> - if (!connector->encoder) {
> - drm_err(&dev_priv->drm, "[%s:%d] encoder is not initialized\n",
> - connector->base.name, connector->base.base.id);
> - return -ENODEV;
> - }
> -
> mutex_lock(&hdcp->mutex);
> mutex_lock(&dig_port->hdcp_mutex);
> drm_WARN_ON(&dev_priv->drm,
> hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
> - hdcp->content_type = content_type;
> -
> - if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
> - hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
> - hdcp->stream_transcoder = pipe_config->cpu_transcoder;
> - } else {
> - hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
> - hdcp->stream_transcoder = INVALID_TRANSCODER;
> - }
>
> - if (DISPLAY_VER(dev_priv) >= 12)
> - dig_port->hdcp_port_data.fw_tc =
> intel_get_mei_fw_tc(hdcp->cpu_transcoder);
> + ret = _intel_hdcp_setup(connector, pipe_config, content_type);
> + if (ret)
> + goto out;
>
> /*
>* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
> @@ -2355,6 +2372,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
> true);
> }
>
> +out:
> mutex_unlock(&dig_port->hdcp_mutex);
> mutex_unlock(&hdcp->mutex);
> return ret;
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
Re: [PATCH v5 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers
On Mon, Apr 11, 2022 at 08:47:29PM +, Sean Paul wrote: > From: Sean Paul > > Rebased set from November. Fixed a nit from Stephen in the msm patch and > moved hdcp registers into the trogdor dtsi file to avoid differences > with sc7180-based windows devices. The set is 4 patches lighter since > some of the changes were accepted into msm. > > I'm still waiting for Intel review of the first 7 patches. Rodrigo/Jani, > would you please provide your input so we can move forward with this > set? I'm a bit concerned with patches 4 and 7. It is hard to map the removals and additions and there are some changes that looks like changing behaviors, but end up not being clear in the big patch. Also with big patch it is prune to the rebasing and backport conflicts. Would be possible to split some work in moving individual functions from i915 to drm little by little with smaller patches? But thank you for this great work. It is also good to align our drm drivers. Thanks, Rodrigo. > > Thanks, > > Sean > > Link: https://patchwork.freedesktop.org/series/94623/ #v1 > Link: https://patchwork.freedesktop.org/series/94713/ #v2 > Link: https://patchwork.freedesktop.org/series/94712/ #v3 > Link: https://patchwork.freedesktop.org/series/94712/ #v4 > > Sean Paul (10): > drm/hdcp: Add drm_hdcp_atomic_check() > drm/hdcp: Avoid changing crtc state in hdcp atomic check > drm/hdcp: Update property value on content type and user changes > drm/hdcp: Expand HDCP helper library for enable/disable/check > drm/i915/hdcp: Consolidate HDCP setup/state cache > drm/i915/hdcp: Retain hdcp_capable return codes > drm/i915/hdcp: Use HDCP helpers for i915 > dt-bindings: msm/dp: Add bindings for HDCP registers > arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller > drm/msm: Implement HDCP 1.x using the new drm HDCP helpers > > .../bindings/display/msm/dp-controller.yaml |7 +- > arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi |8 + > arch/arm64/boot/dts/qcom/sc7180.dtsi |6 +- > drivers/gpu/drm/drm_hdcp.c| 1197 - > drivers/gpu/drm/i915/display/intel_atomic.c |7 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- > .../drm/i915/display/intel_display_debugfs.c | 11 +- > .../drm/i915/display/intel_display_types.h| 58 +- > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 345 ++--- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 17 +- > drivers/gpu/drm/i915/display/intel_hdcp.c | 1011 +++--- > drivers/gpu/drm/i915/display/intel_hdcp.h | 36 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 256 ++-- > drivers/gpu/drm/msm/Makefile |1 + > drivers/gpu/drm/msm/dp/dp_debug.c | 46 +- > drivers/gpu/drm/msm/dp/dp_debug.h |6 +- > drivers/gpu/drm/msm/dp/dp_display.c | 46 +- > drivers/gpu/drm/msm/dp/dp_display.h |5 + > drivers/gpu/drm/msm/dp/dp_drm.c | 68 +- > drivers/gpu/drm/msm/dp/dp_drm.h |5 + > drivers/gpu/drm/msm/dp/dp_hdcp.c | 453 +++ > drivers/gpu/drm/msm/dp/dp_hdcp.h | 27 + > drivers/gpu/drm/msm/dp/dp_parser.c| 20 +- > drivers/gpu/drm/msm/dp/dp_parser.h|4 + > drivers/gpu/drm/msm/dp/dp_reg.h | 32 +- > drivers/gpu/drm/msm/msm_atomic.c | 15 + > include/drm/drm_hdcp.h| 194 +++ > 27 files changed, 2582 insertions(+), 1328 deletions(-) > create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c > create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h > > -- > Sean Paul, Software Engineer, Google / Chromium OS >
Re: [PATCH] drm/gma500: add comments to register definitions
On Tue, Apr 12, 2022 at 3:42 AM James Hilliard wrote: > > Extracted from various sources such EMGD releases. > > Signed-off-by: James Hilliard Hi James, These registers are documented in the Intel 965/G35 and G45 documentation [1]. I don't see a clear benefit of duplicating the names of the registers here. Most other drivers don't do this either. See i915, AMD, etc. I prefer to keep the names in the documentation and then add specific notes for those registers that differ from docs or need additional clarification. The SGX and MSVDX registers are an exception since we don't have docs for them. Any hints about bits for those are welcome as long as we can confirm that they actually do what we think they do. [1] https://01.org/linuxgraphics/documentation > --- > drivers/gpu/drm/gma500/psb_intel_reg.h | 212 + > 1 file changed, 107 insertions(+), 105 deletions(-) > > diff --git a/drivers/gpu/drm/gma500/psb_intel_reg.h > b/drivers/gpu/drm/gma500/psb_intel_reg.h > index ced7b433befb..a754bece30f5 100644 > --- a/drivers/gpu/drm/gma500/psb_intel_reg.h > +++ b/drivers/gpu/drm/gma500/psb_intel_reg.h > @@ -31,7 +31,7 @@ > # define GPIO_DATA_VAL_IN (1 << 12) > # define GPIO_DATA_PULLUP_DISABLE (1 << 13) > > -#define GMBUS0 0x5100 /* clock/port select */ > +#define GMBUS0 0x5100 /* clock/device select register */ > #define GMBUS_RATE_100KHZ(0<<8) > #define GMBUS_RATE_50KHZ (1<<8) > #define GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */ > @@ -46,7 +46,7 @@ > /* 6 reserved */ > #define GMBUS_PORT_DPD 7 /* HDMID */ > #define GMBUS_NUM_PORTS 8 > -#define GMBUS1 0x5104 /* command/status */ > +#define GMBUS1 0x5104 /* command/status register */ > #define GMBUS_SW_CLR_INT (1<<31) > #define GMBUS_SW_RDY (1<<30) > #define GMBUS_ENT(1<<29) /* enable timeout */ > @@ -59,7 +59,7 @@ > #define GMBUS_SLAVE_ADDR_SHIFT 1 > #define GMBUS_SLAVE_READ (1<<0) > #define GMBUS_SLAVE_WRITE(0<<0) > -#define GMBUS2 0x5108 /* status */ > +#define GMBUS2 0x5108 /* status register */ > #define GMBUS_INUSE (1<<15) > #define GMBUS_HW_WAIT_PHASE (1<<14) > #define GMBUS_STALL_TIMEOUT (1<<13) > @@ -67,18 +67,18 @@ > #define GMBUS_HW_RDY (1<<11) > #define GMBUS_SATOER (1<<10) > #define GMBUS_ACTIVE (1<<9) > -#define GMBUS3 0x510c /* data buffer bytes 3-0 */ > -#define GMBUS4 0x5110 /* interrupt mask (Pineview+) */ > +#define GMBUS3 0x510c /* data buffer 3-0 register */ > +#define GMBUS4 0x5110 /* REQUEST_INUSE register (Pineview+) > */ > #define GMBUS_SLAVE_TIMEOUT_EN (1<<4) > #define GMBUS_NAK_EN (1<<3) > #define GMBUS_IDLE_EN(1<<2) > #define GMBUS_HW_WAIT_EN (1<<1) > #define GMBUS_HW_RDY_EN (1<<0) > -#define GMBUS5 0x5120 /* byte index */ > +#define GMBUS5 0x5120 /* 2-byte index register */ > #define GMBUS_2BYTE_INDEX_EN (1<<31) > > -#define BLC_PWM_CTL0x61254 > -#define BLC_PWM_CTL2 0x61250 > +#define BLC_PWM_CTL0x61254 /* Backlight PWM Control */ > +#define BLC_PWM_CTL2 0x61250 /* Image BLM Histogram Control */ > #define PWM_ENABLE(1 << 31) > #define PWM_LEGACY_MODE (1 << 30) > #define PWM_PIPE_B(1 << 29) > @@ -117,37 +117,38 @@ > #define I855_CLOCK_166_250 (3 << 0) > > /* I830 CRTC registers */ > -#define HTOTAL_A 0x6 > -#define HBLANK_A 0x60004 > -#define HSYNC_A0x60008 > -#define VTOTAL_A 0x6000c > -#define VBLANK_A 0x60010 > -#define VSYNC_A0x60014 > -#define PIPEASRC 0x6001c > -#define BCLRPAT_A 0x60020 > +#define HTOTAL_A 0x6 /* Pipe A Horizontal Total Register */ > +#define HBLANK_A 0x60004 /* Pipe A Horizontal Blank Register */ > +#define HSYNC_A0x60008 /* Pipe A Horizontal Sync > Register */ > +#define VTOTAL_A 0x6000c /* Pipe A Vertical Total Register */ > +#define VBLANK_A 0x60010 /* Pipe A Vertical Blank Register */ > +#define VSYNC_A0x60014 /* Pipe A Vertical Sync > Register */ > +#define PIPEASRC 0x6001c /* Pipe A Source Image Size Register > */ > +#define BCLRPAT_A 0x60020 /* Pipe A Border Color Pattern > Register */ > #define VSYNCSHIFT_A 0x60028 > > -#define HTOTAL_B 0x61000 > -#define HBLANK_B 0x61004 > -#define HSYNC_B0x61008 > -#define VTOTAL_B 0x6100c > -#define VBLANK_B 0x61010 > -#define VSYNC_B
Re: [PATCH] drm/tidss: Soft Reset DISPC on startup
Hi,
On 14/03/2022 13:37, Devarsh Thakkar wrote:
Soft reset the display subsystem controller on startup and wait for
the reset to complete. This helps the scenario where display was
already in use by some other core before the linux was booted.
The reason the omapdrm doesn't do a reset is that the PM features on
some of the DSS registers were set and controlled outside dss driver, so
the dss driver could not do a reset just like that. That design was
carried to the tidss driver, although I'm not sure if the reason is
valid on AM6 and J7 platforms.
If that reasoning is not valid, this patch is ok and:
Reviewed-by: Tomi Valkeinen
Tomi
Signed-off-by: Devarsh Thakkar
---
drivers/gpu/drm/tidss/tidss_dispc.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 60b92df615aa..dae47853b728 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -2650,6 +2650,20 @@ static void dispc_init_errata(struct dispc_device *dispc)
}
}
+static void dispc_softreset(struct dispc_device *dispc)
+{
+ u32 val;
+ int ret = 0;
+
+ /* Soft reset */
+ REG_FLD_MOD(dispc, DSS_SYSCONFIG, 1, 1, 1);
+ /* Wait for reset to complete */
+ ret = readl_poll_timeout(dispc->base_common + DSS_SYSSTATUS,
+val, val & 1, 100, 5000);
+ if (ret)
+ dev_warn(dispc->dev, "failed to reset dispc\n");
+}
+
int dispc_init(struct tidss_device *tidss)
{
struct device *dev = tidss->dev;
@@ -2709,6 +2723,10 @@ int dispc_init(struct tidss_device *tidss)
return r;
}
+ /* K2G display controller does not support soft reset */
+ if (feat->subrev != DISPC_K2G)
+ dispc_softreset(dispc);
+
for (i = 0; i < dispc->feat->num_vps; i++) {
u32 gamma_size = dispc->feat->vp_feat.color.gamma_size;
u32 *gamma_table;
Re: [PATCH v8, 00/15] media: mtk-vcodec: support for M8192 decoder
Le lundi 11 avril 2022 à 11:41 +0800, yunfei.d...@mediatek.com a écrit : > Hi Nicolas, > > On Thu, 2022-03-31 at 16:48 -0400, Nicolas Dufresne wrote: > > Hi Yunfei, > > > > thanks for the update, I should be testing this really soon. > > > > Le jeudi 31 mars 2022 à 10:47 +0800, Yunfei Dong a écrit : > > > This series adds support for mt8192 h264/vp8/vp9 decoder drivers. > > > Firstly, refactor > > > power/clock/interrupt interfaces for mt8192 is lat and core > > > architecture. > > > > Similarly to MT8173 and MT8183, a shared* firmware is needed for this > > CODEC to > > work (scp.img). I looked into linux-firmware[1] it has not been added > > for mt8192 > > yet. As your patches are getting close to be ready, it would be > > important to > > look into this so the patchset does not get blocked due to that. > > > > best regards, > > Nicolas > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek > > * Shared at least between MDP3 and MTK VCODEC from my knowledge > > > > Thanks for your remind. > > I have already sent mt8192 scp.img to github. > > https://github.com/yunfeidongmediatek/linux_fw_scp_8192/commit/3ac2fc85bc7dfcebdb92b5b5808b0268cdfb772d > > Waiting for to be merged. On boards I have, the firmware is loaded from /lib/firmware/scp.img, but with this submission it will be in lib/firmware/mediatek/mt8192/scp.img . I haven't found anything around: drivers/remoteproc/mtk_scp.c:812: char *fw_name = "scp.img"; That would use the platform path. This seems like a problem to me, the upstreaming of the firmware isn't being aligned with the were the firmware is picked by the upstream driver. Correct me if I got this wrong, but I'd really like to clarify this. Nicolas > > Best Regards, > Yunfei Dong > > > > > > > Secondly, add new functions to get frame buffer size and resolution > > > according > > > to decoder capability from scp side. Then add callback function to > > > get/put > > > capture buffer in order to enable lat and core decoder in parallel, > > > need to > > > adjust GStreamer at the same time. > > > > > > Then add to support MT21C compressed mode and fix v4l2-compliance > > > fail. > > > > > > Next, extract H264 request api driver to let mt8183 and mt8192 use > > > the same > > > code, and adds mt8192 frame based h264 driver for stateless > > > decoder. > > > > > > Lastly, add vp8 and vp9 stateless decoder drivers. > > > > > > Patches 1 refactor power/clock/interrupt interface. > > > Patches 2~4 get frame buffer size and resolution according to > > > decoder capability. > > > Patches 5 set capture queue bytesused. > > > Patches 6 adjust GStreamer. > > > Patch 7~11 add to support MT21C compressed mode and fix v4l2- > > > compliance fail. > > > patch 12 record capture queue format type. > > > Patch 13~14 extract h264 driver and add mt8192 frame based driver > > > for h264 decoder. > > > Patch 15~16 add vp8 and vp9 stateless decoder drivers. > > > Patch 17 prevent kernel crash when rmmod mtk-vcodec-dec.ko > > > --- > > > changes compared with v6: > > > - adjust GStreamer, separate src buffer done with > > > v4l2_ctrl_request_complete for patch 6. > > > - remove v4l2_m2m_set_dst_buffered. > > > - add new patch to set each plane bytesused in buf prepare for > > > patch 5. > > > - using upstream interface to update vp9 prob tables for patch 16. > > > - fix maintainer comments. > > > - test the driver with chrome VD and GStreamer(H264/VP9/VP8/AV1). > > > changes compared with v6: > > > - rebase to the latest media stage and fix conficts > > > - fix memcpy to memcpy_fromio or memcpy_toio > > > - fix h264 crash when test field bitstream > > > changes compared with v5: > > > - fix vp9 comments for patch 15 > > > - fix vp8 comments for patch 14. > > > - fix comments for patch 12. > > > - fix build errors. > > > changes compared with v4: > > > - fix checkpatch.pl fail. > > > - fix kernel-doc fail. > > > - rebase to the latest media codec driver. > > > changes compared with v3: > > > - remove enum mtk_chip for patch 2. > > > - add vp8 stateless decoder drivers for patch 14. > > > - add vp9 stateless decoder drivers for patch 15. > > > changes compared with v2: > > > - add new patch 11 to record capture queue format type. > > > - separate patch 4 according to tzung-bi's suggestion. > > > - re-write commit message for patch 5 according to tzung-bi's > > > suggestion. > > > changes compared with v1: > > > - rewrite commit message for patch 12. > > > - rewrite cover-letter message. > > > --- > > > Yunfei Dong (17): > > > media: mediatek: vcodec: Add vdec enable/disable hardware helpers > > > media: mediatek: vcodec: Using firmware type to separate > > > different > > > firmware architecture > > > media: mediatek: vcodec: get capture queue buffer size from scp > > > media: mediatek: vcodec: Read max resolution from dec_capability > > > media: mediatek: vcodec: set each plane bytesused in buf prepare > > > media: media
Re: [PATCH v2] drm/gma500: fix a potential repeat execution in psb_driver_load
On Wed, Apr 6, 2022 at 1:31 PM Xiaomeng Tong wrote:
>
> Instead of exiting the loop as expected when an entry is found, the
> list_for_each_entry() continues until the traversal is complete. To
> avoid potential executing 'ret = gma_backlight_init(dev);' repeatly,
> goto outside the loop when the entry is found.
>
> Signed-off-by: Xiaomeng Tong
> ---
>
> changes since v1:
> - goto outside the loop (Xiaomeng Tong)
>
> v1: https://lore.kernel.org/lkml/20220401115811.9656-1-xiam0nd.t...@gmail.com/
>
> ---
> drivers/gpu/drm/gma500/psb_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 2aff54d505e2..929fd47548b4 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -400,9 +400,10 @@ static int psb_driver_load(struct drm_device *dev,
> unsigned long flags)
> case INTEL_OUTPUT_LVDS:
> case INTEL_OUTPUT_MIPI:
> ret = gma_backlight_init(dev);
> - break;
> + goto out;
> }
> }
> +out:
> drm_connector_list_iter_end(&conn_iter);
Hi,
This would work but using gotos like this easily turns the code into
spaghetti. See "7. Centralized exiting of functions" in
Documentation/process/coding-style.rst for when to use gotos.
In this particular case I think we are better off using an
if-statement. What about something like this:
if (gma_encoder->type == INTEL_OUTPUT_LVDS ||
gma_encoder->type == INTEL_OUTPUT_MIPI) {
ret = gma_backlight_init();
break;
}
-Patrik
>
> if (ret)
> --
> 2.17.1
>
[PATCHv3] drm/amdgpu: disable ASPM on Intel Alder Lake based systems
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that won't work
with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as
video/display output, Intel Alder Lake based systems will hang during
suspend/resume.
The issue was initially reported on one system (Dell Precision 3660 with
BIOS version 0.14.81), but was later confirmed to affect at least 4 Alder
Lake based systems.
Add extra check to disable ASPM on Intel Alder Lake based systems.
Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
Reported-by: kernel test robot
Signed-off-by: Richard Gong
---
v3: s/intel_core_asom_chk/aspm_support_quirk_check
correct build error with W=1 option
v2: correct commit description
move the check from chip family to problematic platform
---
drivers/gpu/drm/amd/amdgpu/vi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 039b90cdc3bc..b0b6353b48b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -81,6 +81,10 @@
#include "mxgpu_vi.h"
#include "amdgpu_dm.h"
+#if IS_ENABLED(CONFIG_X86_64)
+#include
+#endif
+
#define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6
#define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK
0x0001L
#define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK 0x0002L
@@ -1134,13 +1138,24 @@ static void vi_enable_aspm(struct amdgpu_device *adev)
WREG32_PCIE(ixPCIE_LC_CNTL, data);
}
+static bool aspm_support_quirk_check(void)
+{
+ if (IS_ENABLED(CONFIG_X86_64)) {
+ struct cpuinfo_x86 *c = &cpu_data(0);
+
+ return (c->x86 == 6 && c->x86_model != INTEL_FAM6_ALDERLAKE);
+ }
+
+ return true;
+}
+
static void vi_program_aspm(struct amdgpu_device *adev)
{
u32 data, data1, orig;
bool bL1SS = false;
bool bClkReqSupport = true;
- if (!amdgpu_device_should_use_aspm(adev))
+ if (!amdgpu_device_should_use_aspm(adev) || !aspm_support_quirk_check())
return;
if (adev->flags & AMD_IS_APU ||
--
2.25.1
[PATCH v2 0/5] drm/i915: ttm for stolen region
This series refactors i915's stolen memory region to use ttm. v2: handle disabled stolen similar to legacy version. relying on ttm to fail allocs works fine, but is dmesg noisy and causes testing dmesg warning regressions. Robert Beckett (5): drm/i915: instantiate ttm ranger manager for stolen memory drm/i915: sanitize mem_flags for stolen buffers drm/i915: ttm move/clear logic fix drm/i915: ttm backend dont provide mmap_offset for kernel buffers drm/i915: stolen memory use ttm backend drivers/gpu/drm/i915/display/intel_fbc.c | 78 ++-- .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 - drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 407 ++ drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 21 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 32 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 7 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 33 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +- drivers/gpu/drm/i915/i915_debugfs.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 5 - drivers/gpu/drm/i915/intel_region_ttm.c | 67 ++- drivers/gpu/drm/i915/intel_region_ttm.h | 8 +- drivers/gpu/drm/i915/selftests/mock_region.c | 3 +- 14 files changed, 319 insertions(+), 371 deletions(-) -- 2.25.1
[PATCH v2 2/5] drm/i915: sanitize mem_flags for stolen buffers
stolen regions are not page backed or considered iomem. Signed-off-by: Robert Beckett --- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c index 358f8a1a30ce..9fe8132de3b2 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c @@ -122,8 +122,9 @@ void i915_ttm_adjust_gem_after_move(struct drm_i915_gem_object *obj) obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM); - obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? I915_BO_FLAG_IOMEM : - I915_BO_FLAG_STRUCT_PAGE; + if (obj->mm.region->id != INTEL_REGION_STOLEN_SMEM) + obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? I915_BO_FLAG_IOMEM : + I915_BO_FLAG_STRUCT_PAGE; cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource, bo->ttm); -- 2.25.1
[PATCH v2 1/5] drm/i915: instantiate ttm ranger manager for stolen memory
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 31 +++-
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a10716f4e717..358f8a1a30ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -58,11 +58,13 @@ i915_ttm_region(struct ttm_device *bdev, int ttm_mem_type)
struct drm_i915_private *i915 = container_of(bdev, typeof(*i915), bdev);
/* There's some room for optimization here... */
- GEM_BUG_ON(ttm_mem_type != I915_PL_SYSTEM &&
- ttm_mem_type < I915_PL_LMEM0);
+ GEM_BUG_ON(ttm_mem_type == I915_PL_GGTT);
+
if (ttm_mem_type == I915_PL_SYSTEM)
return intel_memory_region_lookup(i915, INTEL_MEMORY_SYSTEM,
0);
+ if (ttm_mem_type == I915_PL_STOLEN)
+ return i915->mm.stolen_region;
return intel_memory_region_lookup(i915, INTEL_MEMORY_LOCAL,
ttm_mem_type - I915_PL_LMEM0);
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 62ff77445b01..7d49ea72e33f 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -49,7 +49,7 @@ void intel_region_ttm_device_fini(struct drm_i915_private
*dev_priv)
/*
* Map the i915 memory regions to TTM memory types. We use the
- * driver-private types for now, reserving TTM_PL_VRAM for stolen
+ * driver-private types for now, reserving I915_PL_STOLEN for stolen
* memory and TTM_PL_TT for GGTT use if decided to implement this.
*/
int intel_region_to_ttm_type(const struct intel_memory_region *mem)
@@ -58,11 +58,17 @@ int intel_region_to_ttm_type(const struct
intel_memory_region *mem)
GEM_BUG_ON(mem->type != INTEL_MEMORY_LOCAL &&
mem->type != INTEL_MEMORY_MOCK &&
- mem->type != INTEL_MEMORY_SYSTEM);
+ mem->type != INTEL_MEMORY_SYSTEM &&
+ mem->type != INTEL_MEMORY_STOLEN_SYSTEM &&
+ mem->type != INTEL_MEMORY_STOLEN_LOCAL);
if (mem->type == INTEL_MEMORY_SYSTEM)
return TTM_PL_SYSTEM;
+ if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+ mem->type == INTEL_MEMORY_STOLEN_LOCAL)
+ return I915_PL_STOLEN;
+
type = mem->instance + TTM_PL_PRIV;
GEM_BUG_ON(type >= TTM_NUM_MEM_TYPES);
@@ -86,10 +92,16 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int mem_type = intel_region_to_ttm_type(mem);
int ret;
- ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
- resource_size(&mem->region),
- mem->io_size,
- mem->min_page_size, PAGE_SIZE);
+ if (mem_type == I915_PL_STOLEN) {
+ ret = ttm_range_man_init(bdev, mem_type, false,
+resource_size(&mem->region) >>
PAGE_SHIFT);
+ mem->is_range_manager = true;
+ } else {
+ ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
+ resource_size(&mem->region),
+ mem->io_size,
+ mem->min_page_size, PAGE_SIZE);
+ }
if (ret)
return ret;
@@ -109,6 +121,7 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int intel_region_ttm_fini(struct intel_memory_region *mem)
{
struct ttm_resource_manager *man = mem->region_private;
+ int mem_type = intel_region_to_ttm_type(mem);
int ret = -EBUSY;
int count;
@@ -139,8 +152,10 @@ int intel_region_ttm_fini(struct intel_memory_region *mem)
if (ret || !man)
return ret;
- ret = i915_ttm_buddy_man_fini(&mem->i915->bdev,
- intel_region_to_ttm_type(mem));
+ if (mem_type == I915_PL_STOLEN)
+ ret = ttm_range_man_fini(&mem->i915->bdev, mem_type);
+ else
+ ret = i915_ttm_buddy_man_fini(&mem->i915->bdev, mem_type);
GEM_WARN_ON(ret);
mem->region_private = NULL;
--
2.25.1
[PATCH v2 3/5] drm/i915: ttm move/clear logic fix
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.
The desired behaviour is to clear user allocated buffers and any kernel
buffers that specifically requests it only.
Make the logic match the desired behaviour.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 22 +++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9fe8132de3b2..9cf85f91edb5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,6 +3,7 @@
* Copyright © 2021 Intel Corporation
*/
+#include "drm/ttm/ttm_tt.h"
#include
#include "i915_deps.h"
@@ -470,6 +471,25 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
return fence;
}
+static bool
+allow_clear(struct drm_i915_gem_object *obj, struct ttm_tt *ttm, struct
ttm_resource *dst_mem)
+{
+ /* never clear stolen */
+ if (dst_mem->mem_type == I915_PL_STOLEN)
+ return false;
+ /*
+* we want to clear user buffers and any kernel buffers
+* that specifically request clearing.
+*/
+ if (obj->flags & I915_BO_ALLOC_USER)
+ return true;
+
+ if (ttm && ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)
+ return true;
+
+ return false;
+}
+
/**
* i915_ttm_move - The TTM move callback used by i915.
* @bo: The buffer object.
@@ -520,7 +540,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
return PTR_ERR(dst_rsgt);
clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm ||
!ttm_tt_is_populated(ttm));
- if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+ if (!clear || allow_clear(obj, ttm, dst_mem)) {
struct i915_deps deps;
i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY |
__GFP_NOWARN);
--
2.25.1
[PATCH v2 4/5] drm/i915: ttm backend dont provide mmap_offset for kernel buffers
stolen/kernel buffers should not be mmapable by userland.
do not provide callbacks to facilitate this for these buffers.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 32 +
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index a878910a563c..b20f81836c54 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1092,8 +1092,8 @@ static void i915_ttm_unmap_virtual(struct
drm_i915_gem_object *obj)
ttm_bo_unmap_virtual(i915_gem_to_ttm(obj));
}
-static const struct drm_i915_gem_object_ops i915_gem_ttm_obj_ops = {
- .name = "i915_gem_object_ttm",
+static const struct drm_i915_gem_object_ops i915_gem_ttm_user_obj_ops = {
+ .name = "i915_gem_object_ttm_user",
.flags = I915_GEM_OBJECT_IS_SHRINKABLE |
I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
@@ -,6 +,21 @@ static const struct drm_i915_gem_object_ops
i915_gem_ttm_obj_ops = {
.mmap_ops = &vm_ops_ttm,
};
+static const struct drm_i915_gem_object_ops i915_gem_ttm_kern_obj_ops = {
+ .name = "i915_gem_object_ttm_kern",
+ .flags = I915_GEM_OBJECT_IS_SHRINKABLE |
+I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
+
+ .get_pages = i915_ttm_get_pages,
+ .put_pages = i915_ttm_put_pages,
+ .truncate = i915_ttm_truncate,
+ .shrink = i915_ttm_shrink,
+
+ .adjust_lru = i915_ttm_adjust_lru,
+ .delayed_free = i915_ttm_delayed_free,
+ .migrate = i915_ttm_migrate,
+};
+
void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
@@ -1165,10 +1180,19 @@ int __i915_gem_ttm_object_init(struct
intel_memory_region *mem,
.no_wait_gpu = false,
};
enum ttm_bo_type bo_type;
+ const struct drm_i915_gem_object_ops *ops;
int ret;
drm_gem_private_object_init(&i915->drm, &obj->base, size);
- i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, flags);
+
+ if (flags & I915_BO_ALLOC_USER && intel_region_to_ttm_type(mem) !=
I915_PL_STOLEN) {
+ bo_type = ttm_bo_type_device;
+ ops = &i915_gem_ttm_user_obj_ops;
+ } else {
+ bo_type = ttm_bo_type_kernel;
+ ops = &i915_gem_ttm_kern_obj_ops;
+ }
+ i915_gem_object_init(obj, ops, &lock_class, flags);
obj->bo_offset = offset;
@@ -1178,8 +1202,6 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
INIT_RADIX_TREE(&obj->ttm.get_io_page.radix, GFP_KERNEL | __GFP_NOWARN);
mutex_init(&obj->ttm.get_io_page.lock);
- bo_type = (obj->flags & I915_BO_ALLOC_USER) ? ttm_bo_type_device :
- ttm_bo_type_kernel;
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
--
2.25.1
[PATCH v2 5/5] drm/i915: stolen memory use ttm backend
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 78 ++--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 -
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 407 ++
drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 21 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 7 +
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +-
drivers/gpu/drm/i915/i915_debugfs.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/intel_region_ttm.c | 36 +-
drivers/gpu/drm/i915/intel_region_ttm.h | 8 +-
drivers/gpu/drm/i915/selftests/mock_region.c | 3 +-
12 files changed, 241 insertions(+), 353 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index b653f3ba7c66..dbad1b6471b8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -38,6 +38,7 @@
* forcibly disable it to allow proper screen updates.
*/
+#include "gem/i915_gem_stolen.h"
#include
#include
@@ -51,6 +52,7 @@
#include "intel_display_types.h"
#include "intel_fbc.h"
#include "intel_frontbuffer.h"
+#include "gem/i915_gem_region.h"
#define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS;
(__fbc_id)++) \
@@ -93,8 +95,8 @@ struct intel_fbc {
unsigned int possible_framebuffer_bits;
unsigned int busy_bits;
- struct drm_mm_node compressed_fb;
- struct drm_mm_node compressed_llb;
+ struct ttm_resource *compressed_fb;
+ struct ttm_resource *compressed_llb;
enum intel_fbc_id id;
@@ -332,16 +334,20 @@ static void i8xx_fbc_nuke(struct intel_fbc *fbc)
static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
+ u64 llb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_llb);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ GEM_BUG_ON(llb_offset == I915_BO_INVALID_OFFSET);
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_fb.start, U32_MAX));
+fb_offset, U32_MAX));
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_llb.start, U32_MAX));
+llb_offset, U32_MAX));
intel_de_write(i915, FBC_CFB_BASE,
- i915->dsm.start + fbc->compressed_fb.start);
+ i915->dsm.start + fb_offset);
intel_de_write(i915, FBC_LL_BASE,
- i915->dsm.start + fbc->compressed_llb.start);
+ i915->dsm.start + llb_offset);
}
static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -449,8 +455,10 @@ static bool g4x_fbc_is_compressing(struct intel_fbc *fbc)
static void g4x_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
- intel_de_write(i915, DPFC_CB_BASE, fbc->compressed_fb.start);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ intel_de_write(i915, DPFC_CB_BASE, fb_offset);
}
static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -500,8 +508,10 @@ static bool ilk_fbc_is_compressing(struct intel_fbc *fbc)
static void ilk_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
- intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id),
fbc->compressed_fb.start);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fb_offset);
}
static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -741,21 +751,24 @@ static int find_compression_limit(struct intel_fbc *fbc,
{
struct drm_i915_private *i915 = fbc->i915;
u64 end = intel_fbc_stolen_end(i915);
- int ret, limit = min_limit;
+ int limit = min_limit;
+ struct ttm_resource *res;
size /= limit;
/* Try to over-allocate to reduce reallocations and fragmentation. */
- ret = i915_gem_stolen_insert_node_in_range(i915, &fbc->compressed_fb,
- size <<= 1, 4096, 0, end);
- if (ret == 0)
+ res = i915_gem_stolen_reserve_range(i915, size <<= 1, 0, end);
+ if (!IS_ERR(res)) {
+ fbc->compressed_fb = res;
return limit;
+ }
for (; limit <= intel_fbc_max_limit(i915); limit <<=
[PATCH 5.10 1/1] drm/amdgpu: Ensure the AMDGPU file descriptor is legitimate
[ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
This is a partial cherry-pick of the above upstream commit.
It ensures the file descriptor passed in by userspace is a valid one.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 26f8a21383774..1b4c7ced8b92c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1024,11 +1024,15 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct
kgd_dev *kgd,
struct dma_fence **ef)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct drm_file *drm_priv = filp->private_data;
- struct amdgpu_fpriv *drv_priv = drm_priv->driver_priv;
- struct amdgpu_vm *avm = &drv_priv->vm;
+ struct amdgpu_fpriv *drv_priv;
+ struct amdgpu_vm *avm;
int ret;
+ ret = amdgpu_file_to_fpriv(filp, &drv_priv);
+ if (ret)
+ return ret;
+ avm = &drv_priv->vm;
+
/* Already a compute VM? */
if (avm->process_info)
return -EINVAL;
--
2.35.1.1178.g4f1659d476-goog
[PATCH 4.19 2/2] drm/amdgpu: Ensure the AMDGPU file descriptor is legitimate
[ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
This is a partial cherry-pick of the above upstream commit.
It ensures the file descriptor passed in by userspace is a valid one.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index f92597c292fe5..4488aad64643b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1044,11 +1044,15 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct
kgd_dev *kgd,
struct dma_fence **ef)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct drm_file *drm_priv = filp->private_data;
- struct amdgpu_fpriv *drv_priv = drm_priv->driver_priv;
- struct amdgpu_vm *avm = &drv_priv->vm;
+ struct amdgpu_fpriv *drv_priv;
+ struct amdgpu_vm *avm;
int ret;
+ ret = amdgpu_file_to_fpriv(filp, &drv_priv);
+ if (ret)
+ return ret;
+ avm = &drv_priv->vm;
+
/* Already a compute VM? */
if (avm->process_info)
return -EINVAL;
--
2.35.1.1178.g4f1659d476-goog
[PATCH 4.19 1/2] drm/amdgpu: Check if fd really is an amdgpu fd.
From: Bas Nieuwenhuizen
[ Upstream commit 021830d24ba55a578f602979274965344c8e6284 ]
Otherwise we interpret the file private data as drm & amdgpu data
while it might not be, possibly allowing one to get memory corruption.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 10 +++---
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 447c4c7a36d68..acbd33fcb73d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -955,6 +955,8 @@ struct amdgpu_gfx {
DECLARE_BITMAP (pipe_reserve_bitmap,
AMDGPU_MAX_COMPUTE_QUEUES);
};
+int amdgpu_file_to_fpriv(struct file *filp, struct amdgpu_fpriv **fpriv);
+
int amdgpu_ib_get(struct amdgpu_device *adev, struct amdgpu_vm *vm,
unsigned size, struct amdgpu_ib *ib);
void amdgpu_ib_free(struct amdgpu_device *adev, struct amdgpu_ib *ib,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 63b1e325b45c5..b3b22a87b232b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1132,6 +1132,22 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
#endif
};
+int amdgpu_file_to_fpriv(struct file *filp, struct amdgpu_fpriv **fpriv)
+{
+struct drm_file *file;
+
+ if (!filp)
+ return -EINVAL;
+
+ if (filp->f_op != &amdgpu_driver_kms_fops) {
+ return -EINVAL;
+ }
+
+ file = filp->private_data;
+ *fpriv = file->driver_priv;
+ return 0;
+}
+
static bool
amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
bool in_vblank_irq, int *vpos, int *hpos,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
index 1cafe8d83a4db..0b70410488b66 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
@@ -54,16 +54,20 @@ static int amdgpu_sched_process_priority_override(struct
amdgpu_device *adev,
enum drm_sched_priority
priority)
{
struct file *filp = fget(fd);
- struct drm_file *file;
struct amdgpu_fpriv *fpriv;
struct amdgpu_ctx *ctx;
uint32_t id;
+ int r;
if (!filp)
return -EINVAL;
- file = filp->private_data;
- fpriv = file->driver_priv;
+ r = amdgpu_file_to_fpriv(filp, &fpriv);
+ if (r) {
+ fput(filp);
+ return r;
+ }
+
idr_for_each_entry(&fpriv->ctx_mgr.ctx_handles, ctx, id)
amdgpu_ctx_priority_override(ctx, priority);
--
2.35.1.1178.g4f1659d476-goog
Re: AMD Display Core (DC) patches (was: [PATCH 13/16] drm/amd/display: Revert FEC check in validation)
On Tue, Apr 12, 2022 at 2:52 AM Paul Menzel wrote: > > [Cc: +dri-devel@lists.freedesktop.org, +Daniel Vetter, +Alexander > Deucher, +Greg KH] > > > Dear Alex, > > > I am a little confused and upset about how Display Core patches are > handled in the Linux kernel. > > > Am 25.03.22 um 23:53 schrieb Alex Hung: > > From: Martin Leung > > git puts a line “This reverts commit …” into the commit message, when > something is reverted. Why isn’t this here? Right now, commit > 7d56a154e22f, reverted here, is proposed for the stable series. I guess, > because these indicators and meta data are missing. Sasha's tools proposed to pick it up which I often struggle with. It's very useful, but at the same time, we don't have the bandwidth to test every combination of patches that Sacha proposes on every stable kernel. The additional metadata would be useful, but I'm not sure if it would solve this problem. This patch would likely be picked up by Sasha as well once it landed. > > > why and how: > > causes failure on install on certain machines > > Why are such kind of commit messages accepted? What does “failure on > install” even mean? Why can’t the machine configuration be documented so > it can be reproduced, when necessary. > > No less confusing, the date you posted it on amd-gfx is from March 25th, > 2022, but the author date of the commit in agd5f/amd-staging-drm-next is > `Fri Mar 18 11:12:36 2022 -0400`. Why is the patch missing the Date > field then? > > > Reviewed-by: George Shen > > Acked-by: Alex Hung > > Signed-off-by: Martin Leung > > Shouldn’t the Signed-off-by line by the author go first? > > You committed this on `Mon Mar 28 08:26:48 2022 -0600`, while you posted > the patch on amd-gfx on Friday. How should *proper* review happen over > the weekend? > > > --- > > drivers/gpu/drm/amd/display/dc/core/dc.c | 4 > > 1 file changed, 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c > > b/drivers/gpu/drm/amd/display/dc/core/dc.c > > index f2ad8f58e69c..c436db416708 100644 > > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c > > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c > > @@ -1496,10 +1496,6 @@ bool dc_validate_boot_timing(const struct dc *dc, > > if (!link->link_enc->funcs->is_dig_enabled(link->link_enc)) > > return false; > > > > - /* Check for FEC status*/ > > - if (link->link_enc->funcs->fec_is_active(link->link_enc)) > > - return false; > > - > > enc_inst = link->link_enc->funcs->get_dig_frontend(link->link_enc); > > > > if (enc_inst == ENGINE_ID_UNKNOWN) > > The patch reverted here, also lacked proper review, had a to-be desired > commit message, did not follow the Linux kernel coding style (missing > space before the comment terminator), so should not have been committed > in the first place. > > Seeing how many people are in the Cc list, I would have hoped, that > somebody noticed and commented. The current state also makes it really > hard for non-AMD employees to get the necessary information to do proper > reviews as the needed documentation and information is non-public. So > good/excellent commit messages are a must. I think to remember, you > replied to me once, that Display Core patches are shared also with the > Microsoft Windows driver, restricting the workflow options. But I think > the issues I mentioned are unrelated. I know graphics hardware is very > complex, but if quality of the commits and review would be improved, > hopefully it saves time for everyone in the end, as less bugs are > introduced. I agree that good commit messages are ideal and we should strive for them, but this is certainly not limited to GPUs. Subsystems all require a certain amount of assumed knowledge when it comes to commit messages. At the same time, I think it would be good to set expectations. Too many frivolous review comments and escalations tends to turn people off even if they are well intentioned. There are always new people becoming kernel developers that may not have had a lot of previous kernel experience. That said, to the AMD developers, please try and address every comment. Alex
Re: [PATCHv3] drm/amdgpu: disable ASPM on Intel Alder Lake based systems
On Tue, Apr 12, 2022 at 10:59 AM Richard Gong wrote:
>
> Active State Power Management (ASPM) feature is enabled since kernel 5.14.
> There are some AMD GFX cards (such as WX3200 and RX640) that won't work
> with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as
> video/display output, Intel Alder Lake based systems will hang during
> suspend/resume.
>
> The issue was initially reported on one system (Dell Precision 3660 with
> BIOS version 0.14.81), but was later confirmed to affect at least 4 Alder
> Lake based systems.
>
> Add extra check to disable ASPM on Intel Alder Lake based systems.
>
> Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
> Reported-by: kernel test robot
> Signed-off-by: Richard Gong
> ---
> v3: s/intel_core_asom_chk/aspm_support_quirk_check
> correct build error with W=1 option
> v2: correct commit description
> move the check from chip family to problematic platform
> ---
> drivers/gpu/drm/amd/amdgpu/vi.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 039b90cdc3bc..b0b6353b48b9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -81,6 +81,10 @@
> #include "mxgpu_vi.h"
> #include "amdgpu_dm.h"
>
> +#if IS_ENABLED(CONFIG_X86_64)
Shouldn't this be X86? You could theoretically run this on 32 bit.
Alex
> +#include
> +#endif
> +
> #define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6
> #define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK
> 0x0001L
> #define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK 0x0002L
> @@ -1134,13 +1138,24 @@ static void vi_enable_aspm(struct amdgpu_device *adev)
> WREG32_PCIE(ixPCIE_LC_CNTL, data);
> }
>
> +static bool aspm_support_quirk_check(void)
> +{
> + if (IS_ENABLED(CONFIG_X86_64)) {
> + struct cpuinfo_x86 *c = &cpu_data(0);
> +
> + return (c->x86 == 6 && c->x86_model != INTEL_FAM6_ALDERLAKE);
> + }
> +
> + return true;
> +}
> +
> static void vi_program_aspm(struct amdgpu_device *adev)
> {
> u32 data, data1, orig;
> bool bL1SS = false;
> bool bClkReqSupport = true;
>
> - if (!amdgpu_device_should_use_aspm(adev))
> + if (!amdgpu_device_should_use_aspm(adev) ||
> !aspm_support_quirk_check())
> return;
>
> if (adev->flags & AMD_IS_APU ||
> --
> 2.25.1
>
[PATCH 1/9] vfio: Make vfio_(un)register_notifier accept a vfio_device
All callers have a struct vfio_device trivially available, pass it in
directly and avoid calling the expensive vfio_group_get_from_dev().
To support the unconverted kvmgt mdev driver add
mdev_legacy_get_vfio_device() which will return the vfio_device pointer
vfio_mdev.c puts in the drv_data.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 15 +--
drivers/s390/cio/vfio_ccw_ops.c | 7 +++
drivers/s390/crypto/vfio_ap_ops.c | 14 +++---
drivers/vfio/mdev/vfio_mdev.c | 12
drivers/vfio/vfio.c | 25 +++--
include/linux/mdev.h | 1 +
include/linux/vfio.h | 4 ++--
7 files changed, 41 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 057ec449010458..bb59d21cf898ab 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -904,6 +904,7 @@ static int intel_vgpu_group_notifier(struct notifier_block
*nb,
static int intel_vgpu_open_device(struct mdev_device *mdev)
{
+ struct vfio_device *vfio_dev = mdev_legacy_get_vfio_device(mdev);
struct intel_vgpu *vgpu = mdev_get_drvdata(mdev);
struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
unsigned long events;
@@ -914,7 +915,7 @@ static int intel_vgpu_open_device(struct mdev_device *mdev)
vdev->group_notifier.notifier_call = intel_vgpu_group_notifier;
events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;
- ret = vfio_register_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY, &events,
+ ret = vfio_register_notifier(vfio_dev, VFIO_IOMMU_NOTIFY, &events,
&vdev->iommu_notifier);
if (ret != 0) {
gvt_vgpu_err("vfio_register_notifier for iommu failed: %d\n",
@@ -923,7 +924,7 @@ static int intel_vgpu_open_device(struct mdev_device *mdev)
}
events = VFIO_GROUP_NOTIFY_SET_KVM;
- ret = vfio_register_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY, &events,
+ ret = vfio_register_notifier(vfio_dev, VFIO_GROUP_NOTIFY, &events,
&vdev->group_notifier);
if (ret != 0) {
gvt_vgpu_err("vfio_register_notifier for group failed: %d\n",
@@ -961,11 +962,11 @@ static int intel_vgpu_open_device(struct mdev_device
*mdev)
vdev->vfio_group = NULL;
undo_register:
- vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
+ vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
&vdev->group_notifier);
undo_iommu:
- vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
+ vfio_unregister_notifier(vfio_dev, VFIO_IOMMU_NOTIFY,
&vdev->iommu_notifier);
out:
return ret;
@@ -988,6 +989,7 @@ static void __intel_vgpu_release(struct intel_vgpu *vgpu)
struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
struct drm_i915_private *i915 = vgpu->gvt->gt->i915;
struct kvmgt_guest_info *info;
+ struct vfio_device *vfio_dev;
int ret;
if (!handle_valid(vgpu->handle))
@@ -998,12 +1000,13 @@ static void __intel_vgpu_release(struct intel_vgpu *vgpu)
intel_gvt_ops->vgpu_release(vgpu);
- ret = vfio_unregister_notifier(mdev_dev(vdev->mdev), VFIO_IOMMU_NOTIFY,
+ vfio_dev = mdev_legacy_get_vfio_device(vdev->mdev);
+ ret = vfio_unregister_notifier(vfio_dev, VFIO_IOMMU_NOTIFY,
&vdev->iommu_notifier);
drm_WARN(&i915->drm, ret,
"vfio_unregister_notifier for iommu failed: %d\n", ret);
- ret = vfio_unregister_notifier(mdev_dev(vdev->mdev), VFIO_GROUP_NOTIFY,
+ ret = vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
&vdev->group_notifier);
drm_WARN(&i915->drm, ret,
"vfio_unregister_notifier for group failed: %d\n", ret);
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index d8589afac272f1..e1ce24d8fb2555 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -183,7 +183,7 @@ static int vfio_ccw_mdev_open_device(struct vfio_device
*vdev)
private->nb.notifier_call = vfio_ccw_mdev_notifier;
- ret = vfio_register_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,
+ ret = vfio_register_notifier(vdev, VFIO_IOMMU_NOTIFY,
&events, &private->nb);
if (ret)
return ret;
@@ -204,8 +204,7 @@ static int vfio_ccw_mdev_open_device(struct vfio_device
*vdev)
out_unregister:
vfio_ccw_unregister_dev_regions(private);
- vfio_unregister_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,
-&private->nb);
+ vfio_unregister_notifier(vdev, VFIO_IOMMU_NOTIFY, &private->nb);
return ret;
}
@@ -223,7 +222,7 @@ static void vfio_ccw_mdev_close_d
[PATCH 3/9] vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 4 +-
drivers/s390/cio/vfio_ccw_cp.c| 6 +--
drivers/s390/crypto/vfio_ap_ops.c | 8 ++--
drivers/vfio/vfio.c | 40 ++-
include/linux/vfio.h | 4 +-
5 files changed, 24 insertions(+), 38 deletions(-)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 9f26079cacae35..6aeca741dc9be1 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -279,10 +279,10 @@ Translation APIs for Mediated Devices
The following APIs are provided for translating user pfn to host pfn in a VFIO
driver::
- extern int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
+ extern int vfio_pin_pages(struct vfio_device *vdev, unsigned long
*user_pfn,
int npage, int prot, unsigned long *phys_pfn);
- extern int vfio_unpin_pages(struct device *dev, unsigned long *user_pfn,
+ extern int vfio_unpin_pages(struct vfio_device *vdev, unsigned long
*user_pfn,
int npage);
These functions call back into the back-end IOMMU module by using the pin_pages
diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
index af5048a1ba8894..e362cb962a7234 100644
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ b/drivers/s390/cio/vfio_ccw_cp.c
@@ -103,13 +103,13 @@ static int pfn_array_pin(struct pfn_array *pa, struct
vfio_device *vdev)
{
int ret = 0;
- ret = vfio_pin_pages(vdev->dev, pa->pa_iova_pfn, pa->pa_nr,
+ ret = vfio_pin_pages(vdev, pa->pa_iova_pfn, pa->pa_nr,
IOMMU_READ | IOMMU_WRITE, pa->pa_pfn);
if (ret < 0) {
goto err_out;
} else if (ret > 0 && ret != pa->pa_nr) {
- vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, ret);
+ vfio_unpin_pages(vdev, pa->pa_iova_pfn, ret);
ret = -EINVAL;
goto err_out;
}
@@ -127,7 +127,7 @@ static void pfn_array_unpin_free(struct pfn_array *pa,
struct vfio_device *vdev)
{
/* Only unpin if any pages were pinned to begin with */
if (pa->pa_nr)
- vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, pa->pa_nr);
+ vfio_unpin_pages(vdev, pa->pa_iova_pfn, pa->pa_nr);
pa->pa_nr = 0;
kfree(pa->pa_iova_pfn);
}
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 69768061cd7bd9..a10b3369d76c41 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -124,7 +124,7 @@ static void vfio_ap_free_aqic_resources(struct
vfio_ap_queue *q)
q->saved_isc = VFIO_AP_ISC_INVALID;
}
if (q->saved_pfn && !WARN_ON(!q->matrix_mdev)) {
- vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
+ vfio_unpin_pages(&q->matrix_mdev->vdev,
&q->saved_pfn, 1);
q->saved_pfn = 0;
}
@@ -258,7 +258,7 @@ static struct ap_queue_status vfio_ap_irq_enable(struct
vfio_ap_queue *q,
return status;
}
- ret = vfio_pin_pages(mdev_dev(q->matrix_mdev->mdev), &g_pfn, 1,
+ ret = vfio_pin_pages(&q->matrix_mdev->vdev, &g_pfn, 1,
IOMMU_READ | IOMMU_WRITE, &h_pfn);
switch (ret) {
case 1:
@@ -301,7 +301,7 @@ static struct ap_queue_status vfio_ap_irq_enable(struct
vfio_ap_queue *q,
break;
case AP_RESPONSE_OTHERWISE_CHANGED:
/* We could not modify IRQ setings: clear new configuration */
- vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev), &g_pfn, 1);
+ vfio_unpin_pages(&q->matrix_mdev->vdev, &g_pfn, 1);
kvm_s390_gisc_unregister(kvm, isc);
break;
default:
@@ -1250,7 +1250,7 @@ static int vfio_ap_mdev_iommu_notifier(struct
notifier_block *nb,
struct vfio_iommu_type1_dma_unmap *unmap = data;
unsigned long g_pfn = unmap->iova >> PAGE_SHIFT;
- vfio_unpin_pages(mdev_dev(matrix_mdev->mdev), &g_pfn, 1);
+ vfio_unpin_pages(&matrix_mdev->vdev, &g_pfn, 1);
return NOTIFY_OK;
}
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 8a5c46aa2bef61..24b92a45cfc8f1 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -2142,32 +2142,26 @@ EXPORT_SYMBOL(vfio_set_irqs_validate_and_prepare);
* @phys_pfn[out]: array of host PFNs
* Return error or num
[PATCH 5/9] vfio: Pass in a struct vfio_device * to vfio_dma_rw()
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 5 +++--
drivers/vfio/vfio.c | 22 ++
include/linux/vfio.h | 2 +-
3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index df7d87409e3a9c..3302d5d4d92146 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -2184,8 +2184,9 @@ static int kvmgt_rw_gpa(unsigned long handle, unsigned
long gpa,
info = (struct kvmgt_guest_info *)handle;
- return vfio_dma_rw(kvmgt_vdev(info->vgpu)->vfio_group,
- gpa, buf, len, write);
+ return vfio_dma_rw(
+ mdev_legacy_get_vfio_device(kvmgt_vdev(info->vgpu)->mdev),
+ gpa, buf, len, write);
}
static int kvmgt_read_gpa(unsigned long handle, unsigned long gpa,
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 24b92a45cfc8f1..e6e102e017623b 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -2323,32 +2323,28 @@ EXPORT_SYMBOL(vfio_group_unpin_pages);
* As the read/write of user space memory is conducted via the CPUs and is
* not a real device DMA, it is not necessary to pin the user space memory.
*
- * The caller needs to call vfio_group_get_external_user() or
- * vfio_group_get_external_user_from_dev() prior to calling this interface,
- * so as to prevent the VFIO group from disposal in the middle of the call.
- * But it can keep the reference to the VFIO group for several calls into
- * this interface.
- * After finishing using of the VFIO group, the caller needs to release the
- * VFIO group by calling vfio_group_put_external_user().
- *
- * @group [in] : VFIO group
+ * @vdev [in] : VFIO device
* @user_iova [in] : base IOVA of a user space buffer
* @data [in] : pointer to kernel buffer
* @len [in] : kernel buffer length
* @write : indicate read or write
* Return error code on failure or 0 on success.
*/
-int vfio_dma_rw(struct vfio_group *group, dma_addr_t user_iova,
+int vfio_dma_rw(struct vfio_device *vdev, dma_addr_t user_iova,
void *data, size_t len, bool write)
{
struct vfio_container *container;
struct vfio_iommu_driver *driver;
int ret = 0;
- if (!group || !data || len <= 0)
+ if (!data || len <= 0)
return -EINVAL;
- container = group->container;
+ ret = vfio_group_add_container_user(vdev->group);
+ if (ret)
+ return ret;
+
+ container = vdev->group->container;
driver = container->iommu_driver;
if (likely(driver && driver->ops->dma_rw))
@@ -2357,6 +2353,8 @@ int vfio_dma_rw(struct vfio_group *group, dma_addr_t
user_iova,
else
ret = -ENOTTY;
+ vfio_group_try_dissolve_container(vdev->group);
+
return ret;
}
EXPORT_SYMBOL(vfio_dma_rw);
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 8f2a09801a660b..91d46e532ca104 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -161,7 +161,7 @@ extern int vfio_group_pin_pages(struct vfio_group *group,
extern int vfio_group_unpin_pages(struct vfio_group *group,
unsigned long *user_iova_pfn, int npage);
-extern int vfio_dma_rw(struct vfio_group *group, dma_addr_t user_iova,
+extern int vfio_dma_rw(struct vfio_device *vdev, dma_addr_t user_iova,
void *data, size_t len, bool write);
extern struct iommu_domain *vfio_group_iommu_domain(struct vfio_group *group);
--
2.35.1
[PATCH 7/9] drm/i915/gvt: Delete kvmgt_vdev::vfio_group
Nothing references this struct member any more, delete it completely.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index d7c22a2601f3ad..b15dbe9ecd7e15 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -133,7 +133,6 @@ struct kvmgt_vdev {
struct work_struct release_work;
atomic_t released;
struct vfio_device *vfio_device;
- struct vfio_group *vfio_group;
};
static inline struct kvmgt_vdev *kvmgt_vdev(struct intel_vgpu *vgpu)
@@ -911,7 +910,6 @@ static int intel_vgpu_open_device(struct mdev_device *mdev)
struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
unsigned long events;
int ret;
- struct vfio_group *vfio_group;
vdev->iommu_notifier.notifier_call = intel_vgpu_iommu_notifier;
vdev->group_notifier.notifier_call = intel_vgpu_group_notifier;
@@ -934,20 +932,12 @@ static int intel_vgpu_open_device(struct mdev_device
*mdev)
goto undo_iommu;
}
- vfio_group = vfio_group_get_external_user_from_dev(mdev_dev(mdev));
- if (IS_ERR_OR_NULL(vfio_group)) {
- ret = !vfio_group ? -EFAULT : PTR_ERR(vfio_group);
- gvt_vgpu_err("vfio_group_get_external_user_from_dev failed\n");
- goto undo_register;
- }
- vdev->vfio_group = vfio_group;
-
/* Take a module reference as mdev core doesn't take
* a reference for vendor driver.
*/
if (!try_module_get(THIS_MODULE)) {
ret = -ENODEV;
- goto undo_group;
+ goto undo_register;
}
ret = kvmgt_guest_init(mdev);
@@ -962,10 +952,6 @@ static int intel_vgpu_open_device(struct mdev_device *mdev)
undo_module_get:
module_put(THIS_MODULE);
-undo_group:
- vfio_group_put_external_user(vdev->vfio_group);
- vdev->vfio_group = NULL;
-
undo_register:
vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
&vdev->group_notifier);
@@ -1023,7 +1009,6 @@ static void __intel_vgpu_release(struct intel_vgpu *vgpu)
kvmgt_guest_exit(info);
intel_vgpu_release_msi_eventfd_ctx(vgpu);
- vfio_group_put_external_user(vdev->vfio_group);
vdev->kvm = NULL;
vgpu->handle = 0;
--
2.35.1
[PATCH 2/9] vfio/ccw: Remove mdev from struct channel_program
The next patch wants the vfio_device instead. There is no reason to store
a pointer here since we can container_of back to the vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_cp.c | 44 +++--
drivers/s390/cio/vfio_ccw_cp.h | 4 +--
drivers/s390/cio/vfio_ccw_fsm.c | 3 +--
3 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
index 8d1b2771c1aa02..af5048a1ba8894 100644
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ b/drivers/s390/cio/vfio_ccw_cp.c
@@ -16,6 +16,7 @@
#include
#include "vfio_ccw_cp.h"
+#include "vfio_ccw_private.h"
struct pfn_array {
/* Starting guest physical I/O address. */
@@ -98,17 +99,17 @@ static int pfn_array_alloc(struct pfn_array *pa, u64 iova,
unsigned int len)
* If the pin request partially succeeds, or fails completely,
* all pages are left unpinned and a negative error value is returned.
*/
-static int pfn_array_pin(struct pfn_array *pa, struct device *mdev)
+static int pfn_array_pin(struct pfn_array *pa, struct vfio_device *vdev)
{
int ret = 0;
- ret = vfio_pin_pages(mdev, pa->pa_iova_pfn, pa->pa_nr,
+ ret = vfio_pin_pages(vdev->dev, pa->pa_iova_pfn, pa->pa_nr,
IOMMU_READ | IOMMU_WRITE, pa->pa_pfn);
if (ret < 0) {
goto err_out;
} else if (ret > 0 && ret != pa->pa_nr) {
- vfio_unpin_pages(mdev, pa->pa_iova_pfn, ret);
+ vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, ret);
ret = -EINVAL;
goto err_out;
}
@@ -122,11 +123,11 @@ static int pfn_array_pin(struct pfn_array *pa, struct
device *mdev)
}
/* Unpin the pages before releasing the memory. */
-static void pfn_array_unpin_free(struct pfn_array *pa, struct device *mdev)
+static void pfn_array_unpin_free(struct pfn_array *pa, struct vfio_device
*vdev)
{
/* Only unpin if any pages were pinned to begin with */
if (pa->pa_nr)
- vfio_unpin_pages(mdev, pa->pa_iova_pfn, pa->pa_nr);
+ vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, pa->pa_nr);
pa->pa_nr = 0;
kfree(pa->pa_iova_pfn);
}
@@ -190,7 +191,7 @@ static void convert_ccw0_to_ccw1(struct ccw1 *source,
unsigned long len)
* Within the domain (@mdev), copy @n bytes from a guest physical
* address (@iova) to a host physical address (@to).
*/
-static long copy_from_iova(struct device *mdev,
+static long copy_from_iova(struct vfio_device *vdev,
void *to, u64 iova,
unsigned long n)
{
@@ -203,9 +204,9 @@ static long copy_from_iova(struct device *mdev,
if (ret < 0)
return ret;
- ret = pfn_array_pin(&pa, mdev);
+ ret = pfn_array_pin(&pa, vdev);
if (ret < 0) {
- pfn_array_unpin_free(&pa, mdev);
+ pfn_array_unpin_free(&pa, vdev);
return ret;
}
@@ -226,7 +227,7 @@ static long copy_from_iova(struct device *mdev,
break;
}
- pfn_array_unpin_free(&pa, mdev);
+ pfn_array_unpin_free(&pa, vdev);
return l;
}
@@ -423,11 +424,13 @@ static int ccwchain_loop_tic(struct ccwchain *chain,
static int ccwchain_handle_ccw(u32 cda, struct channel_program *cp)
{
+ struct vfio_device *vdev =
+ &container_of(cp, struct vfio_ccw_private, cp)->vdev;
struct ccwchain *chain;
int len, ret;
/* Copy 2K (the most we support today) of possible CCWs */
- len = copy_from_iova(cp->mdev, cp->guest_cp, cda,
+ len = copy_from_iova(vdev, cp->guest_cp, cda,
CCWCHAIN_LEN_MAX * sizeof(struct ccw1));
if (len)
return len;
@@ -508,6 +511,8 @@ static int ccwchain_fetch_direct(struct ccwchain *chain,
int idx,
struct channel_program *cp)
{
+ struct vfio_device *vdev =
+ &container_of(cp, struct vfio_ccw_private, cp)->vdev;
struct ccw1 *ccw;
struct pfn_array *pa;
u64 iova;
@@ -526,7 +531,7 @@ static int ccwchain_fetch_direct(struct ccwchain *chain,
if (ccw_is_idal(ccw)) {
/* Read first IDAW to see if it's 4K-aligned or not. */
/* All subsequent IDAws will be 4K-aligned. */
- ret = copy_from_iova(cp->mdev, &iova, ccw->cda, sizeof(iova));
+ ret = copy_from_iova(vdev, &iova, ccw->cda, sizeof(iova));
if (ret)
return ret;
} else {
@@ -555,7 +560,7 @@ static int ccwchain_fetch_direct(struct ccwchain *chain,
if (ccw_is_idal(ccw)) {
/* Copy guest IDAL into host IDAL */
- ret = copy_from_iova(cp->mdev, idaws, ccw->cda, idal_len);
+ ret = copy_from_iova(vdev, idaws, ccw->cda, idal_len);
[PATCH 6/9] drm/i915/gvt: Add missing module_put() in error unwind
try_module_get() must be undone if kvmgt_guest_init() fails or we leak the
module reference count on the failure path since the close_device op is
never called in this case.
Fixes: 9bdb073464d6 ("drm/i915/gvt: Change KVMGT as self load module")
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3302d5d4d92146..d7c22a2601f3ad 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -952,13 +952,16 @@ static int intel_vgpu_open_device(struct mdev_device
*mdev)
ret = kvmgt_guest_init(mdev);
if (ret)
- goto undo_group;
+ goto undo_module_get;
intel_gvt_ops->vgpu_activate(vgpu);
atomic_set(&vdev->released, 0);
return ret;
+undo_module_get:
+ module_put(THIS_MODULE);
+
undo_group:
vfio_group_put_external_user(vdev->vfio_group);
vdev->vfio_group = NULL;
--
2.35.1
[PATCH 9/9] vfio: Remove calls to vfio_group_add_container_user()
When the open_device() op is called the container_users is incremented and held incremented until close_device(). Thus, so long as drivers call functions within their open_device()/close_device() region they do not need to worry about the container_users. These functions can all only be called between open_device()/close_device(): vfio_pin_pages() vfio_unpin_pages() vfio_dma_rw() vfio_register_notifier() vfio_unregister_notifier() So eliminate the calls to vfio_group_add_container_user() and add a simple WARN_ON to detect mis-use by drivers. Signed-off-by: Jason Gunthorpe --- drivers/vfio/vfio.c | 67 + 1 file changed, 13 insertions(+), 54 deletions(-) diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c index 3d75505bf3cc26..ab0c3f5635905c 100644 --- a/drivers/vfio/vfio.c +++ b/drivers/vfio/vfio.c @@ -2121,9 +2121,8 @@ int vfio_pin_pages(struct vfio_device *vdev, unsigned long *user_pfn, int npage, if (group->dev_counter > 1) return -EINVAL; - ret = vfio_group_add_container_user(group); - if (ret) - return ret; + if (WARN_ON(!READ_ONCE(vdev->open_count))) + return -EINVAL; container = group->container; driver = container->iommu_driver; @@ -2134,8 +2133,6 @@ int vfio_pin_pages(struct vfio_device *vdev, unsigned long *user_pfn, int npage, else ret = -ENOTTY; - vfio_group_try_dissolve_container(group); - return ret; } EXPORT_SYMBOL(vfio_pin_pages); @@ -2162,9 +2159,8 @@ int vfio_unpin_pages(struct vfio_device *vdev, unsigned long *user_pfn, if (npage > VFIO_PIN_PAGES_MAX_ENTRIES) return -E2BIG; - ret = vfio_group_add_container_user(vdev->group); - if (ret) - return ret; + if (WARN_ON(!READ_ONCE(vdev->open_count))) + return -EINVAL; container = vdev->group->container; driver = container->iommu_driver; @@ -2174,8 +2170,6 @@ int vfio_unpin_pages(struct vfio_device *vdev, unsigned long *user_pfn, else ret = -ENOTTY; - vfio_group_try_dissolve_container(vdev->group); - return ret; } EXPORT_SYMBOL(vfio_unpin_pages); @@ -2207,9 +2201,8 @@ int vfio_dma_rw(struct vfio_device *vdev, dma_addr_t user_iova, if (!data || len <= 0) return -EINVAL; - ret = vfio_group_add_container_user(vdev->group); - if (ret) - return ret; + if (WARN_ON(!READ_ONCE(vdev->open_count))) + return -EINVAL; container = vdev->group->container; driver = container->iommu_driver; @@ -2219,9 +2212,6 @@ int vfio_dma_rw(struct vfio_device *vdev, dma_addr_t user_iova, user_iova, data, len, write); else ret = -ENOTTY; - - vfio_group_try_dissolve_container(vdev->group); - return ret; } EXPORT_SYMBOL(vfio_dma_rw); @@ -2234,10 +2224,6 @@ static int vfio_register_iommu_notifier(struct vfio_group *group, struct vfio_iommu_driver *driver; int ret; - ret = vfio_group_add_container_user(group); - if (ret) - return -EINVAL; - container = group->container; driver = container->iommu_driver; if (likely(driver && driver->ops->register_notifier)) @@ -2245,9 +2231,6 @@ static int vfio_register_iommu_notifier(struct vfio_group *group, events, nb); else ret = -ENOTTY; - - vfio_group_try_dissolve_container(group); - return ret; } @@ -2258,10 +2241,6 @@ static int vfio_unregister_iommu_notifier(struct vfio_group *group, struct vfio_iommu_driver *driver; int ret; - ret = vfio_group_add_container_user(group); - if (ret) - return -EINVAL; - container = group->container; driver = container->iommu_driver; if (likely(driver && driver->ops->unregister_notifier)) @@ -2269,9 +2248,6 @@ static int vfio_unregister_iommu_notifier(struct vfio_group *group, nb); else ret = -ENOTTY; - - vfio_group_try_dissolve_container(group); - return ret; } @@ -2300,10 +2276,6 @@ static int vfio_register_group_notifier(struct vfio_group *group, if (*events) return -EINVAL; - ret = vfio_group_add_container_user(group); - if (ret) - return -EINVAL; - ret = blocking_notifier_chain_register(&group->notifier, nb); /* @@ -2313,25 +2285,6 @@ static int vfio_register_group_notifier(struct vfio_group *group, if (!ret && set_kvm && group->kvm) blocking_notifier_call_chain(&group->notifier, VFIO_GROUP_NOTIFY_SET_KVM, group->kvm); - - vfio_group_try_dissol
[PATCH 4/9] drm/i915/gvt: Change from vfio_group_(un)pin_pages to vfio_(un)pin_pages
Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
reason to use a group interface here, kvmgt has easy access to a
vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index bb59d21cf898ab..df7d87409e3a9c 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -268,6 +268,7 @@ static void gvt_unpin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
{
struct drm_i915_private *i915 = vgpu->gvt->gt->i915;
struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
+ struct vfio_device *vfio_dev = mdev_legacy_get_vfio_device(vdev->mdev);
int total_pages;
int npage;
int ret;
@@ -277,7 +278,7 @@ static void gvt_unpin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
for (npage = 0; npage < total_pages; npage++) {
unsigned long cur_gfn = gfn + npage;
- ret = vfio_group_unpin_pages(vdev->vfio_group, &cur_gfn, 1);
+ ret = vfio_unpin_pages(vfio_dev, &cur_gfn, 1);
drm_WARN_ON(&i915->drm, ret != 1);
}
}
@@ -287,6 +288,7 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
unsigned long size, struct page **page)
{
struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
+ struct vfio_device *vfio_dev = mdev_legacy_get_vfio_device(vdev->mdev);
unsigned long base_pfn = 0;
int total_pages;
int npage;
@@ -301,8 +303,8 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
unsigned long cur_gfn = gfn + npage;
unsigned long pfn;
- ret = vfio_group_pin_pages(vdev->vfio_group, &cur_gfn, 1,
- IOMMU_READ | IOMMU_WRITE, &pfn);
+ ret = vfio_pin_pages(vfio_dev, &cur_gfn, 1,
+IOMMU_READ | IOMMU_WRITE, &pfn);
if (ret != 1) {
gvt_vgpu_err("vfio_pin_pages failed for gfn 0x%lx, ret
%d\n",
cur_gfn, ret);
--
2.35.1
[PATCH 8/9] vfio: Remove dead code
Now that callers have been updated to use the vfio_device APIs the driver
facing group interface is no longer used, delete it:
- vfio_group_get_external_user_from_dev()
- vfio_group_pin_pages()
- vfio_group_unpin_pages()
- vfio_group_iommu_domain()
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 151 ---
include/linux/vfio.h | 11
2 files changed, 162 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index e6e102e017623b..3d75505bf3cc26 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1947,44 +1947,6 @@ struct vfio_group *vfio_group_get_external_user(struct
file *filep)
}
EXPORT_SYMBOL_GPL(vfio_group_get_external_user);
-/*
- * External user API, exported by symbols to be linked dynamically.
- * The external user passes in a device pointer
- * to verify that:
- * - A VFIO group is assiciated with the device;
- * - IOMMU is set for the group.
- * If both checks passed, vfio_group_get_external_user_from_dev()
- * increments the container user counter to prevent the VFIO group
- * from disposal before external user exits and returns the pointer
- * to the VFIO group.
- *
- * When the external user finishes using the VFIO group, it calls
- * vfio_group_put_external_user() to release the VFIO group and
- * decrement the container user counter.
- *
- * @dev [in] : device
- * Return error PTR or pointer to VFIO group.
- */
-
-struct vfio_group *vfio_group_get_external_user_from_dev(struct device *dev)
-{
- struct vfio_group *group;
- int ret;
-
- group = vfio_group_get_from_dev(dev);
- if (!group)
- return ERR_PTR(-ENODEV);
-
- ret = vfio_group_add_container_user(group);
- if (ret) {
- vfio_group_put(group);
- return ERR_PTR(ret);
- }
-
- return group;
-}
-EXPORT_SYMBOL_GPL(vfio_group_get_external_user_from_dev);
-
void vfio_group_put_external_user(struct vfio_group *group)
{
vfio_group_try_dissolve_container(group);
@@ -2218,101 +2180,6 @@ int vfio_unpin_pages(struct vfio_device *vdev, unsigned
long *user_pfn,
}
EXPORT_SYMBOL(vfio_unpin_pages);
-/*
- * Pin a set of guest IOVA PFNs and return their associated host PFNs for a
- * VFIO group.
- *
- * The caller needs to call vfio_group_get_external_user() or
- * vfio_group_get_external_user_from_dev() prior to calling this interface,
- * so as to prevent the VFIO group from disposal in the middle of the call.
- * But it can keep the reference to the VFIO group for several calls into
- * this interface.
- * After finishing using of the VFIO group, the caller needs to release the
- * VFIO group by calling vfio_group_put_external_user().
- *
- * @group [in] : VFIO group
- * @user_iova_pfn [in] : array of user/guest IOVA PFNs to be pinned.
- * @npage [in] : count of elements in user_iova_pfn array.
- * This count should not be greater
- * VFIO_PIN_PAGES_MAX_ENTRIES.
- * @prot [in] : protection flags
- * @phys_pfn [out] : array of host PFNs
- * Return error or number of pages pinned.
- */
-int vfio_group_pin_pages(struct vfio_group *group,
-unsigned long *user_iova_pfn, int npage,
-int prot, unsigned long *phys_pfn)
-{
- struct vfio_container *container;
- struct vfio_iommu_driver *driver;
- int ret;
-
- if (!group || !user_iova_pfn || !phys_pfn || !npage)
- return -EINVAL;
-
- if (group->dev_counter > 1)
- return -EINVAL;
-
- if (npage > VFIO_PIN_PAGES_MAX_ENTRIES)
- return -E2BIG;
-
- container = group->container;
- driver = container->iommu_driver;
- if (likely(driver && driver->ops->pin_pages))
- ret = driver->ops->pin_pages(container->iommu_data,
-group->iommu_group, user_iova_pfn,
-npage, prot, phys_pfn);
- else
- ret = -ENOTTY;
-
- return ret;
-}
-EXPORT_SYMBOL(vfio_group_pin_pages);
-
-/*
- * Unpin a set of guest IOVA PFNs for a VFIO group.
- *
- * The caller needs to call vfio_group_get_external_user() or
- * vfio_group_get_external_user_from_dev() prior to calling this interface,
- * so as to prevent the VFIO group from disposal in the middle of the call.
- * But it can keep the reference to the VFIO group for several calls into
- * this interface.
- * After finishing using of the VFIO group, the caller needs to release the
- * VFIO group by calling vfio_group_put_external_user().
- *
- * @group [in] : vfio group
- * @user_iova_pfn [in] : array of user/guest IOVA PFNs to be unpinned.
- * @npage [in] : count of elements in user_iova_pfn array.
- * This count should not be greater than
- * VFIO_PIN_PAGES_MAX_ENTRIES.
- * Return error or number of pages unp
[PATCH 0/9] Make the rest of the VFIO driver interface use vfio_device
Prior series have transformed other parts of VFIO from working on struct device or struct vfio_group into working directly on struct vfio_device. Based on that work we now have vfio_device's readily available in all the drivers. Update the rest of the driver facing API to use vfio_device as an input. The following are switched from struct device to struct vfio_device: vfio_register_notifier() vfio_unregister_notifier() vfio_pin_pages() vfio_unpin_pages() vfio_dma_rw() The following group APIs are obsoleted and removed by just using struct vfio_device with the above: vfio_group_pin_pages() vfio_group_unpin_pages() vfio_group_iommu_domain() vfio_group_get_external_user_from_dev() To retain the performance of the new device APIs relative to their group versions optimize how vfio_group_add_container_user() is used to avoid calling it when the driver must already guarantee the device is open and the container_users incrd. The remaining exported VFIO group interfaces are only used by kvm, and are addressed by a parallel series. There is a conflict with Christoph's gvt rework here: https://lore.kernel.org/all/20220411141403.86980-1-...@lst.de/ I've organized this so it is independent of Christoph's series, by adding the temporary mdev_legacy_get_vfio_device(), however it is easy for me to rebase. We can decide what to do as we see what becomes mergable. My preference would be to see Christoph's series merged into the drm&vfio trees and we do both series this cycle. I have a followup series that needs this. This is also part of the iommufd work - moving the driver facing interface to vfio_device provides a much cleaner path to integrate with iommufd. Signed-off-by: Jason Gunthorpe Jason Gunthorpe (9): vfio: Make vfio_(un)register_notifier accept a vfio_device vfio/ccw: Remove mdev from struct channel_program vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages() drm/i915/gvt: Change from vfio_group_(un)pin_pages to vfio_(un)pin_pages vfio: Pass in a struct vfio_device * to vfio_dma_rw() drm/i915/gvt: Add missing module_put() in error unwind drm/i915/gvt: Delete kvmgt_vdev::vfio_group vfio: Remove dead code vfio: Remove calls to vfio_group_add_container_user() .../driver-api/vfio-mediated-device.rst | 4 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 48 ++- drivers/s390/cio/vfio_ccw_cp.c| 44 +-- drivers/s390/cio/vfio_ccw_cp.h| 4 +- drivers/s390/cio/vfio_ccw_fsm.c | 3 +- drivers/s390/cio/vfio_ccw_ops.c | 7 +- drivers/s390/crypto/vfio_ap_ops.c | 22 +- drivers/vfio/mdev/vfio_mdev.c | 12 + drivers/vfio/vfio.c | 283 ++ include/linux/mdev.h | 1 + include/linux/vfio.h | 21 +- 11 files changed, 115 insertions(+), 334 deletions(-) base-commit: ce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e -- 2.35.1
[PATCH v3 0/5] drm/solomon: Add SSD130x OLED displays SPI support
Hello, This series adds a ssd130x-spi driver that provides a 4-wire SPI transport support for SSD130x OLED controllers that can be accessed over a SPI bus. The driver is quite similar to existing ssd130x-i2c driver that is used by I2C controllers, but there is a difference in the protocol used by SSD130x depending on the transport used. The details are in patch #4 description. Patch #1 just makes the current ssd130x-i2c compatible strings in the DT binding to be deprecated, and add new ones that don't have an "fb-i2c". Patch #2 extends the DT binding with the properties needed to support SPI. Patch #3 adds the new compatible strings to the OF device ID table in the ssd130x-i2c DRM driver and deprecate the old ones. Patch #4 moves the device info for the different SSD130x variants from the ssd130x-i2c transport driver to the ssd130x core driver. Finally patch #5 adds the ssd130x-spi DRM driver for the OLED controllers that come with a 4-wire SPI interface, instead of an I2C interface. This is a v3 that addresses the issues pointed out in v2. Best regards, Javier Changes in v3: - Drop the "sinowealth,sh1106-i2c", wasn't in a released version (Chen-Yu Tsai) - Continue enforcing required properties for deprecated strings (Maxime Ripard) - Add a comment to the properties required for SPI (Geert Uytterhoeven) - Drop the "sinowealth,sh1106-i2c", wasn't in a released version (Chen-Yu Tsai) - s/it/they in the commit description (Geert Uytterhoeven) - Drop unnecessary blank line (Geert Uytterhoeven) - Export variants array and use &info[ID] in device table (Andy Shevchenko) - Drop ssd130x_spi_get_dc() helper and open code it (Geert Uytterhoeven) - Export variants array and use &info[ID] in device table (Andy Shevchenko) - Add Geert Uytterhoeven's Reviewed-by tag to patches. Changes in v2: - Drop the -i2c suffixes from the compatible strings too (Geert Uytterhoeven) - Don't add compatible strings with an "-spi" suffix (Geert Uytterhoeven) - Use the compatible strings that don't have "fb-i2c" (Geert Uytterhoeven). - Drop ssd13x_variant_to_info() and just use the array index (Neil Armstrong). - Add the same compatible strings than I2C (Geert Uytterhoeven) - Add Mark Brown's Acked-by tag to all patches. Javier Martinez Canillas (5): dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings dt-bindings: display: ssd1307fb: Extend schema for SPI controllers drm/solomon: Add ssd130x new compatible strings and deprecate old ones. drm/solomon: Move device info from ssd130x-i2c to the core driver drm/solomon: Add SSD130x OLED displays SPI support .../bindings/display/solomon,ssd1307fb.yaml | 82 ++-- drivers/gpu/drm/solomon/Kconfig | 9 + drivers/gpu/drm/solomon/Makefile | 1 + drivers/gpu/drm/solomon/ssd130x-i2c.c | 62 +++--- drivers/gpu/drm/solomon/ssd130x-spi.c | 177 ++ drivers/gpu/drm/solomon/ssd130x.c | 36 +++- drivers/gpu/drm/solomon/ssd130x.h | 14 ++ 7 files changed, 324 insertions(+), 57 deletions(-) create mode 100644 drivers/gpu/drm/solomon/ssd130x-spi.c -- 2.35.1
[PATCH v3 1/5] dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings
The current compatible strings for SSD130x I2C controllers contain both an
"fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
and also that are for devices that can be accessed over an I2C bus.
But a DT is supposed to describe the hardware and not Linux implementation
details. So let's deprecate those compatible strings and add new ones that
only contain the vendor and device name, without any of these suffixes.
These will just describe the device and can be matched by both I2C and SPI
DRM drivers. The required properties should still be enforced for old ones.
While being there, just drop the "sinowealth,sh1106-i2c" compatible string
since that was never present in a released Linux version.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v3:
- Drop the "sinowealth,sh1106-i2c", wasn't in a released version (Chen-Yu Tsai)
- Continue enforcing required properties for deprecated strings (Maxime Ripard)
Changes in v2:
- Drop the -i2c suffixes from the compatible strings too (Geert Uytterhoeven)
.../bindings/display/solomon,ssd1307fb.yaml | 44 +--
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
index ade61d502edd..7653b6c3fcb6 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
@@ -12,12 +12,22 @@ maintainers:
properties:
compatible:
-enum:
- - sinowealth,sh1106-i2c
- - solomon,ssd1305fb-i2c
- - solomon,ssd1306fb-i2c
- - solomon,ssd1307fb-i2c
- - solomon,ssd1309fb-i2c
+oneOf:
+ # Deprecated compatible strings
+ - items:
+ - enum:
+ - solomon,ssd1305fb-i2c
+ - solomon,ssd1306fb-i2c
+ - solomon,ssd1307fb-i2c
+ - solomon,ssd1309fb-i2c
+deprecated: true
+ - items:
+ - enum:
+ - sinowealth,sh1106
+ - solomon,ssd1305
+ - solomon,ssd1306
+ - solomon,ssd1307
+ - solomon,ssd1309
reg:
maxItems: 1
@@ -136,7 +146,7 @@ allOf:
properties:
compatible:
contains:
-const: sinowealth,sh1106-i2c
+const: sinowealth,sh1106
then:
properties:
solomon,dclk-div:
@@ -148,7 +158,9 @@ allOf:
properties:
compatible:
contains:
-const: solomon,ssd1305fb-i2c
+enum:
+ - solomon,ssd1305-i2c
+ - solomon,ssd1305
then:
properties:
solomon,dclk-div:
@@ -160,7 +172,9 @@ allOf:
properties:
compatible:
contains:
-const: solomon,ssd1306fb-i2c
+enum:
+ - solomon,ssd1306-i2c
+ - solomon,ssd1306
then:
properties:
solomon,dclk-div:
@@ -172,7 +186,9 @@ allOf:
properties:
compatible:
contains:
-const: solomon,ssd1307fb-i2c
+enum:
+ - solomon,ssd1307-i2c
+ - solomon,ssd1307
then:
properties:
solomon,dclk-div:
@@ -186,7 +202,9 @@ allOf:
properties:
compatible:
contains:
-const: solomon,ssd1309fb-i2c
+enum:
+ - solomon,ssd1309-i2c
+ - solomon,ssd1309
then:
properties:
solomon,dclk-div:
@@ -203,14 +221,14 @@ examples:
#size-cells = <0>;
ssd1307: oled@3c {
-compatible = "solomon,ssd1307fb-i2c";
+compatible = "solomon,ssd1307";
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7>;
};
ssd1306: oled@3d {
-compatible = "solomon,ssd1306fb-i2c";
+compatible = "solomon,ssd1306";
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7>;
--
2.35.1
[PATCH v3 2/5] dt-bindings: display: ssd1307fb: Extend schema for SPI controllers
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the properties and examples for OLED devices under SPI.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v3:
- Add a comment to the properties required for SPI (Geert Uytterhoeven)
Changes in v2:
- Don't add compatible strings with an "-spi" suffix (Geert Uytterhoeven)
.../bindings/display/solomon,ssd1307fb.yaml | 38 ++-
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
index 7653b6c3fcb6..7d7de92df86f 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
@@ -38,9 +38,16 @@ properties:
reset-gpios:
maxItems: 1
+ # Only required for SPI
+ dc-gpios:
+maxItems: 1
+
vbat-supply:
description: The supply for VBAT
+ # Only required for SPI
+ spi-max-frequency: true
+
solomon,height:
$ref: /schemas/types.yaml#/definitions/uint32
default: 16
@@ -220,14 +227,14 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
-ssd1307: oled@3c {
+ssd1307_i2c: oled@3c {
compatible = "solomon,ssd1307";
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7>;
};
-ssd1306: oled@3d {
+ssd1306_i2c: oled@3d {
compatible = "solomon,ssd1306";
reg = <0x3c>;
pwms = <&pwm 4 3000>;
@@ -238,3 +245,30 @@ examples:
solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>;
};
};
+ - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ssd1307_spi: oled@0 {
+compatible = "solomon,ssd1307";
+reg = <0x0>;
+pwms = <&pwm 4 3000>;
+reset-gpios = <&gpio2 7>;
+dc-gpios = <&gpio2 8>;
+spi-max-frequency = <1000>;
+};
+
+ssd1306_spi: oled@1 {
+compatible = "solomon,ssd1306";
+reg = <0x1>;
+pwms = <&pwm 4 3000>;
+reset-gpios = <&gpio2 7>;
+dc-gpios = <&gpio2 8>;
+spi-max-frequency = <1000>;
+solomon,com-lrremap;
+solomon,com-invdir;
+solomon,com-offset = <32>;
+solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>;
+};
+};
--
2.35.1
[PATCH v3 3/5] drm/solomon: Add ssd130x new compatible strings and deprecate old ones.
The current compatible strings for SSD130x I2C controllers contain an "fb"
and "-i2c" suffixes. These have been deprecated and more correct ones were
added, that don't encode a subsystem or bus used to interface the devices.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v3:
- Drop the "sinowealth,sh1106-i2c", wasn't in a released version (Chen-Yu Tsai)
Changes in v2:
- Use the compatible strings that don't have "fb-i2c" (Geert Uytterhoeven).
drivers/gpu/drm/solomon/ssd130x-i2c.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
index d099b241dd3f..45867ef2bc8b 100644
--- a/drivers/gpu/drm/solomon/ssd130x-i2c.c
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -88,9 +88,26 @@ static struct ssd130x_deviceinfo ssd130x_ssd1309_deviceinfo
= {
static const struct of_device_id ssd130x_of_match[] = {
{
- .compatible = "sinowealth,sh1106-i2c",
+ .compatible = "sinowealth,sh1106",
.data = &ssd130x_sh1106_deviceinfo,
},
+ {
+ .compatible = "solomon,ssd1305",
+ .data = &ssd130x_ssd1305_deviceinfo,
+ },
+ {
+ .compatible = "solomon,ssd1306",
+ .data = &ssd130x_ssd1306_deviceinfo,
+ },
+ {
+ .compatible = "solomon,ssd1307",
+ .data = &ssd130x_ssd1307_deviceinfo,
+ },
+ {
+ .compatible = "solomon,ssd1309",
+ .data = &ssd130x_ssd1309_deviceinfo,
+ },
+ /* Deprecated but kept for backward compatibility */
{
.compatible = "solomon,ssd1305fb-i2c",
.data = &ssd130x_ssd1305_deviceinfo,
--
2.35.1
[PATCH v3 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
These are declared in the ssd130x-i2c transport driver but the information
is not I2C specific, and could be used by other SSD130x transport drivers.
Move them to the ssd130x core driver and just set the OF device entries to
an ID that could be used to lookup the correct device info from an array.
While being there, also move the SSD130X_DATA and SSD130X_COMMAND control
bytes. Since even though they are used by the I2C interface, they could
also be useful for other transport protocols such as SPI.
Suggested-by: Chen-Yu Tsai
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v3:
- s/it/they in the commit description (Geert Uytterhoeven)
- Drop unnecessary blank line (Geert Uytterhoeven)
- Export variants array and use &info[ID] in device table (Andy Shevchenko)
Changes in v2:
- Drop ssd13x_variant_to_info() and just use the array index (Neil Armstrong).
drivers/gpu/drm/solomon/ssd130x-i2c.c | 51 +--
drivers/gpu/drm/solomon/ssd130x.c | 36 +--
drivers/gpu/drm/solomon/ssd130x.h | 14
3 files changed, 56 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
index 45867ef2bc8b..13b0713e31ad 100644
--- a/drivers/gpu/drm/solomon/ssd130x-i2c.c
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -53,76 +53,43 @@ static void ssd130x_i2c_shutdown(struct i2c_client *client)
ssd130x_shutdown(ssd130x);
}
-static struct ssd130x_deviceinfo ssd130x_sh1106_deviceinfo = {
- .default_vcomh = 0x40,
- .default_dclk_div = 1,
- .default_dclk_frq = 5,
- .page_mode_only = 1,
-};
-
-static struct ssd130x_deviceinfo ssd130x_ssd1305_deviceinfo = {
- .default_vcomh = 0x34,
- .default_dclk_div = 1,
- .default_dclk_frq = 7,
-};
-
-static struct ssd130x_deviceinfo ssd130x_ssd1306_deviceinfo = {
- .default_vcomh = 0x20,
- .default_dclk_div = 1,
- .default_dclk_frq = 8,
- .need_chargepump = 1,
-};
-
-static struct ssd130x_deviceinfo ssd130x_ssd1307_deviceinfo = {
- .default_vcomh = 0x20,
- .default_dclk_div = 2,
- .default_dclk_frq = 12,
- .need_pwm = 1,
-};
-
-static struct ssd130x_deviceinfo ssd130x_ssd1309_deviceinfo = {
- .default_vcomh = 0x34,
- .default_dclk_div = 1,
- .default_dclk_frq = 10,
-};
-
static const struct of_device_id ssd130x_of_match[] = {
{
.compatible = "sinowealth,sh1106",
- .data = &ssd130x_sh1106_deviceinfo,
+ .data = &ssd130x_variants[SH1106_ID],
},
{
.compatible = "solomon,ssd1305",
- .data = &ssd130x_ssd1305_deviceinfo,
+ .data = &ssd130x_variants[SSD1305_ID],
},
{
.compatible = "solomon,ssd1306",
- .data = &ssd130x_ssd1306_deviceinfo,
+ .data = &ssd130x_variants[SSD1306_ID],
},
{
.compatible = "solomon,ssd1307",
- .data = &ssd130x_ssd1307_deviceinfo,
+ .data = &ssd130x_variants[SSD1307_ID],
},
{
.compatible = "solomon,ssd1309",
- .data = &ssd130x_ssd1309_deviceinfo,
+ .data = &ssd130x_variants[SSD1309_ID],
},
/* Deprecated but kept for backward compatibility */
{
.compatible = "solomon,ssd1305fb-i2c",
- .data = &ssd130x_ssd1305_deviceinfo,
+ .data = &ssd130x_variants[SSD1305_ID],
},
{
.compatible = "solomon,ssd1306fb-i2c",
- .data = &ssd130x_ssd1306_deviceinfo,
+ .data = &ssd130x_variants[SSD1306_ID],
},
{
.compatible = "solomon,ssd1307fb-i2c",
- .data = &ssd130x_ssd1307_deviceinfo,
+ .data = &ssd130x_variants[SSD1307_ID],
},
{
.compatible = "solomon,ssd1309fb-i2c",
- .data = &ssd130x_ssd1309_deviceinfo,
+ .data = &ssd130x_variants[SSD1309_ID],
},
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index a7e784518c69..c9b80ab8727b 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -39,11 +39,9 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-#define SSD130X_DATA 0x40
-#define SSD130X_COMMAND0x80
-
#define SSD130X_PAGE_COL_START_LOW 0x00
#define SSD130X_PAGE_COL_START_HIGH0x10
+
#define SSD130X_SET_ADDRESS_MODE 0x20
#define SSD130X_SET_COL_RANGE 0x21
#define SSD130X_SET_PAGE_RANGE 0x22
@@ -94,6 +92,38 @@
#define MAX_CONTRAST 255
+const struct ssd130x_deviceinfo ssd130x_variants[] = {
+ [SH1106_ID] = {
+ .d
[PATCH v3 5/5] drm/solomon: Add SSD130x OLED displays SPI support
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over SPI.
There is a difference in the communication protocol when using 4-wire SPI
instead of I2C. For the latter, a control byte that contains a D/C# field
has to be sent. This field tells the controller whether the data has to be
written to the command register or to the graphics display data memory.
But for 4-wire SPI that control byte is not used, instead a real D/C# line
must be pulled HIGH for commands data and LOW for graphics display data.
For this reason the standard SPI regmap can't be used and a custom .write
bus handler is needed.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
---
Changes in v3:
- Drop ssd130x_spi_get_dc() helper and open code it (Geert Uytterhoeven)
- Export variants array and use &info[ID] in device table (Andy Shevchenko)
Changes in v2:
- Add the same compatible strings than I2C (Geert Uytterhoeven)
drivers/gpu/drm/solomon/Kconfig | 9 ++
drivers/gpu/drm/solomon/Makefile | 1 +
drivers/gpu/drm/solomon/ssd130x-spi.c | 177 ++
3 files changed, 187 insertions(+)
create mode 100644 drivers/gpu/drm/solomon/ssd130x-spi.c
diff --git a/drivers/gpu/drm/solomon/Kconfig b/drivers/gpu/drm/solomon/Kconfig
index 8c0a0c788385..e170716d976b 100644
--- a/drivers/gpu/drm/solomon/Kconfig
+++ b/drivers/gpu/drm/solomon/Kconfig
@@ -20,3 +20,12 @@ config DRM_SSD130X_I2C
I2C bus.
If M is selected the module will be called ssd130x-i2c.
+
+config DRM_SSD130X_SPI
+ tristate "DRM support for Solomon SSD130X OLED displays (SPI bus)"
+ depends on DRM_SSD130X && SPI
+ select REGMAP
+ help
+ Say Y here if the SSD130x OLED display is connected via SPI bus.
+
+ If M is selected the module will be called ssd130x-spi.
diff --git a/drivers/gpu/drm/solomon/Makefile b/drivers/gpu/drm/solomon/Makefile
index 4bfc5acb0447..b5fc792257d7 100644
--- a/drivers/gpu/drm/solomon/Makefile
+++ b/drivers/gpu/drm/solomon/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_DRM_SSD130X) += ssd130x.o
obj-$(CONFIG_DRM_SSD130X_I2C) += ssd130x-i2c.o
+obj-$(CONFIG_DRM_SSD130X_SPI) += ssd130x-spi.o
diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c
b/drivers/gpu/drm/solomon/ssd130x-spi.c
new file mode 100644
index ..4fda420ae0a6
--- /dev/null
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * DRM driver for Solomon SSD130X OLED displays (SPI bus)
+ *
+ * Copyright 2022 Red Hat Inc.
+ * Authors: Javier Martinez Canillas
+ */
+#include
+#include
+
+#include "ssd130x.h"
+
+#define DRIVER_NAME"ssd130x-spi"
+#define DRIVER_DESC"DRM driver for Solomon SSD130X OLED displays (SPI)"
+
+struct ssd130x_spi_transport {
+ struct spi_device *spi;
+ struct gpio_desc *dc;
+};
+
+static const struct regmap_config ssd130x_spi_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+/*
+ * The regmap bus .write handler, it is just a wrapper around spi_write()
+ * but toggling the Data/Command control pin (D/C#). Since for 4-wire SPI
+ * a D/C# pin is used, in contrast with I2C where a control byte is sent,
+ * prior to every data byte, that contains a bit with the D/C# value.
+ *
+ * These control bytes are considered registers by the ssd130x core driver
+ * and can be used by the ssd130x SPI driver to determine if the data sent
+ * is for a command register or for the Graphic Display Data RAM (GDDRAM).
+ */
+static int ssd130x_spi_write(void *context, const void *data, size_t count)
+{
+ struct ssd130x_spi_transport *t = context;
+ struct spi_device *spi = t->spi;
+ const u8 *reg = data;
+
+ if (*reg == SSD130X_COMMAND)
+ gpiod_set_value_cansleep(t->dc, 0);
+
+ if (*reg == SSD130X_DATA)
+ gpiod_set_value_cansleep(t->dc, 1);
+
+ /* Remove the control byte since is not used by the 4-wire SPI */
+ return spi_write(spi, ((u8 *)data) + 1, count - 1);
+}
+
+/* The ssd130x driver does not read registers but regmap expects a .read */
+static int ssd130x_spi_read(void *context, const void *reg, size_t reg_size,
+ void *val, size_t val_size)
+{
+ return -EOPNOTSUPP;
+}
+
+/*
+ * A custom bus is needed due the special write that toggles a D/C# pin,
+ * another option could be to just have a .reg_write() callback but that
+ * will prevent to do data writes in bulk.
+ *
+ * Once the regmap API is extended to support defining a bulk write handler
+ * in the struct regmap_config, this can be simplified and the bus dropped.
+ */
+static struct regmap_bus regmap_ssd130x_spi_bus = {
+ .write = ssd130x_spi_write,
+ .read = ssd130x_spi_read,
+};
+
+static int ssd130x_spi_probe(struct spi_device *spi)
+{
+ struct ssd130x_spi_transport *t;
+ struct ssd130x_device *ssd130x;
+ st
Re: [PATCH v1] drm/scheduler: Don't kill jobs in interrupt context
On 2022-04-11 18:15, Dmitry Osipenko wrote:
Interrupt context can't sleep. Drivers like Panfrost and MSM are taking
mutex when job is released, and thus, that code can sleep. This results
into "BUG: scheduling while atomic" if locks are contented while job is
freed. There is no good reason for releasing scheduler's jobs in IRQ
context, hence use normal context to fix the trouble.
I am not sure this is the beast Idea to leave job's sw fence signalling
to be
executed in system_wq context which is prone to delays of executing
various work items from around the system. Seems better to me to leave the
fence signaling within the IRQ context and offload only the job freeing or,
maybe handle rescheduling to thread context within drivers implemention
of .free_job cb. Not really sure which is the better.
Andrey
Cc: sta...@vger.kernel.org
Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/scheduler/sched_entity.c | 6 +++---
include/drm/gpu_scheduler.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 191c56064f19..6b25b2f4f5a3 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -190,7 +190,7 @@ long drm_sched_entity_flush(struct drm_sched_entity
*entity, long timeout)
}
EXPORT_SYMBOL(drm_sched_entity_flush);
-static void drm_sched_entity_kill_jobs_irq_work(struct irq_work *wrk)
+static void drm_sched_entity_kill_jobs_work(struct work_struct *wrk)
{
struct drm_sched_job *job = container_of(wrk, typeof(*job), work);
@@ -207,8 +207,8 @@ static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
finish_cb);
- init_irq_work(&job->work, drm_sched_entity_kill_jobs_irq_work);
- irq_work_queue(&job->work);
+ INIT_WORK(&job->work, drm_sched_entity_kill_jobs_work);
+ schedule_work(&job->work);
}
static struct dma_fence *
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 0fca8f38bee4..addb135eeea6 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -28,7 +28,7 @@
#include
#include
#include
-#include
+#include
#define MAX_WAIT_SCHED_ENTITY_Q_EMPTY msecs_to_jiffies(1000)
@@ -295,7 +295,7 @@ struct drm_sched_job {
*/
union {
struct dma_fence_cb finish_cb;
- struct irq_work work;
+ struct work_struct work;
};
uint64_t id;
