Re: [PATCH v3] usb: gadget: aspeed_udc: Add check for dma_alloc_coherent
On Fri, Dec 23, 2022 at 10:54:37PM +0800, Greg KH wrote:
>> diff --git a/drivers/usb/gadget/udc/aspeed_udc.c
>> b/drivers/usb/gadget/udc/aspeed_udc.c
>> index 01968e2167f9..7dc2457c7460 100644
>> --- a/drivers/usb/gadget/udc/aspeed_udc.c
>> +++ b/drivers/usb/gadget/udc/aspeed_udc.c
>> @@ -1516,6 +1516,10 @@ static int ast_udc_probe(struct platform_device *pdev)
>>AST_UDC_EP_DMA_SIZE *
>>AST_UDC_NUM_ENDPOINTS,
>>>ep0_buf_dma, GFP_KERNEL);
>> +if (!udc->ep0_buf) {
>> +rc = -ENOMEM;
>> +goto err;
>> +}
>>
>> udc->gadget.speed = USB_SPEED_UNKNOWN;
>> udc->gadget.max_speed = USB_SPEED_HIGH;
>> --
>> 2.25.1
>>
>
> Why is this just a duplicate of the patch previously submitted here:
> https://lore.kernel.org/r/20221125092833.74822-1-yuan...@huawei.com
>
> confused,
>
> greg k-h
Yes, it is the same as mine.
As the previous patch had not been merged into the Linux kernel,
my tool found the same error and report it.
And both of us chose the most concise way to fix the error.
That is why the patches are the same.
Thanks,
Jiang
Re: [PATCH v3] usb: gadget: aspeed_udc: Add check for dma_alloc_coherent
On Sat, Dec 24, 2022 at 10:50:01AM +0800, Jiasheng Jiang wrote: > Yes, it is the same as mine. > As the previous patch had not been merged into the Linux kernel, > my tool found the same error and report it. > And both of us chose the most concise way to fix the error. > That is why the patches are the same. I have no context at all here, what does this refer to? confused, greg k-h
Re: [PATCH v3] usb: gadget: aspeed_udc: Add check for dma_alloc_coherent
Yes, it is the same as mine. As the previous patch had not been merged into the Linux kernel, my tool found the same error and report it. And both of us chose the most concise way to fix the error. That is why the patches are the same. Thanks, Jiang
[PATCH AUTOSEL 5.10 11/11] fbdev: smscufx: fix error handling code in ufx_usb_probe
From: Dongliang Mu
[ Upstream commit b76449ee75e21acfe9fa4c653d8598f191ed7d68 ]
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0x88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00
backtrace:
[] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[] kmalloc include/linux/slab.h:553 [inline]
[] kzalloc include/linux/slab.h:689 [inline]
[] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873
[inline]
[] ufx_usb_probe+0x11c/0x15a0
drivers/video/fbdev/smscufx.c:1655
[] usb_probe_interface+0x177/0x370
drivers/usb/core/driver.c:396
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[] device_add+0x642/0xdc0 drivers/base/core.c:3517
[] usb_set_configuration+0x8ef/0xb80
drivers/usb/core/message.c:2170
[] usb_generic_driver_probe+0x8c/0xc0
drivers/usb/core/generic.c:238
[] usb_probe_device+0x5c/0x140
drivers/usb/core/driver.c:293
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
Fix this bug by rewriting the error handling code in ufx_usb_probe.
Reported-by: syzkaller
Tested-by: Dongliang Mu
Signed-off-by: Dongliang Mu
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/smscufx.c | 46 +++
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 5fa3f1e5dfe8..b3295cd7fd4f 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1621,7 +1621,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
struct usb_device *usbdev;
struct ufx_data *dev;
struct fb_info *info;
- int retval;
+ int retval = -ENOMEM;
u32 id_rev, fpga_rev;
/* usb initialization */
@@ -1653,15 +1653,17 @@ static int ufx_usb_probe(struct usb_interface
*interface,
if (!ufx_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
dev_err(dev->gdev, "ufx_alloc_urb_list failed\n");
- goto e_nomem;
+ goto put_ref;
}
/* We don't register a new USB class. Our client interface is fbdev */
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, >dev);
- if (!info)
- goto e_nomem;
+ if (!info) {
+ dev_err(dev->gdev, "framebuffer_alloc failed\n");
+ goto free_urb_list;
+ }
dev->info = info;
info->par = dev;
@@ -1704,22 +1706,34 @@ static int ufx_usb_probe(struct usb_interface
*interface,
check_warn_goto_error(retval, "unable to find common mode for display
and adapter");
retval = ufx_reg_set_bits(dev, 0x4000, 0x0001);
- check_warn_goto_error(retval, "error %d enabling graphics engine",
retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d enabling graphics engine", retval);
+ goto setup_modes;
+ }
/* ready to begin using device */
atomic_set(>usb_active, 1);
dev_dbg(dev->gdev, "checking var");
retval = ufx_ops_check_var(>var, info);
- check_warn_goto_error(retval, "error %d ufx_ops_check_var", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_check_var", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "setting par");
retval = ufx_ops_set_par(info);
- check_warn_goto_error(retval, "error %d ufx_ops_set_par", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_set_par", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "registering framebuffer");
retval = register_framebuffer(info);
- check_warn_goto_error(retval, "error %d register_framebuffer", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d register_framebuffer", retval);
+ goto
[PATCH AUTOSEL 5.4 7/7] fbdev: smscufx: fix error handling code in ufx_usb_probe
From: Dongliang Mu
[ Upstream commit b76449ee75e21acfe9fa4c653d8598f191ed7d68 ]
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0x88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00
backtrace:
[] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[] kmalloc include/linux/slab.h:553 [inline]
[] kzalloc include/linux/slab.h:689 [inline]
[] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873
[inline]
[] ufx_usb_probe+0x11c/0x15a0
drivers/video/fbdev/smscufx.c:1655
[] usb_probe_interface+0x177/0x370
drivers/usb/core/driver.c:396
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[] device_add+0x642/0xdc0 drivers/base/core.c:3517
[] usb_set_configuration+0x8ef/0xb80
drivers/usb/core/message.c:2170
[] usb_generic_driver_probe+0x8c/0xc0
drivers/usb/core/generic.c:238
[] usb_probe_device+0x5c/0x140
drivers/usb/core/driver.c:293
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
Fix this bug by rewriting the error handling code in ufx_usb_probe.
Reported-by: syzkaller
Tested-by: Dongliang Mu
Signed-off-by: Dongliang Mu
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/smscufx.c | 46 +++
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index a5abdec58fe2..53fb34f074c7 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1622,7 +1622,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
struct usb_device *usbdev;
struct ufx_data *dev;
struct fb_info *info;
- int retval;
+ int retval = -ENOMEM;
u32 id_rev, fpga_rev;
/* usb initialization */
@@ -1654,15 +1654,17 @@ static int ufx_usb_probe(struct usb_interface
*interface,
if (!ufx_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
dev_err(dev->gdev, "ufx_alloc_urb_list failed\n");
- goto e_nomem;
+ goto put_ref;
}
/* We don't register a new USB class. Our client interface is fbdev */
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, >dev);
- if (!info)
- goto e_nomem;
+ if (!info) {
+ dev_err(dev->gdev, "framebuffer_alloc failed\n");
+ goto free_urb_list;
+ }
dev->info = info;
info->par = dev;
@@ -1705,22 +1707,34 @@ static int ufx_usb_probe(struct usb_interface
*interface,
check_warn_goto_error(retval, "unable to find common mode for display
and adapter");
retval = ufx_reg_set_bits(dev, 0x4000, 0x0001);
- check_warn_goto_error(retval, "error %d enabling graphics engine",
retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d enabling graphics engine", retval);
+ goto setup_modes;
+ }
/* ready to begin using device */
atomic_set(>usb_active, 1);
dev_dbg(dev->gdev, "checking var");
retval = ufx_ops_check_var(>var, info);
- check_warn_goto_error(retval, "error %d ufx_ops_check_var", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_check_var", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "setting par");
retval = ufx_ops_set_par(info);
- check_warn_goto_error(retval, "error %d ufx_ops_set_par", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_set_par", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "registering framebuffer");
retval = register_framebuffer(info);
- check_warn_goto_error(retval, "error %d register_framebuffer", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d register_framebuffer", retval);
+ goto
[PATCH AUTOSEL 5.15 14/14] fbdev: smscufx: fix error handling code in ufx_usb_probe
From: Dongliang Mu
[ Upstream commit b76449ee75e21acfe9fa4c653d8598f191ed7d68 ]
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0x88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00
backtrace:
[] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[] kmalloc include/linux/slab.h:553 [inline]
[] kzalloc include/linux/slab.h:689 [inline]
[] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873
[inline]
[] ufx_usb_probe+0x11c/0x15a0
drivers/video/fbdev/smscufx.c:1655
[] usb_probe_interface+0x177/0x370
drivers/usb/core/driver.c:396
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[] device_add+0x642/0xdc0 drivers/base/core.c:3517
[] usb_set_configuration+0x8ef/0xb80
drivers/usb/core/message.c:2170
[] usb_generic_driver_probe+0x8c/0xc0
drivers/usb/core/generic.c:238
[] usb_probe_device+0x5c/0x140
drivers/usb/core/driver.c:293
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
Fix this bug by rewriting the error handling code in ufx_usb_probe.
Reported-by: syzkaller
Tested-by: Dongliang Mu
Signed-off-by: Dongliang Mu
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/smscufx.c | 46 +++
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 5fa3f1e5dfe8..b3295cd7fd4f 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1621,7 +1621,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
struct usb_device *usbdev;
struct ufx_data *dev;
struct fb_info *info;
- int retval;
+ int retval = -ENOMEM;
u32 id_rev, fpga_rev;
/* usb initialization */
@@ -1653,15 +1653,17 @@ static int ufx_usb_probe(struct usb_interface
*interface,
if (!ufx_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
dev_err(dev->gdev, "ufx_alloc_urb_list failed\n");
- goto e_nomem;
+ goto put_ref;
}
/* We don't register a new USB class. Our client interface is fbdev */
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, >dev);
- if (!info)
- goto e_nomem;
+ if (!info) {
+ dev_err(dev->gdev, "framebuffer_alloc failed\n");
+ goto free_urb_list;
+ }
dev->info = info;
info->par = dev;
@@ -1704,22 +1706,34 @@ static int ufx_usb_probe(struct usb_interface
*interface,
check_warn_goto_error(retval, "unable to find common mode for display
and adapter");
retval = ufx_reg_set_bits(dev, 0x4000, 0x0001);
- check_warn_goto_error(retval, "error %d enabling graphics engine",
retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d enabling graphics engine", retval);
+ goto setup_modes;
+ }
/* ready to begin using device */
atomic_set(>usb_active, 1);
dev_dbg(dev->gdev, "checking var");
retval = ufx_ops_check_var(>var, info);
- check_warn_goto_error(retval, "error %d ufx_ops_check_var", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_check_var", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "setting par");
retval = ufx_ops_set_par(info);
- check_warn_goto_error(retval, "error %d ufx_ops_set_par", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_set_par", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "registering framebuffer");
retval = register_framebuffer(info);
- check_warn_goto_error(retval, "error %d register_framebuffer", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d register_framebuffer", retval);
+ goto
[PATCH AUTOSEL 6.0 18/18] fbdev: smscufx: fix error handling code in ufx_usb_probe
From: Dongliang Mu
[ Upstream commit b76449ee75e21acfe9fa4c653d8598f191ed7d68 ]
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0x88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00
backtrace:
[] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[] kmalloc include/linux/slab.h:553 [inline]
[] kzalloc include/linux/slab.h:689 [inline]
[] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873
[inline]
[] ufx_usb_probe+0x11c/0x15a0
drivers/video/fbdev/smscufx.c:1655
[] usb_probe_interface+0x177/0x370
drivers/usb/core/driver.c:396
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[] device_add+0x642/0xdc0 drivers/base/core.c:3517
[] usb_set_configuration+0x8ef/0xb80
drivers/usb/core/message.c:2170
[] usb_generic_driver_probe+0x8c/0xc0
drivers/usb/core/generic.c:238
[] usb_probe_device+0x5c/0x140
drivers/usb/core/driver.c:293
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
Fix this bug by rewriting the error handling code in ufx_usb_probe.
Reported-by: syzkaller
Tested-by: Dongliang Mu
Signed-off-by: Dongliang Mu
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/smscufx.c | 46 +++
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 9343b7a4ac89..2ad6e98ce10d 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1622,7 +1622,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
struct usb_device *usbdev;
struct ufx_data *dev;
struct fb_info *info;
- int retval;
+ int retval = -ENOMEM;
u32 id_rev, fpga_rev;
/* usb initialization */
@@ -1654,15 +1654,17 @@ static int ufx_usb_probe(struct usb_interface
*interface,
if (!ufx_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
dev_err(dev->gdev, "ufx_alloc_urb_list failed\n");
- goto e_nomem;
+ goto put_ref;
}
/* We don't register a new USB class. Our client interface is fbdev */
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, >dev);
- if (!info)
- goto e_nomem;
+ if (!info) {
+ dev_err(dev->gdev, "framebuffer_alloc failed\n");
+ goto free_urb_list;
+ }
dev->info = info;
info->par = dev;
@@ -1705,22 +1707,34 @@ static int ufx_usb_probe(struct usb_interface
*interface,
check_warn_goto_error(retval, "unable to find common mode for display
and adapter");
retval = ufx_reg_set_bits(dev, 0x4000, 0x0001);
- check_warn_goto_error(retval, "error %d enabling graphics engine",
retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d enabling graphics engine", retval);
+ goto setup_modes;
+ }
/* ready to begin using device */
atomic_set(>usb_active, 1);
dev_dbg(dev->gdev, "checking var");
retval = ufx_ops_check_var(>var, info);
- check_warn_goto_error(retval, "error %d ufx_ops_check_var", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_check_var", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "setting par");
retval = ufx_ops_set_par(info);
- check_warn_goto_error(retval, "error %d ufx_ops_set_par", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_set_par", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "registering framebuffer");
retval = register_framebuffer(info);
- check_warn_goto_error(retval, "error %d register_framebuffer", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d register_framebuffer", retval);
+ goto
[PATCH AUTOSEL 6.1 26/26] fbdev: smscufx: fix error handling code in ufx_usb_probe
From: Dongliang Mu
[ Upstream commit b76449ee75e21acfe9fa4c653d8598f191ed7d68 ]
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0x88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00
backtrace:
[] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[] kmalloc include/linux/slab.h:553 [inline]
[] kzalloc include/linux/slab.h:689 [inline]
[] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873
[inline]
[] ufx_usb_probe+0x11c/0x15a0
drivers/video/fbdev/smscufx.c:1655
[] usb_probe_interface+0x177/0x370
drivers/usb/core/driver.c:396
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[] device_add+0x642/0xdc0 drivers/base/core.c:3517
[] usb_set_configuration+0x8ef/0xb80
drivers/usb/core/message.c:2170
[] usb_generic_driver_probe+0x8c/0xc0
drivers/usb/core/generic.c:238
[] usb_probe_device+0x5c/0x140
drivers/usb/core/driver.c:293
[] call_driver_probe drivers/base/dd.c:560 [inline]
[] really_probe+0x12d/0x390 drivers/base/dd.c:639
[] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
Fix this bug by rewriting the error handling code in ufx_usb_probe.
Reported-by: syzkaller
Tested-by: Dongliang Mu
Signed-off-by: Dongliang Mu
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/smscufx.c | 46 +++
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 9343b7a4ac89..2ad6e98ce10d 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1622,7 +1622,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
struct usb_device *usbdev;
struct ufx_data *dev;
struct fb_info *info;
- int retval;
+ int retval = -ENOMEM;
u32 id_rev, fpga_rev;
/* usb initialization */
@@ -1654,15 +1654,17 @@ static int ufx_usb_probe(struct usb_interface
*interface,
if (!ufx_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
dev_err(dev->gdev, "ufx_alloc_urb_list failed\n");
- goto e_nomem;
+ goto put_ref;
}
/* We don't register a new USB class. Our client interface is fbdev */
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, >dev);
- if (!info)
- goto e_nomem;
+ if (!info) {
+ dev_err(dev->gdev, "framebuffer_alloc failed\n");
+ goto free_urb_list;
+ }
dev->info = info;
info->par = dev;
@@ -1705,22 +1707,34 @@ static int ufx_usb_probe(struct usb_interface
*interface,
check_warn_goto_error(retval, "unable to find common mode for display
and adapter");
retval = ufx_reg_set_bits(dev, 0x4000, 0x0001);
- check_warn_goto_error(retval, "error %d enabling graphics engine",
retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d enabling graphics engine", retval);
+ goto setup_modes;
+ }
/* ready to begin using device */
atomic_set(>usb_active, 1);
dev_dbg(dev->gdev, "checking var");
retval = ufx_ops_check_var(>var, info);
- check_warn_goto_error(retval, "error %d ufx_ops_check_var", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_check_var", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "setting par");
retval = ufx_ops_set_par(info);
- check_warn_goto_error(retval, "error %d ufx_ops_set_par", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d ufx_ops_set_par", retval);
+ goto reset_active;
+ }
dev_dbg(dev->gdev, "registering framebuffer");
retval = register_framebuffer(info);
- check_warn_goto_error(retval, "error %d register_framebuffer", retval);
+ if (retval < 0) {
+ dev_err(dev->gdev, "error %d register_framebuffer", retval);
+ goto
Re: [PATCH] drm/tests: reduce drm_mm_test stack usage
On 12/15/22 13:34, Arnd Bergmann wrote: From: Arnd Bergmann The check_reserve_boundaries function uses a lot of kernel stack, and it gets inlined by clang, which makes __drm_test_mm_reserve use even more of it, to the point of hitting the warning limit: drivers/gpu/drm/tests/drm_mm_test.c:344:12: error: stack frame size (1048) exceeds limit (1024) in '__drm_test_mm_reserve' [-Werror,-Wframe-larger-than] When building with gcc, this does not happen, but the structleak plugin can similarly increase the stack usage and needs to be disabled, as we do for all other kunit users. Signed-off-by: Arnd Bergmann Applied it to drm-misc-next-fixes with the small checkpatch fix. Best Regards, - Maíra Canal
[Bug 216840] New: AMDGPU trace message at boot
https://bugzilla.kernel.org/show_bug.cgi?id=216840 Bug ID: 216840 Summary: AMDGPU trace message at boot Product: Drivers Version: 2.5 Kernel Version: 6.1.0 Hardware: AMD OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: carlosalvat...@gmail.com Regression: No Hi, I don't know whether this is important, but I'd like to know what is causing this trace message: https://pastebin.pl/view/94557be6 when booting. Hardware details: - MB: ASUS M5A97 R2.0 - CPU: AMD FX-8350 - Kernel: 6.1.0 - GPU: Radeon HD 7970 (Tahiti) [Gigabyte GV-R797OC-3GD] There are no critical problems when using the system. Other than HDMI port not working anymore (I don't know if this is related. At some point HDMI stopped working and I've got this message: "drm:detect_link_and_local_sink [amdgpu]] *ERROR* No EDID read.", which I bypassed using a HDMI>DP adapter). GRUB command line arguments are: amdgpu.si_support=1 radeon.si_support=0 modprobe.blacklist=radeon amdgpu.vm_update_mode=3 amdgpu.dpm=1 amdgpu.dc=1 amd_iommu=on iommu=pt video=DisplayPort-0:edid/1204x800.bin Regards. -- CarloSalvatore -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 1/4] drm: panel: Add Himax HX8394 panel controller driver
Hello Sam, On 12/23/22 10:17, Sam Ravnborg wrote: > Hi Javier. > > On Thu, Dec 22, 2022 at 11:38:27PM +0100, Javier Martinez Canillas wrote: >> From: Kamil Trzciński >> >> The driver is for panels based on the Himax HX8394 controller, such as the >> HannStar HSD060BHW4 720x1440 TFT LCD panel that uses a MIPI-DSI interface. > > A few comments/nitpicks in the following. > I have been away for a while, and paged out most of my panel knowledge, > so read it all with that in mind. > Thanks a lot for your feedback! I agree with your comments and will address those in the next iteration. > In general - very nicely written driver. > > Sam > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [git pull] drm fixes for 6.2-rc1
The pull request you sent on Fri, 23 Dec 2022 14:02:33 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-12-23 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/55c7d6a91d42ad98cbfb10da077ce8bb7084dc0e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 16/16] drm/amd/display: Don't restrict bpc to 8 bpc
On 12/14/22 04:01, Pekka Paalanen wrote: > On Tue, 13 Dec 2022 18:20:59 +0100 > Michel Dänzer wrote: > >> On 12/12/22 19:21, Harry Wentland wrote: >>> This will let us pass kms_hdr.bpc_switch. >>> >>> I don't see any good reasons why we still need to >>> limit bpc to 8 bpc and doing so is problematic when >>> we enable HDR. >>> >>> If I remember correctly there might have been some >>> displays out there where the advertised link bandwidth >>> was not large enough to drive the default timing at >>> max bpc. This would leave to an atomic commit/check >>> failure which should really be handled in compositors >>> with some sort of fallback mechanism. >>> >>> If this somehow turns out to still be an issue I >>> suggest we add a module parameter to allow users to >>> limit the max_bpc to a desired value. >> >> While leaving the fallback for user space to handle makes some sense >> in theory, in practice most KMS display servers likely won't handle >> it. >> >> Another issue is that if mode validation is based on the maximum bpc >> value, it may reject modes which would work with lower bpc. >> >> >> What Ville (CC'd) suggested before instead (and what i915 seems to be >> doing already) is that the driver should do mode validation based on >> the *minimum* bpc, and automatically make the effective bpc lower >> than the maximum as needed to make the rest of the atomic state work. > > A driver is always allowed to choose a bpc lower than max_bpc, so it > very well should do so when necessary due to *known* hardware etc. > limitations. > I spent a bunch of time to figure out how this actually pans out in amdgpu and it looks like we're doing the right thing, i.e. if bandwidth limitations require it we'll downgrade bpc appropriately. These changes happened over the last couple years or so. So while raising the default max_bpc wasn't safe in amdgpu years ago it is completely fine now. As for the relevant code it's mostly handled in create_validate_stream_for_sink in amdgpu_dm.c where we iterate over a stream's mode validation with decreasing bpc if it fails (down to a bpc of 6). For HDMI we also have a separate adjust_colour_depth_from_display_info function that downgrades bpc in order to fit within the max_tmds_clock. So, in short, this change should not lead to displays not lighting up because we no longer force a given bpc. > So things like mode validation cannot just look at a single max or min > bpc, but it needs to figure out if there is any usable bpc value that > makes the mode work. > > The max_bpc knob exists only for the cases where the sink undetectably > malfunctions unless the bpc is artificially limited more than seems > necessary. That malfunction requires a human to detect, and reconfigure > their system as we don't have a quirk database for this I think. > > The question of userspace wanting a specific bpc is a different matter > and an unsolved one. It also ties to userspace wanting to use the > current mode to avoid a mode switch between e.g. hand-off from firmware > boot splash to proper userspace. That's also unsolved AFAIK. > Agreed, the current "max bpc" just sets a max. We'd probably want a "min bpc" if userspace needs a minimum (e.g., for HDR). Harry > OTOH, we have the discussion that concluded as > https://gitlab.freedesktop.org/wayland/weston/-/issues/612#note_1359898 > which really puts userspace in charge of max_bpc, so the driver-chosen > default value does not have much impact as long as it makes the > firmware-chosen video mode to continue, as requested in > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/995 > given that userspace cannot know what the actual bpc currently is nor > set the exact bpc to keep it the same. > > > Thanks, > pq
Re: [PATCH 1/4] drm/i915/gt: Remove platform comments from workarounds
On Fri, Dec 23, 2022 at 09:02:35AM +, Tvrtko Ursulin wrote:
On 22/12/2022 15:55, Lucas De Marchi wrote:
On Thu, Dec 22, 2022 at 10:27:00AM +, Tvrtko Ursulin wrote:
On 22/12/2022 08:25, Lucas De Marchi wrote:
The comments are redundant to the checks being done to apply the
workarounds and very often get outdated as workarounds need to be
extended to new platforms or steppings. Remove them altogether with
the following matches (platforms extracted from intel_workarounds.c):
find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*/\1/'
find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*\*\//\1
Same things was executed in the gem directory, omitted here for brevity.
There were a few false positives that included the workaround
description. Those were manually patched.
sed -E 's/(Wa[a-zA-Z0-9_]+)[:,]([a-zA-Z0-9,-_\+\[]{2,})/\1/'
then there are false negatives. We have Was in the form
"Wa_xxx:tgl,dg2, mtl". False positives we can fixup, false negatives
we simply don't see. After running that in gt/:
$ git grep ": mtl" -- drivers/gpu/drm/i915/
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c: * Wa_14017073508: mtl
drivers/gpu/drm/i915/i915_reg.h:/* Wa_14017210380: mtl */
I was going with the platform names to avoid the false
negatives and because I was entertaining the idea of only doing this for
latest platforms where we do have the "Wa_[[:number:]]" form
Maybe..
Matt recently said he has this worked planned, but more
importantly - I gather then that the WA lookup tool definitely
does not output these strings?
Whatever it does it's true only at the time it's called. It simply
tells what
are the platforms and steppings the Wa applies to. We can change the
output to whatever we want, but that is not the point.
Those comments get stale and bring no real value as they match 1:1
what the code is supposed to be doing. Several times a patch has to
update just that comment to "extend a workaround" to a next platform.
This is not always done, so we get a comment that doesn't match what is
supposed to be there.
Tl;dr; version - lets park this until January and discuss once
everyone is back.
I'll leave my comment here since I will be out until mid January.
Longer version. I've been trying to get us talking about this a couple
times before and I'd really like to close with an explicit consensus,
discussion points addressed instead of skipped and just moving ahead
with patches.
References:
3fcf71b9-337f-6186-7b00-27cbfd116...@linux.intel.com
Y5j0b/bykbitc...@mdroper-desk1.amr.corp.intel.com
So point I wanted to discuss is whether these comments are truly
useless or maybe they can help during review. If the tool can actually
output them then I am leaning towards that they can be.
I consider "can the tool output xyz?" asking the wrong question.
"The tool", which is our own small python script querying a database can
output anything like that if we want to. The database has information of
what are the platforms/steppings for each the WA is known to be applied
*today*. And that can change and do change often, particularly for early
steppings and recent platforms.
Thought is, when a patch comes for review adding a new platform,
stepping, whatever, to an existing if condition, if it contains the
comments reviewer can more easily spot a hyphotetical logic inversion
error or similar. It is also trivial to check that both condition and
comment have been updated. (So lets not be rash and remove something
maybe useful just because it can go stale *only if* reviewers are not
giving sufficient attention that changes are made in tandem.)
I can argue to the other side too. We don't have comments in the kernel
like
/* Add 1 to i */
i += 1;
This is exactly what these comments are doing. And they are misleading
and may introduce bugs rather than helping reviewing:
Wa_12345:tgl[a0,c0)
if (IS_TGL_GRAPHICS_STEP(STEP_A0, STEP_B0)
One might read the comment, skipping over the condition and thinking
"ok, we already extended this WA to B* steppings, which doesn't match
the code.
From a slightly different angle - do we expect anyone reviewing
workaround patches will cross-check against the tool? Would it be
simpler and more
Re: [PATCH v4 0/7] Introduce debugfs device-centered functions
On 12/22/22 14:20, Daniel Vetter wrote: On Mon, Dec 19, 2022 at 11:49:47AM -0100, Melissa Wen wrote: On 12/19, Maíra Canal wrote: This series introduces the initial structure to make DRM debugfs more device-centered and it is the first step to drop the drm_driver->debugfs_init hooks in the future [1]. Currently, DRM debugfs files are created using drm_debugfs_create_files() on request. The first patch of this series makes it possible for DRM devices for creating debugfs files during drm_dev_register(). For it, it introduces two new functions that can be used by the drivers: drm_debugfs_add_files() and drm_debugfs_add_file(). The requests are added to a list and are created all at once during drm_dev_register(). Moreover, the first patch was based on this RFC series [2]. The main difference between the RFC series and the current series is the creation of a new fops structure to accommodate the new structs and, also, the creation of a new drm_debugfs_open. Moreover, the new series uses device-managed allocation, returns memory allocation errors, and converts more drivers to the new structure. Moreover, since v3, the ability to create debugfs files at late_register hooks was added. In previous versions, modeset components weren't able to create debugfs files at late_register hooks as the registration of drm_minor happens before the registration of the modeset abstractions. So, the third patch fixes this problem by adding a drm_debugfs_late_register() function. Thanks to Melissa Wen for catching this problem! Apart from the third patch, the series looks similiar from its last version. [1] https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n506 [2] https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/ Best Regards, - Maíra Canal --- v1 -> v2: https://lore.kernel.org/dri-devel/20221122190314.185015-1-mca...@igalia.com/T/#t - Fix compilation errors in the second patch (kernel test robot). - Drop debugfs_init hook from vkms (Maíra Canal). - Remove return values and error handling to debugfs related functions (Jani Nikula). - Remove entry from list after the file is created, so that drm_debugfs_init can be called more than once (Maíra Canal). v2 -> v3: https://lore.kernel.org/dri-devel/20221123220725.1272155-1-mca...@igalia.com/ - Rebase on top of drm-misc-next v3 -> v4: https://lore.kernel.org/dri-devel/20221207132325.140393-1-mca...@igalia.com/ - Add Maxime's Reviewed-by tags - Add the ability to create debugfs files at late_register hooks (Melissa Wen). Hi Maíra, Thanks for addressing all comments. Maybe Danvet has some inputs for the late_register approach. I think as a stop-gap (really need to get this stuff landed so people can start to use it) this is ok, but long term I think the right fix is to roll out the same pre-register infrastructure for connector and crtc too. That way drivers don't need to split their setup code into init and register anymore, which is the point of this entire rework. If you want, you can adjust the todo accordingly, but we do already have the paragraph about connector/crtc. But we can do that later on, because this is definitely a great way forward. Thanks a lot for pushing this forward! Anyway, LGTM and the entire series is: Reviewed-by: Melissa Wen On the series: Acked-by: Daniel Vetter Applied this series to drm-misc-next. Best Regards, - Maíra Canal --- Maíra Canal (7): drm/debugfs: create device-centered debugfs functions drm: use new debugfs device-centered functions on DRM core files drm/debugfs: create debugfs late register functions drm/vc4: use new debugfs device-centered functions drm/v3d: use new debugfs device-centered functions drm/vkms: use new debugfs device-centered functions drm/todo: update the debugfs clean up task Documentation/gpu/todo.rst| 9 +-- drivers/gpu/drm/drm_atomic.c | 11 ++- drivers/gpu/drm/drm_client.c | 11 ++- drivers/gpu/drm/drm_debugfs.c | 102 +++--- drivers/gpu/drm/drm_drv.c | 3 + drivers/gpu/drm/drm_framebuffer.c | 11 ++- drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++- drivers/gpu/drm/drm_internal.h| 5 ++ drivers/gpu/drm/drm_mode_config.c | 2 + drivers/gpu/drm/v3d/v3d_debugfs.c | 22 +++--- drivers/gpu/drm/vc4/vc4_bo.c | 10 +-- drivers/gpu/drm/vc4/vc4_crtc.c| 7 +- drivers/gpu/drm/vc4/vc4_debugfs.c | 36 ++--- drivers/gpu/drm/vc4/vc4_dpi.c | 5 +- drivers/gpu/drm/vc4/vc4_drv.c | 1 - drivers/gpu/drm/vc4/vc4_drv.h | 32 ++-- drivers/gpu/drm/vc4/vc4_dsi.c | 6 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 12 +-- drivers/gpu/drm/vc4/vc4_hvs.c | 24 ++ drivers/gpu/drm/vc4/vc4_v3d.c | 14 +--- drivers/gpu/drm/vc4/vc4_vec.c | 6 +- drivers/gpu/drm/vkms/vkms_drv.c | 17 ++---
Re: [PATCH 06/10] drm: Remove usage of deprecated DRM_DEBUG_DRIVER
On Wed, Dec 21, 2022 at 3:14 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 21.12.22 um 11:00 schrieb Jani Nikula:
> > On Wed, 21 Dec 2022, Siddh Raman Pant wrote:
> >> drm_print.h says DRM_DEBUG_DRIVER is deprecated.
> >> Thus, use newer drm_dbg_driver().
> >>
> >> Also fix the deprecation comment in drm_print.h which
> >> mentions drm_dbg() instead of drm_dbg_driver().
> >>
> >> Signed-off-by: Siddh Raman Pant
> >> ---
> >> drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
> >> include/drm/drm_print.h| 2 +-
> >> 2 files changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c
> >> b/drivers/gpu/drm/drm_mipi_dbi.c
> >> index 24af507bb687..6ad399f6ab03 100644
> >> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> >> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> >> @@ -69,11 +69,11 @@
> >> #define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
> >> ({ \
> >> if (!len) \
> >> -DRM_DEBUG_DRIVER("cmd=%02x\n", cmd); \
> >> +drm_dbg_driver(NULL, "cmd=%02x\n", cmd); \
> >> else if (len <= 32) \
> >> -DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, (int)len,
> >> data);\
> >> +drm_dbg_driver(NULL, "cmd=%02x, par=%*ph\n", cmd, (int)len,
> >> data);\
> >> else \
> >> -DRM_DEBUG_DRIVER("cmd=%02x, len=%zu\n", cmd, len); \
> >> +drm_dbg_driver(NULL, "cmd=%02x, len=%zu\n", cmd, len); \
> >> })
> >>
> >> static const u8 mipi_dbi_dcs_read_commands[] = {
> >> @@ -632,7 +632,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *dbi)
> >> DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
> >> return false;
> >>
> >> -DRM_DEBUG_DRIVER("Display is ON\n");
> >> +drm_dbg_driver(NULL, "Display is ON\n");
> >>
> >> return true;
> >> }
> >> @@ -1168,7 +1168,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
> >> mipi_dbi *dbi,
> >>
> >> mutex_init(>cmdlock);
> >>
> >> -DRM_DEBUG_DRIVER("SPI speed: %uMHz\n", spi->max_speed_hz / 100);
> >> +drm_dbg_driver(NULL, "SPI speed: %uMHz\n", spi->max_speed_hz /
> >> 100);
> >>
> >> return 0;
> >> }
> >> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> >> index 53702d830291..10261faec8b6 100644
> >> --- a/include/drm/drm_print.h
> >> +++ b/include/drm/drm_print.h
> >> @@ -614,7 +614,7 @@ void __drm_err(const char *format, ...);
> >> #define DRM_DEBUG(fmt, ...)
> >> \
> >> __drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
> >>
> >> -/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
> >> +/* NOTE: this is deprecated in favor of drm_dbg_driver(NULL, ...). */
> >
> > Way back the idea was to make the shorter drm_dbg() the driver debug,
> > and drm_dbg_core() the drm core debug, because the former vastly
> > outnumbers the the latter.
> >
> > I don't know if that changed with the dyndbg stuff.
well, there was:
commit 95a77b6331c2d2313aa843fa77ec91cd092ab0e4
Author: Jim Cromie
Date: Sun Sep 11 23:28:49 2022 -0600
drm-print: add drm_dbg_driver to improve namespace symmetry
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
>
> I've recently grepped for these macros and nothing uses drm_dbg_driver()
> directly.
I have a use-case for it, in an unready branch thats trying to adapt nouveau
to use dyndbg. Its presence allows macro constructs to paste 'driver'
onto the end, and have it resolve. (see ##cat below)
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -39,6 +39,7 @@
*/
#include
+#include
#include
#include
@@ -263,13 +264,16 @@ void nouveau_drm_device_remove(struct drm_device *dev);
#define NV_WARN(drm,f,a...) NV_PRINTK(warn, &(drm)->client, f, ##a)
#define NV_INFO(drm,f,a...) NV_PRINTK(info, &(drm)->client, f, ##a)
-#define NV_DEBUG(drm,f,a...) do {
\
- if (drm_debug_enabled(DRM_UT_DRIVER)) \
- NV_PRINTK(info, &(drm)->client, f, ##a); \
+#define NV_DRMDBG(cat,c,f,a...) do { \
+ struct nouveau_cli *_cli = (c); \
+ drm_dbg_##cat(_cli->drm->dev, "%s: "f, _cli->name, ##a); \
} while(0)
-#define NV_ATOMIC(drm,f,a...) do {
\
- if (drm_debug_enabled(DRM_UT_ATOMIC)) \
- NV_PRINTK(info, &(drm)->client, f, ##a); \
+
+#define NV_DEBUG(drm,f,a...) do { \
+ NV_DRMDBG(driver, &(drm)->client, f, ##a); \
+} while(0)
+#define NV_ATOMIC(drm,f,a...) do { \
+ NV_DRMDBG(atomic, &(drm)->client,
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, Dec 22, 2022 at 2:29 PM Matthew Brost wrote:
>
> In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
> mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
> seems a bit odd but let us explain the reasoning below.
>
> 1. In XE the submission order from multiple drm_sched_entity is not
> guaranteed to be the same completion even if targeting the same hardware
> engine. This is because in XE we have a firmware scheduler, the GuC,
> which allowed to reorder, timeslice, and preempt submissions. If a using
> shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls
> apart as the TDR expects submission order == completion order. Using a
> dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.
>
> 2. In XE submissions are done via programming a ring buffer (circular
> buffer), a drm_gpu_scheduler provides a limit on number of jobs, if the
> limit of number jobs is set to RING_SIZE / MAX_SIZE_PER_JOB we get flow
> control on the ring for free.
>
> A problem with this design is currently a drm_gpu_scheduler uses a
> kthread for submission / job cleanup. This doesn't scale if a large
> number of drm_gpu_scheduler are used. To work around the scaling issue,
> use a worker rather than kthread for submission / job cleanup.
You might want to enable CONFIG_DRM_MSM in your kconfig, I think you
missed a part
BR,
-R
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 14 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +-
> drivers/gpu/drm/scheduler/sched_main.c | 124
> include/drm/gpu_scheduler.h | 13 +-
> 4 files changed, 93 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index f60753f97ac5..9c2a10aeb0b3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -1489,9 +1489,9 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file
> *m, void *unused)
> for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
> struct amdgpu_ring *ring = adev->rings[i];
>
> - if (!ring || !ring->sched.thread)
> + if (!ring || !ring->sched.ready)
> continue;
> - kthread_park(ring->sched.thread);
> + drm_sched_run_wq_stop(>sched);
> }
>
> seq_printf(m, "run ib test:\n");
> @@ -1505,9 +1505,9 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file
> *m, void *unused)
> for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
> struct amdgpu_ring *ring = adev->rings[i];
>
> - if (!ring || !ring->sched.thread)
> + if (!ring || !ring->sched.ready)
> continue;
> - kthread_unpark(ring->sched.thread);
> + drm_sched_run_wq_start(>sched);
> }
>
> up_write(>reset_domain->sem);
> @@ -1727,7 +1727,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64
> val)
>
> ring = adev->rings[val];
>
> - if (!ring || !ring->funcs->preempt_ib || !ring->sched.thread)
> + if (!ring || !ring->funcs->preempt_ib || !ring->sched.ready)
> return -EINVAL;
>
> /* the last preemption failed */
> @@ -1745,7 +1745,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64
> val)
> goto pro_end;
>
> /* stop the scheduler */
> - kthread_park(ring->sched.thread);
> + drm_sched_run_wq_stop(>sched);
>
> /* preempt the IB */
> r = amdgpu_ring_preempt_ib(ring);
> @@ -1779,7 +1779,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64
> val)
>
> failure:
> /* restart the scheduler */
> - kthread_unpark(ring->sched.thread);
> + drm_sched_run_wq_start(>sched);
>
> up_read(>reset_domain->sem);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 076ae400d099..9552929ccf87 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -4577,7 +4577,7 @@ bool amdgpu_device_has_job_running(struct amdgpu_device
> *adev)
> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> struct amdgpu_ring *ring = adev->rings[i];
>
> - if (!ring || !ring->sched.thread)
> + if (!ring || !ring->sched.ready)
> continue;
>
> spin_lock(>sched.job_list_lock);
> @@ -4708,7 +4708,7 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device
> *adev,
> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> struct amdgpu_ring *ring = adev->rings[i];
>
> - if (!ring || !ring->sched.thread)
> + if (!ring || !ring->sched.ready)
> continue;
>
> /*clear job fence from fence drv to avoid
Re: [PATCH 2/2] drm/amd: Re-create firmware framebuffer on failure to probe
What about a system with multiple GPUs? Hybrid graphics? Headless systems? Regards //Ernst Den tors 22 dec. 2022 kl 19:30 skrev Mario Limonciello < mario.limoncie...@amd.com>: > If the probe sequence fails then the user is stuck with a frozen > screen and can only really recover via SSH or by rebooting and > applying nomodeset to the kernel command line. > > This is particularly problematic as newer GPUs are introduced because > distributions may take some time to land newer GPU firmware. > > So when probe fails, re-create the system framebuffer so that the > user at least has basic graphics support. > > Signed-off-by: Mario Limonciello > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index bf2d50c8c92a..8961c62ab29b 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -40,6 +40,7 @@ > #include > #include > #include > +#include > > #include "amdgpu.h" > #include "amdgpu_irq.h" > @@ -2187,6 +2188,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, > > err_pci: > pci_disable_device(pdev); > + sysfb_enable(); > return ret; > } > > -- > 2.34.1 > >
Re: [PATCH 0/2] Recover from failure to probe GPU
On 12/22/22 13:41, Javier Martinez Canillas wrote: [adding Thomas Zimmermann to CC list] Hello Mario, Interesting case. On 12/22/22 19:30, Mario Limonciello wrote: One of the first thing that KMS drivers do during initialization is destroy the system firmware framebuffer by means of `drm_aperture_remove_conflicting_pci_framebuffers` The reason why that's done at the very beginning is that there are no guarantees that the firmware-provided framebuffer would keep working after the real display controller driver re-initializes the IP block. This means that if for any reason the GPU failed to probe the user will be stuck with at best a screen frozen at the last thing that was shown before the KMS driver continued it's probe. The problem is most pronounced when new GPU support is introduced because users will need to have a recent linux-firmware snapshot on their system when they boot a kernel with matching support. Right. That's a problem indeed but as mentioned there's a gap between the firmware-provided framebuffer is removed and the real driver sets up its framebuffer. However the problem is further exaggerated in the case of amdgpu because it has migrated to "IP discovery" where amdgpu will attempt to load on "ALL" AMD GPUs even if the driver is missing support for IP blocks contained in that GPU. IP discovery requires some probing and isn't run until after the framebuffer has been destroyed. This means a situation can occur where a user purchases a new GPU not yet supported by a distribution and when booting the installer it will "freeze" even if the distribution doesn't have the matching kernel support for those IP blocks. The perfect example of this is Ubuntu 21.10 and the new dGPUs just launched by AMD. The installation media ships with kernel 5.19 (which has IP discovery) but the amdgpu support for those IP blocks landed in kernel 6.0. The matching linux-firmware was released after 21.10's launch. The screen will freeze without nomodeset. Even if a user manages to install and then upgrades to kernel 6.0 after install they'll still have the problem of missing firmware, and the same experience. s/21.10/22.10/ This is quite jarring for users, particularly if they don't know that they have to use "nomodeset" to install. I'm not familiar with AMD GPUs, but could be possible that this discovery and firmware loading step be done at the beginning before the firmware FB is removed ? That way the FB removal will not happen unless that succeeds. Possible? I think so, but maybe Alex can comment on this after the holidays as he's more familiar. It would mean splitting and introducing an entirely new phase to driver initialization. The information about the discovery table comes from VRAM. amdgpu_driver_load_kms -> amdgpu_device_init -> amdgpu_device_ip_early_init Basically that code specific would have to call earlier and then there would need to be a separate set of code for all the IP blocks to *just* collect what firmware they need. To help the situation, allow drivers to re-run the init process for the firmware framebuffer during a failed probe. As this problem is most pronounced with amdgpu, this is the only driver changed. But if this makes sense more generally for other KMS drivers, the call can be added to the cleanup routine for those too. The problem I see is that depending on how far the driver's probe function went, there may not be possible to re-run the init process. Since firmware provided framebuffer may already been destroyed or the IP block just be in a half initialized state. I'm not against this series if it solves the issue in practice for amdgpu, but don't think is a general solution and would like to know Thomas' opinion on this before as well Running on this idea I'm pretty sure that request_firmware returns -ENOENT in this case. So another proposal for when to trigger this flow would be to only do it on -ENOENT. We could then also change amdgpu_discovery.c to return -ENOENT when an IP block isn't supported instead of the current -EINVAL. Or we could instead co-opt -ENOTSUPP and remap all the cases that we explicitly want the system framebuffer to re-initialize to that.
Re: [PATCH] treewide: Convert del_timer*() to timer_shutdown*()
On Tue, 20 Dec 2022 13:45:19 -0500 Steven Rostedt wrote: > [ > Linus, > > I ran the script against your latest master branch: > commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf > > As the timer_shutdown*() code is now in your tree, I figured > we can start doing the conversions. At least add the trivial ones > now as Thomas suggested that this gets applied at the end of the > merge window, to avoid conflicts with linux-next during the > development cycle. I can wait to Friday to run it again, and > resubmit. > > What is the best way to handle this? > ] Note, I just did a git remote update, checked out the latest, re-ran the script, and this patch hasn't changed. -- Steve
Re: [Intel-gfx] [PATCH 0/2] drm/i915: Remove frontbuffer tracking from gem.
On Fri, Dec 2, 2022 at 4:17 AM Tvrtko Ursulin < tvrtko.ursu...@linux.intel.com> wrote: For some reason I has missed this. Thanks Tvrtko for pointing this out. > On 01/12/2022 22:03, Zanoni, Paulo R wrote: > > Hi > > > > I was given a link to https://patchwork.freedesktop.org/series/111494/ > > but can't seem to find it on the mailing list, so I'll reply here. > > > > On Thu, 2022-08-25 at 08:46 +0200, Maarten Lankhorst wrote: > >> Frontbuffer tracking in gem is used in old drivers, but nowadays > everyone > >> calls dirtyfb explicitly. Remove frontbuffer tracking from gem, and > >> isolate it to display only. > > > > Ok, but then how can the Kernel know if the user space running is an > > "old driver" or a new one? Assuming everybody is following the new > > policy is at least risky. > Agree. This is a very old problem. That won't go away simply. > > > > (crazy idea: have an ioctl for user space to tell whether it knows how > > to DirtyFB and another where it can even say it will never be touching > > frontbuffers at all) > To be honest we had this "crazy" idea back there. But we thought that the frontbuffer tracking would be easiest than new api... We were wrong... and we probably need this now if we want to remove the frontbuffer tracking. > > > > Also, when I wrote igt/kms_frontbuffer_tracking, it was agreed that > > whatever was there was a representation of the "rules" of the > > frontbfuffer writing contract/API. And I see on the link above that the > > basic tests of kms_frontbuffer_tracking fail. If > > kms_frontbuffer_tracking requires change due to i915.ko having changed > > the frontbuffer writing rules, then we should do it, and possibly have > > those rules written somewhere. > > > > But then, having the Kernel change expectations like that is not > > exactly what I learned we should be doing, because it's the recipe to > > break user space. > > > > I'm confused, please clarify us a little more. More sentences in the > > commit messages would be absolutely great. > > Right, +1 - we need to be sure there aren't some binaries, running in a > distro somewhere, or whatever, which rely on this and then we are not > allowed to break them. As minimum at least we need an audit and versions > to know how old libraries/programs we are talking about here ie. when > did everyone stop relying on implicit tracking. > > Regards, > > Tvrtko >
Re: [PATCH v3 0/3] Add generic framebuffer support to EFI earlycon driver
Hi Ard, On 12/23/22 16:42, Ard Biesheuvel wrote: (cc Andy) On Wed, 21 Dec 2022 at 11:54, Markuss Broks wrote: Make the EFI earlycon driver be suitable for any linear framebuffers. This should be helpful for early porting of boards with no other means of output, like smartphones/tablets. There seems to be an issue with early_ioremap function on ARM32, but I am unable to find the exact cause. It appears the mappings returned by it are somehow incorrect, thus the driver is disabled on ARM. The reason that this driver is disabled on ARM is because the struct screen_info is not populated early enough, as it is retrieved from a UEFI configuration table. I believe I must be hitting some other bug then, since my driver should not use `struct screen_info` when the arguments are specified manually (e.g. in device-tree or in kernel command line options), and it still is broken on ARM when they are. I got it to work on ARM when I moved the early console initialization later into the kernel booting process, but that mostly defeats the purpose of early console driver, I believe. I've been thinking that it could be some stuff not getting initialized early enough indeed, but I've got no clue what could it be. early_ioremap() works fine on ARM as long as they mapping is torn down before paging_init() EFI early console was disabled on IA64 previously because of missing early_memremap_prot, and this is inherited to this driver. This patch also changes "This patch also changes ..." is usually a strong hint to self that the patches need to be split up. behavior on EFI systems, by selecting the mapping type based on if the framebuffer region intersects with system RAM. If it does, it's common sense that it should be in RAM as a whole, and so the system RAM mapping is used. It was tested to be working on my PC (Intel Z490 platform), as well as several ARM64 boards (Samsung Galaxy S9 (Exynos), iPad Air 2, Xiaomi Mi Pad 4, ...). Markuss Broks (2): drivers: serial: earlycon: Pass device-tree node efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem v1 -> v2: - a new patch correcting serial/earlycon.c argument name to "offset" instead of "node" - move IA64 exclusion from EFI earlycon Kconfig to earlycon driver Kconfig (IA64 has no early_memremap_prot) - move driver from fbdev to console subsystem - select EFI earlycon by default - fetch stride manually from device-tree, as on some devices it seems stride doesn't match the horizontal resolution * bpp. - use saner format (e.g. 1920x1080x32 instead of 1920,1080,32). Markuss Broks (3): drivers: serial: earlycon: Pass device-tree node efi: earlycon: move to video/console to prepare for changes efi: earlycon: Add support for generic framebuffers .../admin-guide/kernel-parameters.txt | 12 +- MAINTAINERS | 5 + drivers/firmware/efi/Kconfig | 7 +- drivers/firmware/efi/Makefile | 1 - drivers/firmware/efi/earlycon.c | 246 -- drivers/tty/serial/earlycon.c | 3 + drivers/video/console/Kconfig | 11 + drivers/video/console/Makefile| 1 + drivers/video/console/earlycon.c | 305 ++ include/linux/serial_core.h | 1 + 10 files changed, 336 insertions(+), 256 deletions(-) delete mode 100644 drivers/firmware/efi/earlycon.c create mode 100644 drivers/video/console/earlycon.c -- 2.39.0 - Markuss P.S. Just noticed I forgot to Ctrl^S the cover letter before saving... The main change v3 does is separate the moving action and edit action into two separate commits, I don't think there're more major changes. With v4 I'd try to attach the proper version log.
Re: [PATCH v3] usb: gadget: aspeed_udc: Add check for dma_alloc_coherent
On Thu, Dec 15, 2022 at 08:31:12PM +0800, Jiasheng Jiang wrote:
> Add the check for the return value of dma_alloc_coherent in order to
> avoid NULL pointer dereference.
>
> This flaw was found using an experimental static analysis tool we are
> developing, APP-Miner, which has not been disclosed.
>
> The allyesconfig build using GCC 9.3.0 shows no new warning. As we
> don't have a UDC device to test with, no runtime testing was able to
> be performed.
>
> Signed-off-by: Jiasheng Jiang
> ---
> Changelog:
>
> v2 -> v3:
>
> 1. Add information of finding tool and tests to commit message.
>
> v1 -> v2:
>
> 1. Add "goto err;" when allocation fails.
> ---
> drivers/usb/gadget/udc/aspeed_udc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/gadget/udc/aspeed_udc.c
> b/drivers/usb/gadget/udc/aspeed_udc.c
> index 01968e2167f9..7dc2457c7460 100644
> --- a/drivers/usb/gadget/udc/aspeed_udc.c
> +++ b/drivers/usb/gadget/udc/aspeed_udc.c
> @@ -1516,6 +1516,10 @@ static int ast_udc_probe(struct platform_device *pdev)
> AST_UDC_EP_DMA_SIZE *
> AST_UDC_NUM_ENDPOINTS,
> >ep0_buf_dma, GFP_KERNEL);
> + if (!udc->ep0_buf) {
> + rc = -ENOMEM;
> + goto err;
> + }
>
> udc->gadget.speed = USB_SPEED_UNKNOWN;
> udc->gadget.max_speed = USB_SPEED_HIGH;
> --
> 2.25.1
>
Why is this just a duplicate of the patch previously submitted here:
https://lore.kernel.org/r/20221125092833.74822-1-yuan...@huawei.com
confused,
greg k-h
Re: [PATCH v3 0/3] Add generic framebuffer support to EFI earlycon driver
(cc Andy) On Wed, 21 Dec 2022 at 11:54, Markuss Broks wrote: > > Make the EFI earlycon driver be suitable for any linear framebuffers. > This should be helpful for early porting of boards with no other means of > output, like smartphones/tablets. There seems to be an issue with > early_ioremap > function on ARM32, but I am unable to find the exact cause. It appears the > mappings > returned by it are somehow incorrect, thus the driver is disabled on ARM. The reason that this driver is disabled on ARM is because the struct screen_info is not populated early enough, as it is retrieved from a UEFI configuration table. early_ioremap() works fine on ARM as long as they mapping is torn down before paging_init() > EFI early > console was disabled on IA64 previously because of missing > early_memremap_prot, > and this is inherited to this driver. > > This patch also changes "This patch also changes ..." is usually a strong hint to self that the patches need to be split up. > behavior on EFI systems, by selecting the mapping type > based on if the framebuffer region intersects with system RAM. If it does, > it's > common sense that it should be in RAM as a whole, and so the system RAM > mapping is > used. It was tested to be working on my PC (Intel Z490 platform), as well as > several > ARM64 boards (Samsung Galaxy S9 (Exynos), iPad Air 2, Xiaomi Mi Pad 4, ...). > > Markuss Broks (2): > drivers: serial: earlycon: Pass device-tree node > efi: earlycon: Add support for generic framebuffers and move to fbdev > subsystem > > > v1 -> v2: > > - a new patch correcting serial/earlycon.c argument name to "offset" instead > of "node" > - move IA64 exclusion from EFI earlycon Kconfig to earlycon driver Kconfig > (IA64 has no early_memremap_prot) > - move driver from fbdev to console subsystem > - select EFI earlycon by default > - fetch stride manually from device-tree, as on some devices it seems stride > doesn't match the horizontal resolution * bpp. > - use saner format (e.g. 1920x1080x32 instead of 1920,1080,32). > > > Markuss Broks (3): > drivers: serial: earlycon: Pass device-tree node > efi: earlycon: move to video/console to prepare for changes > efi: earlycon: Add support for generic framebuffers > > .../admin-guide/kernel-parameters.txt | 12 +- > MAINTAINERS | 5 + > drivers/firmware/efi/Kconfig | 7 +- > drivers/firmware/efi/Makefile | 1 - > drivers/firmware/efi/earlycon.c | 246 -- > drivers/tty/serial/earlycon.c | 3 + > drivers/video/console/Kconfig | 11 + > drivers/video/console/Makefile| 1 + > drivers/video/console/earlycon.c | 305 ++ > include/linux/serial_core.h | 1 + > 10 files changed, 336 insertions(+), 256 deletions(-) > delete mode 100644 drivers/firmware/efi/earlycon.c > create mode 100644 drivers/video/console/earlycon.c > > -- > 2.39.0 >
Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg
From: Andrew Morton Date: Thu, 22 Dec 2022 09:21:47 -0800 > On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda > wrote: > > > Hi all, > > > > I hope there will be place for such tiny helper in kernel. > > Quick cocci analyze shows there is probably few thousands places > > where it could be useful. > > So to clarify, the intent here is a simple readability cleanup for > existing open-coded exchange operations. The intent is *not* to > identify existing xchg() sites which are unnecessarily atomic and to > optimize them by using the non-atomic version. > > Have you considered the latter? > > > I am not sure who is good person to review/ack such patches, > > I can take 'em. > > > so I've used my intuition to construct to/cc lists, sorry for mistakes. > > This is the 2nd approach of the same idea, with comments addressed[0]. > > > > The helper is tiny and there are advices we can leave without it, so > > I want to present few arguments why it would be good to have it: > > > > 1. Code readability/simplification/number of lines: > > > > Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c: > > - previous_min_rate = evport->qos.min_rate; > > - evport->qos.min_rate = min_rate; > > + previous_min_rate = __xchg(evport->qos.min_rate, min_rate); > > > > For sure the code is more compact, and IMHO more readable. > > > > 2. Presence of similar helpers in other somehow related languages/libs: > > > > a) Rust[1]: 'replace' from std::mem module, there is also 'take' > > helper (__xchg(, 0)), which is the same as private helper in > > i915 - fetch_and_zero, see latest patch. > > b) C++ [2]: 'exchange' from utility header. > > > > If the idea is OK there are still 2 qestions to answer: > > > > 1. Name of the helper, __xchg follows kernel conventions, > > but for me Rust names are also OK. > > I like replace(), or, shockingly, exchange(). > > But... Can we simply make swap() return the previous value? > > previous_min_rate = swap(>qos.min_rate, min_rate); Unforunately, swap()'s arguments get passed by names, not as pointers, so you can't do swap(some_ptr, NULL); -- pretty common pattern for xchg. Thanks, Olek
Re: [PATCH] drm/i915/gvt: Replace DEFINE_SIMPLE_ATTRIBUTE by DEFINE_DEBUGFS_ATTRIBUTE
On Fri, Dec 16, 2022 at 09:37:47PM +0530, Deepak R Varma wrote:
> The DEFINE_DEBUGFS_ATTRIBUTE macro has implementation for protecting the
> read/write file operations from removal race conditions. This further
> enables using debugfs_create_file_unsafe() function since there is no need
> for a proxy file operations struct for protection. Hence replace the
> DEFINE_SIMPLE_ATTRIBUTE macro by DEFINE_DEBUGFS_ATTRIBUTE and the
> debugfs_create_file() by the lightweight debugfs_create_file_unsafe()
> versions.
>
> This issue was identified using the coccinelle debugfs_simple_attr.cocci
> semantic patch.
>
> Signed-off-by: Deepak R Varma
Hello,
May I please request a review and feedback on this change proposal?
Thank you,
./drv
> ---
> Please note: The changes are compile tested only.
>
> drivers/gpu/drm/i915/gvt/debugfs.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
> b/drivers/gpu/drm/i915/gvt/debugfs.c
> index 9f1c209d9251..a45a43c35a6b 100644
> --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> @@ -147,9 +147,9 @@ vgpu_scan_nonprivbb_set(void *data, u64 val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(vgpu_scan_nonprivbb_fops,
> - vgpu_scan_nonprivbb_get, vgpu_scan_nonprivbb_set,
> - "0x%llx\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_scan_nonprivbb_fops,
> + vgpu_scan_nonprivbb_get, vgpu_scan_nonprivbb_set,
> + "0x%llx\n");
>
> /**
> * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> @@ -165,8 +165,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
> debugfs_create_bool("active", 0444, vgpu->debugfs, >active);
> debugfs_create_file("mmio_diff", 0444, vgpu->debugfs, vgpu,
> _mmio_diff_fops);
> - debugfs_create_file("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> - _scan_nonprivbb_fops);
> + debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> +_scan_nonprivbb_fops);
> }
>
> /**
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH] drm/i915/gt: Retry RING_HEAD reset until it sticks
On 23/12/2022 12:18, Andi Shyti wrote:
From: Chris Wilson
On Haswell, in particular, we see an issue where resets fails because
the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
doesn't point to the remaining requests to re-run, but may instead point
into the uninitialised portion of the ring, the GPU may be then fed
invalid instructions from a privileged context, often pushing the GPU
into an unrecoverable hang.
If at first the write doesn't succeed, try, try again.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/5432
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3303
Signed-off-by: Chris Wilson
Cc: Andrzej Hajda
Cc: Mika Kuoppala
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 44 +--
drivers/gpu/drm/i915/i915_utils.h | 8
2 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 827adb0cfaea6..cdf283f5b1427 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -192,6 +192,7 @@ static bool stop_ring(struct intel_engine_cs *engine)
static int xcs_resume(struct intel_engine_cs *engine)
{
struct intel_ring *ring = engine->legacy.ring;
+ ktime_t kt;
ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
ring->head, ring->tail);
@@ -230,9 +231,20 @@ static int xcs_resume(struct intel_engine_cs *engine)
set_pp_dir(engine);
/* First wake the ring up to an empty/idle ring */
- ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+ until_timeout_ns(kt, 2 * NSEC_PER_MSEC) {
+ ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+ if (ENGINE_READ_FW(engine, RING_HEAD) == ring->head)
+ break;
+ }
2ms?! Shudder..
#define done \
({ \
ENGINE_WRITE_FW(engine, RING_HEAD, ring->head); \
ENGINE_READ_FW(engine, RING_HEAD) == ring->head; \
})
_wait_for_atomic(done, 2 * USEC_PER_MSEC, needs_to_be_atomic_or_not?);
#undef done
Should work and avoid the need to add yet another helper, please
double-check. Not as pretty, but accumulating generic sounding helpers
in i915_utils.h is a bit frowned upon.
Regards,
Tvrtko
+
ENGINE_WRITE_FW(engine, RING_TAIL, ring->head);
- ENGINE_POSTING_READ(engine, RING_TAIL);
+ if (ENGINE_READ_FW(engine, RING_HEAD) != ENGINE_READ_FW(engine,
RING_TAIL)) {
+ ENGINE_TRACE(engine, "failed to reset empty ring: [%x, %x]:
%x\n",
+ENGINE_READ_FW(engine, RING_HEAD),
+ENGINE_READ_FW(engine, RING_TAIL),
+ring->head);
+ goto err;
+ }
ENGINE_WRITE_FW(engine, RING_CTL,
RING_CTL_SIZE(ring->size) | RING_VALID);
@@ -241,12 +253,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
if (__intel_wait_for_register_fw(engine->uncore,
RING_CTL(engine->mmio_base),
RING_VALID, RING_VALID,
-5000, 0, NULL))
+5000, 0, NULL)) {
+ ENGINE_TRACE(engine, "failed to restart\n");
goto err;
+ }
- if (GRAPHICS_VER(engine->i915) > 2)
+ if (GRAPHICS_VER(engine->i915) > 2) {
ENGINE_WRITE_FW(engine,
RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
+ ENGINE_POSTING_READ(engine, RING_MI_MODE);
+ }
/* Now awake, let it get started */
if (ring->tail != ring->head) {
@@ -259,16 +275,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
return 0;
err:
- drm_err(>i915->drm,
- "%s initialization failed; "
- "ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start %08x
[expected %08x]\n",
- engine->name,
- ENGINE_READ(engine, RING_CTL),
- ENGINE_READ(engine, RING_CTL) & RING_VALID,
- ENGINE_READ(engine, RING_HEAD), ring->head,
- ENGINE_READ(engine, RING_TAIL), ring->tail,
- ENGINE_READ(engine, RING_START),
- i915_ggtt_offset(ring->vma));
+ ENGINE_TRACE(engine,
+"initialization failed; "
+"ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start
%08x [expected %08x]\n",
+ENGINE_READ(engine, RING_CTL),
+ENGINE_READ(engine, RING_CTL) & RING_VALID,
+ENGINE_READ(engine, RING_HEAD), ring->head,
+ENGINE_READ(engine, RING_TAIL), ring->tail,
+ENGINE_READ(engine, RING_START),
+i915_ggtt_offset(ring->vma));
+
Re: [PATCH v2 21/21] staging: media: tegra-video: add tegra20 variant
23.12.2022 16:02, Dmitry Osipenko пишет:
> 28.11.2022 18:23, Luca Ceresoli пишет:
>> +static int tegra20_vip_start_streaming(struct tegra_vip_channel *vip_chan)
>> +{
>> +struct tegra_vi_channel *vi_chan =
>> v4l2_get_subdev_hostdata(_chan->subdev);
>> +int width = vi_chan->format.width;
>> +int height = vi_chan->format.height;
>> +
>> +unsigned int main_input_format;
>> +unsigned int yuv_input_format;
>> +
>> +tegra20_vi_get_input_formats(vi_chan, _input_format,
>> _input_format);
>> +
>> +tegra20_vi_write(vi_chan, TEGRA_VI_VI_CORE_CONTROL, 0);
>> +
>> +tegra20_vi_write(vi_chan, TEGRA_VI_VI_INPUT_CONTROL,
>> + VI_INPUT_VIP_INPUT_ENABLE | main_input_format |
>> yuv_input_format);
>> +
>> +tegra20_vi_write(vi_chan, TEGRA_VI_V_DOWNSCALE_CONTROL, 0);
>> +tegra20_vi_write(vi_chan, TEGRA_VI_H_DOWNSCALE_CONTROL, 0);
>> +
>> +tegra20_vi_write(vi_chan, TEGRA_VI_VIP_V_ACTIVE, height <<
>> VI_VIP_V_ACTIVE_PERIOD_SFT);
>> +tegra20_vi_write(vi_chan, TEGRA_VI_VIP_H_ACTIVE,
>> + roundup(width, 2) << VI_VIP_H_ACTIVE_PERIOD_SFT);
>> +
>> +/*
>> + * For VIP, D9..D2 is mapped to the video decoder's P7..P0.
>> + * Disable/mask out the other Dn wires. When not in BT656
>> + * mode we also need the V/H sync.
>> + */
>> +tegra20_vi_write(vi_chan, TEGRA_VI_PIN_INPUT_ENABLE,
>> + GENMASK(9, 2) << VI_PIN_INPUT_VD_SFT |
>> + VI_PIN_INPUT_HSYNC | VI_PIN_INPUT_VSYNC);
>> +tegra20_vi_write(vi_chan, TEGRA_VI_VI_DATA_INPUT_CONTROL,
>> + GENMASK(9, 2) << VI_DATA_INPUT_SFT);
>> +tegra20_vi_write(vi_chan, TEGRA_VI_PIN_INVERSION, 0);
>> +
>> +tegra20_vi_write(vi_chan, TEGRA_VI_CONT_SYNCPT_OUT_1,
>> + VI_CONT_SYNCPT_OUT_1_CONTINUOUS_SYNCPT |
>> + host1x_syncpt_id(vi_chan->out_sp) <<
>> VI_CONT_SYNCPT_OUT_1_SYNCPT_IDX_SFT);
>
> Wondering whether you also need to set up the sypct_incr condition to
> op_done, it should be immediate by default. I see that T210 VI code sets
> up the incr condition.
Found in the doc "Continuous syncpt always use OP_DONE as condition",
the current code is fine.
Re: [PATCH v2 21/21] staging: media: tegra-video: add tegra20 variant
28.11.2022 18:23, Luca Ceresoli пишет:
> +static int tegra20_vip_start_streaming(struct tegra_vip_channel *vip_chan)
> +{
> + struct tegra_vi_channel *vi_chan =
> v4l2_get_subdev_hostdata(_chan->subdev);
> + int width = vi_chan->format.width;
> + int height = vi_chan->format.height;
> +
> + unsigned int main_input_format;
> + unsigned int yuv_input_format;
> +
> + tegra20_vi_get_input_formats(vi_chan, _input_format,
> _input_format);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_VI_CORE_CONTROL, 0);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_VI_INPUT_CONTROL,
> + VI_INPUT_VIP_INPUT_ENABLE | main_input_format |
> yuv_input_format);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_V_DOWNSCALE_CONTROL, 0);
> + tegra20_vi_write(vi_chan, TEGRA_VI_H_DOWNSCALE_CONTROL, 0);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_VIP_V_ACTIVE, height <<
> VI_VIP_V_ACTIVE_PERIOD_SFT);
> + tegra20_vi_write(vi_chan, TEGRA_VI_VIP_H_ACTIVE,
> + roundup(width, 2) << VI_VIP_H_ACTIVE_PERIOD_SFT);
> +
> + /*
> + * For VIP, D9..D2 is mapped to the video decoder's P7..P0.
> + * Disable/mask out the other Dn wires. When not in BT656
> + * mode we also need the V/H sync.
> + */
> + tegra20_vi_write(vi_chan, TEGRA_VI_PIN_INPUT_ENABLE,
> + GENMASK(9, 2) << VI_PIN_INPUT_VD_SFT |
> + VI_PIN_INPUT_HSYNC | VI_PIN_INPUT_VSYNC);
> + tegra20_vi_write(vi_chan, TEGRA_VI_VI_DATA_INPUT_CONTROL,
> + GENMASK(9, 2) << VI_DATA_INPUT_SFT);
> + tegra20_vi_write(vi_chan, TEGRA_VI_PIN_INVERSION, 0);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_CONT_SYNCPT_OUT_1,
> + VI_CONT_SYNCPT_OUT_1_CONTINUOUS_SYNCPT |
> + host1x_syncpt_id(vi_chan->out_sp) <<
> VI_CONT_SYNCPT_OUT_1_SYNCPT_IDX_SFT);
Wondering whether you also need to set up the sypct_incr condition to
op_done, it should be immediate by default. I see that T210 VI code sets
up the incr condition.
Re: [PATCH v2 09/13] drm/format-helper: Add conversion from XRGB8888 to 15-bit RGB555 formats
Hi Thomas,
Like in "drm/format-helper: Add conversion from XRGB to ARGB"
sparse is printing a warning:
drm_format_helper.c:412:27: warning: incorrect type in assignment (different
base types)
drm_format_helper.c:412:27:expected unsigned short [usertype]
drm_format_helper.c:412:27:got restricted __le16 [usertype]
On Tue, Dec 20, 2022 at 05:11:41PM +0100, Thomas Zimmermann wrote:
> Add conversion from XRGB to XRGB1555, ARGB1555 and RGBA5551, which
> are the formats currently supported by the simplefb infrastructure. The
> new helpers allow the output of XRGB framebuffers to firmware
> scanout buffers in one of the 15-bit formats.
>
> v2:
> * test 15-bit results with local endianness (Jose)
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Javier Martinez Canillas
> ---
> drivers/gpu/drm/drm_format_helper.c | 164 +++
> .../gpu/drm/tests/drm_format_helper_test.c| 189 ++
> include/drm/drm_format_helper.h | 9 +
> 3 files changed, 362 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 3767213ba97d..1cedfe02fadf 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -396,6 +396,161 @@ void drm_fb_xrgb_to_rgb565(struct iosys_map *dst,
> const unsigned int *dst_pi
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
>
> +static void drm_fb_xrgb_to_xrgb1555_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> +{
> + u16 *dbuf16 = dbuf;
> + const __le32 *sbuf32 = sbuf;
> + unsigned int x;
> + u16 val16;
> + u32 pix;
> +
> + for (x = 0; x < pixels; x++) {
> + pix = le32_to_cpu(sbuf32[x]);
> + val16 = ((pix & 0x00f8) >> 9) |
> + ((pix & 0xf800) >> 6) |
> + ((pix & 0x00f8) >> 3);
> + dbuf16[x] = cpu_to_le16(val16);
- dbuf16[x] = cpu_to_le16(val16);
+ dbuf16[x] = (__force u16)cpu_to_le16(val16);
> + }
> +}
> +
> +/**
> + * drm_fb_xrgb_to_xrgb1555 - Convert XRGB to XRGB1555 clip buffer
> + * @dst: Array of XRGB1555 destination buffers
> + * @dst_pitch: Array of numbers of bytes between the start of two
> consecutive scanlines
> + * within @dst; can be NULL if scanlines are stored next to each
> other.
> + * @src: Array of XRGB source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + *
> + * This function copies parts of a framebuffer to display memory and converts
> + * the color format during the process. The parameters @dst, @dst_pitch and
> + * @src refer to arrays. Each array must have at least as many entries as
> + * there are planes in @fb's format. Each entry stores the value for the
> + * format's respective color plane at the same index.
> + *
> + * This function does not apply clipping on @dst (i.e. the destination is at
> the
> + * top-left corner).
> + *
> + * Drivers can use this function for XRGB1555 devices that don't support
> + * XRGB natively.
> + */
> +void drm_fb_xrgb_to_xrgb1555(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> + const struct iosys_map *src, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> +{
> + static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
> + 2,
> + };
> +
> + drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
> + drm_fb_xrgb_to_xrgb1555_line);
> +}
> +EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb1555);
> +
> +static void drm_fb_xrgb_to_argb1555_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> +{
> + u16 *dbuf16 = dbuf;
> + const __le32 *sbuf32 = sbuf;
> + unsigned int x;
> + u16 val16;
> + u32 pix;
> +
> + for (x = 0; x < pixels; x++) {
> + pix = le32_to_cpu(sbuf32[x]);
> + val16 = BIT(15) | /* set alpha bit */
> + ((pix & 0x00f8) >> 9) |
> + ((pix & 0xf800) >> 6) |
> + ((pix & 0x00f8) >> 3);
> + dbuf16[x] = cpu_to_le16(val16);
- dbuf16[x] = cpu_to_le16(val16);
+ dbuf16[x] = (__force u16)cpu_to_le16(val16);
> + }
> +}
> +
> +/**
> + * drm_fb_xrgb_to_argb1555 - Convert XRGB to ARGB1555 clip buffer
> + * @dst: Array of ARGB1555 destination buffers
> + * @dst_pitch: Array of numbers of bytes between the start of two
> consecutive scanlines
> + * within @dst; can be NULL if scanlines are stored next to each
> other.
> + * @src: Array of XRGB source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + *
> + * This function copies parts of a framebuffer to display memory and converts
> + * the color format during the process. The parameters @dst, @dst_pitch and
> + * @src refer to arrays. Each array must have at least as many entries
Re: [PATCH v2 08/13] drm/format-helper: Add conversion from XRGB8888 to ARGB2101010
On Tue, Dec 20, 2022 at 05:11:40PM +0100, Thomas Zimmermann wrote:
> Add dedicated helper to convert from XRGB to ARGB2101010. Sets
> all alpha bits to make pixels fully opaque.
>
> v2:
> * set correct format in struct drm_framebuffer (Javier)
> * use cpubuf_to_le32()
> * type fixes
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Javier Martinez Canillas
Reviewed-by: José Expósito
> ---
> drivers/gpu/drm/drm_format_helper.c | 58 -
> .../gpu/drm/tests/drm_format_helper_test.c| 63 +++
> include/drm/drm_format_helper.h | 3 +
> 3 files changed, 122 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 23837b202988..3767213ba97d 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -605,6 +605,59 @@ void drm_fb_xrgb_to_xrgb2101010(struct iosys_map
> *dst, const unsigned int *d
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010);
>
> +static void drm_fb_xrgb_to_argb2101010_line(void *dbuf, const void
> *sbuf, unsigned int pixels)
> +{
> + __le32 *dbuf32 = dbuf;
> + const __le32 *sbuf32 = sbuf;
> + unsigned int x;
> + u32 val32;
> + u32 pix;
> +
> + for (x = 0; x < pixels; x++) {
> + pix = le32_to_cpu(sbuf32[x]);
> + val32 = ((pix & 0x00ff) << 2) |
> + ((pix & 0xff00) << 4) |
> + ((pix & 0x00ff) << 6);
> + pix = GENMASK(31, 30) | /* set alpha bits */
> + val32 | ((val32 >> 8) & 0x00300c03);
> + *dbuf32++ = cpu_to_le32(pix);
> + }
> +}
> +
> +/**
> + * drm_fb_xrgb_to_argb2101010 - Convert XRGB to ARGB2101010 clip
> buffer
> + * @dst: Array of ARGB2101010 destination buffers
> + * @dst_pitch: Array of numbers of bytes between the start of two
> consecutive scanlines
> + * within @dst; can be NULL if scanlines are stored next to each
> other.
> + * @src: Array of XRGB source buffers
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + *
> + * This function copies parts of a framebuffer to display memory and converts
> + * the color format during the process. The parameters @dst, @dst_pitch and
> + * @src refer to arrays. Each array must have at least as many entries as
> + * there are planes in @fb's format. Each entry stores the value for the
> + * format's respective color plane at the same index.
> + *
> + * This function does not apply clipping on @dst (i.e. the destination is at
> the
> + * top-left corner).
> + *
> + * Drivers can use this function for ARGB2101010 devices that don't support
> XRGB
> + * natively.
> + */
> +void drm_fb_xrgb_to_argb2101010(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *src, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> +{
> + static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
> + 4,
> + };
> +
> + drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
> + drm_fb_xrgb_to_argb2101010_line);
> +}
> +EXPORT_SYMBOL(drm_fb_xrgb_to_argb2101010);
> +
> static void drm_fb_xrgb_to_gray8_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> u8 *dbuf8 = dbuf;
> @@ -696,8 +749,6 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> fb_format = DRM_FORMAT_XRGB;
> if (fb_format == DRM_FORMAT_ARGB2101010)
> fb_format = DRM_FORMAT_XRGB2101010;
> - if (dst_format == DRM_FORMAT_ARGB2101010)
> - dst_format = DRM_FORMAT_XRGB2101010;
>
> if (fb_format == dst_format) {
> drm_fb_memcpy(dst, dst_pitch, src, fb, clip);
> @@ -721,6 +772,9 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> } else if (dst_format == DRM_FORMAT_XRGB2101010) {
> drm_fb_xrgb_to_xrgb2101010(dst, dst_pitch, src, fb,
> clip);
> return 0;
> + } else if (dst_format == DRM_FORMAT_ARGB2101010) {
> + drm_fb_xrgb_to_argb2101010(dst, dst_pitch, src, fb,
> clip);
> + return 0;
> } else if (dst_format == DRM_FORMAT_BGRX) {
> drm_fb_swab(dst, dst_pitch, src, fb, clip, false);
> return 0;
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index bc969413a412..de3aa252e8eb 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -47,6 +47,11 @@ struct convert_to_xrgb2101010_result {
> const u32 expected[TEST_BUF_SIZE];
> };
>
> +struct
Re: [PATCH v2 07/13] drm/format-helper: Add conversion from XRGB8888 to ARGB8888
Hi Thomas,
Compiling this patch with sparse enabled (you can do it from the KUnit
tests adding "--make_options C=2") throws a warning:
drm_format_helper.c:614:27: warning: incorrect type in assignment (different
base types)
drm_format_helper.c:614:27:expected unsigned int [usertype]
drm_format_helper.c:614:27:got restricted __le32 [usertype]
You might want to silence the warning with...
On Tue, Dec 20, 2022 at 05:11:39PM +0100, Thomas Zimmermann wrote:
> Add dedicated helper to convert from XRGB to ARGB. Sets
> all alpha bits to make pixels fully opaque.
>
> v2:
> * use cpubuf_to_le32()
> * type fixes
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Javier Martinez Canillas
> ---
> drivers/gpu/drm/drm_format_helper.c | 53 +++-
> .../gpu/drm/tests/drm_format_helper_test.c| 63 +++
> include/drm/drm_format_helper.h | 3 +
> 3 files changed, 117 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 36d2ca9d0f01..23837b202988 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -446,6 +446,54 @@ void drm_fb_xrgb_to_rgb888(struct iosys_map *dst,
> const unsigned int *dst_pi
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888);
>
> +static void drm_fb_xrgb_to_argb_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> +{
> + u32 *dbuf32 = dbuf;
> + const __le32 *sbuf32 = sbuf;
> + unsigned int x;
> + u32 pix;
> +
> + for (x = 0; x < pixels; x++) {
> + pix = le32_to_cpu(sbuf32[x]);
> + pix |= GENMASK(31, 24); /* fill alpha bits */
> + dbuf32[x] = cpu_to_le32(pix);
- dbuf32[x] = cpu_to_le32(pix);
+ dbuf32[x] = (__force u32)cpu_to_le32(pix);
Other than that:
Reviewed-by: José Expósito
> + }
> +}
> +
> +/**
> + * drm_fb_xrgb_to_argb - Convert XRGB to ARGB clip buffer
> + * @dst: Array of ARGB destination buffers
> + * @dst_pitch: Array of numbers of bytes between the start of two
> consecutive scanlines
> + * within @dst; can be NULL if scanlines are stored next to each
> other.
> + * @src: Array of XRGB source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + *
> + * This function copies parts of a framebuffer to display memory and
> converts the
> + * color format during the process. The parameters @dst, @dst_pitch and @src
> refer
> + * to arrays. Each array must have at least as many entries as there are
> planes in
> + * @fb's format. Each entry stores the value for the format's respective
> color plane
> + * at the same index.
> + *
> + * This function does not apply clipping on @dst (i.e. the destination is at
> the
> + * top-left corner).
> + *
> + * Drivers can use this function for ARGB devices that don't support
> XRGB
> + * natively. It sets an opaque alpha channel as part of the conversion.
> + */
> +void drm_fb_xrgb_to_argb(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> + const struct iosys_map *src, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> +{
> + static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
> + 4,
> + };
> +
> + drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
> + drm_fb_xrgb_to_argb_line);
> +}
> +EXPORT_SYMBOL(drm_fb_xrgb_to_argb);
> +
> static void drm_fb_rgb565_to_xrgb_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> __le32 *dbuf32 = dbuf;
> @@ -646,8 +694,6 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> /* treat alpha channel like filler bits */
> if (fb_format == DRM_FORMAT_ARGB)
> fb_format = DRM_FORMAT_XRGB;
> - if (dst_format == DRM_FORMAT_ARGB)
> - dst_format = DRM_FORMAT_XRGB;
> if (fb_format == DRM_FORMAT_ARGB2101010)
> fb_format = DRM_FORMAT_XRGB2101010;
> if (dst_format == DRM_FORMAT_ARGB2101010)
> @@ -669,6 +715,9 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> } else if (dst_format == DRM_FORMAT_RGB888) {
> drm_fb_xrgb_to_rgb888(dst, dst_pitch, src, fb,
> clip);
> return 0;
> + } else if (dst_format == DRM_FORMAT_ARGB) {
> + drm_fb_xrgb_to_argb(dst, dst_pitch, src, fb,
> clip);
> + return 0;
> } else if (dst_format == DRM_FORMAT_XRGB2101010) {
> drm_fb_xrgb_to_xrgb2101010(dst, dst_pitch, src, fb,
> clip);
> return 0;
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index
Re: [PATCH v2 05/13] drm/format-helper: Type fixes in format-helper tests
On Tue, Dec 20, 2022 at 05:11:37PM +0100, Thomas Zimmermann wrote:
> Change the source-buffer type of le32buf_to_cpu() to __le32* to
> reflect endianness. Result buffers are converted to local endianness,
> so instantiate them from regular u8 or u32 types.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: José Expósito
> ---
> drivers/gpu/drm/tests/drm_format_helper_test.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 04fe373c9d97..c2411ec808a1 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -279,7 +279,7 @@ static u16 *le16buf_to_cpu(struct kunit *test, const
> __le16 *buf, size_t buf_siz
> return dst;
> }
>
> -static u32 *le32buf_to_cpu(struct kunit *test, const u32 *buf, size_t
> buf_size)
> +static u32 *le32buf_to_cpu(struct kunit *test, const __le32 *buf, size_t
> buf_size)
> {
> u32 *dst = NULL;
> int n;
> @@ -323,7 +323,7 @@ static void drm_test_fb_xrgb_to_gray8(struct kunit
> *test)
> const struct convert_xrgb_case *params = test->param_value;
> const struct convert_to_gray8_result *result = >gray8_result;
> size_t dst_size;
> - __u8 *buf = NULL;
> + u8 *buf = NULL;
> __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> @@ -353,7 +353,7 @@ static void drm_test_fb_xrgb_to_rgb332(struct kunit
> *test)
> const struct convert_xrgb_case *params = test->param_value;
> const struct convert_to_rgb332_result *result = >rgb332_result;
> size_t dst_size;
> - __u8 *buf = NULL;
> + u8 *buf = NULL;
> __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> @@ -419,7 +419,7 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
> *test)
> const struct convert_xrgb_case *params = test->param_value;
> const struct convert_to_rgb888_result *result = >rgb888_result;
> size_t dst_size;
> - __u8 *buf = NULL;
> + u8 *buf = NULL;
> __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> @@ -453,7 +453,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
> kunit *test)
> const struct convert_xrgb_case *params = test->param_value;
> const struct convert_to_xrgb2101010_result *result =
> >xrgb2101010_result;
> size_t dst_size;
> - __u32 *buf = NULL;
> + u32 *buf = NULL;
> __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> @@ -475,7 +475,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
> kunit *test)
> iosys_map_set_vaddr(, xrgb);
>
> drm_fb_xrgb_to_xrgb2101010(, >dst_pitch, , ,
> >clip);
> - buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
> + buf = le32buf_to_cpu(test, (__force const __le32 *)buf, dst_size /
> sizeof(u32));
> KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> }
>
> --
> 2.39.0
>
Re: [PATCH v2 04/13] drm/format-helper: Store RGB565 in little-endian order
On Tue, Dec 20, 2022 at 05:11:36PM +0100, Thomas Zimmermann wrote:
> Fix to-RGB565 conversion helpers to store the result in little-
> endian byte order. Update test cases as well.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: José Expósito
> ---
> drivers/gpu/drm/drm_format_helper.c | 9 +
> .../gpu/drm/tests/drm_format_helper_test.c| 20 ++-
> 2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index b98bd7c5caee..f3f3b3809a3e 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -322,7 +322,7 @@ EXPORT_SYMBOL(drm_fb_xrgb_to_rgb332);
>
> static void drm_fb_xrgb_to_rgb565_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> - u16 *dbuf16 = dbuf;
> + __le16 *dbuf16 = dbuf;
> const __le32 *sbuf32 = sbuf;
> unsigned int x;
> u16 val16;
> @@ -333,14 +333,15 @@ static void drm_fb_xrgb_to_rgb565_line(void *dbuf,
> const void *sbuf, unsigne
> val16 = ((pix & 0x00F8) >> 8) |
> ((pix & 0xFC00) >> 5) |
> ((pix & 0x00F8) >> 3);
> - dbuf16[x] = val16;
> + dbuf16[x] = cpu_to_le16(val16);
> }
> }
>
> +/* TODO: implement this helper as conversion to RGB565|BIG_ENDIAN */
> static void drm_fb_xrgb_to_rgb565_swab_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> - u16 *dbuf16 = dbuf;
> + __le16 *dbuf16 = dbuf;
> const __le32 *sbuf32 = sbuf;
> unsigned int x;
> u16 val16;
> @@ -351,7 +352,7 @@ static void drm_fb_xrgb_to_rgb565_swab_line(void
> *dbuf, const void *sbuf,
> val16 = ((pix & 0x00F8) >> 8) |
> ((pix & 0xFC00) >> 5) |
> ((pix & 0x00F8) >> 3);
> - dbuf16[x] = swab16(val16);
> + dbuf16[x] = cpu_to_le16(swab16(val16));
> }
> }
>
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index e7c49e6d3f6d..04fe373c9d97 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -264,6 +264,21 @@ static size_t conversion_buf_size(u32 dst_format,
> unsigned int dst_pitch,
> return dst_pitch * drm_rect_height(clip);
> }
>
> +static u16 *le16buf_to_cpu(struct kunit *test, const __le16 *buf, size_t
> buf_size)
> +{
> + u16 *dst = NULL;
> + int n;
> +
> + dst = kunit_kzalloc(test, sizeof(*dst) * buf_size, GFP_KERNEL);
> + if (!dst)
> + return NULL;
> +
> + for (n = 0; n < buf_size; n++)
> + dst[n] = le16_to_cpu(buf[n]);
> +
> + return dst;
> +}
> +
> static u32 *le32buf_to_cpu(struct kunit *test, const u32 *buf, size_t
> buf_size)
> {
> u32 *dst = NULL;
> @@ -368,7 +383,7 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
> *test)
> const struct convert_xrgb_case *params = test->param_value;
> const struct convert_to_rgb565_result *result = >rgb565_result;
> size_t dst_size;
> - __u16 *buf = NULL;
> + u16 *buf = NULL;
> __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> @@ -390,9 +405,12 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
> *test)
> iosys_map_set_vaddr(, xrgb);
>
> drm_fb_xrgb_to_rgb565(, >dst_pitch, , ,
> >clip, false);
> + buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
> sizeof(__le16));
> KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
>
> + buf = dst.vaddr; /* restore original value of buf */
> drm_fb_xrgb_to_rgb565(, >dst_pitch, , ,
> >clip, true);
> + buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
> sizeof(__le16));
> KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected_swab, dst_size), 0);
> }
>
> --
> 2.39.0
>
Re: [PATCH v2 03/13] drm/format-helper: Fix test-input format conversion
On Tue, Dec 20, 2022 at 05:11:35PM +0100, Thomas Zimmermann wrote:
> Convert test input for format helpers from host byte order to
> little-endian order. The current code does it the other way around,
> but there's no effective difference to the result.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: José Expósito
> ---
> .../gpu/drm/tests/drm_format_helper_test.c| 35 +--
> 1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index cd1d7da3483c..e7c49e6d3f6d 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -279,6 +279,21 @@ static u32 *le32buf_to_cpu(struct kunit *test, const u32
> *buf, size_t buf_size)
> return dst;
> }
>
> +static __le32 *cpubuf_to_le32(struct kunit *test, const u32 *buf, size_t
> buf_size)
> +{
> + __le32 *dst = NULL;
> + int n;
> +
> + dst = kunit_kzalloc(test, sizeof(*dst) * buf_size, GFP_KERNEL);
> + if (!dst)
> + return NULL;
> +
> + for (n = 0; n < buf_size; n++)
> + dst[n] = cpu_to_le32(buf[n]);
> +
> + return dst;
> +}
> +
> static void convert_xrgb_case_desc(struct convert_xrgb_case *t,
> char *desc)
> {
> @@ -294,7 +309,7 @@ static void drm_test_fb_xrgb_to_gray8(struct kunit
> *test)
> const struct convert_to_gray8_result *result = >gray8_result;
> size_t dst_size;
> __u8 *buf = NULL;
> - __u32 *xrgb = NULL;
> + __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> struct drm_framebuffer fb = {
> @@ -310,7 +325,7 @@ static void drm_test_fb_xrgb_to_gray8(struct kunit
> *test)
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
> iosys_map_set_vaddr(, buf);
>
> - xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
> + xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
> iosys_map_set_vaddr(, xrgb);
>
> @@ -324,7 +339,7 @@ static void drm_test_fb_xrgb_to_rgb332(struct kunit
> *test)
> const struct convert_to_rgb332_result *result = >rgb332_result;
> size_t dst_size;
> __u8 *buf = NULL;
> - __u32 *xrgb = NULL;
> + __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> struct drm_framebuffer fb = {
> @@ -340,7 +355,7 @@ static void drm_test_fb_xrgb_to_rgb332(struct kunit
> *test)
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
> iosys_map_set_vaddr(, buf);
>
> - xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
> + xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
> iosys_map_set_vaddr(, xrgb);
>
> @@ -354,7 +369,7 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
> *test)
> const struct convert_to_rgb565_result *result = >rgb565_result;
> size_t dst_size;
> __u16 *buf = NULL;
> - __u32 *xrgb = NULL;
> + __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> struct drm_framebuffer fb = {
> @@ -370,7 +385,7 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
> *test)
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
> iosys_map_set_vaddr(, buf);
>
> - xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
> + xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
> iosys_map_set_vaddr(, xrgb);
>
> @@ -387,7 +402,7 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
> *test)
> const struct convert_to_rgb888_result *result = >rgb888_result;
> size_t dst_size;
> __u8 *buf = NULL;
> - __u32 *xrgb = NULL;
> + __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> struct drm_framebuffer fb = {
> @@ -403,7 +418,7 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
> *test)
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
> iosys_map_set_vaddr(, buf);
>
> - xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
> + xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
> iosys_map_set_vaddr(, xrgb);
>
> @@ -421,7 +436,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
> kunit *test)
> const struct convert_to_xrgb2101010_result *result =
> >xrgb2101010_result;
> size_t dst_size;
> __u32 *buf = NULL;
> - __u32 *xrgb = NULL;
> + __le32 *xrgb = NULL;
> struct iosys_map dst, src;
>
> struct drm_framebuffer fb = {
> @@ -437,7 +452,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
> kunit *test)
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
>
Re: [PATCH v2 02/13] drm/format-helper: Comment on RGB888 byte order
On Tue, Dec 20, 2022 at 05:11:34PM +0100, Thomas Zimmermann wrote:
> RGB888 is different than the other formats as most of its pixels are
> unaligned and therefore helper functions do not use endianness conversion
> helpers. Comment on this in the source code.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: José Expósito
> ---
> drivers/gpu/drm/drm_format_helper.c| 1 +
> drivers/gpu/drm/tests/drm_format_helper_test.c | 4
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 74ff33c2ddaa..b98bd7c5caee 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -404,6 +404,7 @@ static void drm_fb_xrgb_to_rgb888_line(void *dbuf,
> const void *sbuf, unsigne
>
> for (x = 0; x < pixels; x++) {
> pix = le32_to_cpu(sbuf32[x]);
> + /* write blue-green-red to output in little endianness */
> *dbuf8++ = (pix & 0x00FF) >> 0;
> *dbuf8++ = (pix & 0xFF00) >> 8;
> *dbuf8++ = (pix & 0x00FF) >> 16;
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 2191e57f2297..cd1d7da3483c 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -407,6 +407,10 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
> *test)
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
> iosys_map_set_vaddr(, xrgb);
>
> + /*
> + * RGB888 expected results are already in little-endian
> + * order, so there's no need to convert the test output.
> + */
> drm_fb_xrgb_to_rgb888(, >dst_pitch, , ,
> >clip);
> KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> }
> --
> 2.39.0
>
Re: [PATCH v2 21/21] staging: media: tegra-video: add tegra20 variant
28.11.2022 18:23, Luca Ceresoli пишет:
> +/* --
> + * VIP
> + */
> +
> +/*
> + * VIP-specific configuration for stream start.
> + *
> + * Whatever is common among VIP and CSI is done by the VI component (see
> + * tegra20_vi_start_streaming()). Here we do what is VIP-specific.
> + */
> +static int tegra20_vip_start_streaming(struct tegra_vip_channel *vip_chan)
> +{
> + struct tegra_vi_channel *vi_chan =
> v4l2_get_subdev_hostdata(_chan->subdev);
> + int width = vi_chan->format.width;
> + int height = vi_chan->format.height;
> +
> + unsigned int main_input_format;
> + unsigned int yuv_input_format;
> +
> + tegra20_vi_get_input_formats(vi_chan, _input_format,
> _input_format);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_VI_CORE_CONTROL, 0);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_VI_INPUT_CONTROL,
> + VI_INPUT_VIP_INPUT_ENABLE | main_input_format |
> yuv_input_format);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_V_DOWNSCALE_CONTROL, 0);
> + tegra20_vi_write(vi_chan, TEGRA_VI_H_DOWNSCALE_CONTROL, 0);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_VIP_V_ACTIVE, height <<
> VI_VIP_V_ACTIVE_PERIOD_SFT);
> + tegra20_vi_write(vi_chan, TEGRA_VI_VIP_H_ACTIVE,
> + roundup(width, 2) << VI_VIP_H_ACTIVE_PERIOD_SFT);
> +
> + /*
> + * For VIP, D9..D2 is mapped to the video decoder's P7..P0.
> + * Disable/mask out the other Dn wires. When not in BT656
> + * mode we also need the V/H sync.
> + */
> + tegra20_vi_write(vi_chan, TEGRA_VI_PIN_INPUT_ENABLE,
> + GENMASK(9, 2) << VI_PIN_INPUT_VD_SFT |
> + VI_PIN_INPUT_HSYNC | VI_PIN_INPUT_VSYNC);
> + tegra20_vi_write(vi_chan, TEGRA_VI_VI_DATA_INPUT_CONTROL,
> + GENMASK(9, 2) << VI_DATA_INPUT_SFT);
> + tegra20_vi_write(vi_chan, TEGRA_VI_PIN_INVERSION, 0);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_CONT_SYNCPT_OUT_1,
> + VI_CONT_SYNCPT_OUT_1_CONTINUOUS_SYNCPT |
> + host1x_syncpt_id(vi_chan->out_sp) <<
> VI_CONT_SYNCPT_OUT_1_SYNCPT_IDX_SFT);
> +
> + tegra20_vi_write(vi_chan, TEGRA_VI_CAMERA_CONTROL,
> VI_CAMERA_CONTROL_STOP_CAPTURE);
> +
> + return 0;
> +}
> +
> +static const struct tegra_vip_ops tegra20_vip_ops = {
> + .vip_start_streaming = tegra20_vip_start_streaming,
> +};
> +
> +const struct tegra_vip_soc tegra20_vip_soc = {
> + .ops = _vip_ops,
> +};
Shouldn't this be placed in vip.c? Also looks like patch #20 won't link
because tegra20_vip_soc is defined in patch #21.
Re: [PATCH v2 21/21] staging: media: tegra-video: add tegra20 variant
23.12.2022 15:15, Dmitry Osipenko пишет:
> 22.12.2022 12:03, Luca Ceresoli пишет:
>> Hello Dmitry,
>>
>> On Wed, 21 Dec 2022 00:40:20 +0300
>> Dmitry Osipenko wrote:
>>
>>> 28.11.2022 18:23, Luca Ceresoli пишет:
+static int tegra20_channel_capture_frame(struct tegra_vi_channel *chan,
+ struct tegra_channel_buffer *buf)
+{
+ u32 value;
+ int err;
+
+ chan->next_out_sp_idx++;
+
+ tegra20_channel_vi_buffer_setup(chan, buf);
+
+ tegra20_vi_write(chan, TEGRA_VI_CAMERA_CONTROL,
VI_CAMERA_CONTROL_VIP_ENABLE);
+
+ /* Wait for syncpt counter to reach frame start event threshold */
+ err = host1x_syncpt_wait(chan->out_sp, chan->next_out_sp_idx,
+ TEGRA_VI_SYNCPT_WAIT_TIMEOUT, );
>>>
>>> You're not using the "value" variable, it should be NULL.
>>
>> Ah, sure, good catch.
>>
>>> The "chan->out_sp" looks redundant, it duplicates the chan->mw_ack_sp.
>>
>> I agree it is redundant and can be improved.
>>
>>> AFAICS from the doc, T20 has two VI channels, and thus, two mw_ack_sp,
>>> like T210.
>>
>> I'm confused by this. In the current driver, each VI channel has an
>> array of 2 mw_ack_sp, the second of which is only used the ganged
>> CSI ports. I have no docs mentioning ganged ports so I don't know
>> exactly how they work and whether T20 might need more than 1 syncpt per
>> channel or not for CSI. Definitely when using VIP only one such syncpt
>> per each VI (or per each VIP, as per your reply to patch 1) is needed.
>>
>> Bottom line: I think I can simply remove the out_sp and in the VIP code
>> always use chan->mw_ack_sp[0], and document that it's what is called OUT
>> in VIP terms.
>>
>> Does this plan seem good?
>
> Older Tegra VI doesn't have ganged ports, but two memory/CSI channels.
> It feels to me that Tegra VI can capture both channels independently,
> though downstream driver stack used only one of the channels, IIRC.
>
> There is a VI header file from nvddk in downstream kernel, which is
> pretty much the doc by itself.
>
> https://nv-tegra.nvidia.com/r/gitweb?p=linux-2.6.git;a=blob;f=arch/arm/mach-tegra/include/ap20/arvi.h;h=6ce52e8e9a7213e33466d34a71cf3af2b6944b8a;
Although, after a bit closer look, I see that there is only one port
selector there. Hence there only one port can be active at a time.
[PATCH] drm/i915/gt: Retry RING_HEAD reset until it sticks
From: Chris Wilson
On Haswell, in particular, we see an issue where resets fails because
the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
doesn't point to the remaining requests to re-run, but may instead point
into the uninitialised portion of the ring, the GPU may be then fed
invalid instructions from a privileged context, often pushing the GPU
into an unrecoverable hang.
If at first the write doesn't succeed, try, try again.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/5432
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3303
Signed-off-by: Chris Wilson
Cc: Andrzej Hajda
Cc: Mika Kuoppala
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 44 +--
drivers/gpu/drm/i915/i915_utils.h | 8
2 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 827adb0cfaea6..cdf283f5b1427 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -192,6 +192,7 @@ static bool stop_ring(struct intel_engine_cs *engine)
static int xcs_resume(struct intel_engine_cs *engine)
{
struct intel_ring *ring = engine->legacy.ring;
+ ktime_t kt;
ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
ring->head, ring->tail);
@@ -230,9 +231,20 @@ static int xcs_resume(struct intel_engine_cs *engine)
set_pp_dir(engine);
/* First wake the ring up to an empty/idle ring */
- ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+ until_timeout_ns(kt, 2 * NSEC_PER_MSEC) {
+ ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+ if (ENGINE_READ_FW(engine, RING_HEAD) == ring->head)
+ break;
+ }
+
ENGINE_WRITE_FW(engine, RING_TAIL, ring->head);
- ENGINE_POSTING_READ(engine, RING_TAIL);
+ if (ENGINE_READ_FW(engine, RING_HEAD) != ENGINE_READ_FW(engine,
RING_TAIL)) {
+ ENGINE_TRACE(engine, "failed to reset empty ring: [%x, %x]:
%x\n",
+ENGINE_READ_FW(engine, RING_HEAD),
+ENGINE_READ_FW(engine, RING_TAIL),
+ring->head);
+ goto err;
+ }
ENGINE_WRITE_FW(engine, RING_CTL,
RING_CTL_SIZE(ring->size) | RING_VALID);
@@ -241,12 +253,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
if (__intel_wait_for_register_fw(engine->uncore,
RING_CTL(engine->mmio_base),
RING_VALID, RING_VALID,
-5000, 0, NULL))
+5000, 0, NULL)) {
+ ENGINE_TRACE(engine, "failed to restart\n");
goto err;
+ }
- if (GRAPHICS_VER(engine->i915) > 2)
+ if (GRAPHICS_VER(engine->i915) > 2) {
ENGINE_WRITE_FW(engine,
RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
+ ENGINE_POSTING_READ(engine, RING_MI_MODE);
+ }
/* Now awake, let it get started */
if (ring->tail != ring->head) {
@@ -259,16 +275,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
return 0;
err:
- drm_err(>i915->drm,
- "%s initialization failed; "
- "ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start
%08x [expected %08x]\n",
- engine->name,
- ENGINE_READ(engine, RING_CTL),
- ENGINE_READ(engine, RING_CTL) & RING_VALID,
- ENGINE_READ(engine, RING_HEAD), ring->head,
- ENGINE_READ(engine, RING_TAIL), ring->tail,
- ENGINE_READ(engine, RING_START),
- i915_ggtt_offset(ring->vma));
+ ENGINE_TRACE(engine,
+"initialization failed; "
+"ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x]
start %08x [expected %08x]\n",
+ENGINE_READ(engine, RING_CTL),
+ENGINE_READ(engine, RING_CTL) & RING_VALID,
+ENGINE_READ(engine, RING_HEAD), ring->head,
+ENGINE_READ(engine, RING_TAIL), ring->tail,
+ENGINE_READ(engine, RING_START),
+i915_ggtt_offset(ring->vma));
+ GEM_TRACE_DUMP();
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index b64192d9c7daa..f24a25c0685e1 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -254,6 +254,14 @@ wait_remaining_ms_from_jiffies(unsigned long
timestamp_jiffies, int to_wait_ms)
}
}
+/**
+ * until_timeout_ns - Keep retrying (busy spin) until the duration has passed
+ */
+#define until_timeout_ns(end,
Re: [PATCH v2] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/15/2022 6:59 PM, Jeremi Piotrowski wrote:
> On Tue, Dec 13, 2022 at 04:40:27PM +0530, Rijo Thomas wrote:
>> For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
>> ring buffer address sent by host to ASP must be a real physical
>> address and the pages must be physically contiguous.
>>
>> In a virtualized environment though, when the driver is running in a
>> guest VM, the pages allocated by __get_free_pages() may not be
>> contiguous in the host (or machine) physical address space. Guests
>> will see a guest (or pseudo) physical address and not the actual host
>> (or machine) physical address. The TEE running on ASP cannot decipher
>> pseudo physical addresses. It needs host or machine physical address.
>>
>> To resolve this problem, use DMA APIs for allocating buffers that must
>> be shared with TEE. This will ensure that the pages are contiguous in
>> host (or machine) address space. If the DMA handle is an IOVA,
>> translate it into a physical address before sending it to ASP.
>>
>> This patch also exports two APIs (one for buffer allocation and
>> another to free the buffer). This API can be used by AMD-TEE driver to
>> share buffers with TEE.
>>
>> Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
>> Cc: Tom Lendacky
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Rijo Thomas
>> Co-developed-by: Jeshwanth
>> Signed-off-by: Jeshwanth
>> Reviewed-by: Devaraj Rangasamy
>> ---
>> v2:
>> * Removed references to dma_buffer.
>> * If psp_init() fails, clear reference to master device.
>> * Handle gfp flags within psp_tee_alloc_buffer() instead of passing it as
>>a function argument.
>> * Added comments within psp_tee_alloc_buffer() to serve as future
>>documentation.
>>
>> drivers/crypto/ccp/psp-dev.c | 13 ++--
>> drivers/crypto/ccp/tee-dev.c | 124 +++
>> drivers/crypto/ccp/tee-dev.h | 9 +--
>> include/linux/psp-tee.h | 49 ++
>> 4 files changed, 142 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index c9c741ac8442..380f5caaa550 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
>> goto e_err;
>> }
>>
>> -ret = psp_init(psp);
>> -if (ret)
>> -goto e_irq;
>> -
>> if (sp->set_psp_master_device)
>> sp->set_psp_master_device(sp);
>>
>> +ret = psp_init(psp);
>> +if (ret)
>> +goto e_clear;
>> +
>> /* Enable interrupt */
>> iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
>>
>> @@ -175,7 +175,10 @@ int psp_dev_init(struct sp_device *sp)
>>
>> return 0;
>>
>> -e_irq:
>> +e_clear:
>> +if (sp->clear_psp_master_device)
>> +sp->clear_psp_master_device(sp);
>> +
>> sp_free_psp_irq(psp->sp, psp);
>> e_err:
>> sp->psp_data = NULL;
>> diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
>> index 5c9d47f3be37..5c43e6e166f1 100644
>> --- a/drivers/crypto/ccp/tee-dev.c
>> +++ b/drivers/crypto/ccp/tee-dev.c
>> @@ -12,8 +12,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> -#include
>> #include
>>
>> #include "psp-dev.h"
>> @@ -21,25 +22,73 @@
>>
>> static bool psp_dead;
>>
>> +struct psp_tee_buffer *psp_tee_alloc_buffer(unsigned long size)
>> +{
>> +struct psp_device *psp = psp_get_master_device();
>> +struct psp_tee_buffer *buf;
>> +struct iommu_domain *dom;
>> +
>> +if (!psp || !size)
>> +return NULL;
>> +
>> +buf = kzalloc(sizeof(*buf), GFP_KERNEL);
>> +if (!buf)
>> +return NULL;
>> +
>> +/* The pages allocated for PSP Trusted OS must be physically
>> + * contiguous in host (or machine) address space. Therefore,
>> + * use DMA API to allocate memory.
>> + */
>> +
>> +buf->vaddr = dma_alloc_coherent(psp->dev, size, >dma,
>> +GFP_KERNEL | __GFP_ZERO);
>
> dma_alloc_coherent memory is just as contiguous as __get_free_pages, and
> calling dma_alloc_coherent from a guest does not guarantee that the memory is
> contiguous in host memory either. The memory would look contiguous from the
> device point of view thanks to the IOMMU though (in both cases). So this is
> not
> about being contiguous but other properties that you might rely on (dma mask
> most likely, or coherent if you're not running this on x86?).
>
> Can you confirm why this fixes things and update the comment to reflect that.
>
I see what you are saying.
We verified this in Xen Dom0 PV guest, where dma_alloc_coherent() returned a
memory
that is contiguous in machine address space, and the machine address was
returned
in the dma handle (buf->dma).
>> +if (!buf->vaddr || !buf->dma) {
>> +kfree(buf);
>> +return NULL;
>> +}
>> +
>> +buf->size = size;
>> +
>> +
Re: [PATCH v2 21/21] staging: media: tegra-video: add tegra20 variant
22.12.2022 12:03, Luca Ceresoli пишет:
> Hello Dmitry,
>
> On Wed, 21 Dec 2022 00:40:20 +0300
> Dmitry Osipenko wrote:
>
>> 28.11.2022 18:23, Luca Ceresoli пишет:
>>> +static int tegra20_channel_capture_frame(struct tegra_vi_channel *chan,
>>> +struct tegra_channel_buffer *buf)
>>> +{
>>> + u32 value;
>>> + int err;
>>> +
>>> + chan->next_out_sp_idx++;
>>> +
>>> + tegra20_channel_vi_buffer_setup(chan, buf);
>>> +
>>> + tegra20_vi_write(chan, TEGRA_VI_CAMERA_CONTROL,
>>> VI_CAMERA_CONTROL_VIP_ENABLE);
>>> +
>>> + /* Wait for syncpt counter to reach frame start event threshold */
>>> + err = host1x_syncpt_wait(chan->out_sp, chan->next_out_sp_idx,
>>> +TEGRA_VI_SYNCPT_WAIT_TIMEOUT, );
>>
>> You're not using the "value" variable, it should be NULL.
>
> Ah, sure, good catch.
>
>> The "chan->out_sp" looks redundant, it duplicates the chan->mw_ack_sp.
>
> I agree it is redundant and can be improved.
>
>> AFAICS from the doc, T20 has two VI channels, and thus, two mw_ack_sp,
>> like T210.
>
> I'm confused by this. In the current driver, each VI channel has an
> array of 2 mw_ack_sp, the second of which is only used the ganged
> CSI ports. I have no docs mentioning ganged ports so I don't know
> exactly how they work and whether T20 might need more than 1 syncpt per
> channel or not for CSI. Definitely when using VIP only one such syncpt
> per each VI (or per each VIP, as per your reply to patch 1) is needed.
>
> Bottom line: I think I can simply remove the out_sp and in the VIP code
> always use chan->mw_ack_sp[0], and document that it's what is called OUT
> in VIP terms.
>
> Does this plan seem good?
Older Tegra VI doesn't have ganged ports, but two memory/CSI channels.
It feels to me that Tegra VI can capture both channels independently,
though downstream driver stack used only one of the channels, IIRC.
There is a VI header file from nvddk in downstream kernel, which is
pretty much the doc by itself.
https://nv-tegra.nvidia.com/r/gitweb?p=linux-2.6.git;a=blob;f=arch/arm/mach-tegra/include/ap20/arvi.h;h=6ce52e8e9a7213e33466d34a71cf3af2b6944b8a;
Re: [PATCH] drm: Replace DRM_DEBUG with drm_dbg_core in file and ioctl handling
Reviewed-by: Simon Ser
[PATCH] drm: Replace DRM_DEBUG with drm_dbg_core in file and ioctl handling
From: Tvrtko Ursulin
Replace the deprecated macro with the per-device one.
Signed-off-by: Tvrtko Ursulin
Acked-by: Christian König
---
Would anyone like to r-b and merge this small cleanup?
---
drivers/gpu/drm/drm_file.c | 18 +-
drivers/gpu/drm/drm_ioc32.c | 13 +++--
drivers/gpu/drm/drm_ioctl.c | 25 +
3 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 64b4a3a87fbb..a51ff8cee049 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -245,10 +245,10 @@ void drm_file_free(struct drm_file *file)
dev = file->minor->dev;
- DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, open_count=%d\n",
- current->comm, task_pid_nr(current),
- (long)old_encode_dev(file->minor->kdev->devt),
- atomic_read(>open_count));
+ drm_dbg_core(dev, "comm=\"%s\", pid=%d, dev=0x%lx, open_count=%d\n",
+current->comm, task_pid_nr(current),
+(long)old_encode_dev(file->minor->kdev->devt),
+atomic_read(>open_count));
#ifdef CONFIG_DRM_LEGACY
if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
@@ -340,8 +340,8 @@ int drm_open_helper(struct file *filp, struct drm_minor
*minor)
dev->switch_power_state != DRM_SWITCH_POWER_DYNAMIC_OFF)
return -EINVAL;
- DRM_DEBUG("comm=\"%s\", pid=%d, minor=%d\n", current->comm,
- task_pid_nr(current), minor->index);
+ drm_dbg_core(dev, "comm=\"%s\", pid=%d, minor=%d\n",
+current->comm, task_pid_nr(current), minor->index);
priv = drm_file_alloc(minor);
if (IS_ERR(priv))
@@ -450,11 +450,11 @@ EXPORT_SYMBOL(drm_open);
void drm_lastclose(struct drm_device * dev)
{
- DRM_DEBUG("\n");
+ drm_dbg_core(dev, "\n");
if (dev->driver->lastclose)
dev->driver->lastclose(dev);
- DRM_DEBUG("driver lastclose completed\n");
+ drm_dbg_core(dev, "driver lastclose completed\n");
if (drm_core_check_feature(dev, DRIVER_LEGACY))
drm_legacy_dev_reinit(dev);
@@ -485,7 +485,7 @@ int drm_release(struct inode *inode, struct file *filp)
if (drm_dev_needs_global_mutex(dev))
mutex_lock(_global_mutex);
- DRM_DEBUG("open_count = %d\n", atomic_read(>open_count));
+ drm_dbg_core(dev, "open_count = %d\n", atomic_read(>open_count));
drm_close_helper(filp);
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 5d82891c3222..49a743f62b4a 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -972,6 +972,7 @@ long drm_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
unsigned int nr = DRM_IOCTL_NR(cmd);
struct drm_file *file_priv = filp->private_data;
+ struct drm_device *dev = file_priv->minor->dev;
drm_ioctl_compat_t *fn;
int ret;
@@ -986,14 +987,14 @@ long drm_compat_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
if (!fn)
return drm_ioctl(filp, cmd, arg);
- DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
- current->comm, task_pid_nr(current),
- (long)old_encode_dev(file_priv->minor->kdev->devt),
- file_priv->authenticated,
- drm_compat_ioctls[nr].name);
+ drm_dbg_core(dev, "comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
+current->comm, task_pid_nr(current),
+(long)old_encode_dev(file_priv->minor->kdev->devt),
+file_priv->authenticated,
+drm_compat_ioctls[nr].name);
ret = (*fn)(filp, cmd, arg);
if (ret)
- DRM_DEBUG("ret = %d\n", ret);
+ drm_dbg_core(dev, "ret = %d\n", ret);
return ret;
}
EXPORT_SYMBOL(drm_compat_ioctl);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ca2a6e6101dc..7c9d66ee917d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -440,7 +440,7 @@ static int drm_setversion(struct drm_device *dev, void
*data, struct drm_file *f
int drm_noop(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
- DRM_DEBUG("\n");
+ drm_dbg_core(dev, "\n");
return 0;
}
EXPORT_SYMBOL(drm_noop);
@@ -856,16 +856,16 @@ long drm_ioctl(struct file *filp,
out_size = 0;
ksize = max(max(in_size, out_size), drv_size);
- DRM_DEBUG("comm=\"%s\" pid=%d, dev=0x%lx, auth=%d, %s\n",
- current->comm, task_pid_nr(current),
- (long)old_encode_dev(file_priv->minor->kdev->devt),
- file_priv->authenticated, ioctl->name);
+ drm_dbg_core(dev, "comm=\"%s\" pid=%d, dev=0x%lx, auth=%d, %s\n",
+
Re: [Intel-gfx] [RFC PATCH 11/20] drm/i915: Remove gem and overlay frontbuffer tracking
On 22/12/2022 22:21, Matthew Brost wrote:
From: Maarten Lankhorst
Frontbuffer update handling should be done explicitly by using dirtyfb
calls only.
A bit terse - questions around if this breaks something, and if it does
what and why it is okay, were left hanging in the air in the previous
thread (a6cdde0b-47a1-967d-f2c4-9299618cb...@linux.intel.com). Can that
be discussed please?
Plus, this does not appear to be either DRM core or Xe work so maybe
doesn't need to be in this series to start with?!
Regards,
Tvrtko
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 1 +
drivers/gpu/drm/i915/display/intel_drrs.c | 1 +
drivers/gpu/drm/i915/display/intel_fb.c | 1 +
drivers/gpu/drm/i915/display/intel_overlay.c | 14 ---
.../drm/i915/display/intel_plane_initial.c| 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 1 +
.../drm/i915/display/skl_universal_plane.c| 1 +
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 ---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 7 --
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 --
drivers/gpu/drm/i915/gem/i915_gem_object.c| 25 ---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 22
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 4 ---
drivers/gpu/drm/i915/i915_driver.c| 1 +
drivers/gpu/drm/i915/i915_gem.c | 8 --
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 -
drivers/gpu/drm/i915/i915_vma.c | 12 -
17 files changed, 7 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index ecaeb7dc196b..633e462d96a0 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -17,6 +17,7 @@
#include "intel_display_types.h"
#include "intel_fb.h"
#include "intel_fbc.h"
+#include "intel_frontbuffer.h"
#include "intel_sprite.h"
/* Primary plane formats for gen <= 3 */
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 5b9e3814..3503d112387d 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -9,6 +9,7 @@
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_drrs.h"
+#include "intel_frontbuffer.h"
#include "intel_panel.h"
/**
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 63137ae5ab21..7cf31c87884c 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -12,6 +12,7 @@
#include "intel_display_types.h"
#include "intel_dpt.h"
#include "intel_fb.h"
+#include "intel_frontbuffer.h"
#define check_array_bounds(i915, a, i) drm_WARN_ON(&(i915)->drm, (i) >= ARRAY_SIZE(a))
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c b/drivers/gpu/drm/i915/display/intel_overlay.c
index c12bdca8da9b..5b86563ce577 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -186,7 +186,6 @@ struct intel_overlay {
struct intel_crtc *crtc;
struct i915_vma *vma;
struct i915_vma *old_vma;
- struct intel_frontbuffer *frontbuffer;
bool active;
bool pfit_active;
u32 pfit_vscale_ratio; /* shifted-point number, (1<<12) == 1.0 */
@@ -287,20 +286,9 @@ static void intel_overlay_flip_prepare(struct
intel_overlay *overlay,
struct i915_vma *vma)
{
enum pipe pipe = overlay->crtc->pipe;
- struct intel_frontbuffer *frontbuffer = NULL;
drm_WARN_ON(>i915->drm, overlay->old_vma);
- if (vma)
- frontbuffer = intel_frontbuffer_get(vma->obj);
-
- intel_frontbuffer_track(overlay->frontbuffer, frontbuffer,
- INTEL_FRONTBUFFER_OVERLAY(pipe));
-
- if (overlay->frontbuffer)
- intel_frontbuffer_put(overlay->frontbuffer);
- overlay->frontbuffer = frontbuffer;
-
intel_frontbuffer_flip_prepare(overlay->i915,
INTEL_FRONTBUFFER_OVERLAY(pipe));
@@ -810,8 +798,6 @@ static int intel_overlay_do_put_image(struct intel_overlay *overlay,
goto out_pin_section;
}
- i915_gem_object_flush_frontbuffer(new_bo, ORIGIN_DIRTYFB);
-
if (!overlay->active) {
const struct intel_crtc_state *crtc_state =
overlay->crtc->config;
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index 76be796df255..cad9c8884af3 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -9,6 +9,7 @@
#include "intel_display.h"
#include "intel_display_types.h"
#include
Re: [PATCH v14 1/5] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint
On 23/12/2022 09:57, Krzysztof Kozlowski wrote:
On 22/12/2022 17:22, Kuogee Hsieh wrote:
On 12/22/2022 2:47 AM, Krzysztof Kozlowski wrote:
On 16/12/2022 20:11, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
Changes in v6:
-- add data-lanes and link-frequencies to yaml
Changes in v7:
-- change 16000 to 162000
-- separate yaml to different patch
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v9:
-- use symbol rate (hz) for link-frequencies at dp_out at sc7180_trogdor.dtsi
Changes in v13:
-- delete an extra space at data-lanes
Signed-off-by: Kuogee Hsieh
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +-
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 4
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index eae22e6..e2783dd 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -814,7 +814,11 @@ hp_i2c: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+data-lanes = <0 1>;
+link-frequencies = /bits/ 64 <162000 27 54>;
Messed order of nodes.
can you please give me more details and how should i fixed it?
Node overrides/extends are more or less ordered by name. dp should not
be around mdp, but for example dsi.
I think it would be better to also rename dp_out to mdss_dp_out. To keep
all mdss entries nearby.
--
With best wishes
Dmitry
Re: [PATCH 1/4] drm: panel: Add Himax HX8394 panel controller driver
Hi Javier.
On Thu, Dec 22, 2022 at 11:38:27PM +0100, Javier Martinez Canillas wrote:
> From: Kamil Trzciński
>
> The driver is for panels based on the Himax HX8394 controller, such as the
> HannStar HSD060BHW4 720x1440 TFT LCD panel that uses a MIPI-DSI interface.
A few comments/nitpicks in the following.
I have been away for a while, and paged out most of my panel knowledge,
so read it all with that in mind.
In general - very nicely written driver.
Sam
>
> Signed-off-by: Kamil Trzciński
> Co-developed-by: Ondrej Jirman
> Signed-off-by: Ondrej Jirman
> Co-developed-by: Javier Martinez Canillas
> Signed-off-by: Javier Martinez Canillas
> ---
>
> drivers/gpu/drm/panel/Kconfig | 12 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-himax-hx8394.c | 460 +
> 3 files changed, 473 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-himax-hx8394.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 737edcdf9eef..7ee9c83f09a7 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -154,6 +154,18 @@ config DRM_PANEL_FEIYANG_FY07024DI26A30D
> Say Y if you want to enable support for panels based on the
> Feiyang FY07024DI26A30-D MIPI-DSI interface.
>
> +config DRM_PANEL_HIMAX_HX8394
> + tristate "HIMAX HX8394 MIPI-DSI LCD panels"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y if you want to enable support for panels based on the
> + Himax HX8394 controller, such as the HannStar HSD060BHW4
> + 720x1440 TFT LCD panel that uses a MIPI-DSI interface.
> +
> + If M is selected the module will be called panel-himax-hx8394.
> +
> config DRM_PANEL_ILITEK_IL9322
> tristate "Ilitek ILI9322 320x240 QVGA panels"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index f8f9d9f6a307..84c01adafd4c 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
> obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
> obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
> obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
> panel-feiyang-fy07024di26a30d.o
> +obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
> diff --git a/drivers/gpu/drm/panel/panel-himax-hx8394.c
> b/drivers/gpu/drm/panel/panel-himax-hx8394.c
> new file mode 100644
> index ..b22eec0674b5
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-himax-hx8394.c
> @@ -0,0 +1,460 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for panels based on Himax HX8394 controller, such as:
> + *
> + * - HannStar HSD060BHW4 5.99" MIPI-DSI panel
> + *
> + * Copyright (C) Kamil Trzciński
Needs year
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
I do not think this include is used.
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "panel-himax-hx8394"
> +
> +/* Manufacturer specific commands sent via DSI, listed in HX8394-F datasheet
> */
> +#define HX8394_CMD_SETSEQUENCE 0xb0
> +#define HX8394_CMD_SETPOWER0xb1
> +#define HX8394_CMD_SETDISP 0xb2
> +#define HX8394_CMD_SETCYC 0xb4
> +#define HX8394_CMD_SETVCOM 0xb6
> +#define HX8394_CMD_SETTE 0xb7
> +#define HX8394_CMD_SETSENSOR 0xb8
> +#define HX8394_CMD_SETEXTC 0xb9
> +#define HX8394_CMD_SETMIPI 0xba
> +#define HX8394_CMD_SETOTP 0xbb
> +#define HX8394_CMD_SETREGBANK 0xbd
> +#define HX8394_CMD_UNKNOWN10xc0
> +#define HX8394_CMD_SETDGCLUT 0xc1
> +#define HX8394_CMD_SETID 0xc3
> +#define HX8394_CMD_SETDDB 0xc4
> +#define HX8394_CMD_UNKNOWN20xc6
> +#define HX8394_CMD_SETCABC 0xc9
> +#define HX8394_CMD_SETCABCGAIN 0xca
> +#define HX8394_CMD_SETPANEL0xcc
> +#define HX8394_CMD_SETOFFSET 0xd2
> +#define HX8394_CMD_SETGIP0 0xd3
> +#define HX8394_CMD_UNKNOWN30xd4
> +#define HX8394_CMD_SETGIP1 0xd5
> +#define HX8394_CMD_SETGIP2 0xd6
> +#define HX8394_CMD_SETGPO 0xd6
> +#define HX8394_CMD_SETSCALING 0xdd
> +#define HX8394_CMD_SETIDLE 0xdf
> +#define HX8394_CMD_SETGAMMA0xe0
> +#define HX8394_CMD_SETCHEMODE_DYN 0xe4
> +#define HX8394_CMD_SETCHE 0xe5
> +#define HX8394_CMD_SETCESEL0xe6
> +#define HX8394_CMD_SET_SP_CMD 0xe9
> +#define HX8394_CMD_SETREADINDEX0xfe
> +#define HX8394_CMD_GETSPIREAD 0xff
> +
> +struct hx8394 {
> + struct device *dev;
> + struct
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 doesnotcomp...@posteo.de changed: What|Removed |Added CC||doesnotcomp...@posteo.de --- Comment #69 from doesnotcomp...@posteo.de --- Hello, I'm encountering a similar regression on the 6.1.1 kernel (not present in this form on 6.0.12, although the system occasionally freezes as well). When connecting a Thinkpad USB-C Dock with two monitors to my Ryzen 3500U Thinkpad, the system freezes with a null-pointer dereference in amdgpu. Kernel: Linux version 6.1.1-arch1-1 (linux@archlinux) (gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.39.0) #1 SMP PREEMPT_DYNAMIC Wed, 21 Dec 2022 22:27:55 + Graphics controller: Advanced Micro Devices, Inc. [AMD/ATI] Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile Series] (rev d2) Output from journalctl: Dec 23 09:42:29 kevin-t495 kernel: usb 2-1.3.3: New USB device found, idVendor=17ef, idProduct=a395, bcdDevice=60.70 Dec 23 09:42:29 kevin-t495 kernel: usb 2-1.3.3: New USB device strings: Mfr=10, Product=11, SerialNumber=0 Dec 23 09:42:29 kevin-t495 kernel: usb 2-1.3.3: Product: USB2.0 Hub Dec 23 09:42:29 kevin-t495 kernel: usb 2-1.3.3: Manufacturer: Lenovo Dec 23 09:42:29 kevin-t495 kernel: [drm] Downstream port present 1, type 2 Dec 23 09:42:29 kevin-t495 kernel: BUG: kernel NULL pointer dereference, address: 0008 Dec 23 09:42:29 kevin-t495 kernel: #PF: supervisor read access in kernel mode Dec 23 09:42:29 kevin-t495 kernel: #PF: error_code(0x) - not-present page Dec 23 09:42:29 kevin-t495 kernel: PGD 0 P4D 0 Dec 23 09:42:29 kevin-t495 kernel: Oops: [#1] PREEMPT SMP NOPTI Dec 23 09:42:29 kevin-t495 kernel: CPU: 4 PID: 998 Comm: sway Not tainted 6.1.1-arch1-1 #1 9bd09188b430be630e611f984454e4f3c489be77 Dec 23 09:42:29 kevin-t495 kernel: Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 Dec 23 09:42:29 kevin-t495 kernel: RIP: 0010:drm_dp_atomic_find_time_slots+0x61/0x2a0 [drm_display_helper] Dec 23 09:42:29 kevin-t495 kernel: Code: 00 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d ce 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8b 40 08 4d 8d 65 38 8b 88 90 00 00 00 b8 01 00 00 00 d3 e0 41 Dec 23 09:42:29 kevin-t495 kernel: RSP: 0018:a526c0eef780 EFLAGS: 00010293 Dec 23 09:42:29 kevin-t495 kernel: RAX: RBX: 9555ef407200 RCX: 0214 Dec 23 09:42:29 kevin-t495 kernel: RDX: 9555c4124800 RSI: 9555429ba540 RDI: 9555ef407200 Dec 23 09:42:29 kevin-t495 kernel: RBP: 9555cfc76000 R08: 0001 R09: 9555c4242050 Dec 23 09:42:29 kevin-t495 kernel: R10: a526c0eef8a0 R11: 4cb505a0 R12: 026d60dce16e8423 Dec 23 09:42:29 kevin-t495 kernel: R13: 95554cb505a0 R14: 9555429ba540 R15: 0214 Dec 23 09:42:29 kevin-t495 kernel: FS: 7fb56378b980() GS:9557f0b0() knlGS: Dec 23 09:42:29 kevin-t495 kernel: CS: 0010 DS: ES: CR0: 80050033 Dec 23 09:42:29 kevin-t495 kernel: CR2: 0008 CR3: 00010ae2a000 CR4: 003506e0 Dec 23 09:42:29 kevin-t495 kernel: Call Trace: Dec 23 09:42:29 kevin-t495 kernel: Dec 23 09:42:29 kevin-t495 kernel: compute_mst_dsc_configs_for_link+0x31d/0x9d0 [amdgpu 895e2b3772442c7d04dbf61a65c8a3690bb074b6] Dec 23 09:42:29 kevin-t495 kernel: ? cm_helper_translate_curve_to_degamma_hw_format+0x5f0/0x5f0 [amdgpu 895e2b3772442c7d04dbf61a65c8a3690bb074b6] Dec 23 09:42:29 kevin-t495 kernel: ? fill_plane_buffer_attributes+0x355/0x530 [amdgpu 895e2b3772442c7d04dbf61a65c8a3690bb074b6] Dec 23 09:42:29 kevin-t495 kernel: compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 895e2b3772442c7d04dbf61a65c8a3690bb074b6] Dec 23 09:42:29 kevin-t495 kernel: amdgpu_dm_atomic_check+0xf81/0x1230 [amdgpu 895e2b3772442c7d04dbf61a65c8a3690bb074b6] Dec 23 09:42:29 kevin-t495 kernel: drm_atomic_check_only+0x537/0xba0 Dec 23 09:42:29 kevin-t495 kernel: drm_mode_atomic_ioctl+0x750/0xbb0 Dec 23 09:42:29 kevin-t495 kernel: ? drm_property_add_enum+0x180/0x180 Dec 23 09:42:29 kevin-t495 kernel: ? idr_alloc+0x3a/0x70 Dec 23 09:42:29 kevin-t495 kernel: ? drm_atomic_set_property+0xbc0/0xbc0 Dec 23 09:42:29 kevin-t495 kernel: drm_ioctl_kernel+0xcd/0x170 Dec 23 09:42:29 kevin-t495 kernel: drm_ioctl+0x1eb/0x450 Dec 23 09:42:29 kevin-t495 kernel: ? drm_atomic_set_property+0xbc0/0xbc0 Dec 23 09:42:29 kevin-t495 kernel: amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 895e2b3772442c7d04dbf61a65c8a3690bb074b6] Dec 23 09:42:29 kevin-t495 kernel: __x64_sys_ioctl+0x94/0xd0 Dec 23 09:42:29 kevin-t495 kernel: do_syscall_64+0x5f/0x90 Dec 23 09:42:29 kevin-t495 kernel: ? syscall_exit_to_user_mode+0x1b/0x40 Dec 23 09:42:29 kevin-t495 kernel: ? do_syscall_64+0x6b/0x90 Dec 23 09:42:29 kevin-t495 kernel: ? do_syscall_64+0x6b/0x90 Dec 23 09:42:29 kevin-t495 kernel: ?
Re: [PATCH 1/4] drm/i915/gt: Remove platform comments from workarounds
On 22/12/2022 15:55, Lucas De Marchi wrote:
On Thu, Dec 22, 2022 at 10:27:00AM +, Tvrtko Ursulin wrote:
On 22/12/2022 08:25, Lucas De Marchi wrote:
The comments are redundant to the checks being done to apply the
workarounds and very often get outdated as workarounds need to be
extended to new platforms or steppings. Remove them altogether with
the following matches (platforms extracted from intel_workarounds.c):
find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*/\1/'
find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*\*\//\1
Same things was executed in the gem directory, omitted here for brevity.
There were a few false positives that included the workaround
description. Those were manually patched.
sed -E 's/(Wa[a-zA-Z0-9_]+)[:,]([a-zA-Z0-9,-_\+\[]{2,})/\1/'
then there are false negatives. We have Was in the form
"Wa_xxx:tgl,dg2, mtl". False positives we can fixup, false negatives
we simply don't see. After running that in gt/:
$ git grep ": mtl" -- drivers/gpu/drm/i915/
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c: * Wa_14017073508: mtl
drivers/gpu/drm/i915/i915_reg.h:/* Wa_14017210380: mtl */
I was going with the platform names to avoid the false
negatives and because I was entertaining the idea of only doing this for
latest platforms where we do have the "Wa_[[:number:]]" form
Maybe..
Matt recently said he has this worked planned, but more importantly -
I gather then that the WA lookup tool definitely does not output these
strings?
Whatever it does it's true only at the time it's called. It simply tells
what
are the platforms and steppings the Wa applies to. We can change the
output to whatever we want, but that is not the point.
Those comments get stale and bring no real value as they match 1:1
what the code is supposed to be doing. Several times a patch has to
update just that comment to "extend a workaround" to a next platform.
This is not always done, so we get a comment that doesn't match what is
supposed to be there.
Tl;dr; version - lets park this until January and discuss once everyone
is back.
Longer version. I've been trying to get us talking about this a couple
times before and I'd really like to close with an explicit consensus,
discussion points addressed instead of skipped and just moving ahead
with patches.
References:
3fcf71b9-337f-6186-7b00-27cbfd116...@linux.intel.com
Y5j0b/bykbitc...@mdroper-desk1.amr.corp.intel.com
So point I wanted to discuss is whether these comments are truly useless
or maybe they can help during review. If the tool can actually output
them then I am leaning towards that they can be.
Thought is, when a patch comes for review adding a new platform,
stepping, whatever, to an existing if condition, if it contains the
comments reviewer can more easily spot a hyphotetical logic inversion
error or similar. It is also trivial to check that both condition and
comment have been updated. (So lets not be rash and remove something
maybe useful just because it can go stale *only if* reviewers are not
giving sufficient attention that changes are made in tandem.)
From a slightly different angle - do we expect anyone reviewing
workaround patches will cross-check against the tool? Would it be
simpler and more efficient that they could just cross-check against the
comment output from the tool and put into the patch by the author?
And point here to stress out is that accidental logic errors (missed
workarounds) can be super expensive to debug in the field. Sometimes it
can literally take _months_ for sporadic and hard to reproduce issues to
get debugged, handed over between the teams, etc. So any way in which we
can influence the likelyhood of that happening is something to weigh
carefully.
Secondary but also important - if i915 is end of line then an extra why
we want to rip out this for ancient platforms. Is the cost/benefit
positive there?
As a side note, and going back to the question of what the tool can
output. Long time ago I had an idea where we could improve all this by
making it completely data-driven. Have the WA database inspecting tool
output a table which could be directly pasted into code and interpreted
by i915.
For reference look at
[RESEND] backlight: ktz8866: Add support for Kinetic KTZ8866 backlight
Add support for Kinetic KTZ8866 backlight, which is used in
Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
downstream implementation [1].
[1]
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c
Signed-off-by: Jianhua Lu
---
drivers/video/backlight/Kconfig | 8 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/ktz8866.c | 174 ++
drivers/video/backlight/ktz8866.h | 31 ++
4 files changed, 214 insertions(+)
create mode 100644 drivers/video/backlight/ktz8866.c
create mode 100644 drivers/video/backlight/ktz8866.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 936ba1e4d35e..2845fd7e33ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -190,6 +190,14 @@ config BACKLIGHT_KTD253
which is a 1-wire GPIO-controlled backlight found in some mobile
phones.
+config BACKLIGHT_KTZ8866
+ tristate "Backlight Driver for Kinetic KTZ8866"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y to enabled the backlight driver for the Kinetic KTZ8866
+ found in Xiaomi Mi Pad 5 series.
+
config BACKLIGHT_LM3533
tristate "Backlight Driver for LM3533"
depends on MFD_LM3533
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e815f3f1deff..f70a819c304c 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
+obj-$(CONFIG_BACKLIGHT_KTZ8866)+= ktz8866.o
obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
diff --git a/drivers/video/backlight/ktz8866.c
b/drivers/video/backlight/ktz8866.c
new file mode 100644
index ..a0ea6ebbda60
--- /dev/null
+++ b/drivers/video/backlight/ktz8866.c
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Backlight driver for the Kinetic KTZ8866
+ *
+ * Copyright (C) Jianhua Lu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ktz8866.h"
+
+#define DEF_BRIGHTNESS 1500
+#define MAX_BRIGHTNESS 2047
+#define REG_MAX 0x15
+
+/* Helper */
+#define low_3_bit(x) ((x)&0x7)
+#define high_8_bit(x) ((x >> 3) & 0xFF)
+
+struct ktz8866 {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ bool state;
+};
+
+enum {
+ LED_OFF,
+ LED_ON,
+};
+
+static const struct regmap_config ktz8866_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = REG_MAX,
+};
+
+static int ktz8866_write(struct ktz8866 *ktz, unsigned int reg,
+unsigned int val)
+{
+ return regmap_write(ktz->regmap, reg, val);
+}
+
+static int ktz8866_update_bits(struct ktz8866 *ktz, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ return regmap_update_bits(ktz->regmap, reg, mask, val);
+}
+
+static int
+ktz8866_backlight_update_status(struct backlight_device *backlight_dev)
+{
+ struct ktz8866 *ktz = bl_get_data(backlight_dev);
+ unsigned int brightness = backlight_get_brightness(backlight_dev);
+
+ if (!ktz->state && brightness > 0) {
+ ktz8866_update_bits(ktz, BL_EN, BIT(6), BIT(6));
+ ktz->state = LED_ON;
+ } else if (brightness == 0) {
+ ktz8866_update_bits(ktz, BL_EN, BIT(6), 0);
+ ktz->state = LED_OFF;
+ msleep(10);
+ }
+
+ /* Set brightness */
+ ktz8866_write(ktz, BL_BRT_LSB, low_3_bit(brightness));
+ ktz8866_write(ktz, BL_BRT_MSB, high_8_bit(brightness));
+
+ return 0;
+}
+
+static const struct backlight_ops ktz8866_backlight_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = ktz8866_backlight_update_status,
+};
+
+static void ktz8866_init(struct ktz8866 *ktz)
+{
+ /* Enable 1~5 current sinks */
+ ktz8866_write(ktz, BL_EN, 0x1F);
+ /* Backlight OVP 26.4V */
+ ktz8866_write(ktz, BL_CFG1, 0x33);
+ /* LED ramping time 128ms */
+ ktz8866_write(ktz, BL_CFG2, 0xBD);
+ /* LED on/off ramping time 1ms */
+ ktz8866_write(ktz, BL_DIMMING, 0x11);
+ /* Enable OUTP and OUTN via pin ENP and ENN */
+ ktz8866_write(ktz, LCD_BIAS_CFG1, 0x9F);
+ /* Backlight Full-scale LED Current 30.0mA */
+ ktz8866_write(ktz, FULL_SCALE_CURRENT, 0xF9);
+}
+
+static int ktz8866_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct backlight_device *backlight_dev;
+ struct
[PATCH v3 1/2] backlight: ktz8866: Add support for Kinetic KTZ8866 backlight
Add support for Kinetic KTZ8866 backlight, which is used in
Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
downstream implementation [1].
[1]
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c
Signed-off-by: Jianhua Lu
---
Changes in v2:
- Add missing staitc modifier to ktz8866_write function.
Changes in v3:
- Add 2022 to Copyright line.
- Sort headers
- Remove meaningless comment
- Use definitions instead of hardcoding.
- Add missing maintainer info
MAINTAINERS | 6 +
drivers/video/backlight/Kconfig | 8 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/ktz8866.c | 180 ++
drivers/video/backlight/ktz8866.h | 31 +
5 files changed, 226 insertions(+)
create mode 100644 drivers/video/backlight/ktz8866.c
create mode 100644 drivers/video/backlight/ktz8866.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1daadaa4d48b..b33385b5fd3c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11507,6 +11507,12 @@ M: John Hawley
S: Maintained
F: tools/testing/ktest
+KTZ8866 BACKLIGHT DRIVER
+M: Jianhua Lu
+S: Maintained
+F: Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
+F: drivers/video/backlight/ktz8866.c
+
L3MDEV
M: David Ahern
L: net...@vger.kernel.org
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 936ba1e4d35e..2845fd7e33ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -190,6 +190,14 @@ config BACKLIGHT_KTD253
which is a 1-wire GPIO-controlled backlight found in some mobile
phones.
+config BACKLIGHT_KTZ8866
+ tristate "Backlight Driver for Kinetic KTZ8866"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y to enabled the backlight driver for the Kinetic KTZ8866
+ found in Xiaomi Mi Pad 5 series.
+
config BACKLIGHT_LM3533
tristate "Backlight Driver for LM3533"
depends on MFD_LM3533
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e815f3f1deff..f70a819c304c 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
+obj-$(CONFIG_BACKLIGHT_KTZ8866)+= ktz8866.o
obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
diff --git a/drivers/video/backlight/ktz8866.c
b/drivers/video/backlight/ktz8866.c
new file mode 100644
index ..ea641bdfc4d2
--- /dev/null
+++ b/drivers/video/backlight/ktz8866.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Backlight driver for the Kinetic KTZ8866
+ *
+ * Copyright (C) 2022 Jianhua Lu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ktz8866.h"
+
+#define DEFAULT_BRIGHTNESS 1500
+#define MAX_BRIGHTNESS 2047
+#define REG_MAX 0x15
+
+#define BL_EN_BIT BIT(6)
+#define BL_CURRENT_SINKS 0x1F
+#define BL_OVP_LIMIT 0x33
+#define LED_CURRENT_RAMPING_TIME 0xBD
+#define LED_DIMMING_TIME 0x11
+#define LCD_BIAS_EN 0x9F
+#define LED_CURRENT 0xF9
+
+#define low_3_bit(x) ((x)&0x7)
+#define high_8_bit(x) ((x >> 3) & 0xFF)
+
+struct ktz8866 {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ bool state;
+};
+
+enum {
+ LED_OFF,
+ LED_ON,
+};
+
+static const struct regmap_config ktz8866_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = REG_MAX,
+};
+
+static int ktz8866_write(struct ktz8866 *ktz, unsigned int reg,
+unsigned int val)
+{
+ return regmap_write(ktz->regmap, reg, val);
+}
+
+static int ktz8866_update_bits(struct ktz8866 *ktz, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ return regmap_update_bits(ktz->regmap, reg, mask, val);
+}
+
+static int ktz8866_backlight_update_status(struct backlight_device
*backlight_dev)
+{
+ struct ktz8866 *ktz = bl_get_data(backlight_dev);
+ unsigned int brightness = backlight_get_brightness(backlight_dev);
+
+ if (!ktz->state && brightness > 0) {
+ ktz8866_update_bits(ktz, BL_EN, BL_EN_BIT, BL_EN_BIT);
+ ktz->state = LED_ON;
+ } else if (brightness == 0) {
+ ktz8866_update_bits(ktz, BL_EN, BL_EN_BIT, 0);
+ ktz->state = LED_OFF;
+ msleep(10);
+ }
+
+ /* Set brightness */
+ ktz8866_write(ktz, BL_BRT_LSB, low_3_bit(brightness));
+ ktz8866_write(ktz, BL_BRT_MSB, high_8_bit(brightness));
+
+
[PATCH v2 7/9] drm: Remove usage of deprecated DRM_DEBUG_PRIME
drm_print.h says DRM_DEBUG_PRIME is deprecated in favor of
drm_dbg_prime().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_gem_dma_helper.c | 4 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index 1ba551b0ab97..0f903cc8914a 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -477,8 +477,8 @@ drm_gem_dma_prime_import_sg_table(struct drm_device *dev,
dma_obj->dma_addr = sg_dma_address(sgt->sgl);
dma_obj->sgt = sgt;
- DRM_DEBUG_PRIME("dma_addr = %pad, size = %zu\n", _obj->dma_addr,
- attach->dmabuf->size);
+ drm_dbg_prime(dev, "dma_addr = %pad, size = %zu\n", _obj->dma_addr,
+ attach->dmabuf->size);
return _obj->base;
}
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index f0b6b69f4baf..1b9a6b357d8a 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -764,7 +764,7 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
shmem->sgt = sgt;
- DRM_DEBUG_PRIME("size = %zu\n", size);
+ drm_dbg_prime(dev, "size = %zu\n", size);
return >base;
}
--
2.35.1
[PATCH v2 9/9] drm/drm_lease: Remove usage of deprecated DRM_DEBUG_LEASE
drm_print.h says DRM_DEBUG_LEASE is deprecated in favor of
drm_dbg_lease().
Signed-off-by: Siddh Raman Pant
Reviewed-by: Simon Ser
---
drivers/gpu/drm/drm_lease.c | 64 -
1 file changed, 34 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index c442d5e766d1..08b4f29f8b61 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -213,11 +213,11 @@ static struct drm_master *drm_lease_create(struct
drm_master *lessor, struct idr
int id;
void *entry;
- DRM_DEBUG_LEASE("lessor %d\n", lessor->lessee_id);
+ drm_dbg_lease(dev, "lessor %d\n", lessor->lessee_id);
lessee = drm_master_create(lessor->dev);
if (!lessee) {
- DRM_DEBUG_LEASE("drm_master_create failed\n");
+ drm_dbg_lease(dev, "drm_master_create failed\n");
return ERR_PTR(-ENOMEM);
}
@@ -231,7 +231,7 @@ static struct drm_master *drm_lease_create(struct
drm_master *lessor, struct idr
error = -EBUSY;
if (error != 0) {
- DRM_DEBUG_LEASE("object %d failed %d\n", object, error);
+ drm_dbg_lease(dev, "object %d failed %d\n", object,
error);
goto out_lessee;
}
}
@@ -249,7 +249,8 @@ static struct drm_master *drm_lease_create(struct
drm_master *lessor, struct idr
/* Move the leases over */
lessee->leases = *leases;
- DRM_DEBUG_LEASE("new lessee %d %p, lessor %d %p\n", lessee->lessee_id,
lessee, lessor->lessee_id, lessor);
+ drm_dbg_lease(dev, "new lessee %d %p, lessor %d %p\n",
+ lessee->lessee_id, lessee, lessor->lessee_id, lessor);
mutex_unlock(>mode_config.idr_mutex);
return lessee;
@@ -268,7 +269,7 @@ void drm_lease_destroy(struct drm_master *master)
mutex_lock(>mode_config.idr_mutex);
- DRM_DEBUG_LEASE("drm_lease_destroy %d\n", master->lessee_id);
+ drm_dbg_lease(dev, "drm_lease_destroy %d\n", master->lessee_id);
/* This master is referenced by all lessees, hence it cannot be
destroyed
* until all of them have been
@@ -277,7 +278,8 @@ void drm_lease_destroy(struct drm_master *master)
/* Remove this master from the lessee idr in the owner */
if (master->lessee_id != 0) {
- DRM_DEBUG_LEASE("remove master %d from device list of
lessees\n", master->lessee_id);
+ drm_dbg_lease(dev, "remove master %d from device list of
lessees\n",
+ master->lessee_id);
idr_remove(&(drm_lease_owner(master)->lessee_idr),
master->lessee_id);
}
@@ -292,7 +294,7 @@ void drm_lease_destroy(struct drm_master *master)
drm_master_put(>lessor);
}
- DRM_DEBUG_LEASE("drm_lease_destroy done %d\n", master->lessee_id);
+ drm_dbg_lease(dev, "drm_lease_destroy done %d\n", master->lessee_id);
}
static void _drm_lease_revoke(struct drm_master *top)
@@ -308,7 +310,8 @@ static void _drm_lease_revoke(struct drm_master *top)
* the tree is fully connected, we can do this without recursing
*/
for (;;) {
- DRM_DEBUG_LEASE("revoke leases for %p %d\n", master,
master->lessee_id);
+ drm_dbg_lease(master->dev, "revoke leases for %p %d\n",
+ master, master->lessee_id);
/* Evacuate the lease */
idr_for_each_entry(>leases, entry, object)
@@ -408,7 +411,7 @@ static int fill_object_idr(struct drm_device *dev,
ret = validate_lease(dev, object_count, objects, universal_planes);
if (ret) {
- DRM_DEBUG_LEASE("lease validation failed\n");
+ drm_dbg_lease(dev, "lease validation failed\n");
goto out_free_objects;
}
@@ -418,7 +421,7 @@ static int fill_object_idr(struct drm_device *dev,
struct drm_mode_object *obj = objects[o];
u32 object_id = objects[o]->id;
- DRM_DEBUG_LEASE("Adding object %d to lease\n", object_id);
+ drm_dbg_lease(dev, "Adding object %d to lease\n", object_id);
/*
* We're using an IDR to hold the set of leased
@@ -430,8 +433,8 @@ static int fill_object_idr(struct drm_device *dev,
*/
ret = idr_alloc(leases, _lease_idr_object , object_id,
object_id + 1, GFP_KERNEL);
if (ret < 0) {
- DRM_DEBUG_LEASE("Object %d cannot be inserted into
leases (%d)\n",
- object_id, ret);
+ drm_dbg_lease(dev, "Object %d cannot be inserted into
leases (%d)\n",
+ object_id, ret);
goto out_free_objects;
}
if (obj->type ==
[PATCH v2 0/9] drm: Remove usage of deprecated DRM_* macros
This patchset aims to remove usages of deprecated DRM_* macros from the files residing in drivers/gpu/drm root. In process, I found out that NULL as first argument of drm_dbg_* wasn't working, but it was listed as the alternative in deprecation comment, so I fixed that before removing usages of DRM_DEBUG_* macros. This patchset should be applied in order as changes might be dependent. Please review and let me know if any errors are there, and hopefully this gets accepted. Changes in v2: - Removed conversions to pr_*() in DRM_INFO, DRM_NOTE, and DRM_ERROR changes. - Due to above, DRM_NOTE usage cannot be removed and the patch is dropped. - DRY: NULL support is now achieved by way of a separate function. Siddh Raman Pant (9): drm: Remove usage of deprecated DRM_INFO drm: Remove usage of deprecated DRM_ERROR drm/print: Fix support for NULL as first argument of drm_dbg_* drm: Remove usage of deprecated DRM_DEBUG drm: Remove usage of deprecated DRM_DEBUG_DRIVER drm: Remove usage of deprecated DRM_DEBUG_KMS drm: Remove usage of deprecated DRM_DEBUG_PRIME drm/drm_blend: Remove usage of deprecated DRM_DEBUG_ATOMIC drm/drm_lease: Remove usage of deprecated DRM_DEBUG_LEASE drivers/gpu/drm/drm_agpsupport.c | 4 +- drivers/gpu/drm/drm_blend.c| 13 ++- drivers/gpu/drm/drm_bridge.c | 8 +- drivers/gpu/drm/drm_bufs.c | 122 + drivers/gpu/drm/drm_client_modeset.c | 118 +--- drivers/gpu/drm/drm_color_mgmt.c | 4 +- drivers/gpu/drm/drm_connector.c| 28 +++--- drivers/gpu/drm/drm_context.c | 18 ++-- drivers/gpu/drm/drm_crtc.c | 36 drivers/gpu/drm/drm_crtc_helper.c | 60 ++-- drivers/gpu/drm/drm_debugfs_crc.c | 8 +- drivers/gpu/drm/drm_displayid.c| 4 +- drivers/gpu/drm/drm_dma.c | 10 +- drivers/gpu/drm/drm_drv.c | 20 ++-- drivers/gpu/drm/drm_edid.c | 17 ++-- drivers/gpu/drm/drm_file.c | 18 ++-- drivers/gpu/drm/drm_framebuffer.c | 3 +- drivers/gpu/drm/drm_gem.c | 7 +- drivers/gpu/drm/drm_gem_dma_helper.c | 6 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 6 +- drivers/gpu/drm/drm_hashtab.c | 6 +- drivers/gpu/drm/drm_ioc32.c| 13 +-- drivers/gpu/drm/drm_ioctl.c| 24 ++--- drivers/gpu/drm/drm_irq.c | 4 +- drivers/gpu/drm/drm_lease.c| 68 +++--- drivers/gpu/drm/drm_legacy_misc.c | 4 +- drivers/gpu/drm/drm_lock.c | 20 ++-- drivers/gpu/drm/drm_mipi_dbi.c | 19 ++-- drivers/gpu/drm/drm_mode_config.c | 2 +- drivers/gpu/drm/drm_mode_object.c | 6 +- drivers/gpu/drm/drm_modes.c| 10 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/drm_pci.c | 12 +-- drivers/gpu/drm/drm_plane.c| 46 +- drivers/gpu/drm/drm_probe_helper.c | 39 drivers/gpu/drm/drm_rect.c | 4 +- drivers/gpu/drm/drm_scatter.c | 19 ++-- drivers/gpu/drm/drm_syncobj.c | 2 +- drivers/gpu/drm/drm_sysfs.c| 22 ++--- drivers/gpu/drm/drm_vm.c | 45 + include/drm/drm_print.h| 44 ++--- 41 files changed, 486 insertions(+), 435 deletions(-) -- 2.35.1
[PATCH v3 6/7] drm: rcar-du: Bump V3U to gen 4
V3U is actually gen 4 IP, like in V4H. Bump up V3U gen in the
rcar_du_r8a779a0_info.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 46c60a2d710d..c7c5217cfc1a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -504,7 +504,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7799x_info = {
};
static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
- .gen = 3,
+ .gen = 4,
.features = RCAR_DU_FEATURE_CRTC_IRQ
| RCAR_DU_FEATURE_VSP1_SOURCE
| RCAR_DU_FEATURE_NO_BLENDING,
--
2.34.1
[PATCH v2 4/9] drm: Remove usage of deprecated DRM_DEBUG
drm_print.h says DRM_DEBUG is deprecated in favor of drm_dbg_core().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_agpsupport.c | 4 +-
drivers/gpu/drm/drm_bufs.c| 114 +++---
drivers/gpu/drm/drm_context.c | 14 ++--
drivers/gpu/drm/drm_dma.c | 10 +--
drivers/gpu/drm/drm_drv.c | 10 +--
drivers/gpu/drm/drm_file.c| 18 ++---
drivers/gpu/drm/drm_gem.c | 5 +-
drivers/gpu/drm/drm_hashtab.c | 6 +-
drivers/gpu/drm/drm_ioc32.c | 13 ++--
drivers/gpu/drm/drm_ioctl.c | 24 +++
drivers/gpu/drm/drm_irq.c | 4 +-
drivers/gpu/drm/drm_lease.c | 2 +-
drivers/gpu/drm/drm_legacy_misc.c | 4 +-
drivers/gpu/drm/drm_lock.c| 20 +++---
drivers/gpu/drm/drm_mode_object.c | 6 +-
drivers/gpu/drm/drm_pci.c | 12 ++--
drivers/gpu/drm/drm_plane.c | 12 ++--
drivers/gpu/drm/drm_scatter.c | 10 +--
drivers/gpu/drm/drm_syncobj.c | 2 +-
drivers/gpu/drm/drm_sysfs.c | 14 ++--
drivers/gpu/drm/drm_vm.c | 43 ++-
21 files changed, 178 insertions(+), 169 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index a4ad6fd13abc..d27686d6e82d 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -315,8 +315,8 @@ int drm_legacy_agp_bind(struct drm_device *dev, struct
drm_agp_binding *request)
if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
- DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
- dev->agp->base, entry->bound);
+ drm_dbg_core(dev, "base = 0x%lx entry->bound = 0x%lx\n",
+dev->agp->base, entry->bound);
return 0;
}
EXPORT_SYMBOL(drm_legacy_agp_bind);
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 98aaf3379a3b..feedd7c6f0d5 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -171,8 +171,8 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
kfree(map);
return -EINVAL;
}
- DRM_DEBUG("offset = 0x%08llx, size = 0x%08lx, type = %d\n",
- (unsigned long long)map->offset, map->size, map->type);
+ drm_dbg_core(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
+(unsigned long long)map->offset, map->size, map->type);
/* page-align _DRM_SHM maps. They are allocated here so there is no
security
* hole created by that and it works around various broken drivers that
use
@@ -205,10 +205,10 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
- DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size,
- list->map->size);
+ drm_dbg_core(dev, "Matching maps of type %d
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size,
+list->map->size);
list->map->size = map->size;
}
@@ -239,9 +239,9 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
- DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size,
list->map->size);
+ drm_dbg_core(dev, "Matching maps of type %d
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size,
list->map->size);
list->map->size = map->size;
}
@@ -250,8 +250,8 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
return 0;
}
map->handle = vmalloc_user(map->size);
- DRM_DEBUG("%lu %d %p\n",
- map->size, order_base_2(map->size), map->handle);
+ drm_dbg_core(dev, "%lu %d %p\n",
+map->size, order_base_2(map->size), map->handle);
if (!map->handle) {
kfree(map);
return -ENOMEM;
@@ -308,8 +308,8 @@ static int
Re: [PATCH 2/2] dt-bindings: leds: backlight: add binding for Kinetic KTZ8866 backlight
Thanks for review, I will resend this path. Krzysztof Kozlowski 于 2022年12月21日周三 16:13写道： > On 21/12/2022 08:02, Jianhua Lu wrote: > > Add device tree bindings for the Kinetic KTZ8866 backlight driver. > > 1. Your patches are not properly threaded which makes it difficult to > review and handle them. Resend with proper threads. > > 2. Subject: drop second, redundant "binding for". > > > > > Signed-off-by: Jianhua Lu > > --- > > .../leds/backlight/kinetic,ktz8866.yaml | 37 +++ > > 1 file changed, 37 insertions(+) > > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > > > > diff --git > a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > > new file mode 100644 > > index ..7286c3fc7f5d > > --- /dev/null > > +++ > b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > > @@ -0,0 +1,37 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktz8866.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Kinetic Technologies KTZ8866 backlight > > + > > +maintainers: > > + - Jianhua Lu > > + > > +description: | > > + The Kinetic Technologies KTZ8866 is a high efficiency 6-sinks led > backlight > > + with dual lcd bias power. > > + https://www.kinet-ic.com/ktz8866/ > > + > > +allOf: > > + - $ref: common.yaml# > > + > > +properties: > > + compatible: > > +items: > > + const: kinetic,ktz8866 > > Does not look like you tested the bindings. Please run `make > dt_binding_check` (see > Documentation/devicetree/bindings/writing-schema.rst for instructions). > > > + > > +required: > > + - compatible > > + > > +additionalProperties: false > > This should be rather unevaluatedProperties: false, otherwise you do not > allow any other properties, except compatible. Was this the intention? > > Best regards, > Krzysztof > >
[PATCH v3 1/7] media: Add 2-10-10-10 RGB formats
Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
Signed-off-by: Tomi Valkeinen
---
.../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 3 +
include/uapi/linux/videodev2.h| 3 +
3 files changed, 200 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
index 30f51cd33f99..d330aeb4d3eb 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
@@ -763,6 +763,200 @@ nomenclature that instead use the order of components as
seen in a 24- or
\normalsize
+10 Bits Per Component
+=
+
+These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
+bytes. They are named based on the order of the RGB components as seen in a
+32-bit word, which is then stored in memory in little endian byte order
+(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
+number of bits for each component.
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. tabularcolumns::
|p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+
+.. flat-table:: RGB Formats 10 Bits Per Color Component
+:header-rows: 2
+:stub-columns: 0
+
+* - Identifier
+ - Code
+ - :cspan:`7` Byte 0 in memory
+ - :cspan:`7` Byte 1
+ - :cspan:`7` Byte 2
+ - :cspan:`7` Byte 3
+* -
+ -
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+* .. _V4L2-PIX-FMT-RGBX1010102:
+
+ - ``V4L2_PIX_FMT_RGBX1010102``
+ - 'RX30'
+
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - x
+ - x
+
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ -
+* .. _V4L2-PIX-FMT-RGBA1010102:
+
+ - ``V4L2_PIX_FMT_RGBA1010102``
+ - 'RA30'
+
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - a\ :sub:`1`
+ - a\ :sub:`0`
+
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ -
+* .. _V4L2-PIX-FMT-ARGB2101010:
+
+ - ``V4L2_PIX_FMT_ARGB2101010``
+ - 'AR30'
+
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+
+ - a\ :sub:`1`
+ - a\ :sub:`0`
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ -
+
+.. raw:: latex
+
+\endgroup
+
+
Deprecated RGB Formats
==
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index fddba75d9074..875b9a95e3c8 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1304,6 +1304,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_BGRX32: descr = "32-bit XBGR 8-8-8-8"; break;
case
Re: [PATCH 2/2] dt-bindings: leds: backlight: add binding for Kinetic KTZ8866 backlight
Yes, I will Krzysztof Kozlowski 于 2022年12月21日周三 17:46写道： > On 21/12/2022 10:40, jianhua lu wrote: > > Thanks for review, I will resend this path. > > Are you going to test it, before sending? > > Best regards, > Krzysztof > >
[PATCH v2 5/9] drm: Remove usage of deprecated DRM_DEBUG_DRIVER
drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().
Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
include/drm/drm_print.h| 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 24af507bb687..6ad399f6ab03 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -69,11 +69,11 @@
#define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
({ \
if (!len) \
- DRM_DEBUG_DRIVER("cmd=%02x\n", cmd); \
+ drm_dbg_driver(NULL, "cmd=%02x\n", cmd); \
else if (len <= 32) \
- DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, (int)len, data);\
+ drm_dbg_driver(NULL, "cmd=%02x, par=%*ph\n", cmd, (int)len,
data);\
else \
- DRM_DEBUG_DRIVER("cmd=%02x, len=%zu\n", cmd, len); \
+ drm_dbg_driver(NULL, "cmd=%02x, len=%zu\n", cmd, len); \
})
static const u8 mipi_dbi_dcs_read_commands[] = {
@@ -632,7 +632,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *dbi)
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
- DRM_DEBUG_DRIVER("Display is ON\n");
+ drm_dbg_driver(NULL, "Display is ON\n");
return true;
}
@@ -1168,7 +1168,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
mipi_dbi *dbi,
mutex_init(>cmdlock);
- DRM_DEBUG_DRIVER("SPI speed: %uMHz\n", spi->max_speed_hz / 100);
+ drm_dbg_driver(NULL, "SPI speed: %uMHz\n", spi->max_speed_hz / 100);
return 0;
}
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 6d2d5c522e25..3f81f4edbe1d 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -582,7 +582,7 @@ void __drm_err(const char *format, ...);
#define DRM_DEBUG(fmt, ...)\
__drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
-/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
+/* NOTE: this is deprecated in favor of drm_dbg_driver(NULL, ...). */
#define DRM_DEBUG_DRIVER(fmt, ...) \
__drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
--
2.35.1
[PATCH v3 2/7] media: Add Y210, Y212 and Y216 formats
Add Y210, Y212 and Y216 formats.
Signed-off-by: Tomi Valkeinen
---
.../media/v4l/pixfmt-packed-yuv.rst | 49 ++-
drivers/media/v4l2-core/v4l2-ioctl.c | 3 ++
include/uapi/linux/videodev2.h| 8 +++
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
index bf283a1b5581..24a771542059 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
@@ -262,7 +262,12 @@ the second byte and Y'\ :sub:`7-0` in the third byte.
=
These formats, commonly referred to as YUYV or YUY2, subsample the chroma
-components horizontally by 2, storing 2 pixels in 4 bytes.
+components horizontally by 2, storing 2 pixels in a container. The container
+is 32-bits for 8-bit formats, and 64-bits for 10+-bit formats.
+
+The packed YUYV formats with more than 8 bits per component are stored as four
+16-bit little-endian words. Each word's most significant bits contain one
+component, and the least significant bits are zero padding.
.. raw:: latex
@@ -270,7 +275,7 @@ components horizontally by 2, storing 2 pixels in 4 bytes.
.. tabularcolumns::
|p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
-.. flat-table:: Packed YUV 4:2:2 Formats
+.. flat-table:: Packed YUV 4:2:2 Formats in 32-bit container
:header-rows: 1
:stub-columns: 0
@@ -337,6 +342,46 @@ components horizontally by 2, storing 2 pixels in 4 bytes.
- Y'\ :sub:`3`
- Cb\ :sub:`2`
+.. tabularcolumns::
|p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
+
+.. flat-table:: Packed YUV 4:2:2 Formats in 64-bit container
+:header-rows: 1
+:stub-columns: 0
+
+* - Identifier
+ - Code
+ - Word 0
+ - Word 1
+ - Word 2
+ - Word 3
+* .. _V4L2-PIX-FMT-Y210:
+
+ - ``V4L2_PIX_FMT_Y210``
+ - 'Y210'
+
+ - Y'\ :sub:`0` (bits 15-6)
+ - Cb\ :sub:`0` (bits 15-6)
+ - Y'\ :sub:`1` (bits 15-6)
+ - Cr\ :sub:`0` (bits 15-6)
+* .. _V4L2-PIX-FMT-Y212:
+
+ - ``V4L2_PIX_FMT_Y212``
+ - 'Y212'
+
+ - Y'\ :sub:`0` (bits 15-4)
+ - Cb\ :sub:`0` (bits 15-4)
+ - Y'\ :sub:`1` (bits 15-4)
+ - Cr\ :sub:`0` (bits 15-4)
+* .. _V4L2-PIX-FMT-Y216:
+
+ - ``V4L2_PIX_FMT_Y216``
+ - 'Y216'
+
+ - Y'\ :sub:`0` (bits 15-0)
+ - Cb\ :sub:`0` (bits 15-0)
+ - Y'\ :sub:`1` (bits 15-0)
+ - Cr\ :sub:`0` (bits 15-0)
+
.. raw:: latex
\normalsize
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 875b9a95e3c8..a244d5181120 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1449,6 +1449,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_META_FMT_RK_ISP1_STAT_3A: descr = "Rockchip ISP1 3A
Statistics"; break;
case V4L2_PIX_FMT_NV12M_8L128: descr = "NV12M (8x128 Linear)"; break;
case V4L2_PIX_FMT_NV12M_10BE_8L128: descr = "10-bit NV12M (8x128
Linear, BE)"; break;
+ case V4L2_PIX_FMT_Y210: descr = "10-bit YUYV Packed"; break;
+ case V4L2_PIX_FMT_Y212: descr = "12-bit YUYV Packed"; break;
+ case V4L2_PIX_FMT_Y216: descr = "16-bit YUYV Packed"; break;
default:
/* Compressed formats */
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 51d6a8aa4e17..403db3fb5cfa 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -621,6 +621,14 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_YUVX32 v4l2_fourcc('Y', 'U', 'V', 'X') /* 32
YUVX-8-8-8-8 */
#define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0
2 lines y, 1 line uv interleaved */
+/*
+ * YCbCr packed format. For each Y2xx format, xx bits of valid data occupy the
MSBs
+ * of the 16 bit components, and 16-xx bits of zero padding occupy the LSBs.
+ */
+#define V4L2_PIX_FMT_Y210v4l2_fourcc('Y', '2', '1', '0') /* 32 YUYV 4:2:2
*/
+#define V4L2_PIX_FMT_Y212v4l2_fourcc('Y', '2', '1', '2') /* 32 YUYV 4:2:2
*/
+#define V4L2_PIX_FMT_Y216v4l2_fourcc('Y', '2', '1', '6') /* 32 YUYV 4:2:2
*/
+
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
4:2:0 */
#define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
4:2:0 */
--
2.34.1
[PATCH v2 6/9] drm: Remove usage of deprecated DRM_DEBUG_KMS
drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
drm_dbg_kms().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 112 ++---
drivers/gpu/drm/drm_color_mgmt.c | 4 +-
drivers/gpu/drm/drm_connector.c| 21 ++---
drivers/gpu/drm/drm_crtc.c | 36
drivers/gpu/drm/drm_crtc_helper.c | 54 ++--
drivers/gpu/drm/drm_debugfs_crc.c | 5 +-
drivers/gpu/drm/drm_displayid.c| 4 +-
drivers/gpu/drm/drm_edid.c | 17 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 +-
drivers/gpu/drm/drm_lease.c| 2 +-
drivers/gpu/drm/drm_mipi_dbi.c | 7 +-
drivers/gpu/drm/drm_modes.c| 10 +--
drivers/gpu/drm/drm_plane.c| 32 +++
drivers/gpu/drm/drm_probe_helper.c | 39 -
drivers/gpu/drm/drm_rect.c | 4 +-
drivers/gpu/drm/drm_sysfs.c| 8 +-
16 files changed, 189 insertions(+), 170 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index c4517dea924e..7c1e8352ff71 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -246,8 +246,9 @@ static void drm_client_connectors_enabled(struct
drm_connector **connectors,
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
enabled[i] = drm_connector_enabled(connector, true);
- DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- connector->display_info.non_desktop ? "non
desktop" : str_yes_no(enabled[i]));
+ drm_dbg_kms(connector->dev, "connector %d enabled? %s\n",
+ connector->base.id,
+ connector->display_info.non_desktop ? "non desktop"
: str_yes_no(enabled[i]));
any_enabled |= enabled[i];
}
@@ -307,7 +308,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
if (can_clone) {
- DRM_DEBUG_KMS("can clone using command line\n");
+ drm_dbg_kms(dev, "can clone using command line\n");
return true;
}
@@ -332,7 +333,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
if (can_clone) {
- DRM_DEBUG_KMS("can clone using 1024x768\n");
+ drm_dbg_kms(dev, "can clone using 1024x768\n");
return true;
}
drm_info(dev, "kms: can't enable cloning when we probably wanted
to.\n");
@@ -356,8 +357,9 @@ static int drm_client_get_tile_offsets(struct drm_connector
**connectors,
continue;
if (!modes[i] && (h_idx || v_idx)) {
- DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
- connector->base.id);
+ drm_dbg_kms(connector->dev,
+ "no modes for connector tiled %d %d\n",
+ i, connector->base.id);
continue;
}
if (connector->tile_h_loc < h_idx)
@@ -368,7 +370,8 @@ static int drm_client_get_tile_offsets(struct drm_connector
**connectors,
}
offsets[idx].x = hoffset;
offsets[idx].y = voffset;
- DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx,
v_idx);
+ drm_dbg_kms(NULL, "returned %d %d for %d %d\n",
+ hoffset, voffset, h_idx, v_idx);
return 0;
}
@@ -425,14 +428,16 @@ static bool drm_client_target_preferred(struct
drm_connector **connectors,
drm_client_get_tile_offsets(connectors,
connector_count, modes, offsets, i,
connector->tile_h_loc,
connector->tile_v_loc);
}
- DRM_DEBUG_KMS("looking for cmdline mode on connector %d\n",
- connector->base.id);
+ drm_dbg_kms(connector->dev,
+ "looking for cmdline mode on connector %d\n",
+ connector->base.id);
/* got for command line mode first */
modes[i] = drm_connector_pick_cmdline_mode(connector);
if (!modes[i]) {
- DRM_DEBUG_KMS("looking for preferred mode on connector
%d %d\n",
- connector->base.id, connector->tile_group
? connector->tile_group->id : 0);
+ drm_dbg_kms(connector->dev,
+ "looking for preferred mode on connector %d
%d\n",
+ connector->base.id, connector->tile_group ?
connector->tile_group->id : 0);
modes[i] = drm_connector_has_preferred_mode(connector,
width, height);
}
/* No preferred
[PATCH v3 3/7] media: renesas: vsp1: Change V3U to be gen4
V3U is actually gen4, not gen3. The same IP is also used in the
(not-yet-supported) V4H.
Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
to represent the model correctly. V3U and V4H can still be
differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
and update the code to correctly match for gen 4.
Signed-off-by: Tomi Valkeinen
---
drivers/media/platform/renesas/vsp1/vsp1_drv.c | 4 ++--
drivers/media/platform/renesas/vsp1/vsp1_hgo.c | 4 ++--
drivers/media/platform/renesas/vsp1/vsp1_lif.c | 1 +
drivers/media/platform/renesas/vsp1/vsp1_regs.h | 2 +-
drivers/media/platform/renesas/vsp1/vsp1_rpf.c | 12 ++--
drivers/media/platform/renesas/vsp1/vsp1_video.c | 4 ++--
drivers/media/platform/renesas/vsp1/vsp1_wpf.c | 4 ++--
7 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
index c260d318d298..5710152d6511 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
@@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.wpf_count = 2,
.num_bru_inputs = 5,
}, {
- .version = VI6_IP_VERSION_MODEL_VSPD_V3U,
+ .version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
.model = "VSP2-D",
- .gen = 3,
+ .gen = 4,
.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
.lif_count = 1,
.rpf_count = 5,
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
index bf3f981f93a1..e6492deb0a64 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
@@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
/* Initialize the control handler. */
v4l2_ctrl_handler_init(>ctrls.handler,
- vsp1->info->gen == 3 ? 2 : 1);
+ vsp1->info->gen >= 3 ? 2 : 1);
hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(>ctrls.handler,
_max_rgb_control, NULL);
- if (vsp1->info->gen == 3)
+ if (vsp1->info->gen >= 3)
hgo->ctrls.num_bins =
v4l2_ctrl_new_custom(>ctrls.handler,
_num_bins_control, NULL);
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
index 186a5730e1e3..0ab2e0c70474 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
@@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
break;
case VI6_IP_VERSION_MODEL_VSPD_GEN3:
+ case VI6_IP_VERSION_MODEL_VSPD_GEN4:
default:
hbth = 0;
obth = 3000;
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
index 8928f4c6bb55..8c9333f76858 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
@@ -766,7 +766,7 @@
#define VI6_IP_VERSION_MODEL_VSPD_V3 (0x18 << 8)
#define VI6_IP_VERSION_MODEL_VSPDL_GEN3(0x19 << 8)
#define VI6_IP_VERSION_MODEL_VSPBS_GEN3(0x1a << 8)
-#define VI6_IP_VERSION_MODEL_VSPD_V3U (0x1c << 8)
+#define VI6_IP_VERSION_MODEL_VSPD_GEN4 (0x1c << 8)
/* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
#define VI6_IP_VERSION_MODEL_VSPD_RZG2L(0x80 << 8)
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
index 75083cb234fe..045aa54f7998 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
@@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity
*entity,
* a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
* otherwise.
*
-* The Gen3 RPF has extended alpha capability and can both multiply the
+* The Gen3+ RPF has extended alpha capability and can both multiply the
* alpha channel by a fixed global alpha value, and multiply the pixel
* components to convert the input to premultiplied alpha.
*
* As alpha premultiplication is available in the BRx for both Gen2 and
-* Gen3 we handle it there and use the Gen3 alpha multiplier for global
+* Gen3+ we handle it there and use the Gen3 alpha multiplier for global
* alpha multiplication only. This however prevents conversion to
* premultiplied alpha if no BRx is present in the pipeline. If that use
*
[PATCH v2 1/2] backlight: ktz8866: Add support for Kinetic KTZ8866 backlight
Add support for Kinetic KTZ8866 backlight, which is used in
Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
downstream implementation [1].
[1]
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c
Signed-off-by: Jianhua Lu
---
Changces in v2:
- Add missing staitc modifier to ktz8866_write function.
drivers/video/backlight/Kconfig | 8 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/ktz8866.c | 174 ++
drivers/video/backlight/ktz8866.h | 31 ++
4 files changed, 214 insertions(+)
create mode 100644 drivers/video/backlight/ktz8866.c
create mode 100644 drivers/video/backlight/ktz8866.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 936ba1e4d35e..2845fd7e33ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -190,6 +190,14 @@ config BACKLIGHT_KTD253
which is a 1-wire GPIO-controlled backlight found in some mobile
phones.
+config BACKLIGHT_KTZ8866
+ tristate "Backlight Driver for Kinetic KTZ8866"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y to enabled the backlight driver for the Kinetic KTZ8866
+ found in Xiaomi Mi Pad 5 series.
+
config BACKLIGHT_LM3533
tristate "Backlight Driver for LM3533"
depends on MFD_LM3533
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e815f3f1deff..f70a819c304c 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
+obj-$(CONFIG_BACKLIGHT_KTZ8866)+= ktz8866.o
obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
diff --git a/drivers/video/backlight/ktz8866.c
b/drivers/video/backlight/ktz8866.c
new file mode 100644
index ..a0ea6ebbda60
--- /dev/null
+++ b/drivers/video/backlight/ktz8866.c
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Backlight driver for the Kinetic KTZ8866
+ *
+ * Copyright (C) Jianhua Lu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ktz8866.h"
+
+#define DEF_BRIGHTNESS 1500
+#define MAX_BRIGHTNESS 2047
+#define REG_MAX 0x15
+
+/* Helper */
+#define low_3_bit(x) ((x)&0x7)
+#define high_8_bit(x) ((x >> 3) & 0xFF)
+
+struct ktz8866 {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ bool state;
+};
+
+enum {
+ LED_OFF,
+ LED_ON,
+};
+
+static const struct regmap_config ktz8866_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = REG_MAX,
+};
+
+static int ktz8866_write(struct ktz8866 *ktz, unsigned int reg,
+unsigned int val)
+{
+ return regmap_write(ktz->regmap, reg, val);
+}
+
+static int ktz8866_update_bits(struct ktz8866 *ktz, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ return regmap_update_bits(ktz->regmap, reg, mask, val);
+}
+
+static int
+ktz8866_backlight_update_status(struct backlight_device *backlight_dev)
+{
+ struct ktz8866 *ktz = bl_get_data(backlight_dev);
+ unsigned int brightness = backlight_get_brightness(backlight_dev);
+
+ if (!ktz->state && brightness > 0) {
+ ktz8866_update_bits(ktz, BL_EN, BIT(6), BIT(6));
+ ktz->state = LED_ON;
+ } else if (brightness == 0) {
+ ktz8866_update_bits(ktz, BL_EN, BIT(6), 0);
+ ktz->state = LED_OFF;
+ msleep(10);
+ }
+
+ /* Set brightness */
+ ktz8866_write(ktz, BL_BRT_LSB, low_3_bit(brightness));
+ ktz8866_write(ktz, BL_BRT_MSB, high_8_bit(brightness));
+
+ return 0;
+}
+
+static const struct backlight_ops ktz8866_backlight_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = ktz8866_backlight_update_status,
+};
+
+static void ktz8866_init(struct ktz8866 *ktz)
+{
+ /* Enable 1~5 current sinks */
+ ktz8866_write(ktz, BL_EN, 0x1F);
+ /* Backlight OVP 26.4V */
+ ktz8866_write(ktz, BL_CFG1, 0x33);
+ /* LED ramping time 128ms */
+ ktz8866_write(ktz, BL_CFG2, 0xBD);
+ /* LED on/off ramping time 1ms */
+ ktz8866_write(ktz, BL_DIMMING, 0x11);
+ /* Enable OUTP and OUTN via pin ENP and ENN */
+ ktz8866_write(ktz, LCD_BIAS_CFG1, 0x9F);
+ /* Backlight Full-scale LED Current 30.0mA */
+ ktz8866_write(ktz, FULL_SCALE_CURRENT, 0xF9);
+}
+
+static int ktz8866_probe(struct i2c_client *client,
+const struct
[PATCH v3 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)
Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010, Y210 and
Y212.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 30
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 50 +--
2 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 8c2719efda2a..adfb36b0e815 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -259,6 +259,24 @@ static const struct rcar_du_format_info
rcar_du_format_infos[] = {
.bpp = 32,
.planes = 1,
.hsub = 1,
+ }, {
+ .fourcc = DRM_FORMAT_RGBX1010102,
+ .v4l2 = V4L2_PIX_FMT_RGBX1010102,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 1,
+ }, {
+ .fourcc = DRM_FORMAT_RGBA1010102,
+ .v4l2 = V4L2_PIX_FMT_RGBA1010102,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 1,
+ }, {
+ .fourcc = DRM_FORMAT_ARGB2101010,
+ .v4l2 = V4L2_PIX_FMT_ARGB2101010,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 1,
}, {
.fourcc = DRM_FORMAT_YVYU,
.v4l2 = V4L2_PIX_FMT_YVYU,
@@ -307,6 +325,18 @@ static const struct rcar_du_format_info
rcar_du_format_infos[] = {
.bpp = 24,
.planes = 3,
.hsub = 1,
+ }, {
+ .fourcc = DRM_FORMAT_Y210,
+ .v4l2 = V4L2_PIX_FMT_Y210,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 2,
+ }, {
+ .fourcc = DRM_FORMAT_Y212,
+ .v4l2 = V4L2_PIX_FMT_Y212,
+ .bpp = 32,
+ .planes = 1,
+ .hsub = 2,
},
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index e465aef41585..fe90be51d64e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -139,6 +139,43 @@ static const u32 rcar_du_vsp_formats[] = {
DRM_FORMAT_YVU444,
};
+/*
+ * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
+ * formats and Y210 & Y212 formats.
+ */
+static const u32 rcar_du_vsp_formats_gen4[] = {
+ DRM_FORMAT_RGB332,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_RGBX1010102,
+ DRM_FORMAT_RGBA1010102,
+ DRM_FORMAT_ARGB2101010,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV21,
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV61,
+ DRM_FORMAT_YUV420,
+ DRM_FORMAT_YVU420,
+ DRM_FORMAT_YUV422,
+ DRM_FORMAT_YVU422,
+ DRM_FORMAT_YUV444,
+ DRM_FORMAT_YVU444,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+};
+
static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
{
struct rcar_du_vsp_plane_state *state =
@@ -436,14 +473,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
device_node *np,
? DRM_PLANE_TYPE_PRIMARY
: DRM_PLANE_TYPE_OVERLAY;
struct rcar_du_vsp_plane *plane = >planes[i];
+ unsigned int num_formats;
+ const u32 *formats;
+
+ if (rcdu->info->gen < 4) {
+ num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
+ formats = rcar_du_vsp_formats;
+ } else {
+ num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
+ formats = rcar_du_vsp_formats_gen4;
+ }
plane->vsp = vsp;
plane->index = i;
ret = drm_universal_plane_init(>ddev, >plane,
crtcs, _du_vsp_plane_funcs,
- rcar_du_vsp_formats,
- ARRAY_SIZE(rcar_du_vsp_formats),
+ formats, num_formats,
NULL, type, NULL);
if (ret < 0)
return ret;
--
2.34.1
Re: [PATCH 04/10] drm/print: Fix support for NULL as first argument of drm_dbg_*
On Wed, Dec 21 2022 at 14:38:08 +0530, Thomas Zimmermann wrote:
> Hi
>
> Am 20.12.22 um 21:16 schrieb Siddh Raman Pant:
>> Comments say macros DRM_DEBUG_* are deprecated in favor of
>> drm_dbg_*(NULL, ...), but they have broken support for it,
>> as the macro will result in `(NULL) ? (NULL)->dev : NULL`.
>>
>> Thus, fix them by casting input drm to a temporary struct ptr,
>> with the same convention as in __DRM_DEFINE_DBG_RATELIMITED.
>>
>> Signed-off-by: Siddh Raman Pant
>> ---
>> include/drm/drm_print.h | 89 -
>> 1 file changed, 69 insertions(+), 20 deletions(-)
>>
>> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
>> index a44fb7ef257f..53702d830291 100644
>> --- a/include/drm/drm_print.h
>> +++ b/include/drm/drm_print.h
>> @@ -486,26 +486,75 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
>> device *dev,
>> __drm_printk((drm), err, _ratelimited, "*ERROR* " fmt, ##__VA_ARGS__)
>> -#define drm_dbg_core(drm, fmt, ...) \
>> - drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
> ...
>> +#define drm_dbg_core(drm, fmt, ...) \
>> +({ \
>> + const struct drm_device *drm_ = (drm); \
>> + drm_dev_dbg(drm_ ? drm_->dev : NULL, DRM_UT_CORE, \
>> + fmt, ##__VA_ARGS__); \
>> +})
>
> Instead of doing this for each drm_dbg_ macro, rather add an internal helper
> that returns the device or NULL like this:
>
> static inline struct device *__drm_print_dev(struct drm_device *drm)
> {
> if (drm)
> return drm->dev;
> return NULL;
> }
>
> and change the macros to
>
> drm_dbg_core(drm, fmt, ...)
> drm_dev_dbg(__drm_print_dev(drm), DRM_UT_CORE, )
>
> and so on.
>
> Best regards
> Thomas
Sure, I'll send a v2.
Thanks,
Siddh
Re: [PATCH] drm/vmwgfx: Fix passing partly uninitialized drm_mode_fb_cmd2 struct
On Wed, Dec 21, 2022 at 3:45 PM Thorsten Leemhuis wrote: > > Hi, this is your Linux kernel regression tracker. The relevant code here > is not my area of expertise, nevertheless a few questions: Thank you > > On 21.12.22 03:23, Kaiwan N Billimoria wrote: > > [REGRESSION] ? > > > Testing with 6.1, I find the same issue - VirtualBox VMs seem to hang > > on boot, though the kernel has this patch applied of course... > > Maybe I'm missing something, but what made you assume that it's the same > issue? The fix for that issue talked about "garbage" in some structures > that "can cause random failures during the bringup of the fbcon." Yeah, > maybe that ca result in a hang, but I didn't see it that thread (but > maybe I missed) I got an Oops when testing with VirtualBox; managed to recover it; pl have a look: https://gist.github.com/kaiwan/a79ad81fa63440b790724a136d16407d The presence of the ttm module in the Oops in RIP: RIP: 0010:ttm_bo_move_memcpy+0x15f/0x2e0 [ttm] and the vmwgfx module's funcs in the call stack made me think that perhaps it's the same issue... Am unsure, you folks will of course know better. > > > Am running VirtualBox 7.0.4 on an x86_64 Linux (Ubuntu 22.04.1) host; > > the system hangs on boot with the screen > > going blank. > > A bit more details would be helpful. For example: is anything printed at > all before the system hangs? What's the last kernel that worked for you > (and is the newer kernel using a similar build configuration)? Earlier kernels all seem to work fine, with a similar (localmodconfig) config.. Also, as mentioned, putting 'nomodeset' in the kernel cmd line has it work just fine, even with 6.1 >Which > graphics adapater did you configure in VirtualBox? VMSVGA > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) Thanks Thorsten... -kaiwan. > > P.S.: As the Linux kernel's regression tracker I deal with a lot of > reports and sometimes miss something important when writing mails like > this. If that's the case here, don't hesitate to tell me in a public > reply, it's in everyone's interest to set the public record straight.
[PATCH v2 2/9] drm: Remove usage of deprecated DRM_ERROR
drm_print.h says DRM_ERROR is deprecated.
Thus, use newer printing macros drm_err() and pr_err().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_bridge.c | 8
drivers/gpu/drm/drm_bufs.c | 8
drivers/gpu/drm/drm_client_modeset.c | 4 ++--
drivers/gpu/drm/drm_context.c| 4 ++--
drivers/gpu/drm/drm_crtc_helper.c| 6 +++---
drivers/gpu/drm/drm_debugfs_crc.c| 3 ++-
drivers/gpu/drm/drm_drv.c| 8
drivers/gpu/drm/drm_framebuffer.c| 3 ++-
drivers/gpu/drm/drm_gem.c| 2 +-
drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
drivers/gpu/drm/drm_mode_config.c| 2 +-
drivers/gpu/drm/drm_modeset_helper.c | 2 +-
drivers/gpu/drm/drm_plane.c | 2 +-
drivers/gpu/drm/drm_scatter.c| 9 +
drivers/gpu/drm/drm_vm.c | 2 +-
16 files changed, 35 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1545c50fd1c8..20a8cde70640 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -312,11 +312,11 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
drm_bridge *bridge,
list_del(>chain_node);
#ifdef CONFIG_OF
- DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
- bridge->of_node, encoder->name, ret);
+ drm_err(encoder->dev, "failed to attach bridge %pOF to encoder %s:
%d\n",
+ bridge->of_node, encoder->name, ret);
#else
- DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
- encoder->name, ret);
+ drm_err(encoder->dev, "failed to attach bridge to encoder %s: %d\n",
+ encoder->name, ret);
#endif
return ret;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index fcca21e8efac..98aaf3379a3b 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1474,15 +1474,15 @@ int drm_legacy_freebufs(struct drm_device *dev, void
*data,
if (copy_from_user(, >list[i], sizeof(idx)))
return -EFAULT;
if (idx < 0 || idx >= dma->buf_count) {
- DRM_ERROR("Index %d (of %d max)\n",
- idx, dma->buf_count - 1);
+ drm_err(dev, "Index %d (of %d max)\n",
+ idx, dma->buf_count - 1);
return -EINVAL;
}
idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
- DRM_ERROR("Process %d freeing buffer not owned\n",
- task_pid_nr(current));
+ drm_err(dev, "Process %d freeing buffer not owned\n",
+ task_pid_nr(current));
return -EINVAL;
}
drm_legacy_free_buffer(dev, buf);
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 2b76d4828c5f..c4517dea924e 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -812,7 +812,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
offsets = kcalloc(connector_count, sizeof(*offsets), GFP_KERNEL);
enabled = kcalloc(connector_count, sizeof(bool), GFP_KERNEL);
if (!crtcs || !modes || !enabled || !offsets) {
- DRM_ERROR("Memory allocation failed\n");
+ drm_err(client->dev, "Memory allocation failed\n");
ret = -ENOMEM;
goto out;
}
@@ -836,7 +836,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
offsets, enabled, width, height)
&&
!drm_client_target_preferred(connectors, connector_count,
modes,
offsets, enabled, width,
height))
- DRM_ERROR("Unable to find initial modes\n");
+ drm_err(client->dev, "Unable to find initial modes\n");
DRM_DEBUG_KMS("picking CRTCs for %dx%d config\n",
width, height);
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index c6e6a3e7219a..f6d68fad8311 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -276,7 +276,7 @@ int drm_legacy_setsareactx(struct drm_device *dev, void
*data,
static int drm_context_switch(struct drm_device * dev, int old, int new)
{
if (test_and_set_bit(0, >context_flag)) {
- DRM_ERROR("Reentering -- FIXME\n");
+ drm_err(dev, "Reentering -- FIXME\n");
return -EBUSY;
}
@@ -307,7 +307,7 @@ static int drm_context_switch_complete(struct drm_device
Re: [PATCH 00/10] drm: Remove usage of deprecated DRM_* macros
On Wed, Dec 21 2022 at 14:46:12 +0530, Thomas Zimmermann wrote:
> Hi
>
> Am 20.12.22 um 21:16 schrieb Siddh Raman Pant:
>> This patchset aims to remove usages of deprecated DRM_* macros from the
>> files residing in drivers/gpu/drm root.
>>
>> In process, I found out that NULL as first argument of drm_dbg_* wasn't
>> working, but it was listed as the alternative in deprecation comment,
>> so I fixed that before removing usages of DRM_DEBUG_* macros.
>>
>> This patchset should be applied in order as changes might be dependent.
>>
>> Please review and let me know if any errors are there, and hopefully
>> this gets accepted.
>
> Thanks for the patchset. Overall this looks fine.
>
> But the use of pr_() functions is not optimal in my opinion. I know that
> I recommended using it, but at a closer look, I think we might want to
> reconsider that. I wouldn't like losing the '[drm]' tag, but adding them
> to each pr_() call isn't a good idea either.
>
> I think it would be nicer to replace DRM_INFO with drm_info(NULL, ).
> Depending on the device being NULL, the helpers would select dev-based
> messages or printk-based messages. It would then work like drm_dbg_().
> But it needs some additional changes.
>
> Can you first move all pr_() related changes into a new patchset? The
> trivial conversion were the device is known and not NULL can remain in
> this patchset and be merged soon. We can afterwards have a separate
> discussion for the changes that currently involve pr_().
>
> Best regards
> Thomas
Maybe I can just cope for NULL in __drm_printk and change all pr_*()
changes in this patchset to the appropriate ones.
Something like:
#define __drm_printk(drm, level, type, fmt, ...)
\
({
\
drm_ = __drm_print_dev(drm);
\
if (drm_)
\
dev_##level##type((drm_)->dev, "[drm] " fmt, ##__VA_ARGS__);
\
else
\
pr_##level##type("[drm] " fmt, ##__VA_ARGS__);
\
})
Thanks,
Siddh
[PATCH v2 2/2] dt-bindings: leds: backlight: Add Kinetic KTZ8866 backlight
Add Kinetic KTZ8866 backlight binding documentation.
Signed-off-by: Jianhua Lu
---
Changes in v2:
- Remove "items" between "compatible" and "const: kinetic,ktz8866"
- Change "additionalProperties" to "unevaluatedProperties"
.../leds/backlight/kinetic,ktz8866.yaml | 36 +++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
new file mode 100644
index ..c63c21bf69d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktz8866.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kinetic Technologies KTZ8866 backlight
+
+maintainers:
+ - Jianhua Lu
+
+description: |
+ The Kinetic Technologies KTZ8866 is a high efficiency 6-sinks led backlight
+ with dual lcd bias power.
+ https://www.kinet-ic.com/ktz8866/
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+const: kinetic,ktz8866
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+backlight {
+compatible = "kinetic,ktz8866";
+
+pinctrl-names = "default";
+pinctrl-0 = <_en_default>;
+};
--
2.38.2
[PATCH v2 8/9] drm/drm_blend: Remove usage of deprecated DRM_DEBUG_ATOMIC
drm_print.h says DRM_DEBUG_ATOMIC is deprecated in favor of
drm_dbg_atomic().
Signed-off-by: Siddh Raman Pant
Reviewed-by: Simon Ser
---
drivers/gpu/drm/drm_blend.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index b4c8cab7158c..6e74de833466 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -450,8 +450,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct
drm_crtc *crtc,
int i, n = 0;
int ret = 0;
- DRM_DEBUG_ATOMIC("[CRTC:%d:%s] calculating normalized zpos values\n",
-crtc->base.id, crtc->name);
+ drm_dbg_atomic(dev, "[CRTC:%d:%s] calculating normalized zpos values\n",
+ crtc->base.id, crtc->name);
states = kmalloc_array(total_planes, sizeof(*states), GFP_KERNEL);
if (!states)
@@ -469,9 +469,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct
drm_crtc *crtc,
goto done;
}
states[n++] = plane_state;
- DRM_DEBUG_ATOMIC("[PLANE:%d:%s] processing zpos value %d\n",
-plane->base.id, plane->name,
-plane_state->zpos);
+ drm_dbg_atomic(dev, "[PLANE:%d:%s] processing zpos value %d\n",
+ plane->base.id, plane->name, plane_state->zpos);
}
sort(states, n, sizeof(*states), drm_atomic_state_zpos_cmp, NULL);
@@ -480,8 +479,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct
drm_crtc *crtc,
plane = states[i]->plane;
states[i]->normalized_zpos = i;
- DRM_DEBUG_ATOMIC("[PLANE:%d:%s] normalized zpos value %d\n",
-plane->base.id, plane->name, i);
+ drm_dbg_atomic(dev, "[PLANE:%d:%s] normalized zpos value %d\n",
+ plane->base.id, plane->name, i);
}
crtc_state->zpos_changed = true;
--
2.35.1
Re: [RESEND] dt-bindings: leds: backlight: Add Kinetic KTZ8866 backlight
On Wed, Dec 21, 2022 at 04:03:44PM +0100, Krzysztof Kozlowski wrote: > On 21/12/2022 14:24, Jianhua Lu wrote: > > Add Kinetic KTZ8866 backlight binding documentation. > > > > Signed-off-by: Jianhua Lu > > Do not resend. You need to fix everything, test and send a new patchset > (entire) with the changelog. Ok, I got it. I was just a bit confused about "Need to resend with proper thread". > > Best regards, > Krzysztof >
[PATCH v2 3/9] drm/print: Fix support for NULL as first argument of drm_dbg_*
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.
Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
Use it in drm_dbg_*, and also in __DRM_DEFINE_DBG_RATELIMITED,
where a similar (but correct) NULL check was in place.
Signed-off-by: Siddh Raman Pant
---
include/drm/drm_print.h | 42 -
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..6d2d5c522e25 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -34,6 +34,7 @@
#include
#include
+#include
/* Do *not* use outside of drm_print.[ch]! */
extern unsigned long __drm_debug;
@@ -451,6 +452,22 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
device *dev,
* Prefer drm_device based logging over device or prink based logging.
*/
+/**
+ * __drm_get_dev_ptr - Helper function to get device type pointer even if NULL
+ *is passed. Primarily for use in print macros, since they
+ *need to handle NULL as the first argument passed.
+ * @drm: The *drm_device pointer, or NULL.
+ *
+ * RETURNS:
+ * The *device pointer, or NULL.
+ */
+static inline struct device *__drm_get_dev_ptr(const struct drm_device *drm)
+{
+ if (drm)
+ return drm->dev;
+ return NULL;
+}
+
/* Helper for struct drm_device based logging. */
#define __drm_printk(drm, level, type, fmt, ...) \
dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
@@ -487,25 +504,25 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
device *dev,
#define drm_dbg_core(drm, fmt, ...)\
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
-#define drm_dbg_driver(drm, fmt, ...)
\
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_CORE, fmt, ##__VA_ARGS__)
+#define drm_dbg_driver(drm, fmt, ...) \
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define drm_dbg_kms(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_KMS, fmt, ##__VA_ARGS__)
#define drm_dbg_prime(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_PRIME, fmt, ##__VA_ARGS__)
#define drm_dbg_atomic(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
#define drm_dbg_vbl(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_VBL, fmt, ##__VA_ARGS__)
#define drm_dbg_state(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_STATE, fmt, ##__VA_ARGS__)
#define drm_dbg_lease(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_LEASE, fmt, ##__VA_ARGS__)
#define drm_dbg_dp(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_DP, fmt, ##__VA_ARGS__)
#define drm_dbg_drmres(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_DRMRES, fmt, ##__VA_ARGS__)
#define drm_dbg(drm, fmt, ...) drm_dbg_driver(drm, fmt, ##__VA_ARGS__)
@@ -596,10 +613,9 @@ void __drm_err(const char *format, ...);
#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
\
({
\
static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL,
DEFAULT_RATELIMIT_BURST);\
- const struct drm_device *drm_ = (drm);
\
\
if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(_))
\
- drm_dev_printk(drm_ ?
[PATCH v2 1/9] drm: Remove usage of deprecated DRM_INFO
drm_print.h says DRM_INFO is deprecated.
Thus, use newer printing macros drm_info() and pr_info().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 7 ---
drivers/gpu/drm/drm_drv.c| 2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index d553e793e673..2b76d4828c5f 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -335,7 +335,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
}
- DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+ drm_info(dev, "kms: can't enable cloning when we probably wanted
to.\n");
return false;
}
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 547356e00341..34c26b2a974e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -165,13 +165,14 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
return;
if (mode->force) {
- DRM_INFO("forcing %s connector %s\n", connector->name,
-drm_get_connector_force_name(mode->force));
+ drm_info(connector->dev, "forcing %s connector %s\n",
+connector->name,
drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
- DRM_INFO("cmdline forces connector %s panel_orientation to
%d\n",
+ drm_info(connector->dev,
+"cmdline forces connector %s panel_orientation to
%d\n",
connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 73b845a75d52..bc98e4bcf2c1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -938,7 +938,7 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
- DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
+ drm_info(dev, "Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver->name, driver->major, driver->minor,
driver->patchlevel, driver->date,
dev->dev ? dev_name(dev->dev) : "virtual device",
--
2.35.1
[PATCH v3 5/7] media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210, Y212)
Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010, Y210 and
Y212.
Signed-off-by: Tomi Valkeinen
---
.../media/platform/renesas/vsp1/vsp1_pipe.c | 18 +++
.../media/platform/renesas/vsp1/vsp1_regs.h | 23
.../media/platform/renesas/vsp1/vsp1_rpf.c| 52 +++
3 files changed, 93 insertions(+)
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
index f72ac01c21ea..f8093ba9539e 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
@@ -146,6 +146,18 @@ static const struct vsp1_format_info vsp1_video_formats[]
= {
VI6_FMT_ARGB_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
1, { 32, 0, 0 }, false, false, 1, 1, false },
+ { V4L2_PIX_FMT_RGBX1010102, MEDIA_BUS_FMT_ARGB_1X32,
+ VI6_FMT_RGB10_RGB10A2_A2RGB10,
+ VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 1, 1, false },
+ { V4L2_PIX_FMT_RGBA1010102, MEDIA_BUS_FMT_ARGB_1X32,
+ VI6_FMT_RGB10_RGB10A2_A2RGB10,
+ VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 1, 1, false },
+ { V4L2_PIX_FMT_ARGB2101010, MEDIA_BUS_FMT_ARGB_1X32,
+ VI6_FMT_RGB10_RGB10A2_A2RGB10,
+ VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 1, 1, false },
{ V4L2_PIX_FMT_UYVY, MEDIA_BUS_FMT_AYUV8_1X32,
VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
@@ -202,6 +214,12 @@ static const struct vsp1_format_info vsp1_video_formats[]
= {
VI6_FMT_Y_U_V_444, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
3, { 8, 8, 8 }, false, true, 1, 1, false },
+ { V4L2_PIX_FMT_Y210, MEDIA_BUS_FMT_AYUV8_1X32,
+ VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 2, 1, false },
+ { V4L2_PIX_FMT_Y212, MEDIA_BUS_FMT_AYUV8_1X32,
+ VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+ 1, { 32, 0, 0 }, false, false, 2, 1, false },
};
/**
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
index c61e8dafeecf..d94343ae57a1 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
@@ -228,6 +228,28 @@
#define VI6_RPF_MULT_ALPHA_RATIO_MASK (0xff << 0)
#define VI6_RPF_MULT_ALPHA_RATIO_SHIFT 0
+#define VI6_RPF_EXT_INFMT0 0x0370
+#define VI6_RPF_EXT_INFMT0_F2B BIT(12)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_8(0 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_10 (1 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_12 (2 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_8(0 << 4)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_10 (1 << 4)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_12 (2 << 4)
+#define VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10 (3 << 0)
+
+#define VI6_RPF_EXT_INFMT1 0x0374
+#define VI6_RPF_EXT_INFMT1_PACK_CPOS(a, b, c, d) \
+ (((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
+
+#define VI6_RPF_EXT_INFMT2 0x0378
+#define VI6_RPF_EXT_INFMT2_PACK_CLEN(a, b, c, d) \
+ (((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
+
+#define VI6_RPF_BRDITH_CTRL0x03e0
+#define VI6_RPF_BRDITH_CTRL_ODEBIT(8)
+#define VI6_RPF_BRDITH_CTRL_CBRM BIT(0)
+
/*
-
* WPF Control Registers
*/
@@ -846,6 +868,7 @@
#define VI6_FMT_XBXGXR_262626 0x21
#define VI6_FMT_ABGR_ 0x22
#define VI6_FMT_XXRGB_885650x23
+#define VI6_FMT_RGB10_RGB10A2_A2RGB10 0x30
#define VI6_FMT_Y_UV_444 0x40
#define VI6_FMT_Y_UV_422 0x41
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
index 045aa54f7998..3b17f5fa4067 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
@@ -109,6 +109,58 @@ static void rpf_configure_stream(struct vsp1_entity
*entity,
vsp1_rpf_write(rpf, dlb, VI6_RPF_INFMT, infmt);
vsp1_rpf_write(rpf, dlb, VI6_RPF_DSWAP, fmtinfo->swap);
+ if (entity->vsp1->info->gen == 4) {
+ u32 ext_infmt0;
+ u32 ext_infmt1;
+ u32 ext_infmt2;
+
+ switch (fmtinfo->fourcc) {
+ case V4L2_PIX_FMT_RGBX1010102:
+ ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
+ ext_infmt1 = VI6_RPF_EXT_INFMT1_PACK_CPOS(0, 10, 20, 0);
+ ext_infmt2 = VI6_RPF_EXT_INFMT2_PACK_CLEN(10, 10, 10,
0);
+ break;
Re: [PATCH 04/10] drm/print: Fix support for NULL as first argument of drm_dbg_*
On Wed, Dec 21 2022 at 15:11:07 +0530, Jani Nikula wrote: > On Wed, 21 Dec 2022, Siddh Raman Pant wrote: >> Comments say macros DRM_DEBUG_* are deprecated in favor of >> drm_dbg_*(NULL, ...), but they have broken support for it, >> as the macro will result in `(NULL) ? (NULL)->dev : NULL`. > > What's wrong with that? NULL is not a struct, so the syntax is incorrect. Note that this isn't about a dev pointer whose value is NULL, the first argument is NULL directly. So "NULL" is directly substituted as is. If it was a dev pointer, then the definition of struct allowed for no error, but here gcc will generate the following error: error: request for member ‘dev’ in something not a structure or union Hence, there is a need to fix them. Thanks, Siddh
Re: [PATCH 2/2] dt-bindings: leds: backlight: add binding for Kinetic KTZ8866 backlight
On Wed, Dec 21, 2022 at 07:45:59AM -0600, Rob Herring wrote:
>
> On Wed, 21 Dec 2022 15:02:16 +0800, Jianhua Lu wrote:
> > Add device tree bindings for the Kinetic KTZ8866 backlight driver.
> >
> > Signed-off-by: Jianhua Lu
> > ---
> > .../leds/backlight/kinetic,ktz8866.yaml | 37 +++
> > 1 file changed, 37 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
> >
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml:
> properties:compatible:items: {'const': 'kinetic,ktz8866'} is not of type
> 'array'
> from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
>
> doc reference errors (make refcheckdocs):
>
> See
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20221221070216.17850-1-lujianhua...@gmail.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>
I have resent a new patch and gotten rip of errors of the old dt-binding yaml.
Re: [PATCH v9 5/5] drm/bridge: cdns-dsi: Add support for J721E wrapper
On 31/10/2022 14:19, Rahul T R wrote: Add support for wrapper settings for DSI bridge on j721e. Also enable DPI0 --- --- | ---| |--- | | DSS | DPI2 |->| DPI0 | DSI Wrapper | | ---| |--- | --- --- As shown above DPI2 output of DSS is connected to DPI0 input of DSI Wrapper, DSI wrapper gives control wheather to enable/disable DPI0 input. In j721e above is the only configuration supported Signed-off-by: Rahul T R --- drivers/gpu/drm/bridge/cadence/Kconfig| 10 drivers/gpu/drm/bridge/cadence/Makefile | 1 + .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 35 - .../gpu/drm/bridge/cadence/cdns-dsi-core.h| 13 + .../gpu/drm/bridge/cadence/cdns-dsi-j721e.c | 51 +++ .../gpu/drm/bridge/cadence/cdns-dsi-j721e.h | 16 ++ 6 files changed, 125 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h Reviewed-by: Tomi Valkeinen Tomi
[PATCH v3 0/7] media/drm: renesas: Add new pixel formats
From: Tomi Valkeinen Hi, These add new pixel formats for Renesas V3U and V4H SoCs. As the display pipeline is split between DRM and V4L2 components, this series touches both subsystems. I'm sending all these together to simplify review. If needed, I can later split this to V4L2 and DRM parts, of which the V4L2 part needs to be merged first. Changes in v3: - Addressed all the review comments - Added Y212 - Updated the kernel docs for the new formats - Changed the RGB format names to match the DRM's format names - Updated RPF register field macros according to the comments Tomi Tomi Valkeinen (7): media: Add 2-10-10-10 RGB formats media: Add Y210, Y212 and Y216 formats media: renesas: vsp1: Change V3U to be gen4 media: renesas: vsp1: Add V4H SoC version media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210, Y212) drm: rcar-du: Bump V3U to gen 4 drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210) .../media/v4l/pixfmt-packed-yuv.rst | 49 - .../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 30 +++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 50 - .../media/platform/renesas/vsp1/vsp1_drv.c| 4 +- .../media/platform/renesas/vsp1/vsp1_hgo.c| 4 +- .../media/platform/renesas/vsp1/vsp1_lif.c| 1 + .../media/platform/renesas/vsp1/vsp1_pipe.c | 18 ++ .../media/platform/renesas/vsp1/vsp1_regs.h | 26 ++- .../media/platform/renesas/vsp1/vsp1_rpf.c| 64 +- .../media/platform/renesas/vsp1/vsp1_video.c | 4 +- .../media/platform/renesas/vsp1/vsp1_wpf.c| 4 +- drivers/media/v4l2-core/v4l2-ioctl.c | 6 + include/uapi/linux/videodev2.h| 11 + 15 files changed, 447 insertions(+), 20 deletions(-) -- 2.34.1
[RESEND] dt-bindings: leds: backlight: Add Kinetic KTZ8866 backlight
Add Kinetic KTZ8866 backlight binding documentation.
Signed-off-by: Jianhua Lu
---
.../leds/backlight/kinetic,ktz8866.yaml | 36 +++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
new file mode 100644
index ..c63c21bf69d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktz8866.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kinetic Technologies KTZ8866 backlight
+
+maintainers:
+ - Jianhua Lu
+
+description: |
+ The Kinetic Technologies KTZ8866 is a high efficiency 6-sinks led backlight
+ with dual lcd bias power.
+ https://www.kinet-ic.com/ktz8866/
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+const: kinetic,ktz8866
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+backlight {
+compatible = "kinetic,ktz8866";
+
+pinctrl-names = "default";
+pinctrl-0 = <_en_default>;
+};
--
2.38.2
[PATCH v3 2/2] dt-bindings: leds: backlight: Add Kinetic KTZ8866 backlight
Add Kinetic KTZ8866 backlight binding documentation.
Signed-off-by: Jianhua Lu
Reviewed-by: Krzysztof Kozlowski
---
Changes in v2:
- Remove "items" between "compatible" and "const: kinetic,ktz8866"
- Change "additionalProperties" to "unevaluatedProperties"
Changes in v3:
- Add Krzysztof's R-b
.../leds/backlight/kinetic,ktz8866.yaml | 36 +++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
new file mode 100644
index ..c63c21bf69d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktz8866.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kinetic Technologies KTZ8866 backlight
+
+maintainers:
+ - Jianhua Lu
+
+description: |
+ The Kinetic Technologies KTZ8866 is a high efficiency 6-sinks led backlight
+ with dual lcd bias power.
+ https://www.kinet-ic.com/ktz8866/
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+const: kinetic,ktz8866
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+backlight {
+compatible = "kinetic,ktz8866";
+
+pinctrl-names = "default";
+pinctrl-0 = <_en_default>;
+};
--
2.38.2
[PATCH v3 4/7] media: renesas: vsp1: Add V4H SoC version
Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC. Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart --- drivers/media/platform/renesas/vsp1/vsp1_regs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h index 8c9333f76858..c61e8dafeecf 100644 --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h @@ -782,6 +782,7 @@ #define VI6_IP_VERSION_SOC_M3N (0x04 << 0) #define VI6_IP_VERSION_SOC_E3 (0x04 << 0) #define VI6_IP_VERSION_SOC_V3U (0x05 << 0) +#define VI6_IP_VERSION_SOC_V4H (0x06 << 0) /* RZ/G2L SoCs have no version register, So use 0x80 for SoC Identification */ #define VI6_IP_VERSION_SOC_RZG2L (0x80 << 0) -- 2.34.1
Re: [PATCH 2/4] dt-bindings: display: Add Himax HX8394 panel controller bindings
Hello Krzysztof, On 12/23/22 09:12, Krzysztof Kozlowski wrote: [...] > With three above: > > Reviewed-by: Krzysztof Kozlowski > Thanks a lot for the review! I'll fix the issues you pointed out in v2. > Best regards, > Krzysztof > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 2/4] dt-bindings: display: Add Himax HX8394 panel controller bindings
On 22/12/2022 23:38, Javier Martinez Canillas wrote: > Add device tree bindings for panels based on the Himax HX8394 controller, > such as the HannStar HSD060BHW4 720x1440 TFT LCD panel that is connected > through a MIPI-DSI video interface. Subject: drop second, redundant "bindings". > > Signed-off-by: Javier Martinez Canillas > --- > > .../bindings/display/panel/himax,hx8394.yaml | 68 +++ > 1 file changed, 68 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml > > diff --git > a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml > b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml > new file mode 100644 > index ..a8084e95f2fe > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml > @@ -0,0 +1,68 @@ > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/panel/himax,hx8394.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Himax HX8394 MIPI-DSI LCD panel controller device tree bindings Drop "device tree bindings" > + > +maintainers: > + - Javier Martinez Canillas > + > +description: > + Device tree bindings for panels based on the Himax HX8394 controller, > + such as the HannStar HSD060BHW4 720x1440 TFT LCD panel connected with > + a MIPI-DSI video interface. > + > +allOf: > + - $ref: panel-common.yaml# > + > +properties: > + compatible: > +enum: > + # HannStar HSD060BHW4 5.99" 720x1440 TFT LCD panel > + - hannstar,hsd060bhw4 > + > + port: true Put the port next to other "true" properties. > + reg: > +maxItems: 1 > +description: DSI virtual channel > + With three above: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
