Re: [PATCH v2 03/12] drm/rockchip: vop2: set half_block_en bit in all mode
Am Mittwoch, 22. November 2023, 13:54:13 CET schrieb Andy Yan:
> From: Andy Yan
>
> At first we thought the half_block_en bit in AFBCD_CTRL register
> only work in afbc mode. But the fact is that it control the line
> buffer in all mode(afbc/tile/line), so we need configure it in
> all case.
>
> Signed-off-by: Andy Yan
This looks common to the rk3568 variant, right, so I guess this should
have a
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
perhaps?
Heiko
Re: [PATCH v2 04/12] drm/rockchip: vop2: clear afbc en and transform bit for cluster window at linear mode
Am Mittwoch, 22. November 2023, 13:54:25 CET schrieb Andy Yan:
> From: Andy Yan
>
> The enable bit and transform offset of cluster windows should be
> cleared when it work at linear mode, or we may have a iommu fault
> issue.
>
> Signed-off-by: Andy Yan
I guess same here?
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Re: [PATCH 2/6] drm/bridge: tc358775: Fix getting dsi host data lanes
* Michael Walle [231127 14:31]: > + dt maintainers > > > > I actually have the same fix, but with one additional detail, which > > > I'm > > > unsure about though: This looks at the data-lanes property of the > > > *remote* > > > endpoint whereas other bridge drivers (see tc358767, ti-sn65dsi83, > > > lt8912b, > > > anx7625) look at the local endpoint and I'm not sure what is correct. > > > > Yes I've been wondering about that too. Let's just move it over to the > > bridge node? We could produce a warning if the dsi host node has the > > data-lanes property.. No current in kernel users AFAIK. > > I haven't found any in-tree users either. In my patch, I first try the > remote > end and then the local end. But thinking more about it I don't think > this is correct. Maybe we can do it the other way around, first try > data-lanes of the local endpoint and if not found, then try the remote > one. That way, we would at least be backwards compatible in the driver. > And for the dt-bindings, make it mandatory to have a local data-lanes. OK sounds good to me. Tony
Re: [PATCH] Revert "drm/sched: Qualify drm_sched_wakeup() by drm_sched_entity_is_ready()"
Hi Bert,
# The title of the patch should be:
drm/sched: Partial revert of "Qualify drm_sched_wakeup() by
drm_sched_entity_is_ready()"
On 2023-11-27 08:30, Bert Karwatzki wrote:
> Commit f3123c25 (in combination with the use of work queues by the gpu
Commit f3123c2590005c, in combination with the use of work queues by the GPU
scheduler, leads to random lock-ups of the GUI.
> scheduler) leads to random lock ups of the GUI [1,2].
>
> This is not a complete revert of commit f3123c25 as drm_sched_wakeup
This is a partial revert of of commit f3123c2590005c since drm_sched_wakeup()
> still needs its entity argument to pass it to drm_sched_can_queue.
... drm_sched_can_queue().
# Don't forget a SoB line!
Signed-off-by: Bert ...
>> [1] https://gitlab.freedesktop.org/drm/amd/-/issues/2994
# Use a Link: tag instead, like this:
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2994
> [2] https://lists.freedesktop.org/archives/dri-devel/2023-November/431606.html
# Use a Link: tag instead, like this:
Link: https://lists.freedesktop.org/archives/dri-devel/2023-November/431606.html
>
> This reverts commit f3123c2590005c5ff631653d31428e40cd10c618.
# The line above is *not* necessary, since this is a partial commit. Instead we
need
# a Fixes: line, like this:
Fixes: f3123c2590005c ("drm/sched: Qualify drm_sched_wakeup() by
drm_sched_entity_is_ready()")
###---
Then after you do "git format-patch", post it like this:
git send-email \
--in-reply-to=c5292d06-2e37-4715-96dc-699f36911...@gmail.com \
--to=ltuiko...@gmail.com \
--cc=christian.koe...@amd.com \
--cc=d...@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=matthew.br...@intel.com \
--cc=spassw...@web.de \
--cc=tvrtko.ursu...@intel.com \
/path/to/PATCH
This follows your thread where all the information is stored.
Thanks!
--
Regards,
Luben
OpenPGP_0x4C15479431A334AF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
[PATCH v2 17/32] fbdev/au1200fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig| 5 +
drivers/video/fbdev/au1200fb.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index de57bf59e0179..4c82890887ba1 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1457,10 +1457,7 @@ config FB_AU1100
config FB_AU1200
bool "Au1200/Au1300 LCD Driver"
depends on (FB = y) && MIPS_ALCHEMY
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_DMAMEM_HELPERS
help
This is the framebuffer driver for the Au1200/Au1300 SOCs.
It can drive various panels and CRTs by passing in kernel cmd line
diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index 817c1ebb625b6..16ebbab500972 100644
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1488,15 +1488,12 @@ static int au1200fb_ioctl(struct fb_info *info,
unsigned int cmd,
static const struct fb_ops au1200fb_fb_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_check_var = au1200fb_fb_check_var,
.fb_set_par = au1200fb_fb_set_par,
.fb_setcolreg = au1200fb_fb_setcolreg,
.fb_blank = au1200fb_fb_blank,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_DMAMEM_OPS_DRAW,
.fb_sync= NULL,
.fb_ioctl = au1200fb_ioctl,
.fb_mmap= au1200fb_fb_mmap,
--
2.43.0
[PATCH v2 12/32] fbdev/sh_mobile_lcdcfb: Set FBINFO_VIRTFB flag
The sh_mobile_lcdcfb driver operates on DMA-able system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/sh_mobile_lcdcfb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c index 1364dafaadb1d..5c99fc8a409fd 100644 --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c @@ -1567,6 +1567,7 @@ sh_mobile_lcdc_overlay_fb_init(struct sh_mobile_lcdc_overlay *ovl) info->fbops = _mobile_lcdc_overlay_ops; info->device = priv->dev; + info->flags |= FBINFO_VIRTFB; info->screen_buffer = ovl->fb_mem; info->par = ovl; @@ -2053,6 +2054,7 @@ sh_mobile_lcdc_channel_fb_init(struct sh_mobile_lcdc_chan *ch, info->fbops = _mobile_lcdc_ops; info->device = priv->dev; + info->flags |= FBINFO_VIRTFB; info->screen_buffer = ch->fb_mem; info->pseudo_palette = >pseudo_palette; info->par = ch; -- 2.43.0
[PATCH v2 29/32] fbdev: Push pgprot_decrypted() into mmap implementations
If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically
calls pgprot_decrypted(). But the default fb_mmap code doesn't handle
pgprot_decrypted().
Move the call to pgprot_decrypted() into each drivers' fb_mmap function.
This only concerns fb_mmap functions for system and DMA memory. For
I/O memory, which is the default case, nothing changes. The fb_mmap
for I/O-memory can later be moved into a helper as well.
DRM's fbdev emulation handles pgprot_decrypted() internally via the
Prime helpers. Fbdev doesn't have to do anything in this case. In
cases where DRM uses deferred I/O, this patch updates fb_mmap correctly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/auxdisplay/cfag12864bfb.c | 2 ++
drivers/auxdisplay/ht16k33.c | 2 ++
drivers/video/fbdev/amba-clcd.c| 2 ++
drivers/video/fbdev/au1100fb.c | 2 ++
drivers/video/fbdev/au1200fb.c | 2 ++
drivers/video/fbdev/core/fb_chrdev.c | 5 -
drivers/video/fbdev/core/fb_defio.c| 2 ++
drivers/video/fbdev/ep93xx-fb.c| 2 ++
drivers/video/fbdev/gbefb.c| 2 ++
drivers/video/fbdev/omap/omapfb_main.c | 2 ++
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 ++
drivers/video/fbdev/ps3fb.c| 2 ++
drivers/video/fbdev/sa1100fb.c | 2 ++
drivers/video/fbdev/sbuslib.c | 1 +
drivers/video/fbdev/sh_mobile_lcdcfb.c | 4
drivers/video/fbdev/smscufx.c | 2 ++
drivers/video/fbdev/udlfb.c| 2 ++
drivers/video/fbdev/vermilion/vermilion.c | 2 ++
drivers/video/fbdev/vfb.c | 2 ++
19 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/auxdisplay/cfag12864bfb.c
b/drivers/auxdisplay/cfag12864bfb.c
index ede0f9a513110..5ba19c339f088 100644
--- a/drivers/auxdisplay/cfag12864bfb.c
+++ b/drivers/auxdisplay/cfag12864bfb.c
@@ -51,6 +51,8 @@ static int cfag12864bfb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
{
struct page *pages = virt_to_page(cfag12864b_buffer);
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return vm_map_pages_zero(vma, , 1);
}
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index 2f1dc6b4e2765..a90430b7d07ba 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -351,6 +351,8 @@ static int ht16k33_mmap(struct fb_info *info, struct
vm_area_struct *vma)
struct ht16k33_priv *priv = info->par;
struct page *pages = virt_to_page(priv->fbdev.buffer);
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return vm_map_pages_zero(vma, , 1);
}
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 0399db369e709..47d373f04f3f0 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -829,6 +829,8 @@ static int clcdfb_of_dma_setup(struct clcd_fb *fb)
static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
{
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return dma_mmap_wc(>dev->dev, vma, fb->fb.screen_base,
fb->fb.fix.smem_start, fb->fb.fix.smem_len);
}
diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index a9c8d33a6ef71..08109ce535cd4 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -342,6 +342,8 @@ int au1100fb_fb_mmap(struct fb_info *fbi, struct
vm_area_struct *vma)
{
struct au1100fb_device *fbdev = to_au1100fb_device(fbi);
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
pgprot_val(vma->vm_page_prot) |= (6 << 9); //CCA=6
return dma_mmap_coherent(fbdev->dev, vma, fbdev->fb_mem, fbdev->fb_phys,
diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index 16ebbab500972..6f20efc663d7e 100644
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1236,6 +1236,8 @@ static int au1200fb_fb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
{
struct au1200fb_device *fbdev = info->par;
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return dma_mmap_coherent(fbdev->dev, vma,
fbdev->fb_mem, fbdev->fb_phys, fbdev->fb_len);
}
diff --git a/drivers/video/fbdev/core/fb_chrdev.c
b/drivers/video/fbdev/core/fb_chrdev.c
index 32a7315b4b6dd..b73a122950a94 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -325,11 +325,6 @@ static int fb_mmap(struct file *file, struct
vm_area_struct *vma)
if (info->fbops->fb_mmap) {
int res;
- /*
-* The framebuffer needs to be accessed decrypted, be sure
-* SME protection is removed ahead of
[PATCH v2 22/32] fbdev/vt8500lcdfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/vt8500lcdfb.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6fc43b40acac3..4e06e403d0217 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1467,6 +1467,7 @@ config FB_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
select FB_MODE_HELPERS
select VIDEOMODE_HELPERS
help
diff --git a/drivers/video/fbdev/vt8500lcdfb.c
b/drivers/video/fbdev/vt8500lcdfb.c
index 42d39a9d5130f..42c25dc851976 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -241,6 +241,7 @@ static int vt8500lcd_blank(int blank, struct fb_info *info)
static const struct fb_ops vt8500lcd_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_set_par = vt8500lcd_set_par,
.fb_setcolreg = vt8500lcd_setcolreg,
.fb_fillrect= wmt_ge_fillrect,
@@ -250,6 +251,7 @@ static const struct fb_ops vt8500lcd_ops = {
.fb_ioctl = vt8500lcd_ioctl,
.fb_pan_display = vt8500lcd_pan_display,
.fb_blank = vt8500lcd_blank,
+ // .fb_mmap needs DMA mmap
};
static irqreturn_t vt8500lcd_handle_irq(int irq, void *dev_id)
@@ -357,7 +359,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
fbi->fb.fix.smem_start = fb_mem_phys;
fbi->fb.fix.smem_len= fb_mem_len;
- fbi->fb.screen_base = fb_mem_virt;
+ fbi->fb.screen_buffer = fb_mem_virt;
fbi->palette_size = PAGE_ALIGN(512);
fbi->palette_cpu= dma_alloc_coherent(>dev,
--
2.43.0
[PATCH v2 08/32] auxdisplay/cfag12864bfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Miguel Ojeda
Reviewed-by: Javier Martinez Canillas
Acked-by: Miguel Ojeda
---
drivers/auxdisplay/Kconfig| 5 +
drivers/auxdisplay/cfag12864bfb.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index 64012cda4d126..4377e53f8f572 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -112,10 +112,7 @@ config CFAG12864B
depends on X86
depends on FB
depends on KS0108
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_SYSMEM_HELPERS
default n
help
If you have a Crystalfontz 128x64 2-color LCD, cfag12864b Series,
diff --git a/drivers/auxdisplay/cfag12864bfb.c
b/drivers/auxdisplay/cfag12864bfb.c
index c0ba693845aaf..ede0f9a513110 100644
--- a/drivers/auxdisplay/cfag12864bfb.c
+++ b/drivers/auxdisplay/cfag12864bfb.c
@@ -56,11 +56,8 @@ static int cfag12864bfb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
static const struct fb_ops cfag12864bfb_ops = {
.owner = THIS_MODULE,
- .fb_read = fb_sys_read,
- .fb_write = fb_sys_write,
- .fb_fillrect = sys_fillrect,
- .fb_copyarea = sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_SYSMEM_OPS_RDWR,
+ __FB_DEFAULT_SYSMEM_OPS_DRAW,
.fb_mmap = cfag12864bfb_mmap,
};
--
2.43.0
[PATCH v2 14/32] fbdev/smscufx: Select correct helpers
The driver uses deferred I/O. Select the correct helpers via FB_SYSMEM_HELPERS_DEFERRED in the Kconfig file. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 1eab89a07bbc5..d110d89b21d46 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -1683,11 +1683,7 @@ config FB_SMSCUFX tristate "SMSC UFX6000/7000 USB Framebuffer support" depends on FB && USB select FB_MODE_HELPERS - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO + select FB_SYSMEM_HELPERS_DEFERRED help This is a kernel framebuffer driver for SMSC UFX USB devices. Supports fbdev clients like xf86-video-fbdev, kdrive, fbi, and -- 2.43.0
[PATCH v2 26/32] staging/sm750fb: Initialize fb_ops with fbdev macros
Initialize all instances of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Greg Kroah-Hartman
Cc: linux-stag...@lists.linux.dev
Reviewed-by: Javier Martinez Canillas
---
drivers/staging/sm750fb/sm750.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 35098516f53c9..04c1b32a22c5e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -665,31 +665,28 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
static const struct fb_ops lynxfb_ops = {
.owner = THIS_MODULE,
+ FB_DEFAULT_IOMEM_OPS,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
.fb_blank = lynxfb_ops_blank,
.fb_pan_display = lynxfb_ops_pan_display,
- .fb_fillrect = cfb_fillrect,
- .fb_imageblit = cfb_imageblit,
- .fb_copyarea = cfb_copyarea,
};
static const struct fb_ops lynxfb_ops_with_cursor = {
.owner = THIS_MODULE,
+ FB_DEFAULT_IOMEM_OPS,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
.fb_blank = lynxfb_ops_blank,
.fb_pan_display = lynxfb_ops_pan_display,
- .fb_fillrect = cfb_fillrect,
- .fb_copyarea = cfb_copyarea,
- .fb_imageblit = cfb_imageblit,
.fb_cursor = lynxfb_ops_cursor,
};
static const struct fb_ops lynxfb_ops_accel = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_IOMEM_OPS_RDWR,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
@@ -698,10 +695,12 @@ static const struct fb_ops lynxfb_ops_accel = {
.fb_fillrect = lynxfb_ops_fillrect,
.fb_copyarea = lynxfb_ops_copyarea,
.fb_imageblit = lynxfb_ops_imageblit,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
static const struct fb_ops lynxfb_ops_accel_with_cursor = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_IOMEM_OPS_RDWR,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
@@ -711,6 +710,7 @@ static const struct fb_ops lynxfb_ops_accel_with_cursor = {
.fb_copyarea = lynxfb_ops_copyarea,
.fb_imageblit = lynxfb_ops_imageblit,
.fb_cursor = lynxfb_ops_cursor,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
static int lynxfb_set_fbinfo(struct fb_info *info, int index)
--
2.43.0
[PATCH v2 09/32] auxdisplay/ht16k33: Set FBINFO_VIRTFB flag
The ht16k33 driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Miguel Ojeda Cc: Robin van der Gracht Reviewed-by: Javier Martinez Canillas Acked-by: Miguel Ojeda Acked-by: Robin van der Gracht --- drivers/auxdisplay/ht16k33.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c index 3a2d883872249..f1716e3ce6a92 100644 --- a/drivers/auxdisplay/ht16k33.c +++ b/drivers/auxdisplay/ht16k33.c @@ -640,6 +640,7 @@ static int ht16k33_fbdev_probe(struct device *dev, struct ht16k33_priv *priv, INIT_DELAYED_WORK(>work, ht16k33_fb_update); fbdev->info->fbops = _fb_ops; + fbdev->info->flags |= FBINFO_VIRTFB; fbdev->info->screen_buffer = fbdev->buffer; fbdev->info->screen_size = HT16K33_FB_SIZE; fbdev->info->fix = ht16k33_fb_fix; -- 2.43.0
[PATCH v2 04/32] fbdev/vfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 5 +
drivers/video/fbdev/vfb.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 53693c826ebdd..63956382ffb65 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1800,10 +1800,7 @@ config FB_DA8XX
config FB_VIRTUAL
tristate "Virtual Frame Buffer support (ONLY FOR TESTING!)"
depends on FB
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_SYSMEM_HELPERS
help
This is a `virtual' frame buffer device. It operates on a chunk of
unswappable kernel memory instead of on the memory of a graphics
diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index c748b9311fb12..f6140f247e4b0 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -80,15 +80,12 @@ static int vfb_mmap(struct fb_info *info,
static const struct fb_ops vfb_ops = {
.owner = THIS_MODULE,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_SYSMEM_OPS_RDWR,
.fb_check_var = vfb_check_var,
.fb_set_par = vfb_set_par,
.fb_setcolreg = vfb_setcolreg,
.fb_pan_display = vfb_pan_display,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_SYSMEM_OPS_DRAW,
.fb_mmap= vfb_mmap,
};
--
2.43.0
[PATCH v2 31/32] fbdev: Warn on incorrect framebuffer access
Test in framebuffer read, write and drawing helpers if FBINFO_VIRTFB
has been set correctly. Framebuffers in I/O memory should only be
accessed with the architecture's respective helpers. Framebuffers
in system memory should be accessed with the regular load and
store operations. Presumably not all drivers get this right, so we
now warn about it.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/cfbcopyarea.c | 3 +++
drivers/video/fbdev/core/cfbfillrect.c | 3 +++
drivers/video/fbdev/core/cfbimgblt.c | 3 +++
drivers/video/fbdev/core/fb_io_fops.c | 9 +
drivers/video/fbdev/core/fb_sys_fops.c | 6 ++
drivers/video/fbdev/core/syscopyarea.c | 3 +++
drivers/video/fbdev/core/sysfillrect.c | 3 +++
drivers/video/fbdev/core/sysimgblt.c | 3 +++
include/linux/fb.h | 8 +++-
9 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/cfbcopyarea.c
b/drivers/video/fbdev/core/cfbcopyarea.c
index 5b80bf3dae504..a271f57d9c6c1 100644
--- a/drivers/video/fbdev/core/cfbcopyarea.c
+++ b/drivers/video/fbdev/core/cfbcopyarea.c
@@ -391,6 +391,9 @@ void cfb_copyarea(struct fb_info *p, const struct
fb_copyarea *area)
if (p->state != FBINFO_STATE_RUNNING)
return;
+ if (p->flags & FBINFO_VIRTFB)
+ fb_warn_once(p, "Framebuffer is not in I/O address space.");
+
/* if the beginning of the target area might overlap with the end of
the source area, be have to copy the area reverse. */
if ((dy == sy && dx > sx) || (dy > sy)) {
diff --git a/drivers/video/fbdev/core/cfbfillrect.c
b/drivers/video/fbdev/core/cfbfillrect.c
index ba9f58b2a5e86..cbaa4c9e2355a 100644
--- a/drivers/video/fbdev/core/cfbfillrect.c
+++ b/drivers/video/fbdev/core/cfbfillrect.c
@@ -287,6 +287,9 @@ void cfb_fillrect(struct fb_info *p, const struct
fb_fillrect *rect)
if (p->state != FBINFO_STATE_RUNNING)
return;
+ if (p->flags & FBINFO_VIRTFB)
+ fb_warn_once(p, "Framebuffer is not in I/O address space.");
+
if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
p->fix.visual == FB_VISUAL_DIRECTCOLOR )
fg = ((u32 *) (p->pseudo_palette))[rect->color];
diff --git a/drivers/video/fbdev/core/cfbimgblt.c
b/drivers/video/fbdev/core/cfbimgblt.c
index 9ebda4e0dc7ab..7d1d2f1a627dc 100644
--- a/drivers/video/fbdev/core/cfbimgblt.c
+++ b/drivers/video/fbdev/core/cfbimgblt.c
@@ -326,6 +326,9 @@ void cfb_imageblit(struct fb_info *p, const struct fb_image
*image)
if (p->state != FBINFO_STATE_RUNNING)
return;
+ if (p->flags & FBINFO_VIRTFB)
+ fb_warn_once(p, "Framebuffer is not in I/O address space.");
+
bitstart = (dy * p->fix.line_length * 8) + (dx * bpp);
start_index = bitstart & (32 - 1);
pitch_index = (p->fix.line_length & (bpl - 1)) * 8;
diff --git a/drivers/video/fbdev/core/fb_io_fops.c
b/drivers/video/fbdev/core/fb_io_fops.c
index 60805e43914e5..3408ff1b2b7a0 100644
--- a/drivers/video/fbdev/core/fb_io_fops.c
+++ b/drivers/video/fbdev/core/fb_io_fops.c
@@ -12,6 +12,9 @@ ssize_t fb_io_read(struct fb_info *info, char __user *buf,
size_t count, loff_t
int c, cnt = 0, err = 0;
unsigned long total_size, trailing;
+ if (info->flags & FBINFO_VIRTFB)
+ fb_warn_once(info, "Framebuffer is not in I/O address space.");
+
if (!info->screen_base)
return -ENODEV;
@@ -73,6 +76,9 @@ ssize_t fb_io_write(struct fb_info *info, const char __user
*buf, size_t count,
int c, cnt = 0, err = 0;
unsigned long total_size, trailing;
+ if (info->flags & FBINFO_VIRTFB)
+ fb_warn_once(info, "Framebuffer is not in I/O address space.");
+
if (!info->screen_base)
return -ENODEV;
@@ -138,6 +144,9 @@ int fb_io_mmap(struct fb_info *info, struct vm_area_struct
*vma)
u32 len = info->fix.smem_len;
unsigned long mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >>
PAGE_SHIFT;
+ if (info->flags & FBINFO_VIRTFB)
+ fb_warn_once(info, "Framebuffer is not in I/O address space.");
+
/*
* This can be either the framebuffer mapping, or if pgoff points
* past it, the mmio mapping.
diff --git a/drivers/video/fbdev/core/fb_sys_fops.c
b/drivers/video/fbdev/core/fb_sys_fops.c
index 0cb0989abda61..a9aa6519a5b30 100644
--- a/drivers/video/fbdev/core/fb_sys_fops.c
+++ b/drivers/video/fbdev/core/fb_sys_fops.c
@@ -22,6 +22,9 @@ ssize_t fb_sys_read(struct fb_info *info, char __user *buf,
size_t count,
unsigned long total_size, c;
ssize_t ret;
+ if (!(info->flags & FBINFO_VIRTFB))
+ fb_warn_once(info, "Framebuffer is not in virtual address
space.");
+
if (!info->screen_buffer)
return -ENODEV;
@@ -64,6 +67,9 @@ ssize_t fb_sys_write(struct
[PATCH v2 02/32] fbdev/sm712fb: Use correct initializer macros for struct fb_ops
Only initialize mmap and draw helpers with macros; leave read/write
callbacks to driver implementations. Fixes the following warnings:
CC [M] drivers/video/fbdev/sm712fb.o
sm712fb.c:1355:25: warning: initialized field overwritten [-Woverride-init]
1355 | .fb_fillrect = cfb_fillrect,
| ^~~~
sm712fb.c:1355:25: note: (near initialization for 'smtcfb_ops.fb_fillrect')
sm712fb.c:1356:25: warning: initialized field overwritten [-Woverride-init]
1356 | .fb_imageblit = cfb_imageblit,
| ^
sm712fb.c:1356:25: note: (near initialization for 'smtcfb_ops.fb_imageblit')
sm712fb.c:1357:25: warning: initialized field overwritten [-Woverride-init]
1357 | .fb_copyarea = cfb_copyarea,
| ^~~~
sm712fb.c:1357:25: note: (near initialization for 'smtcfb_ops.fb_copyarea')
sm712fb.c:1358:25: warning: initialized field overwritten [-Woverride-init]
1358 | .fb_read = smtcfb_read,
| ^~~
sm712fb.c:1358:25: note: (near initialization for 'smtcfb_ops.fb_read')
sm712fb.c:1359:25: warning: initialized field overwritten [-Woverride-init]
1359 | .fb_write = smtcfb_write,
| ^~~~
sm712fb.c:1359:25: note: (near initialization for 'smtcfb_ops.fb_write')
Signed-off-by: Thomas Zimmermann
Fixes: 586132cf1d38 ("fbdev/sm712fb: Initialize fb_ops to fbdev I/O-memory
helpers")
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: Arnd Bergmann
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/sm712fb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
index 3f8ef50e32095..104f122e0f273 100644
--- a/drivers/video/fbdev/sm712fb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -1347,16 +1347,14 @@ static int smtc_set_par(struct fb_info *info)
static const struct fb_ops smtcfb_ops = {
.owner= THIS_MODULE,
- FB_DEFAULT_IOMEM_OPS,
.fb_check_var = smtc_check_var,
.fb_set_par = smtc_set_par,
.fb_setcolreg = smtc_setcolreg,
.fb_blank = smtc_blank,
- .fb_fillrect = cfb_fillrect,
- .fb_imageblit = cfb_imageblit,
- .fb_copyarea = cfb_copyarea,
+ __FB_DEFAULT_IOMEM_OPS_DRAW,
.fb_read = smtcfb_read,
.fb_write = smtcfb_write,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
/*
--
2.43.0
[PATCH v2 05/32] fbdev/arcfb: Set FBINFO_VIRTFB flag
The arcfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Jaya Kumar Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/arcfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c index cff11cb04a551..7344e825543af 100644 --- a/drivers/video/fbdev/arcfb.c +++ b/drivers/video/fbdev/arcfb.c @@ -529,6 +529,7 @@ static int arcfb_probe(struct platform_device *dev) if (!info) goto err_fb_alloc; + info->flags |= FBINFO_VIRTFB; info->screen_buffer = videomemory; info->fbops = _ops; -- 2.43.0
[PATCH v2 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag
The picolcd_fb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: "Bruno Prémont" Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-in...@vger.kernel.org Reviewed-by: Javier Martinez Canillas Acked-by: Bruno Prémont Acked-by: Jiri Kosina --- drivers/hid/hid-picolcd_fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c index a4dccdcda26fc..d799d325e 100644 --- a/drivers/hid/hid-picolcd_fb.c +++ b/drivers/hid/hid-picolcd_fb.c @@ -505,6 +505,7 @@ int picolcd_init_framebuffer(struct picolcd_data *data) dev_err(dev, "can't get a free page for framebuffer\n"); goto err_nomem; } + info->flags |= FBINFO_VIRTFB; info->screen_buffer = fbdata->bitmap; info->fix.smem_start = (unsigned long)fbdata->bitmap; memset(fbdata->vbitmap, 0xff, PICOLCDFB_SIZE); -- 2.43.0
[PATCH v2 18/32] fbdev/ps3fb: Set FBINFO_VIRTFB flag
The ps3fb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: linuxppc-...@lists.ozlabs.org Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/ps3fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c index 64d291d6b1532..de81ad3a5d1ed 100644 --- a/drivers/video/fbdev/ps3fb.c +++ b/drivers/video/fbdev/ps3fb.c @@ -1145,7 +1145,7 @@ static int ps3fb_probe(struct ps3_system_bus_device *dev) info->fix.smem_len = ps3fb_videomemory.size - GPU_FB_START; info->pseudo_palette = par->pseudo_palette; - info->flags = FBINFO_READS_FAST | + info->flags = FBINFO_VIRTFB | FBINFO_READS_FAST | FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN; retval = fb_alloc_cmap(>cmap, 256, 0); -- 2.43.0
[PATCH v2 25/32] staging/sm750fb: Declare fb_ops as constant
Split up lynxfb_ops and declare each as constant. The fb_ops
instance used to be modified while initializing the driver. It is
now constant and the driver picks the correct instance, depending
on the settings for acceleration and cursor support.
Signed-off-by: Thomas Zimmermann
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Greg Kroah-Hartman
Cc: linux-stag...@lists.linux.dev
Acked-by: Javier Martinez Canillas
---
drivers/staging/sm750fb/sm750.c | 59 +++--
1 file changed, 49 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 79bcd5bd49380..35098516f53c9 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -663,16 +663,53 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
return ret;
}
-static struct fb_ops lynxfb_ops = {
+static const struct fb_ops lynxfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
.fb_blank = lynxfb_ops_blank,
+ .fb_pan_display = lynxfb_ops_pan_display,
.fb_fillrect = cfb_fillrect,
.fb_imageblit = cfb_imageblit,
.fb_copyarea = cfb_copyarea,
- /* cursor */
+};
+
+static const struct fb_ops lynxfb_ops_with_cursor = {
+ .owner = THIS_MODULE,
+ .fb_check_var = lynxfb_ops_check_var,
+ .fb_set_par = lynxfb_ops_set_par,
+ .fb_setcolreg = lynxfb_ops_setcolreg,
+ .fb_blank = lynxfb_ops_blank,
+ .fb_pan_display = lynxfb_ops_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+ .fb_cursor = lynxfb_ops_cursor,
+};
+
+static const struct fb_ops lynxfb_ops_accel = {
+ .owner = THIS_MODULE,
+ .fb_check_var = lynxfb_ops_check_var,
+ .fb_set_par = lynxfb_ops_set_par,
+ .fb_setcolreg = lynxfb_ops_setcolreg,
+ .fb_blank = lynxfb_ops_blank,
+ .fb_pan_display = lynxfb_ops_pan_display,
+ .fb_fillrect = lynxfb_ops_fillrect,
+ .fb_copyarea = lynxfb_ops_copyarea,
+ .fb_imageblit = lynxfb_ops_imageblit,
+};
+
+static const struct fb_ops lynxfb_ops_accel_with_cursor = {
+ .owner = THIS_MODULE,
+ .fb_check_var = lynxfb_ops_check_var,
+ .fb_set_par = lynxfb_ops_set_par,
+ .fb_setcolreg = lynxfb_ops_setcolreg,
+ .fb_blank = lynxfb_ops_blank,
+ .fb_pan_display = lynxfb_ops_pan_display,
+ .fb_fillrect = lynxfb_ops_fillrect,
+ .fb_copyarea = lynxfb_ops_copyarea,
+ .fb_imageblit = lynxfb_ops_imageblit,
.fb_cursor = lynxfb_ops_cursor,
};
@@ -714,7 +751,6 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int
index)
par->index = index;
output->channel = >channel;
sm750fb_set_drv(par);
- lynxfb_ops.fb_pan_display = lynxfb_ops_pan_display;
/*
* set current cursor variable and proc pointer,
@@ -731,19 +767,22 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int
index)
crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
- if (!g_hwcursor) {
- lynxfb_ops.fb_cursor = NULL;
+ if (!g_hwcursor)
sm750_hw_cursor_disable(>cursor);
- }
/* set info->fbops, must be set before fb_find_mode */
if (!sm750_dev->accel_off) {
/* use 2d acceleration */
- lynxfb_ops.fb_fillrect = lynxfb_ops_fillrect;
- lynxfb_ops.fb_copyarea = lynxfb_ops_copyarea;
- lynxfb_ops.fb_imageblit = lynxfb_ops_imageblit;
+ if (!g_hwcursor)
+ info->fbops = _ops_accel;
+ else
+ info->fbops = _ops_accel_with_cursor;
+ } else {
+ if (!g_hwcursor)
+ info->fbops = _ops;
+ else
+ info->fbops = _ops_with_cursor;
}
- info->fbops = _ops;
if (!g_fbmode[index]) {
g_fbmode[index] = g_def_fbmode;
--
2.43.0
[PATCH v2 10/32] auxdisplay/ht16k33: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Miguel Ojeda
Cc: Robin van der Gracht
Reviewed-by: Javier Martinez Canillas
Acked-by: Miguel Ojeda
Reviewed-by: Robin van der Gracht
---
drivers/auxdisplay/Kconfig | 5 +
drivers/auxdisplay/ht16k33.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index 4377e53f8f572..d944d5298eca8 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -167,10 +167,7 @@ config IMG_ASCII_LCD
config HT16K33
tristate "Holtek Ht16K33 LED controller with keyscan"
depends on FB && I2C && INPUT
- select FB_SYS_FOPS
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
+ select FB_SYSMEM_HELPERS
select INPUT_MATRIXKMAP
select FB_BACKLIGHT
select NEW_LEDS
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index f1716e3ce6a92..2f1dc6b4e2765 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -356,12 +356,9 @@ static int ht16k33_mmap(struct fb_info *info, struct
vm_area_struct *vma)
static const struct fb_ops ht16k33_fb_ops = {
.owner = THIS_MODULE,
- .fb_read = fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_SYSMEM_OPS_RDWR,
.fb_blank = ht16k33_blank,
- .fb_fillrect = sys_fillrect,
- .fb_copyarea = sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_SYSMEM_OPS_DRAW,
.fb_mmap = ht16k33_mmap,
};
--
2.43.0
[PATCH v2 00/32] fbdev: Modularize helpers for struct fb_ops
Convert the remaining fbdev drivers to use fbdev's helpers macros for struct fb_ops. Then push the current default code for file-I/O operations into a module and remove it as default. Each driver now selects the helpers its needs for file I/O and drawing to its framebuffer. If no helper has been set for an operation in struct fb_ops, the operation is unsupported. Once applied, fbdev drivers will not include unnecessary helper code. The helpers will also be more robust against mis-use. The first 2 patches are bug fixes. Patches 3 to 26 modify fbdev drivers to set up their fb_ops structures correctly and select the necessary helpers. Patches 27 and 28 do a few additional minor cleanups. Patches 29 to 32 move all helpers for struct fb_ops into modules and drop the default. Helpers also warn if they operate on the wrong type of framebuffer memory. Framebuffers in I/O memory and system memory can only be used with the correct helper functions. v2: * warn once if I/O callbacks are missing (Javier) Thomas Zimmermann (32): fbdev/acornfb: Fix name of fb_ops initializer macro fbdev/sm712fb: Use correct initializer macros for struct fb_ops fbdev/vfb: Set FBINFO_VIRTFB flag fbdev/vfb: Initialize fb_ops with fbdev macros fbdev/arcfb: Set FBINFO_VIRTFB flag fbdev/arcfb: Use generator macros for deferred I/O auxdisplay/cfag12864bfb: Set FBINFO_VIRTFB flag auxdisplay/cfag12864bfb: Initialize fb_ops with fbdev macros auxdisplay/ht16k33: Set FBINFO_VIRTFB flag auxdisplay/ht16k33: Initialize fb_ops with fbdev macros hid/picolcd_fb: Set FBINFO_VIRTFB flag fbdev/sh_mobile_lcdcfb: Set FBINFO_VIRTFB flag fbdev/sh_mobile_lcdcfb: Initialize fb_ops with fbdev macros fbdev/smscufx: Select correct helpers fbdev/udlfb: Select correct helpers fbdev/au1200fb: Set FBINFO_VIRTFB flag fbdev/au1200fb: Initialize fb_ops with fbdev macros fbdev/ps3fb: Set FBINFO_VIRTFB flag fbdev/ps3fb: Initialize fb_ops with fbdev macros media/ivtvfb: Initialize fb_ops to fbdev I/O-memory helpers fbdev/clps711x-fb: Initialize fb_ops with fbdev macros fbdev/vt8500lcdfb: Initialize fb_ops with fbdev macros fbdev/wm8505fb: Initialize fb_ops to fbdev I/O-memory helpers fbdev/cyber2000fb: Initialize fb_ops with fbdev macros staging/sm750fb: Declare fb_ops as constant staging/sm750fb: Initialize fb_ops with fbdev macros fbdev: Rename FB_SYS_FOPS token to FB_SYSMEM_FOPS fbdev: Remove trailing whitespaces fbdev: Push pgprot_decrypted() into mmap implementations fbdev: Move default fb_mmap code into helper function fbdev: Warn on incorrect framebuffer access fbdev: Remove default file-I/O implementations drivers/auxdisplay/Kconfig| 10 +- drivers/auxdisplay/cfag12864bfb.c | 10 +- drivers/auxdisplay/ht16k33.c | 10 +- drivers/hid/hid-picolcd_fb.c | 1 + drivers/media/pci/ivtv/Kconfig| 4 +- drivers/media/pci/ivtv/ivtvfb.c | 6 +- drivers/staging/sm750fb/sm750.c | 65 -- drivers/video/fbdev/Kconfig | 50 ++-- drivers/video/fbdev/acornfb.c | 2 +- drivers/video/fbdev/amba-clcd.c | 2 + drivers/video/fbdev/arcfb.c | 114 +- drivers/video/fbdev/au1100fb.c| 2 + drivers/video/fbdev/au1200fb.c| 11 +- drivers/video/fbdev/clps711x-fb.c | 4 +- drivers/video/fbdev/core/Kconfig | 7 +- drivers/video/fbdev/core/Makefile | 2 +- drivers/video/fbdev/core/cfbcopyarea.c| 3 + drivers/video/fbdev/core/cfbfillrect.c| 3 + drivers/video/fbdev/core/cfbimgblt.c | 3 + drivers/video/fbdev/core/fb_chrdev.c | 68 ++- drivers/video/fbdev/core/fb_defio.c | 2 + drivers/video/fbdev/core/fb_io_fops.c | 36 ++ drivers/video/fbdev/core/fb_sys_fops.c| 6 + drivers/video/fbdev/core/syscopyarea.c| 3 + drivers/video/fbdev/core/sysfillrect.c| 3 + drivers/video/fbdev/core/sysimgblt.c | 3 + drivers/video/fbdev/cyber2000fb.c | 9 +- drivers/video/fbdev/ep93xx-fb.c | 2 + drivers/video/fbdev/gbefb.c | 2 + drivers/video/fbdev/omap/omapfb_main.c| 2 + .../video/fbdev/omap2/omapfb/omapfb-main.c| 2 + drivers/video/fbdev/ps3fb.c | 11 +- drivers/video/fbdev/sa1100fb.c| 2 + drivers/video/fbdev/sbuslib.c | 5 +- drivers/video/fbdev/sh_mobile_lcdcfb.c| 16 +-- drivers/video/fbdev/sm712fb.c | 6 +- drivers/video/fbdev/smscufx.c | 2 + drivers/video/fbdev/udlfb.c | 2 + drivers/video/fbdev/vermilion/vermilion.c | 2 + drivers/video/fbdev/vfb.c | 10 +- drivers/video/fbdev/vt8500lcdfb.c | 4 +-
[PATCH v2 30/32] fbdev: Move default fb_mmap code into helper function
Move the default fb_mmap code for I/O address spaces into the helper
function fb_io_mmap(). The helper can either be called via struct
fb_ops.fb_mmap or as the default if no fb_mmap has been set. Also
set the new helper in __FB_DEFAULT_IOMEM_OPS_MMAP.
In the mid-term, fb_io_mmap() is supposed to become optional. Fbdev
drivers will initialize their struct fb_ops.fb_mmap to the helper
and select a corresponding Kconfig token. The helper can then be made
optional at compile time.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fb_chrdev.c | 36 +--
drivers/video/fbdev/core/fb_io_fops.c | 27
include/linux/fb.h| 3 ++-
3 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_chrdev.c
b/drivers/video/fbdev/core/fb_chrdev.c
index b73a122950a94..089441c9d810f 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -314,20 +314,16 @@ static long fb_compat_ioctl(struct file *file, unsigned
int cmd,
static int fb_mmap(struct file *file, struct vm_area_struct *vma)
{
struct fb_info *info = file_fb_info(file);
- unsigned long mmio_pgoff;
- unsigned long start;
- u32 len;
+ int res;
if (!info)
return -ENODEV;
+
mutex_lock(>mm_lock);
if (info->fbops->fb_mmap) {
- int res;
res = info->fbops->fb_mmap(info, vma);
- mutex_unlock(>mm_lock);
- return res;
#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
} else if (info->fbdefio) {
/*
@@ -335,35 +331,15 @@ static int fb_mmap(struct file *file, struct
vm_area_struct *vma)
* minimum, point struct fb_ops.fb_mmap to
fb_deferred_io_mmap().
*/
dev_warn_once(info->dev, "fbdev mmap not set up for deferred
I/O.\n");
- mutex_unlock(>mm_lock);
- return -ENODEV;
+ res = -ENODEV;
#endif
+ } else {
+ res = fb_io_mmap(info, vma);
}
- /*
-* Ugh. This can be either the frame buffer mapping, or
-* if pgoff points past it, the mmio mapping.
-*/
- start = info->fix.smem_start;
- len = info->fix.smem_len;
- mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
- if (vma->vm_pgoff >= mmio_pgoff) {
- if (info->var.accel_flags) {
- mutex_unlock(>mm_lock);
- return -EINVAL;
- }
-
- vma->vm_pgoff -= mmio_pgoff;
- start = info->fix.mmio_start;
- len = info->fix.mmio_len;
- }
mutex_unlock(>mm_lock);
- vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
- vma->vm_page_prot = pgprot_framebuffer(vma->vm_page_prot, vma->vm_start,
- vma->vm_end, start);
-
- return vm_iomap_memory(vma, start, len);
+ return res;
}
static int fb_open(struct inode *inode, struct file *file)
diff --git a/drivers/video/fbdev/core/fb_io_fops.c
b/drivers/video/fbdev/core/fb_io_fops.c
index 871b829521af3..60805e43914e5 100644
--- a/drivers/video/fbdev/core/fb_io_fops.c
+++ b/drivers/video/fbdev/core/fb_io_fops.c
@@ -132,5 +132,32 @@ ssize_t fb_io_write(struct fb_info *info, const char
__user *buf, size_t count,
}
EXPORT_SYMBOL(fb_io_write);
+int fb_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ unsigned long start = info->fix.smem_start;
+ u32 len = info->fix.smem_len;
+ unsigned long mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >>
PAGE_SHIFT;
+
+ /*
+* This can be either the framebuffer mapping, or if pgoff points
+* past it, the mmio mapping.
+*/
+ if (vma->vm_pgoff >= mmio_pgoff) {
+ if (info->var.accel_flags)
+ return -EINVAL;
+
+ vma->vm_pgoff -= mmio_pgoff;
+ start = info->fix.mmio_start;
+ len = info->fix.mmio_len;
+ }
+
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ vma->vm_page_prot = pgprot_framebuffer(vma->vm_page_prot, vma->vm_start,
+ vma->vm_end, start);
+
+ return vm_iomap_memory(vma, start, len);
+}
+EXPORT_SYMBOL(fb_io_mmap);
+
MODULE_DESCRIPTION("Fbdev helpers for framebuffers in I/O memory");
MODULE_LICENSE("GPL");
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 94e2c44c65699..a36d05b576b0c 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -536,6 +536,7 @@ extern ssize_t fb_io_read(struct fb_info *info, char __user
*buf,
size_t count, loff_t *ppos);
extern ssize_t fb_io_write(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos);
+int
[PATCH v2 32/32] fbdev: Remove default file-I/O implementations
Drop the default implementations for file read, write and mmap
operations. Each fbdev driver must now provide an implementation
and select any necessary helpers. If no implementation has been
set, fbdev returns an errno code to user space. The code is the
same as if the operation had not been set in the file_operations
struct.
This change makes the fbdev helpers for I/O memory optional. Most
systems only use system-memory framebuffers via DRM's fbdev emulation.
v2:
* warn once if I/O callbacks are missing (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/Kconfig | 1 -
drivers/video/fbdev/core/fb_chrdev.c | 37 +---
include/linux/fb.h | 5
3 files changed, 17 insertions(+), 26 deletions(-)
diff --git a/drivers/video/fbdev/core/Kconfig b/drivers/video/fbdev/core/Kconfig
index faab5d50cac3c..21053bf00dc58 100644
--- a/drivers/video/fbdev/core/Kconfig
+++ b/drivers/video/fbdev/core/Kconfig
@@ -4,7 +4,6 @@
#
config FB_CORE
- select FB_IOMEM_FOPS
select VIDEO_CMDLINE
tristate
diff --git a/drivers/video/fbdev/core/fb_chrdev.c
b/drivers/video/fbdev/core/fb_chrdev.c
index 089441c9d810f..4ebd16b7e3b8d 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -34,13 +34,13 @@ static ssize_t fb_read(struct file *file, char __user *buf,
size_t count, loff_t
if (!info)
return -ENODEV;
+ if (fb_WARN_ON_ONCE(info, !info->fbops->fb_read))
+ return -EINVAL;
+
if (info->state != FBINFO_STATE_RUNNING)
return -EPERM;
- if (info->fbops->fb_read)
- return info->fbops->fb_read(info, buf, count, ppos);
-
- return fb_io_read(info, buf, count, ppos);
+ return info->fbops->fb_read(info, buf, count, ppos);
}
static ssize_t fb_write(struct file *file, const char __user *buf, size_t
count, loff_t *ppos)
@@ -50,13 +50,13 @@ static ssize_t fb_write(struct file *file, const char
__user *buf, size_t count,
if (!info)
return -ENODEV;
+ if (fb_WARN_ON_ONCE(info, !info->fbops->fb_write))
+ return -EINVAL;
+
if (info->state != FBINFO_STATE_RUNNING)
return -EPERM;
- if (info->fbops->fb_write)
- return info->fbops->fb_write(info, buf, count, ppos);
-
- return fb_io_write(info, buf, count, ppos);
+ return info->fbops->fb_write(info, buf, count, ppos);
}
static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
@@ -319,24 +319,11 @@ static int fb_mmap(struct file *file, struct
vm_area_struct *vma)
if (!info)
return -ENODEV;
- mutex_lock(>mm_lock);
-
- if (info->fbops->fb_mmap) {
-
- res = info->fbops->fb_mmap(info, vma);
-#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
- } else if (info->fbdefio) {
- /*
-* FB deferred I/O wants you to handle mmap in your drivers. At
a
-* minimum, point struct fb_ops.fb_mmap to
fb_deferred_io_mmap().
-*/
- dev_warn_once(info->dev, "fbdev mmap not set up for deferred
I/O.\n");
- res = -ENODEV;
-#endif
- } else {
- res = fb_io_mmap(info, vma);
- }
+ if (fb_WARN_ON_ONCE(info, !info->fbops->fb_mmap))
+ return -ENODEV;
+ mutex_lock(>mm_lock);
+ res = info->fbops->fb_mmap(info, vma);
mutex_unlock(>mm_lock);
return res;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 24f0ec3662352..05dc9624897df 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -867,4 +867,9 @@ static inline bool fb_modesetting_disabled(const char
*drvname)
#define fb_warn_once(fb_info, fmt, ...)
\
pr_warn_once("fb%d: " fmt, (fb_info)->node, ##__VA_ARGS__)
+#define fb_WARN_ONCE(fb_info, condition, fmt, ...) \
+ WARN_ONCE(condition, "fb%d: " fmt, (fb_info)->node, ##__VA_ARGS__)
+#define fb_WARN_ON_ONCE(fb_info, x) \
+ fb_WARN_ONCE(fb_info, (x), "%s", "fb_WARN_ON_ONCE(" __stringify(x) ")")
+
#endif /* _LINUX_FB_H */
--
2.43.0
[PATCH v2 28/32] fbdev: Remove trailing whitespaces
Fix coding style. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/sbuslib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c index 21e9fd8e69e26..4d524db5c4f26 100644 --- a/drivers/video/fbdev/sbuslib.c +++ b/drivers/video/fbdev/sbuslib.c @@ -48,7 +48,7 @@ int sbusfb_mmap_helper(struct sbus_mmap_map *map, unsigned long map_offset = 0; unsigned long off; int i; - + if (!(vma->vm_flags & (VM_SHARED | VM_MAYSHARE))) return -EINVAL; @@ -72,7 +72,7 @@ int sbusfb_mmap_helper(struct sbus_mmap_map *map, #define POFF_MASK (PAGE_MASK|0x1UL) #else #define POFF_MASK (PAGE_MASK) -#endif +#endif map_offset = (physbase + map[i].poff) & POFF_MASK; break; } -- 2.43.0
[PATCH v2 24/32] fbdev/cyber2000fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 5 +
drivers/video/fbdev/cyber2000fb.c | 9 +
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 004a63cdea5a3..37c8188752baf 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -178,10 +178,7 @@ config FB_IMX
config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
depends on FB && PCI && (BROKEN || !SPARC64)
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- select FB_IOMEM_FOPS
+ select FB_IOMEM_HELPERS
select VIDEO_NOMODESET
help
This enables support for the Integraphics CyberPro 20x0 and 5000
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/drivers/video/fbdev/cyber2000fb.c
index 52105dc1a72f3..abb87d3576db0 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -227,13 +227,6 @@ cyber2000fb_copyarea(struct fb_info *info, const struct
fb_copyarea *region)
CO_REG_CMD_H, cfb);
}
-static void
-cyber2000fb_imageblit(struct fb_info *info, const struct fb_image *image)
-{
- cfb_imageblit(info, image);
- return;
-}
-
static int cyber2000fb_sync(struct fb_info *info)
{
struct cfb_info *cfb = container_of(info, struct cfb_info, fb);
@@ -1069,7 +1062,7 @@ static const struct fb_ops cyber2000fb_ops = {
.fb_pan_display = cyber2000fb_pan_display,
.fb_fillrect= cyber2000fb_fillrect,
.fb_copyarea= cyber2000fb_copyarea,
- .fb_imageblit = cyber2000fb_imageblit,
+ .fb_imageblit = cfb_imageblit,
.fb_sync= cyber2000fb_sync,
__FB_DEFAULT_IOMEM_OPS_MMAP,
};
--
2.43.0
[PATCH v2 23/32] fbdev/wm8505fb: Initialize fb_ops to fbdev I/O-memory helpers
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able address space. This explictily
sets the read/write, draw and mmap callbacks to the correct default
implementation. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation to be invoked; hence requireing the I/O
helpers to be built in any case. Setting all callbacks in all
drivers explicitly will allow to make the I/O helpers optional.
This benefits systems that do not use these functions.
Set the callbacks via macros. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig| 1 +
drivers/video/fbdev/wm8505fb.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4e06e403d0217..004a63cdea5a3 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1480,6 +1480,7 @@ config FB_WM8505
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
select FB_MODE_HELPERS
select VIDEOMODE_HELPERS
help
diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
index 5833147aa43d1..00952e9c88028 100644
--- a/drivers/video/fbdev/wm8505fb.c
+++ b/drivers/video/fbdev/wm8505fb.c
@@ -248,6 +248,7 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
static const struct fb_ops wm8505fb_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_set_par = wm8505fb_set_par,
.fb_setcolreg = wm8505fb_setcolreg,
.fb_fillrect= wmt_ge_fillrect,
@@ -256,6 +257,7 @@ static const struct fb_ops wm8505fb_ops = {
.fb_sync= wmt_ge_sync,
.fb_pan_display = wm8505fb_pan_display,
.fb_blank = wm8505fb_blank,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
static int wm8505fb_probe(struct platform_device *pdev)
--
2.43.0
[PATCH v2 01/32] fbdev/acornfb: Fix name of fb_ops initializer macro
Fix build by using the correct name for the initializer macro
for struct fb_ops.
Signed-off-by: Thomas Zimmermann
Fixes: 9037afde8b9d ("fbdev/acornfb: Use fbdev I/O helpers")
Cc: Thomas Zimmermann
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: Javier Martinez Canillas
Cc: Arnd Bergmann
Cc: # v6.6+
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/acornfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/acornfb.c b/drivers/video/fbdev/acornfb.c
index 163d2c9f951c3..f0600f6ca2548 100644
--- a/drivers/video/fbdev/acornfb.c
+++ b/drivers/video/fbdev/acornfb.c
@@ -605,7 +605,7 @@ acornfb_pan_display(struct fb_var_screeninfo *var, struct
fb_info *info)
static const struct fb_ops acornfb_ops = {
.owner = THIS_MODULE,
- FB_IOMEM_DEFAULT_OPS,
+ FB_DEFAULT_IOMEM_OPS,
.fb_check_var = acornfb_check_var,
.fb_set_par = acornfb_set_par,
.fb_setcolreg = acornfb_setcolreg,
--
2.43.0
[PATCH v2 03/32] fbdev/vfb: Set FBINFO_VIRTFB flag
The vfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/vfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c index 1b7c338f99560..c748b9311fb12 100644 --- a/drivers/video/fbdev/vfb.c +++ b/drivers/video/fbdev/vfb.c @@ -440,6 +440,7 @@ static int vfb_probe(struct platform_device *dev) if (!info) goto err; + info->flags |= FBINFO_VIRTFB; info->screen_buffer = videomemory; info->fbops = _ops; -- 2.43.0
Re: (subset) [PATCH 00/31] Fix and improve Rockchip RK3128 support
On Tue, 29 Aug 2023 19:16:16 +0200, Alex Bee wrote: > this series fixes some issues I found when testing my "new" RK3128 board > with the mainline kernel and adds some core functionality like SMP bringup, > usb and networking. > > The propably most distinctive change is the split up of the DTs for the > different SoCs of this platform: RK3126 and RK3128. Even if I'm not adding > a RK3126 board in this series: I think this change should be done as early > as possible in order to avoid issues in future. > Actually it should have been done like that in the first place. > > [...] Applied, thanks! [08/31] phy: rockchip-inno-usb2: Split ID interrupt phy registers commit: 2fda59099462ee700e424ba3ac928d13ad6389a8 [09/31] phy: phy-rockchip-inno-usb2: Add RK3128 support commit: 62ff41017e147472b07de6125c3be82ce02a8dd7 Best regards, -- ~Vinod
Re: (subset) [PATCH v9 00/12] drm/meson: add support for MIPI DSI Display
On Fri, 24 Nov 2023 09:41:11 +0100, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > [...] Applied, thanks! [03/12] dt-bindings: phy: amlogic,meson-axg-mipi-pcie-analog: drop text about parent syscon and drop example commit: 130601d488fa06447283767e447909ce9e975e43 [04/12] dt-bindings: phy: amlogic,g12a-mipi-dphy-analog: drop unneeded reg property and example commit: 5f4a9a66f8a7582e90311fa8251da33a8d2111d7 Best regards, -- ~Vinod
Re: [PATCH] phy: mediatek: mipi: mt8183: fix minimal supported frequency
On Thu, 23 Nov 2023 12:02:02 +0100, Michael Walle wrote: > The lowest supported clock frequency of the PHY is 125MHz (see also > mtk_mipi_tx_pll_enable()), but the clamping in .round_rate() has the > wrong minimal value, which will make the .enable() op return -EINVAL on > low frequencies. Fix the minimal clamping value. > > Applied, thanks! [1/1] phy: mediatek: mipi: mt8183: fix minimal supported frequency commit: 06f76e464ac81c6915430b7155769ea4ef16efe4 Best regards, -- ~Vinod
Re: [PATCH 3/6] drm/bridge: tc358775: Add jeida-24 support
> The jeida-24 register values are the default hardware settings, but they
> not listed in the driver. Let's add them.
jeida-24 and jeida-18 should have the same mapping, jeida-18 is broken in
this driver. could you test this patch:
--snip--
>From 46da1d76d4908e5879ed746cce1faeacd69c432e Mon Sep 17 00:00:00 2001
From: Michael Walle
Date: Wed, 4 Oct 2023 13:52:57 +0200
Subject: [PATCH] drm/bridge: tc358775: fix support for jeida-18 and jeida-24
The bridge always uses 24bpp internally. Therefore, for jeida-18
mapping we need to discard the lowest two bits for each channel and thus
starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
lanes instead of three, with the forth pair transmitting the lowest two
bits of each channel. Thus, the mapping between jeida-18 and jeida-24
is actually the same, except that one channel is turned off (by
selecting the RGB666 format in VPCTRL).
While at it, remove the bogus comment about the hardware default because
the default is overwritten in any case.
Tested with a jeida-18 display (Evervision VGG644804).
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
index 90a89d70d832..592c69c2aedc 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -454,10 +454,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
connector->display_info.bus_formats[0],
tc->bpc);
- /*
-* Default hardware register settings of tc358775 configured
-* with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
-*/
if (connector->display_info.bus_formats[0] ==
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
/* VESA-24 */
@@ -468,14 +464,15 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1,
LVI_B2));
d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
LVI_L0));
d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_R6));
- } else { /* MEDIA_BUS_FMT_RGB666_1X7X3_SPWG - JEIDA-18 */
- d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2,
LVI_R3));
- d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_L0, LVI_R5,
LVI_G0));
- d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_L0,
LVI_L0));
- d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G3, LVI_G4, LVI_G5,
LVI_B0));
- d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_L0, LVI_L0, LVI_B1,
LVI_B2));
- d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
LVI_L0));
- d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_L0));
+ } else {
+ /* JEIDA-18 and JEIDA-24 */
+ d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R2, LVI_R3, LVI_R4,
LVI_R5));
+ d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R6, LVI_R1, LVI_R7,
LVI_G2));
+ d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G3, LVI_G4, LVI_G0,
LVI_G1));
+ d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G5, LVI_G6, LVI_G7,
LVI_B2));
+ d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B0, LVI_B1, LVI_B3,
LVI_B4));
+ d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B5, LVI_B6, LVI_B7,
LVI_L0));
+ d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_R0));
}
d2l_write(tc->i2c, VFUEN, VFUEN_EN);
--
2.39.2
Re: [PATCH 4/4] drm/mediatek: support the DSI0 output on the MT8195 VDOSYS0
Il 23/11/23 14:37, Michael Walle ha scritto: With the latest dynamic selection of the output component, we can now support different outputs. Move current output component into the dynamic routes array and add the new DSI0 output. Signed-off-by: Michael Walle Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH 1/4] dt-bindings: display: mediatek: dsi: add compatible for MediaTek MT8195
Il 23/11/23 14:37, Michael Walle ha scritto: Add the compatible string for MediaTek MT8195 SoC, using the same DSI block as the MT8183. Signed-off-by: Michael Walle Reviewed-by: AngeloGioacchino Del Regno
[PATCH] Revert "drm/sched: Qualify drm_sched_wakeup() by drm_sched_entity_is_ready()"
Commit f3123c25 (in combination with the use of work queues by the gpu
scheduler) leads to random lock ups of the GUI [1,2].
This is not a complete revert of commit f3123c25 as drm_sched_wakeup
still needs its entity argument to pass it to drm_sched_can_queue.
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/2994
[2] https://lists.freedesktop.org/archives/dri-devel/2023-November/431606.html
This reverts commit f3123c2590005c5ff631653d31428e40cd10c618.
---
drivers/gpu/drm/scheduler/sched_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 682aebe96db7..550492a7a031 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1029,9 +1029,8 @@ EXPORT_SYMBOL(drm_sched_job_cleanup);
void drm_sched_wakeup(struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity)
{
- if (drm_sched_entity_is_ready(entity))
- if (drm_sched_can_queue(sched, entity))
- drm_sched_run_job_queue(sched);
+ if (drm_sched_can_queue(sched, entity))
+ drm_sched_run_job_queue(sched);
}
/**
--
2.43.0
Re: [PATCH 3/6] drm/bridge: tc358775: Add jeida-24 support
* Michael Walle [231127 13:25]:
> > The jeida-24 register values are the default hardware settings, but they
> > not listed in the driver. Let's add them.
>
> jeida-24 and jeida-18 should have the same mapping, jeida-18 is broken in
> this driver. could you test this patch:
Yes great works for me with the tc358765 patches:
Tested-by: Tony Lindgren
> --snip--
>
> From 46da1d76d4908e5879ed746cce1faeacd69c432e Mon Sep 17 00:00:00 2001
> From: Michael Walle
> Date: Wed, 4 Oct 2023 13:52:57 +0200
> Subject: [PATCH] drm/bridge: tc358775: fix support for jeida-18 and jeida-24
>
> The bridge always uses 24bpp internally. Therefore, for jeida-18
> mapping we need to discard the lowest two bits for each channel and thus
> starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
> lanes instead of three, with the forth pair transmitting the lowest two
> bits of each channel. Thus, the mapping between jeida-18 and jeida-24
> is actually the same, except that one channel is turned off (by
> selecting the RGB666 format in VPCTRL).
>
> While at it, remove the bogus comment about the hardware default because
> the default is overwritten in any case.
>
> Tested with a jeida-18 display (Evervision VGG644804).
>
> Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
> Signed-off-by: Michael Walle
> ---
> drivers/gpu/drm/bridge/tc358775.c | 21 +
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c
> b/drivers/gpu/drm/bridge/tc358775.c
> index 90a89d70d832..592c69c2aedc 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -454,10 +454,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
> connector->display_info.bus_formats[0],
> tc->bpc);
> - /*
> - * Default hardware register settings of tc358775 configured
> - * with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
> - */
> if (connector->display_info.bus_formats[0] ==
> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
> /* VESA-24 */
> @@ -468,14 +464,15 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1,
> LVI_B2));
> d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
> LVI_L0));
> d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
> LVI_R6));
> - } else { /* MEDIA_BUS_FMT_RGB666_1X7X3_SPWG - JEIDA-18 */
> - d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2,
> LVI_R3));
> - d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_L0, LVI_R5,
> LVI_G0));
> - d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_L0,
> LVI_L0));
> - d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G3, LVI_G4, LVI_G5,
> LVI_B0));
> - d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_L0, LVI_L0, LVI_B1,
> LVI_B2));
> - d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
> LVI_L0));
> - d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
> LVI_L0));
> + } else {
> + /* JEIDA-18 and JEIDA-24 */
> + d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R2, LVI_R3, LVI_R4,
> LVI_R5));
> + d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R6, LVI_R1, LVI_R7,
> LVI_G2));
> + d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G3, LVI_G4, LVI_G0,
> LVI_G1));
> + d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G5, LVI_G6, LVI_G7,
> LVI_B2));
> + d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B0, LVI_B1, LVI_B3,
> LVI_B4));
> + d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B5, LVI_B6, LVI_B7,
> LVI_L0));
> + d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
> LVI_R0));
> }
>
> d2l_write(tc->i2c, VFUEN, VFUEN_EN);
> --
> 2.39.2
>
Re: [PATCH v2 01/12] drm/rockchip: move output interface related definition to rockchip_drm_drv.h
On Wed, Nov 22, 2023 at 08:53:49PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> The output interface related definition can shared between
> vop and vop2, move them to rockchip_drm_drv.h can avoid duplicated
> definition.
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
>
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 -
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 1 -
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 -
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
> drivers/gpu/drm/rockchip/inno_hdmi.c| 1 -
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 1 -
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 17 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h| 16 +---
> drivers/gpu/drm/rockchip/rockchip_lvds.c| 1 -
> drivers/gpu/drm/rockchip/rockchip_rgb.c | 1 -
> 11 files changed, 19 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 84aa811ca1e9..bd08d57486fe 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -30,7 +30,6 @@
> #include
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #define RK3288_GRF_SOC_CON6 0x25c
> #define RK3288_EDP_LCDC_SEL BIT(5)
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index 21254e4e107a..a855c45ae7f3 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -24,7 +24,6 @@
>
> #include "cdn-dp-core.h"
> #include "cdn-dp-reg.h"
> -#include "rockchip_drm_vop.h"
>
> static inline struct cdn_dp_device *connector_to_dp(struct drm_connector
> *connector)
> {
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 6396f9324dab..4cc8ed8f4fbd 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -26,7 +26,6 @@
> #include
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #define DSI_PHY_RSTZ 0xa0
> #define PHY_DISFORCEPLL 0
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 341550199111..fe33092abbe7 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -18,7 +18,6 @@
> #include
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #define RK3228_GRF_SOC_CON2 0x0408
> #define RK3228_HDMI_SDAIN_MSKBIT(14)
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index 6e5b922a121e..f6d819803c0e 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -23,7 +23,6 @@
> #include
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #include "inno_hdmi.h"
>
> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> index fa6e592e0276..78136d0c5a65 100644
> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> @@ -17,7 +17,6 @@
> #include "rk3066_hdmi.h"
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #define DEFAULT_PLLA_RATE 3000
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index aeb03a57240f..3d8ab2defa1b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -20,6 +20,23 @@
> #define ROCKCHIP_MAX_CONNECTOR 2
> #define ROCKCHIP_MAX_CRTC4
>
> +/*
> + * display output interface supported by rockchip lcdc
> + */
> +#define ROCKCHIP_OUT_MODE_P888 0
> +#define ROCKCHIP_OUT_MODE_BT1120 0
> +#define ROCKCHIP_OUT_MODE_P666 1
> +#define ROCKCHIP_OUT_MODE_P565 2
> +#define ROCKCHIP_OUT_MODE_BT656 5
> +#define ROCKCHIP_OUT_MODE_S888 8
> +#define ROCKCHIP_OUT_MODE_S888_DUMMY 12
> +#define ROCKCHIP_OUT_MODE_YUV420 14
> +/* for use special outface */
> +#define ROCKCHIP_OUT_MODE_ 15
> +
> +/* output flags */
> +#define ROCKCHIP_OUTPUT_DSI_DUAL BIT(0)
> +
> struct drm_device;
> struct drm_connector;
> struct iommu_domain;
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 4b2daefeb8c1..43d9c9191b7a 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -277,17 +277,7 @@
Re: [PATCH v2 02/12] Revert "drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume"
On Wed, Nov 22, 2023 at 08:54:00PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> This reverts commit b63a553e8f5aa6574eeb535a551817a93c426d8c.
>
> regcache_sync will try to reload the configuration in regcache to
> hardware, but the registers of 4 Cluster windows and Esmart1/2/3 on
> the upcoming rk3588 can not be set successfully before internal PD
> power on.
>
> Also it's better to keep the hardware register as it is before we really
> enable it.
>
> So let's revert this version, and keep the first version:
> commit afa965a45e01 ("drm/rockchip: vop2: fix suspend/resume")
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 312da5783362..57784d0a22a6 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -217,6 +217,8 @@ struct vop2 {
> struct vop2_win win[];
> };
>
> +static const struct regmap_config vop2_regmap_config;
> +
> static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
> {
> return container_of(crtc, struct vop2_video_port, crtc);
> @@ -883,7 +885,11 @@ static void vop2_enable(struct vop2 *vop2)
> return;
> }
>
> - regcache_sync(vop2->map);
> + ret = regmap_reinit_cache(vop2->map, _regmap_config);
> + if (ret) {
> + drm_err(vop2->drm, "failed to reinit cache: %d\n", ret);
> + return;
> + }
>
> if (vop2->data->soc_id == 3566)
> vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
> @@ -913,8 +919,6 @@ static void vop2_disable(struct vop2 *vop2)
>
> pm_runtime_put_sync(vop2->dev);
>
> - regcache_mark_dirty(vop2->map);
> -
> clk_disable_unprepare(vop2->aclk);
> clk_disable_unprepare(vop2->hclk);
> }
> --
> 2.34.1
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 03/12] drm/rockchip: vop2: set half_block_en bit in all mode
On Wed, Nov 22, 2023 at 08:54:13PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> At first we thought the half_block_en bit in AFBCD_CTRL register
> only work in afbc mode. But the fact is that it control the line
> buffer in all mode(afbc/tile/line), so we need configure it in
> all case.
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 25 ++--
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 57784d0a22a6..639dfebc6bd1 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -521,6 +521,18 @@ static bool rockchip_vop2_mod_supported(struct drm_plane
> *plane, u32 format,
> return vop2_convert_afbc_format(format) >= 0;
> }
>
> +/*
> + * 0: Full mode, 16 lines for one tail
> + * 1: half block mode, 8 lines one tail
> + */
> +static bool vop2_half_block_enable(struct drm_plane_state *pstate)
> +{
> + if (pstate->rotation & (DRM_MODE_ROTATE_270 | DRM_MODE_ROTATE_90))
> + return false;
> + else
> + return true;
> +}
> +
> static u32 vop2_afbc_transform_offset(struct drm_plane_state *pstate,
> bool afbc_half_block_en)
> {
> @@ -1144,6 +1156,7 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> bool rotate_90 = pstate->rotation & DRM_MODE_ROTATE_90;
> struct rockchip_gem_object *rk_obj;
> unsigned long offset;
> + bool half_block_en;
> bool afbc_en;
> dma_addr_t yrgb_mst;
> dma_addr_t uv_mst;
> @@ -1236,6 +1249,7 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> dsp_info = (dsp_h - 1) << 16 | ((dsp_w - 1) & 0x);
>
> format = vop2_convert_format(fb->format->format);
> + half_block_en = vop2_half_block_enable(pstate);
>
> drm_dbg(vop2->drm, "vp%d update %s[%dx%d->%dx%d@%dx%d] fmt[%p4cc_%s]
> addr[%pad]\n",
> vp->id, win->data->name, actual_w, actual_h, dsp_w, dsp_h,
> @@ -1243,6 +1257,9 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> >format->format,
> afbc_en ? "AFBC" : "", _mst);
>
> + if (vop2_cluster_window(win))
> + vop2_win_write(win, VOP2_WIN_AFBC_HALF_BLOCK_EN, half_block_en);
> +
> if (afbc_en) {
> u32 stride;
>
> @@ -1283,13 +1300,7 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap);
> vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
> vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0);
> - if (pstate->rotation & (DRM_MODE_ROTATE_270 |
> DRM_MODE_ROTATE_90)) {
> - vop2_win_write(win, VOP2_WIN_AFBC_HALF_BLOCK_EN, 0);
> - transform_offset = vop2_afbc_transform_offset(pstate,
> false);
> - } else {
> - vop2_win_write(win, VOP2_WIN_AFBC_HALF_BLOCK_EN, 1);
> - transform_offset = vop2_afbc_transform_offset(pstate,
> true);
> - }
> + transform_offset = vop2_afbc_transform_offset(pstate,
> half_block_en);
> vop2_win_write(win, VOP2_WIN_AFBC_HDR_PTR, yrgb_mst);
> vop2_win_write(win, VOP2_WIN_AFBC_PIC_SIZE, act_info);
> vop2_win_write(win, VOP2_WIN_AFBC_TRANSFORM_OFFSET,
> transform_offset);
> --
> 2.34.1
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 06/12] drm/rockchip: vop2: rename grf to sys_grf
On Wed, Nov 22, 2023 at 08:54:54PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> The vop2 need to reference more grf(system grf, vop grf, vo0/1 grf,etc)
> in the upcoming rk3588.
>
> So we rename the current system grf to sys_grf.
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index b32a291c5caa..4bcc405bcf11 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -190,7 +190,7 @@ struct vop2 {
> void __iomem *regs;
> struct regmap *map;
>
> - struct regmap *grf;
> + struct regmap *sys_grf;
>
> /* physical map length of vop2 register */
> u32 len;
> @@ -1503,9 +1503,9 @@ static void rk3568_set_intf_mux(struct vop2_video_port
> *vp, int id,
> dip &= ~RK3568_DSP_IF_POL__RGB_LVDS_PIN_POL;
> dip |= FIELD_PREP(RK3568_DSP_IF_POL__RGB_LVDS_PIN_POL,
> polflags);
> if (polflags & POLFLAG_DCLK_INV)
> - regmap_write(vop2->grf, RK3568_GRF_VO_CON1, BIT(3 + 16)
> | BIT(3));
> + regmap_write(vop2->sys_grf, RK3568_GRF_VO_CON1, BIT(3 +
> 16) | BIT(3));
> else
> - regmap_write(vop2->grf, RK3568_GRF_VO_CON1, BIT(3 +
> 16));
> + regmap_write(vop2->sys_grf, RK3568_GRF_VO_CON1, BIT(3 +
> 16));
> break;
> case ROCKCHIP_VOP2_EP_HDMI0:
> die &= ~RK3568_SYS_DSP_INFACE_EN_HDMI_MUX;
> @@ -2764,7 +2764,7 @@ static int vop2_bind(struct device *dev, struct device
> *master, void *data)
> return PTR_ERR(vop2->lut_regs);
> }
>
> - vop2->grf = syscon_regmap_lookup_by_phandle(dev->of_node,
> "rockchip,grf");
> + vop2->sys_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
> "rockchip,grf");
>
> vop2->hclk = devm_clk_get(vop2->dev, "hclk");
> if (IS_ERR(vop2->hclk)) {
> --
> 2.34.1
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 05/12] drm/rockchip: vop2: Set YUV/RGB overlay mode
On Wed, Nov 22, 2023 at 08:54:38PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> Set overlay mode register according to the
> output mode is yuv or rgb.
>
> Signed-off-by: Andy Yan
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 19 ---
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index 3d8ab2defa1b..7a58c5c9d4ec 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -51,6 +51,7 @@ struct rockchip_crtc_state {
> u32 bus_format;
> u32 bus_flags;
> int color_space;
> + bool yuv_overlay;
This struct already contains a bool type variable. Please add this one
next to it to keep the struct size smaller.
> };
> #define to_rockchip_crtc_state(s) \
> container_of(s, struct rockchip_crtc_state, base)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index a019cc9bbd54..b32a291c5caa 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1612,6 +1612,8 @@ static void vop2_crtc_atomic_enable(struct drm_crtc
> *crtc,
>
> vop2->enable_count++;
>
> + vcstate->yuv_overlay = is_yuv_output(vcstate->bus_format);
> +
> vop2_crtc_enable_irq(vp, VP_INT_POST_BUF_EMPTY);
>
> polflags = 0;
> @@ -1639,7 +1641,7 @@ static void vop2_crtc_atomic_enable(struct drm_crtc
> *crtc,
> if (vop2_output_uv_swap(vcstate->bus_format, vcstate->output_mode))
> dsp_ctrl |= RK3568_VP_DSP_CTRL__DSP_RB_SWAP;
>
> - if (is_yuv_output(vcstate->bus_format))
> + if (vcstate->yuv_overlay)
> dsp_ctrl |= RK3568_VP_DSP_CTRL__POST_DSP_OUT_R2Y;
>
> vop2_dither_setup(crtc, _ctrl);
> @@ -1948,10 +1950,12 @@ static void vop2_setup_layer_mixer(struct
> vop2_video_port *vp)
> u16 hdisplay;
> u32 bg_dly;
> u32 pre_scan_dly;
> + u32 ovl_ctrl;
> int i;
> struct vop2_video_port *vp0 = >vps[0];
> struct vop2_video_port *vp1 = >vps[1];
> struct vop2_video_port *vp2 = >vps[2];
> + struct rockchip_crtc_state *vcstate =
> to_rockchip_crtc_state(vp->crtc.state);
>
> adjusted_mode = >crtc.state->adjusted_mode;
> hsync_len = adjusted_mode->crtc_hsync_end -
> adjusted_mode->crtc_hsync_start;
> @@ -1964,7 +1968,14 @@ static void vop2_setup_layer_mixer(struct
> vop2_video_port *vp)
> pre_scan_dly = ((bg_dly + (hdisplay >> 1) - 1) << 16) | hsync_len;
> vop2_vp_write(vp, RK3568_VP_PRE_SCAN_HTIMING, pre_scan_dly);
>
> - vop2_writel(vop2, RK3568_OVL_CTRL, 0);
> + ovl_ctrl = vop2_readl(vop2, RK3568_OVL_CTRL);
> + if (vcstate->yuv_overlay)
> + ovl_ctrl |= BIT(vp->id);
> + else
> + ovl_ctrl &= ~BIT(vp->id);
Some
#define RK3568_OVL_CTRL__YUV_MODE(vp) BIT(vp)
Would be nice.
> +
> + vop2_writel(vop2, RK3568_OVL_CTRL, ovl_ctrl);
Is it necessary to write this register twice?
> +
> port_sel = vop2_readl(vop2, RK3568_OVL_PORT_SEL);
> port_sel &= RK3568_OVL_PORT_SEL__SEL_PORT;
>
> @@ -2036,9 +2047,11 @@ static void vop2_setup_layer_mixer(struct
> vop2_video_port *vp)
> layer_sel |= RK3568_OVL_LAYER_SEL__LAYER(nlayer + ofs, 5);
> }
>
> + ovl_ctrl |= RK3568_OVL_CTRL__LAYERSEL_REGDONE_IMD;
> +
> vop2_writel(vop2, RK3568_OVL_LAYER_SEL, layer_sel);
> vop2_writel(vop2, RK3568_OVL_PORT_SEL, port_sel);
> - vop2_writel(vop2, RK3568_OVL_CTRL,
> RK3568_OVL_CTRL__LAYERSEL_REGDONE_IMD);
> + vop2_writel(vop2, RK3568_OVL_CTRL, ovl_ctrl);
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 1/2] drm/sched: Rename priority MIN to LOW
Am 27.11.23 um 15:13 schrieb Luben Tuikov: On 2023-11-27 08:55, Christian König wrote: Hi Luben, Am 24.11.23 um 08:57 schrieb Christian König: Am 24.11.23 um 06:27 schrieb Luben Tuikov: Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW. This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler priorities in ascending order, DRM_SCHED_PRIORITY_LOW, DRM_SCHED_PRIORITY_NORMAL, DRM_SCHED_PRIORITY_HIGH, DRM_SCHED_PRIORITY_KERNEL. Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Danilo Krummrich Cc: Alex Deucher Cc: Christian König Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Luben Tuikov Reviewed-by: Christian König Looks like you missed one usage in Nouveau: drivers/gpu/drm/nouveau/nouveau_sched.c:21:41: error: ‘DRM_SCHED_PRIORITY_MIN’ undeclared here (not in a function); did you mean ‘DRM_SCHED_PRIORITY_LOW’? 21 | NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN, | ^~ | DRM_SCHED_PRIORITY_LOW This now results in a build error on drm-misc-next. I'm waiting for someone to R-B the fix I posted two days ago: https://lore.kernel.org/r/20231125192246.87268-2-ltuiko...@gmail.com There must be something wrong with the dri-devel mailing list (or my gmail, but I doubt so). I don't see this mail in my inbox anywhere. Feel free to add my rb and push it. Thanks, Christian.
[PATCH v2] drm/atomic-helpers: Invoke end_fb_access while owning plane state
Invoke drm_plane_helper_funcs.end_fb_access before
drm_atomic_helper_commit_hw_done(). The latter function hands over
ownership of the plane state to the following commit, which might
free it. Releasing resources in end_fb_access then operates on undefined
state. This bug has been observed with non-blocking commits when they
are being queued up quickly.
Here is an example stack trace from the bug report. The plane state has
been free'd already, so the pages for drm_gem_fb_vunmap() are gone.
Unable to handle kernel paging request at virtual address 00010049
[...]
drm_gem_fb_vunmap+0x18/0x74
drm_gem_end_shadow_fb_access+0x1c/0x2c
drm_atomic_helper_cleanup_planes+0x58/0xd8
drm_atomic_helper_commit_tail+0x90/0xa0
commit_tail+0x15c/0x188
commit_work+0x14/0x20
For aborted commits, it is still ok to run end_fb_access as part of the
plane's cleanup. Add a test to drm_atomic_helper_cleanup_planes().
v2:
* fix test in drm_atomic_helper_cleanup_planes()
Reported-by: Alyssa Ross
Closes: https://lore.kernel.org/dri-devel/87leazm0ya@alyssa.is/
Suggested-by: Daniel Vetter
Fixes: 94d879eaf7fb ("drm/atomic-helper: Add {begin,end}_fb_access to plane
helpers")
Signed-off-by: Thomas Zimmermann
Cc: # v6.2+
---
drivers/gpu/drm/drm_atomic_helper.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c3f677130def0..bedb42ddd1341 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2784,6 +2784,17 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
funcs->atomic_flush(crtc, old_state);
}
+
+ /*
+* Signal end of framebuffer access here before hw_done. After hw_done,
+* a later commit might have already released the plane state.
+*/
+ for_each_oldnew_plane_in_state(old_state, plane, old_plane_state,
new_plane_state, i) {
+ const struct drm_plane_helper_funcs *funcs =
plane->helper_private;
+
+ if (funcs->end_fb_access)
+ funcs->end_fb_access(plane, new_plane_state);
+ }
}
EXPORT_SYMBOL(drm_atomic_helper_commit_planes);
@@ -2924,6 +2935,12 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
*dev,
for_each_oldnew_plane_in_state(old_state, plane, old_plane_state,
new_plane_state, i) {
const struct drm_plane_helper_funcs *funcs =
plane->helper_private;
+ /*
+* Only clean up here if we're aborting the commit.
+*/
+ if (old_plane_state == plane->state)
+ continue;
+
if (funcs->end_fb_access)
funcs->end_fb_access(plane, new_plane_state);
}
--
2.43.0
Re: [PATCH 1/2] drm/sched: Rename priority MIN to LOW
On 2023-11-27 09:20, Christian König wrote: > Am 27.11.23 um 15:13 schrieb Luben Tuikov: >> On 2023-11-27 08:55, Christian König wrote: >>> Hi Luben, >>> >>> Am 24.11.23 um 08:57 schrieb Christian König: Am 24.11.23 um 06:27 schrieb Luben Tuikov: > Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW. > > This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler > priorities > in ascending order, > DRM_SCHED_PRIORITY_LOW, > DRM_SCHED_PRIORITY_NORMAL, > DRM_SCHED_PRIORITY_HIGH, > DRM_SCHED_PRIORITY_KERNEL. > > Cc: Rob Clark > Cc: Abhinav Kumar > Cc: Dmitry Baryshkov > Cc: Danilo Krummrich > Cc: Alex Deucher > Cc: Christian König > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Luben Tuikov Reviewed-by: Christian König >>> Looks like you missed one usage in Nouveau: >>> >>> drivers/gpu/drm/nouveau/nouveau_sched.c:21:41: error: >>> ‘DRM_SCHED_PRIORITY_MIN’ undeclared here (not in a function); did you >>> mean ‘DRM_SCHED_PRIORITY_LOW’? >>> 21 | NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN, >>> | ^~ >>> | DRM_SCHED_PRIORITY_LOW >>> >>> This now results in a build error on drm-misc-next. >> I'm waiting for someone to R-B the fix I posted two days ago: >> https://lore.kernel.org/r/20231125192246.87268-2-ltuiko...@gmail.com > > There must be something wrong with the dri-devel mailing list (or my > gmail, but I doubt so). I don't see this mail in my inbox anywhere. > > Feel free to add my rb and push it. Done. Thanks. -- Regards, Luben OpenPGP_0x4C15479431A334AF.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[PATCH 1/2] drm/ttm: replace busy placement with flags v3
From: Somalapuram Amaranath
Instead of a list of separate busy placement add flags which indicate
that a placement should only be used when there is room or if we need to
evict.
v2: add missing TTM_PL_FLAG_IDLE for i915
v3: fix auto build test ERROR on drm-tip/drm-tip
Signed-off-by: Christian König
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 11 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 2 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 37
drivers/gpu/drm/loongson/lsdc_ttm.c| 2 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 59 +
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 -
drivers/gpu/drm/qxl/qxl_object.c | 2 -
drivers/gpu/drm/qxl/qxl_ttm.c | 2 -
drivers/gpu/drm/radeon/radeon_object.c | 2 -
drivers/gpu/drm/radeon/radeon_ttm.c| 8 +-
drivers/gpu/drm/radeon/radeon_uvd.c| 1 -
drivers/gpu/drm/ttm/ttm_bo.c | 21 +++--
drivers/gpu/drm/ttm/ttm_resource.c | 73
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 99 +-
include/drm/ttm/ttm_placement.h| 10 ++-
include/drm/ttm/ttm_resource.h | 8 +-
18 files changed, 160 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index cef920a93924..aa0dd6dad068 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -220,9 +220,6 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo,
u32 domain)
placement->num_placement = c;
placement->placement = places;
-
- placement->num_busy_placement = c;
- placement->busy_placement = places;
}
/**
@@ -1406,8 +1403,7 @@ vm_fault_t amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
AMDGPU_GEM_DOMAIN_GTT);
/* Avoid costly evictions; only set GTT as a busy placement */
- abo->placement.num_busy_placement = 1;
- abo->placement.busy_placement = >placements[1];
+ abo->placements[0].flags |= TTM_PL_FLAG_IDLE;
r = ttm_bo_validate(bo, >placement, );
if (unlikely(r == -EBUSY || r == -ERESTARTSYS))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 05991c5c8ddb..9a6a00b1af40 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -102,23 +102,19 @@ static void amdgpu_evict_flags(struct ttm_buffer_object
*bo,
/* Don't handle scatter gather BOs */
if (bo->type == ttm_bo_type_sg) {
placement->num_placement = 0;
- placement->num_busy_placement = 0;
return;
}
/* Object isn't an AMDGPU object so ignore */
if (!amdgpu_bo_is_amdgpu_bo(bo)) {
placement->placement =
- placement->busy_placement =
placement->num_placement = 1;
- placement->num_busy_placement = 1;
return;
}
abo = ttm_to_amdgpu_bo(bo);
if (abo->flags & AMDGPU_GEM_CREATE_DISCARDABLE) {
placement->num_placement = 0;
- placement->num_busy_placement = 0;
return;
}
@@ -128,13 +124,13 @@ static void amdgpu_evict_flags(struct ttm_buffer_object
*bo,
case AMDGPU_PL_OA:
case AMDGPU_PL_DOORBELL:
placement->num_placement = 0;
- placement->num_busy_placement = 0;
return;
case TTM_PL_VRAM:
if (!adev->mman.buffer_funcs_enabled) {
/* Move to system memory */
amdgpu_bo_placement_from_domain(abo,
AMDGPU_GEM_DOMAIN_CPU);
+
} else if (!amdgpu_gmc_vram_full_visible(>gmc) &&
!(abo->flags &
AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) &&
amdgpu_bo_in_cpu_visible_vram(abo)) {
@@ -149,8 +145,7 @@ static void amdgpu_evict_flags(struct ttm_buffer_object *bo,
AMDGPU_GEM_DOMAIN_CPU);
abo->placements[0].fpfn = adev->gmc.visible_vram_size
>> PAGE_SHIFT;
abo->placements[0].lpfn = 0;
- abo->placement.busy_placement = >placements[1];
- abo->placement.num_busy_placement = 1;
+ abo->placements[0].flags |= TTM_PL_FLAG_IDLE;
} else {
/* Move to GTT memory */
amdgpu_bo_placement_from_domain(abo,
AMDGPU_GEM_DOMAIN_GTT |
@@ -967,8 +962,6 @@ int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo)
/* allocate GART space */
placement.num_placement = 1;
[PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT
Try to fill up VRAM as well by setting the busy flag on GTT allocations. This fixes the issue that when VRAM was evacuated for suspend it's never filled up again unless the application is restarted. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index aa0dd6dad068..ddc8fb4db678 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -173,6 +173,12 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) abo->flags & AMDGPU_GEM_CREATE_PREEMPTIBLE ? AMDGPU_PL_PREEMPT : TTM_PL_TT; places[c].flags = 0; + /* +* When GTT is just an alternative to VRAM make sure that we +* only use it as fallback and still try to fill up VRAM first. +*/ + if (domain & AMDGPU_GEM_DOMAIN_VRAM) + places[c].flags |= TTM_PL_FLAG_BUSY; c++; } -- 2.34.1
[PATCH v2 05/12] iommu/arm-smmu-qcom: Add QCM2290 DPU compatible
Add the QCM2290 DPU compatible to clients compatible list, as it also
needs the workarounds.
Signed-off-by: Konrad Dybcio
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 549ae4dba3a6..aea5e85b20ff 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -245,6 +245,7 @@ static const struct of_device_id
qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,adreno" },
{ .compatible = "qcom,mdp4" },
{ .compatible = "qcom,mdss" },
+ { .compatible = "qcom,qcm2290-mdss" },
{ .compatible = "qcom,sc7180-mdss" },
{ .compatible = "qcom,sc7180-mss-pil" },
{ .compatible = "qcom,sc7280-mdss" },
--
2.43.0
[PATCH v2 02/12] dt-bindings: display: msm: Add reg bus and rotator interconnects
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are other connection paths: - a path that connects rotator block to the DDR. - a path that needs to be handled to ensure MDSS register access functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG interconnect. Describe these paths to allow using them in device trees and in the driver. Signed-off-by: Dmitry Baryshkov [Konrad: rework for one vs two MDP paths, update examples] Signed-off-by: Konrad Dybcio --- .../devicetree/bindings/display/msm/mdss-common.yaml | 18 ++ .../bindings/display/msm/qcom,qcm2290-mdss.yaml| 14 ++ .../bindings/display/msm/qcom,sc7180-mdss.yaml | 14 ++ .../bindings/display/msm/qcom,sc7280-mdss.yaml | 14 ++ .../bindings/display/msm/qcom,sm6115-mdss.yaml | 10 ++ .../bindings/display/msm/qcom,sm6125-mdss.yaml | 8 ++-- .../bindings/display/msm/qcom,sm6350-mdss.yaml | 8 ++-- .../bindings/display/msm/qcom,sm6375-mdss.yaml | 8 ++-- .../bindings/display/msm/qcom,sm8450-mdss.yaml | 13 - 9 files changed, 80 insertions(+), 27 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml index f69196e4cc76..c6305a6e0334 100644 --- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml +++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml @@ -61,17 +61,27 @@ properties: ranges: true + # This is not a perfect description, but it's impossible to discern and match + # the entries like we do with interconnect-names interconnects: minItems: 1 items: - description: Interconnect path from mdp0 (or a single mdp) port to the data bus - description: Interconnect path from mdp1 port to the data bus + - description: Interconnect path from CPU to the reg bus interconnect-names: -minItems: 1 -items: - - const: mdp0-mem - - const: mdp1-mem +oneOf: + - minItems: 1 +items: + - const: mdp0-mem + - const: cpu-cfg + + - minItems: 2 +items: + - const: mdp0-mem + - const: mdp1-mem + - const: cpu-cfg resets: items: diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml index d71a8e09a798..f0cdb5422688 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml @@ -36,10 +36,14 @@ properties: maxItems: 2 interconnects: -maxItems: 1 +items: + - description: Interconnect path from mdp0 port to the data bus + - description: Interconnect path from CPU to the reg bus interconnect-names: -maxItems: 1 +items: + - const: mdp0-mem + - const: cpu-cfg patternProperties: "^display-controller@[0-9a-f]+$": @@ -98,8 +102,10 @@ examples: interrupt-controller; #interrupt-cells = <1>; -interconnects = <_virt MASTER_MDP0 SLAVE_EBI1>; -interconnect-names = "mdp0-mem"; +interconnects = <_virt MASTER_MDP0 SLAVE_EBI1>, +< MASTER_APPSS_PROC _noc SLAVE_DISPLAY_CFG>; +interconnect-names = "mdp0-mem", + "cpu-cfg"; iommus = <_smmu 0x420 0x2>, <_smmu 0x421 0x0>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml index 3432a2407caa..7a0555b15ddf 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml @@ -36,10 +36,14 @@ properties: maxItems: 1 interconnects: -maxItems: 1 +items: + - description: Interconnect path from mdp0 port to the data bus + - description: Interconnect path from CPU to the reg bus interconnect-names: -maxItems: 1 +items: + - const: mdp0-mem + - const: cpu-cfg patternProperties: "^display-controller@[0-9a-f]+$": @@ -106,8 +110,10 @@ examples: interrupt-controller; #interrupt-cells = <1>; -interconnects = <_noc MASTER_MDP0 _virt SLAVE_EBI1>; -interconnect-names = "mdp0-mem"; +interconnects = <_noc MASTER_MDP0 _virt SLAVE_EBI1>, +<_noc MASTER_APPSS_PROC _noc SLAVE_DISPLAY_CFG>; +interconnect-names = "mdp0-mem", + "cpu-cfg"; iommus = <_smmu 0x800 0x2>; ranges; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml index bbb727831fca..2947f27e0585 100644 ---
[PATCH v2 01/12] dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
The "qcom,dsi-ctrl-6g-qcm2290" has been deprecated in commit 0c0f65c6dd44
("dt-bindings: msm: dsi-controller-main: Add compatible strings for every
current SoC"), but the example hasn't been updated to reflect that.
Fix that.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
strings for every current SoC")
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
index 5ad155612b6c..d71a8e09a798 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
@@ -56,7 +56,9 @@ patternProperties:
properties:
compatible:
-const: qcom,dsi-ctrl-6g-qcm2290
+items:
+ - const: qcom,qcm2290-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
@@ -136,7 +138,8 @@ examples:
};
dsi@5e94000 {
-compatible = "qcom,dsi-ctrl-6g-qcm2290";
+compatible = "qcom,qcm2290-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
reg = <0x05e94000 0x400>;
reg-names = "dsi_ctrl";
--
2.43.0
[PATCH v2 04/12] dt-bindings: firmware: qcom,scm: Allow interconnect for everyone
Every Qualcomm SoC physically has a "CRYPTO0<->DDR" interconnect lane. Allow this property to be present, no matter the SoC. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 15 --- 1 file changed, 15 deletions(-) diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index 0613a37a851a..f3a87a8426d0 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -178,21 +178,6 @@ allOf: minItems: 3 maxItems: 3 - # Interconnects - - if: - not: -properties: - compatible: -contains: - enum: -- qcom,scm-qdu1000 -- qcom,scm-sc8280xp -- qcom,scm-sm8450 -- qcom,scm-sm8550 -then: - properties: -interconnects: false - # Interrupts - if: not: -- 2.43.0
[PATCH v2 00/12] RB1/QCM2290 features
This series brings: - interconnect plumbing - display setup for QCM2290/QRB2210 and - CAN bus controller - HDMI display - wifi fw variant name for QTI RB1 and the necessary bindings changes Patch 1-2 is for Dmitry/freedreno Patch 3 for Georgi/icc Patch 5 for Will/iommu the rest are for Bjorn/qcom Signed-off-by: Konrad Dybcio --- Changes in v2: - Fix up the bindings example in "qcm2290-mdss: Use the non-deprecated DSI compat" (krzk) - Fix up sc7180 & sc7280 DTs as a result of the bindings changes - Pick up rbs where it makes sense - Link to v1: https://lore.kernel.org/r/20231125-topic-rb1_feat-v1-0-11d71b12b...@linaro.org --- Dmitry Baryshkov (1): arm64: dts: qcom: qrb2210-rb1: add wifi variant property Konrad Dybcio (11): dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat dt-bindings: display: msm: Add reg bus and rotator interconnects dt-bindings: interconnect: qcom,msm8998-bwmon: Add QCM2290 bwmon instance dt-bindings: firmware: qcom,scm: Allow interconnect for everyone iommu/arm-smmu-qcom: Add QCM2290 DPU compatible arm64: dts: qcom: sc7180: Add the missing MDSS icc path arm64: dts: qcom: sc7280: Add the missing MDSS icc path arm64: dts: qcom: qcm2290: Add display nodes arm64: dts: qcom: qcm2290: Hook up interconnects arm64: dts: qcom: qrb2210-rb1: Set up HDMI arm64: dts: qcom: qrb2210-rb1: Enable CAN bus controller .../bindings/display/msm/mdss-common.yaml | 18 +- .../bindings/display/msm/qcom,qcm2290-mdss.yaml| 21 +- .../bindings/display/msm/qcom,sc7180-mdss.yaml | 14 +- .../bindings/display/msm/qcom,sc7280-mdss.yaml | 14 +- .../bindings/display/msm/qcom,sm6115-mdss.yaml | 10 + .../bindings/display/msm/qcom,sm6125-mdss.yaml | 8 +- .../bindings/display/msm/qcom,sm6350-mdss.yaml | 8 +- .../bindings/display/msm/qcom,sm6375-mdss.yaml | 8 +- .../bindings/display/msm/qcom,sm8450-mdss.yaml | 13 +- .../devicetree/bindings/firmware/qcom,scm.yaml | 15 - .../bindings/interconnect/qcom,msm8998-bwmon.yaml | 1 + arch/arm64/boot/dts/qcom/qcm2290.dtsi | 462 + arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 109 + arch/arm64/boot/dts/qcom/sc7180.dtsi | 8 +- arch/arm64/boot/dts/qcom/sc7280.dtsi | 9 +- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 + 16 files changed, 671 insertions(+), 48 deletions(-) --- base-commit: 48bbaf8b793e0770798519f8ee1ea2908ff0943a change-id: 20231125-topic-rb1_feat-dd510532621b Best regards, -- Konrad Dybcio
[PATCH] nouveau/gsp/r535: remove a stray unlock in r535_gsp_rpc_send()
This unlock doesn't belong here and it leads to a double unlock in
the caller, r535_gsp_rpc_push().
Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index dc44f5c7833f..818e5c73b7a6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -365,10 +365,8 @@ r535_gsp_rpc_send(struct nvkm_gsp *gsp, void *argv, bool
wait, u32 repc)
}
ret = r535_gsp_cmdq_push(gsp, rpc);
- if (ret) {
- mutex_unlock(>cmdq.mutex);
+ if (ret)
return ERR_PTR(ret);
- }
if (wait) {
msg = r535_gsp_msg_recv(gsp, fn, repc);
--
2.42.0
Re: [PATCH 2/6] drm/bridge: tc358775: Fix getting dsi host data lanes
> The current code assume hardcoded dsi host endpoint 1, which may not
> be the case. Let's fix that and simplify the code by getting the dsi
> endpoint with of_graph_get_remote_endpoint() that does not assume any
> endpoint numbering.
>
> Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
> Signed-off-by: Tony Lindgren
> ---
> drivers/gpu/drm/bridge/tc358775.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c
> b/drivers/gpu/drm/bridge/tc358775.c
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -528,25 +528,17 @@ tc_mode_valid(struct drm_bridge *bridge,
> static int tc358775_parse_dt(struct device_node *np, struct tc_data *tc)
> {
> struct device_node *endpoint;
> - struct device_node *parent;
> struct device_node *remote;
> int dsi_lanes = -1;
>
> - /*
> - * To get the data-lanes of dsi, we need to access the dsi0_out of port1
> - * of dsi0 endpoint from bridge port0 of d2l_in
> - */
> endpoint = of_graph_get_endpoint_by_regs(tc->dev->of_node,
>TC358775_DSI_IN, -1);
> if (endpoint) {
> - /* dsi0_out node */
> - parent = of_graph_get_remote_port_parent(endpoint);
> + /* Get the configured data lanes on the dsi host side */
> + remote = of_graph_get_remote_endpoint(endpoint);
> of_node_put(endpoint);
> - if (parent) {
> - /* dsi0 port 1 */
> - dsi_lanes = drm_of_get_data_lanes_count_ep(parent, 1,
> -1, 1, 4);
> - of_node_put(parent);
> - }
> + dsi_lanes = drm_of_get_data_lanes_count(remote, 1, 4);
I actually have the same fix, but with one additional detail, which I'm
unsure about though: This looks at the data-lanes property of the *remote*
endpoint whereas other bridge drivers (see tc358767, ti-sn65dsi83, lt8912b,
anx7625) look at the local endpoint and I'm not sure what is correct.
-michael
Re: [PATCH 2/6] drm/bridge: tc358775: Fix getting dsi host data lanes
* Michael Walle [231127 13:10]: > I actually have the same fix, but with one additional detail, which I'm > unsure about though: This looks at the data-lanes property of the *remote* > endpoint whereas other bridge drivers (see tc358767, ti-sn65dsi83, lt8912b, > anx7625) look at the local endpoint and I'm not sure what is correct. Yes I've been wondering about that too. Let's just move it over to the bridge node? We could produce a warning if the dsi host node has the data-lanes property.. No current in kernel users AFAIK. FYI, for omapdrm, we already have a legacy dt property "lanes" for the wiring that tells number of lanes used and the order of the lanes. Regards, Tony
Re: (subset) [PATCH 0/4] drm/mediatek: support DSI output on MT8195
On Thu, 23 Nov 2023 14:37:45 +0100, Michael Walle wrote: > Add support for a DSI output on VDOSYS0. Luckily, there is a new > feature to support dynamic selections of the output (connector). > Use it to add support for a DSI output. > > Apart from that, this is pretty straghtforward by just adding new > compatibles and add the correct DSI nodes to the SoC dtsi. > > [...] Applied, thanks! [2/4] dt-bindings: phy: add compatible for Mediatek MT8195 commit: fa50920b4f82993941e0aac349eb8081ce11e38f Best regards, -- ~Vinod
Re: [PATCH] dma-buf: fix check in dma_resv_add_fence
Ping? Can I get an rb or acked-by for that?
Thanks,
Christian.
Am 15.11.23 um 10:30 schrieb Christian König:
It's valid to add the same fence multiple times to a dma-resv object and
we shouldn't need one extra slot for each.
Signed-off-by: Christian König
Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really
later")
Cc: sta...@vger.kernel.org # v5.19+
---
drivers/dma-buf/dma-resv.c | 2 +-
include/linux/dma-fence.h | 15 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 38b4110378de..eb8b733065b2 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -301,7 +301,7 @@ void dma_resv_add_fence(struct dma_resv *obj, struct
dma_fence *fence,
dma_resv_list_entry(fobj, i, obj, , _usage);
if ((old->context == fence->context && old_usage >= usage &&
-dma_fence_is_later(fence, old)) ||
+dma_fence_is_later_or_same(fence, old)) ||
dma_fence_is_signaled(old)) {
dma_resv_list_set(fobj, i, fence, usage);
dma_fence_put(old);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index ebe78bd3d121..b3772edca2e6 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -498,6 +498,21 @@ static inline bool dma_fence_is_later(struct dma_fence *f1,
return __dma_fence_is_later(f1->seqno, f2->seqno, f1->ops);
}
+/**
+ * dma_fence_is_later_or_same - return true if f1 is later or same as f2
+ * @f1: the first fence from the same context
+ * @f2: the second fence from the same context
+ *
+ * Returns true if f1 is chronologically later than f2 or the same fence. Both
+ * fences must be from the same context, since a seqno is not re-used across
+ * contexts.
+ */
+static inline bool dma_fence_is_later_or_same(struct dma_fence *f1,
+ struct dma_fence *f2)
+{
+ return f1 == f2 || dma_fence_is_later(f1, f2);
+}
+
/**
* dma_fence_later - return the chronologically later fence
* @f1: the first fence from the same context
Re: [PATCH] drm/bridge: panel: Check device dependency before managing device link
On Thu, Nov 23, 2023 at 11:26:15AM +0800, Liu Ying wrote:
> Some panel devices already depend on DRM device, like the panel in
> arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts, because DRM device is
> the ancestor of those panel devices. device_link_add() would fail by
> returning a NULL pointer for those panel devices because of the existing
> dependency. So, check the dependency by calling device_is_dependent()
> before adding or deleting device link between panel device and DRM device
> so that the link is managed only for independent panel devices.
>
> Fixes: 887878014534 ("drm/bridge: panel: Fix device link for
> DRM_BRIDGE_ATTACH_NO_CONNECTOR")
> Fixes: 199cf07ebd2b ("drm/bridge: panel: Add a device link between drm device
> and panel device")
> Reported-by: Linus Walleij
> Closes:
> https://lore.kernel.org/lkml/cacrpkdagzxd6hbix7mvunjajtmepg00pp6+nj1p0jrfj-ar...@mail.gmail.com/T/
> Tested-by: Linus Walleij
> Signed-off-by: Liu Ying
> ---
> drivers/gpu/drm/bridge/panel.c | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index e48823a4f1ed..5e8980023407 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -23,6 +23,7 @@ struct panel_bridge {
> struct drm_panel *panel;
> struct device_link *link;
> u32 connector_type;
> + bool is_independent;
> };
>
> static inline struct panel_bridge *
> @@ -67,12 +68,17 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
> struct drm_device *drm_dev = bridge->dev;
> int ret;
>
> - panel_bridge->link = device_link_add(drm_dev->dev, panel->dev,
> - DL_FLAG_STATELESS);
> - if (!panel_bridge->link) {
> - DRM_ERROR("Failed to add device link between %s and %s\n",
> - dev_name(drm_dev->dev), dev_name(panel->dev));
> - return -EINVAL;
> + panel_bridge->is_independent = !device_is_dependent(drm_dev->dev,
> + panel->dev);
This broke the build. Looks like device_is_dependent() is not even exported.
ERROR: modpost: "device_is_dependent" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
The recommended defconfigs in rerere-cache do seem to have
CONFIG_DRM_KMS_HELPER=m
so this should have been caught before pushing. How did it slip through?
> +
> + if (panel_bridge->is_independent) {
> + panel_bridge->link = device_link_add(drm_dev->dev, panel->dev,
> + DL_FLAG_STATELESS);
> + if (!panel_bridge->link) {
> + DRM_ERROR("Failed to add device link between %s and
> %s\n",
> + dev_name(drm_dev->dev), dev_name(panel->dev));
> + return -EINVAL;
> + }
> }
>
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> @@ -80,7 +86,8 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
>
> if (!bridge->encoder) {
> DRM_ERROR("Missing encoder\n");
> - device_link_del(panel_bridge->link);
> + if (panel_bridge->is_independent)
> + device_link_del(panel_bridge->link);
> return -ENODEV;
> }
>
> @@ -92,7 +99,8 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
>panel_bridge->connector_type);
> if (ret) {
> DRM_ERROR("Failed to initialize connector\n");
> - device_link_del(panel_bridge->link);
> + if (panel_bridge->is_independent)
> + device_link_del(panel_bridge->link);
> return ret;
> }
>
> @@ -115,7 +123,8 @@ static void panel_bridge_detach(struct drm_bridge *bridge)
> struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> struct drm_connector *connector = _bridge->connector;
>
> - device_link_del(panel_bridge->link);
> + if (panel_bridge->is_independent)
> + device_link_del(panel_bridge->link);
>
> /*
>* Cleanup the connector if we know it was initialized.
> --
> 2.37.1
--
Ville Syrjälä
Intel
Re: [PATCH drm-misc-next 4/5] drm/gpuvm: fall back to drm_exec_lock_obj()
Am 25.11.23 um 00:40 schrieb Danilo Krummrich:
Hi Christian,
do you think it makes sense to handle this in drm_exec_prepare_obj() or
even dma_resv_reserve_fences() even?
IIRC for drm_exec the discussion has gone a bit back and forth between
handling 0 and having a separate function which doesn't allocate fences.
We ended up with the solution using separate calls since you either know
that you don't need fences (because you for example only need to look
something up) or you need fences and eventually calculate the number you
need dynamically and if you then end up with 0 it's a bug.
So to sum it up the conclusion was that it's more defensive to complain
about 0 fences to reserve (which reminds me that
dma_resv_reserve_fences() still needs to get a warning for 0 fences as
well).
Regards,
Christian.
- Danilo
On 11/25/23 00:36, Danilo Krummrich wrote:
Fall back to drm_exec_lock_obj() if num_fences is zero for the
drm_gpuvm_prepare_* function family.
Otherwise dma_resv_reserve_fences() would actually allocate slots even
though num_fences is zero.
Cc: Christian König
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c | 36 +---
include/drm/drm_gpuvm.h | 23 +++
2 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index 54f5e8851de5..d1d1c2379e44 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -1085,6 +1085,36 @@ drm_gpuvm_put(struct drm_gpuvm *gpuvm)
}
EXPORT_SYMBOL_GPL(drm_gpuvm_put);
+static int
+exec_prepare_obj(struct drm_exec *exec, struct drm_gem_object *obj,
+ unsigned int num_fences)
+{
+ return num_fences ? drm_exec_prepare_obj(exec, obj, num_fences) :
+ drm_exec_lock_obj(exec, obj);
+}
+
+/**
+ * drm_gpuvm_prepare_vm() - prepare the GPUVMs common dma-resv
+ * @gpuvm: the _gpuvm
+ * @exec: the _exec context
+ * @num_fences: the amount of _fences to reserve
+ *
+ * Calls drm_exec_prepare_obj() for the GPUVMs dummy _gem_object.
+ *
+ * Using this function directly, it is the drivers responsibility to
call
+ * drm_exec_init() and drm_exec_fini() accordingly.
+ *
+ * Returns: 0 on success, negative error code on failure.
+ */
+int
+drm_gpuvm_prepare_vm(struct drm_gpuvm *gpuvm,
+ struct drm_exec *exec,
+ unsigned int num_fences)
+{
+ return exec_prepare_obj(exec, gpuvm->r_obj, num_fences);
+}
+EXPORT_SYMBOL_GPL(drm_gpuvm_prepare_vm);
+
static int
__drm_gpuvm_prepare_objects(struct drm_gpuvm *gpuvm,
struct drm_exec *exec,
@@ -1095,7 +1125,7 @@ __drm_gpuvm_prepare_objects(struct drm_gpuvm
*gpuvm,
int ret = 0;
for_each_vm_bo_in_list(gpuvm, extobj, , vm_bo) {
- ret = drm_exec_prepare_obj(exec, vm_bo->obj, num_fences);
+ ret = exec_prepare_obj(exec, vm_bo->obj, num_fences);
if (ret)
break;
}
@@ -1116,7 +1146,7 @@ drm_gpuvm_prepare_objects_locked(struct
drm_gpuvm *gpuvm,
drm_gpuvm_resv_assert_held(gpuvm);
list_for_each_entry(vm_bo, >extobj.list,
list.entry.extobj) {
- ret = drm_exec_prepare_obj(exec, vm_bo->obj, num_fences);
+ ret = exec_prepare_obj(exec, vm_bo->obj, num_fences);
if (ret)
break;
@@ -1186,7 +1216,7 @@ drm_gpuvm_prepare_range(struct drm_gpuvm
*gpuvm, struct drm_exec *exec,
drm_gpuvm_for_each_va_range(va, gpuvm, addr, end) {
struct drm_gem_object *obj = va->gem.obj;
- ret = drm_exec_prepare_obj(exec, obj, num_fences);
+ ret = exec_prepare_obj(exec, obj, num_fences);
if (ret)
return ret;
}
diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
index f94fec9a8517..b3f82ec7fb17 100644
--- a/include/drm/drm_gpuvm.h
+++ b/include/drm/drm_gpuvm.h
@@ -544,26 +544,9 @@ struct drm_gpuvm_exec {
} extra;
};
-/**
- * drm_gpuvm_prepare_vm() - prepare the GPUVMs common dma-resv
- * @gpuvm: the _gpuvm
- * @exec: the _exec context
- * @num_fences: the amount of _fences to reserve
- *
- * Calls drm_exec_prepare_obj() for the GPUVMs dummy _gem_object.
- *
- * Using this function directly, it is the drivers responsibility to
call
- * drm_exec_init() and drm_exec_fini() accordingly.
- *
- * Returns: 0 on success, negative error code on failure.
- */
-static inline int
-drm_gpuvm_prepare_vm(struct drm_gpuvm *gpuvm,
- struct drm_exec *exec,
- unsigned int num_fences)
-{
- return drm_exec_prepare_obj(exec, gpuvm->r_obj, num_fences);
-}
+int drm_gpuvm_prepare_vm(struct drm_gpuvm *gpuvm,
+ struct drm_exec *exec,
+ unsigned int num_fences);
int drm_gpuvm_prepare_objects(struct drm_gpuvm *gpuvm,
struct drm_exec *exec,
Re: [PATCH 1/2] drm/sched: Rename priority MIN to LOW
Hi Luben,
Am 24.11.23 um 08:57 schrieb Christian König:
Am 24.11.23 um 06:27 schrieb Luben Tuikov:
Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW.
This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler
priorities
in ascending order,
DRM_SCHED_PRIORITY_LOW,
DRM_SCHED_PRIORITY_NORMAL,
DRM_SCHED_PRIORITY_HIGH,
DRM_SCHED_PRIORITY_KERNEL.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Alex Deucher
Cc: Christian König
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
Reviewed-by: Christian König
Looks like you missed one usage in Nouveau:
drivers/gpu/drm/nouveau/nouveau_sched.c:21:41: error:
‘DRM_SCHED_PRIORITY_MIN’ undeclared here (not in a function); did you
mean ‘DRM_SCHED_PRIORITY_LOW’?
21 | NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN,
| ^~
| DRM_SCHED_PRIORITY_LOW
This now results in a build error on drm-misc-next.
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 10 +-
include/drm/gpu_scheduler.h | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index e2ae9ba147ba97..5cb33ac99f7089 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -73,10 +73,10 @@ amdgpu_ctx_to_drm_sched_prio(int32_t ctx_prio)
return DRM_SCHED_PRIORITY_NORMAL;
case AMDGPU_CTX_PRIORITY_VERY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_NORMAL:
return DRM_SCHED_PRIORITY_NORMAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 62bb7fc7448ad9..1a25931607c514 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,7 +325,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h
b/drivers/gpu/drm/msm/msm_gpu.h
index 4252e3839fbc83..eb0c97433e5f8a 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -347,7 +347,7 @@ struct msm_gpu_perfcntr {
* DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in
some
* cases, so we don't use it (no need for kernel generated jobs).
*/
-#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_MIN)
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_LOW)
/**
* struct msm_file_private - per-drm_file context
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 20c9c561843ce1..cb7445be3cbb4e 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -88,7 +88,7 @@ int drm_sched_entity_init(struct drm_sched_entity
*entity,
drm_err(sched_list[0], "entity with out-of-bounds
priority:%u num_rqs:%u\n",
entity->priority, sched_list[0]->num_rqs);
entity->priority = max_t(s32, (s32)
sched_list[0]->num_rqs - 1,
- (s32) DRM_SCHED_PRIORITY_MIN);
+ (s32) DRM_SCHED_PRIORITY_LOW);
}
entity->rq = sched_list[0]->sched_rq[entity->priority];
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 044a8c4875ba64..b6d7bc49ff6ef4 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1052,7 +1052,7 @@ drm_sched_select_entity(struct
drm_gpu_scheduler *sched)
int i;
/* Kernel run queue has higher priority than normal run queue*/
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
drm_sched_rq_select_entity_fifo(sched,
sched->sched_rq[i]) :
drm_sched_rq_select_entity_rr(sched, sched->sched_rq[i]);
@@ -1291,7 +1291,7 @@ int drm_sched_init(struct drm_gpu_scheduler
*sched,
if
Re: [PATCH v2 04/12] drm/rockchip: vop2: clear afbc en and transform bit for cluster window at linear mode
On Wed, Nov 22, 2023 at 08:54:25PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> The enable bit and transform offset of cluster windows should be
> cleared when it work at linear mode, or we may have a iommu fault
> issue.
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 639dfebc6bd1..a019cc9bbd54 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1312,6 +1312,11 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> vop2_win_write(win, VOP2_WIN_AFBC_ROTATE_270, rotate_270);
> vop2_win_write(win, VOP2_WIN_AFBC_ROTATE_90, rotate_90);
> } else {
> + if (vop2_cluster_window(win)) {
> + vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 0);
> + vop2_win_write(win, VOP2_WIN_AFBC_TRANSFORM_OFFSET, 0);
> + }
> +
> vop2_win_write(win, VOP2_WIN_YRGB_VIR,
> DIV_ROUND_UP(fb->pitches[0], 4));
> }
>
> --
> 2.34.1
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH] drm/atomic-helpers: Invoke end_fb_access while owning plane state
Hi
Am 26.11.23 um 16:08 schrieb Alyssa Ross:
Thomas Zimmermann writes:
Invoke drm_plane_helper_funcs.end_fb_access before
drm_atomic_helper_commit_hw_done(). The latter function hands over
ownership of the plane state to the following commit, which might
free it. Releasing resources in end_fb_access then operates on undefined
state. This bug has been observed with non-blocking commits when they
are being queued up quickly.
Here is an example stack trace from the bug report. The plane state has
been free'd already, so the pages for drm_gem_fb_vunmap() are gone.
Unable to handle kernel paging request at virtual address 00010049
[...]
drm_gem_fb_vunmap+0x18/0x74
drm_gem_end_shadow_fb_access+0x1c/0x2c
drm_atomic_helper_cleanup_planes+0x58/0xd8
drm_atomic_helper_commit_tail+0x90/0xa0
commit_tail+0x15c/0x188
commit_work+0x14/0x20
For aborted commits, it is still ok to run end_fb_access as part of the
plane's cleanup. Add a test to drm_atomic_helper_cleanup_planes().
Reported-by: Alyssa Ross
Closes: https://lore.kernel.org/dri-devel/87leazm0ya@alyssa.is/
Suggested-by: Daniel Vetter
Fixes: 94d879eaf7fb ("drm/atomic-helper: Add {begin,end}_fb_access to plane
helpers")
Signed-off-by: Thomas Zimmermann
Cc: # v6.2+
---
drivers/gpu/drm/drm_atomic_helper.c | 17 +
1 file changed, 17 insertions(+)
I've been trying this patch for the last couple of days. Alas the
problem doesn't seem to have been resolved entirely, because I've had
the following Oopses:
Thanks for testing. I think I got the test in
drm_atomic_helper_cleanup_planes() wrong. I'll seend out an update soon.
Best regards
Thomas
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_init] Allocated
atomic state af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_plane_state]
Added [PLANE:31:plane-0] 01cc7517 state to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_crtc_state] Added
[CRTC:33:crtc-0] e546877a state to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_set_fb_for_plane] Set
[FB:37] for [PLANE:31:plane-0] state 01cc7517
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_connector_state]
Added [CONNECTOR:35:Unknown-1] 8cee195b state to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_check_only] checking
af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
Updating routing for [CONNECTOR:35:Unknown-1]
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
[CONNECTOR:35:Unknown-1] keeps [ENCODER:34:None-34], now on [CRTC:33:crtc-0]
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_nonblocking_commit]
committing af08a086 nonblocking
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_default_clear]
Clearing atomic state af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:__drm_atomic_state_free] Freeing
atomic state af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_init] Allocated
atomic state f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_plane_state]
Added [PLANE:31:plane-0] d3b51954 state to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_crtc_state] Added
[CRTC:33:crtc-0] e7c9e6b8 state to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_set_fb_for_plane] Set
[FB:38] for [PLANE:31:plane-0] state d3b51954
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_connector_state]
Added [CONNECTOR:35:Unknown-1] 016b7c7e state to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_check_only] checking
f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
Updating routing for [CONNECTOR:35:Unknown-1]
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
[CONNECTOR:35:Unknown-1] keeps [ENCODER:34:None-34], now on [CRTC:33:crtc-0]
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_default_clear]
Clearing atomic state f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:__drm_atomic_state_free] Freeing
atomic state f87a08e9
simple-framebuffer dd53a4000.framebuffer:
Re: [PATCH 2/6] drm/bridge: tc358775: Fix getting dsi host data lanes
+ dt maintainers I actually have the same fix, but with one additional detail, which I'm unsure about though: This looks at the data-lanes property of the *remote* endpoint whereas other bridge drivers (see tc358767, ti-sn65dsi83, lt8912b, anx7625) look at the local endpoint and I'm not sure what is correct. Yes I've been wondering about that too. Let's just move it over to the bridge node? We could produce a warning if the dsi host node has the data-lanes property.. No current in kernel users AFAIK. I haven't found any in-tree users either. In my patch, I first try the remote end and then the local end. But thinking more about it I don't think this is correct. Maybe we can do it the other way around, first try data-lanes of the local endpoint and if not found, then try the remote one. That way, we would at least be backwards compatible in the driver. And for the dt-bindings, make it mandatory to have a local data-lanes. -michael FYI, for omapdrm, we already have a legacy dt property "lanes" for the wiring that tells number of lanes used and the order of the lanes. Regards, Tony
Re: [PATCH 1/6] dt-bindings: tc358775: Add support for tc358765
* Michael Walle [231127 12:44]: > Hi, > > > The tc358765 is similar to tc358775 except for the stdby-gpios. > > Bad timing (for me). I'm about to send a bigger patch series for the > tc358775 which fixes the (completely) broken initialialization. And also > contains some of your fixes. OK cool, let's merge patches as needed then. Maybe ack the patches that can already be merged, and put together some merged set for the rest of the patches? Or let me know what you prefer, I'll be glad to test and tweak as needed for tc358765. > That being said, I intend to make the standby gpio optional also for the > tc358755, because it might just be hardwired on the board. OK that sounds good to me. > But second, I'm really curious if this bridge is working for you correctly > as it is at the moment. One particular thing I've noticed is that you must > release the reset while both the clock and the data lanes are in LP11 mode. > Otherwise, the bridge won't work properly (i.e. horizontally shifted > picture, or no picture at all). Yes things are working for me. But then again the bridge is initialized by the bootloader, and then Android kernel, and then I kexec to the mainline kernel. And this is with a tc358765 if that might make a difference. So I have not seen your reset issue. Andreas may be seeing it on another tc bridge variant though, so adding Andreas to the loop also. > What DSI host controller are you using? This is an old motorola mz617 tablet with a tc358765 bridge, so omapdrm. I do have one pending patch for omapdrm dsi to change the init order a bit so tc358765 probes reliably. But seems that's a separate issue from your reset issue, I'll post that to the lists too to discuss. What's the dsi host you have? Do you also have some separate i2c eeprom that's needed for initializing something or is that lcd panel specific? No idea what the eeprom is really doing here.. Regards, Tony
Re: Bug in the error handling in TTMs pool implementation
Am 27.11.23 um 13:24 schrieb Karolina Stolarek:
On 24.11.2023 16:53, Christian König wrote:
@Karolina do you of hand know a way how we could exercise this in a
TTM unit test? Basically we would need to redirect the
alloc_pages_node() symbol to an unit test internal function and let
it return an error (or something like that).
Do I understand correctly that you want to mock NULL from
alloc_pages_node() in ttm_pool_alloc_page()? I had a quick look at it,
and found a(n ugly) way to do it.
KUnit provides an API to redirect calls using
KUNIT_STATIC_STUB_REDIRECT that can be registered in the original
function and then overridden in the test. You can read more about the
mechanism in [1].
The problem is that we'd need to introduce a wrapper call for
alloc_pages_node() in TTM and expose it, so the function can be
substituted during the test. We can't directly modify
alloc_pages_node() due to cyclic dependencies caused by
kunit/static_stub.h.
For example, in ttm_pool.c, we'd have:
+struct page *ttm_alloc_pages_node(int nid, gfp_t gfp_mask,
+ unsigned int order)
+{
+ KUNIT_STATIC_STUB_REDIRECT(ttm_alloc_pages_node, nid, gfp_mask,
order);
+ return alloc_pages_node(nid, gfp_mask, order);
+}
+EXPORT_SYMBOL(ttm_alloc_pages_node);
+
/* Allocate pages of size 1 << order with the given gfp_flags */
static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t
gfp_flags,
unsigned int order)
(...)
if (!pool->use_dma_alloc) {
- p = alloc_pages_node(pool->nid, gfp_flags, order);
+ p = ttm_alloc_pages_node(pool->nid, gfp_flags, order);
if (p)
p->private = order;
return p;
And in the test we would say:
+static struct page *fake_ttm_alloc_pages_node(int nid, gfp_t gfp_mask,
+ unsigned int order)
+{
+ return NULL;
+}
+
+static void ttm_pool_alloc_failed(struct kunit *test)
+{
(...)
+ kunit_activate_static_stub(test, ttm_alloc_pages_node,
+ fake_ttm_alloc_pages_node);
+ err = ttm_pool_alloc(pool, tt, _ctx);
+ kunit_deactivate_static_stub(test, ttm_alloc_pages_node);
Christian, what do you think?
Yes, that was exactly what I was looking for.
And you are right that is indeed quite a bit ugly, I was hoping more
like adding debugging hooks or something like that.
Need to look into that in more detail, thanks for the pointer.
Regards,
Christian.
All the best,
Karolina
-
[1] -
https://lore.kernel.org/all/20230128074918.1180523-1-david...@google.com/
[PATCH v2 15/32] fbdev/udlfb: Select correct helpers
The driver uses deferred I/O. Select the correct helpers via FB_SYSMEM_HELPERS_DEFERRED in the Kconfig file. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index d110d89b21d46..de57bf59e0179 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -1696,11 +1696,7 @@ config FB_UDL depends on FB && USB depends on FB_DEVICE select FB_MODE_HELPERS - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO + select FB_SYSMEM_HELPERS_DEFERRED help This is a kernel framebuffer driver for DisplayLink USB devices. Supports fbdev clients like xf86-video-fbdev, kdrive, fbi, and -- 2.43.0
[PATCH v2 20/32] media/ivtvfb: Initialize fb_ops to fbdev I/O-memory helpers
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. This explictily sets
the read/write, draw and mmap callbacks to the correct default
implementation.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation to be invoked; hence requireing the I/O
helpers to be built in any case. Setting all callbacks in all
drivers explicitly will allow to make the I/O helpers optional.
This benefits systems that do not use these functions.
Set the callbacks via macros. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Andy Walls
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Hans Verkuil
---
drivers/media/pci/ivtv/Kconfig | 4 +---
drivers/media/pci/ivtv/ivtvfb.c | 6 +++---
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index 9be52101bc4f2..2498f9079b756 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -48,9 +48,7 @@ config VIDEO_IVTV_ALSA
config VIDEO_FB_IVTV
tristate "Conexant cx23415 framebuffer support"
depends on VIDEO_IVTV && FB
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
+ select FB_IOMEM_HELPERS
help
This is a framebuffer driver for the Conexant cx23415 MPEG
encoder/decoder.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 23c8c094e791b..410477e3e6216 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -927,17 +927,17 @@ static int ivtvfb_blank(int blank_mode, struct fb_info
*info)
static const struct fb_ops ivtvfb_ops = {
.owner = THIS_MODULE,
+ .fb_read= fb_io_read,
.fb_write = ivtvfb_write,
.fb_check_var = ivtvfb_check_var,
.fb_set_par = ivtvfb_set_par,
.fb_setcolreg = ivtvfb_setcolreg,
- .fb_fillrect= cfb_fillrect,
- .fb_copyarea= cfb_copyarea,
- .fb_imageblit = cfb_imageblit,
+ __FB_DEFAULT_IOMEM_OPS_DRAW,
.fb_cursor = NULL,
.fb_ioctl = ivtvfb_ioctl,
.fb_pan_display = ivtvfb_pan_display,
.fb_blank = ivtvfb_blank,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
/* Restore hardware after firmware restart */
--
2.43.0
[PATCH v2 06/32] fbdev/arcfb: Use generator macros for deferred I/O
Implement the driver's fops with the generator macros for deferred
I/O. Only requires per-driver code for the on-scren scanout buffer.
The generated helpers implement reading, writing and drawing on top
of that. Also update the selected Kconfig tokens accordingly.
Actual support for deferred I/O is missing from the driver. So
writing to memory-mapped pages does not automatically update the
scanout buffer.
Signed-off-by: Thomas Zimmermann
Cc: Jaya Kumar
Acked-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 5 +-
drivers/video/fbdev/arcfb.c | 113 +---
2 files changed, 27 insertions(+), 91 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 63956382ffb65..44bf622fc8d74 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -272,10 +272,7 @@ config FB_FM2
config FB_ARC
tristate "Arc Monochrome LCD board support"
depends on FB && (X86 || COMPILE_TEST)
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_SYSMEM_HELPERS_DEFERRED
help
This enables support for the Arc Monochrome LCD board. The board
is based on the KS-108 lcd controller and is typically a matrix
diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
index 7344e825543af..b2408543277ce 100644
--- a/drivers/video/fbdev/arcfb.c
+++ b/drivers/video/fbdev/arcfb.c
@@ -363,39 +363,6 @@ static void arcfb_lcd_update(struct arcfb_par *par,
unsigned int dx,
}
}
-static void arcfb_fillrect(struct fb_info *info,
- const struct fb_fillrect *rect)
-{
- struct arcfb_par *par = info->par;
-
- sys_fillrect(info, rect);
-
- /* update the physical lcd */
- arcfb_lcd_update(par, rect->dx, rect->dy, rect->width, rect->height);
-}
-
-static void arcfb_copyarea(struct fb_info *info,
- const struct fb_copyarea *area)
-{
- struct arcfb_par *par = info->par;
-
- sys_copyarea(info, area);
-
- /* update the physical lcd */
- arcfb_lcd_update(par, area->dx, area->dy, area->width, area->height);
-}
-
-static void arcfb_imageblit(struct fb_info *info, const struct fb_image *image)
-{
- struct arcfb_par *par = info->par;
-
- sys_imageblit(info, image);
-
- /* update the physical lcd */
- arcfb_lcd_update(par, image->dx, image->dy, image->width,
- image->height);
-}
-
static int arcfb_ioctl(struct fb_info *info,
unsigned int cmd, unsigned long arg)
{
@@ -436,76 +403,48 @@ static int arcfb_ioctl(struct fb_info *info,
}
}
-/*
- * this is the access path from userspace. they can seek and write to
- * the fb. it's inefficient for them to do anything less than 64*8
- * writes since we update the lcd in each write() anyway.
- */
-static ssize_t arcfb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
+static void arcfb_damage_range(struct fb_info *info, off_t off, size_t len)
{
- /* modded from epson 1355 */
-
- unsigned long p;
- int err;
- unsigned int fbmemlength,x,y,w,h, bitppos, startpos, endpos, bitcount;
- struct arcfb_par *par;
- unsigned int xres;
-
- if (!info->screen_buffer)
- return -ENODEV;
-
- p = *ppos;
- par = info->par;
- xres = info->var.xres;
- fbmemlength = (xres * info->var.yres)/8;
-
- if (p > fbmemlength)
- return -ENOSPC;
-
- err = 0;
- if ((count + p) > fbmemlength) {
- count = fbmemlength - p;
- err = -ENOSPC;
- }
-
- if (count) {
- char *base_addr;
-
- base_addr = info->screen_buffer;
- count -= copy_from_user(base_addr + p, buf, count);
- *ppos += count;
- err = -EFAULT;
- }
-
+ struct arcfb_par *par = info->par;
+ unsigned int xres = info->var.xres;
+ unsigned int bitppos, startpos, endpos, bitcount;
+ unsigned int x, y, width, height;
- bitppos = p*8;
+ bitppos = off * 8;
startpos = floorXres(bitppos, xres);
- endpos = ceilXres((bitppos + (count*8)), xres);
+ endpos = ceilXres((bitppos + (len * 8)), xres);
bitcount = endpos - startpos;
x = startpos % xres;
y = startpos / xres;
- w = xres;
- h = bitcount / xres;
- arcfb_lcd_update(par, x, y, w, h);
+ width = xres;
+ height = bitcount / xres;
+
+ arcfb_lcd_update(par, x, y, width, height);
+}
- if (count)
- return count;
- return err;
+static void arcfb_damage_area(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height)
+{
+ struct arcfb_par *par = info->par;
+
+ /* update the
[PATCH v2 21/32] fbdev/clps711x-fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
The driver previously selected drawing ops for system memory
although it operates on I/O memory. Fixed now.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 4 +---
drivers/video/fbdev/clps711x-fb.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index f9dab4c900332..6fc43b40acac3 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -146,10 +146,8 @@ config FB_ACORN
config FB_CLPS711X
tristate "CLPS711X LCD support"
depends on FB && (ARCH_CLPS711X || COMPILE_TEST)
+ select FB_IOMEM_HELPERS
select FB_MODE_HELPERS
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
select LCD_CLASS_DEVICE
select VIDEOMODE_HELPERS
help
diff --git a/drivers/video/fbdev/clps711x-fb.c
b/drivers/video/fbdev/clps711x-fb.c
index e956c90efcdcc..dcfd1fbbc7e10 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -155,13 +155,11 @@ static int clps711x_fb_blank(int blank, struct fb_info
*info)
static const struct fb_ops clps711x_fb_ops = {
.owner = THIS_MODULE,
+ FB_DEFAULT_IOMEM_OPS,
.fb_setcolreg = clps711x_fb_setcolreg,
.fb_check_var = clps711x_fb_check_var,
.fb_set_par = clps711x_fb_set_par,
.fb_blank = clps711x_fb_blank,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
};
static int clps711x_lcd_check_fb(struct lcd_device *lcddev, struct fb_info *fi)
--
2.43.0
[PATCH v2 27/32] fbdev: Rename FB_SYS_FOPS token to FB_SYSMEM_FOPS
Rename the token to harmonize naming among various helpers. For example, I/O-memory helpers use FB_IOMEM_FOPS. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/Kconfig | 4 ++-- drivers/video/fbdev/core/Kconfig | 6 +++--- drivers/video/fbdev/core/Makefile | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 37c8188752baf..d5909a9206ffd 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -1464,7 +1464,7 @@ config FB_VT8500 select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS) select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS) select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS + select FB_SYSMEM_FOPS select FB_MODE_HELPERS select VIDEOMODE_HELPERS help @@ -1477,7 +1477,7 @@ config FB_WM8505 select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS) select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS) select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS + select FB_SYSMEM_FOPS select FB_MODE_HELPERS select VIDEOMODE_HELPERS help diff --git a/drivers/video/fbdev/core/Kconfig b/drivers/video/fbdev/core/Kconfig index 7a3ed13bed708..faab5d50cac3c 100644 --- a/drivers/video/fbdev/core/Kconfig +++ b/drivers/video/fbdev/core/Kconfig @@ -129,7 +129,7 @@ config FB_LITTLE_ENDIAN endchoice -config FB_SYS_FOPS +config FB_SYSMEM_FOPS tristate depends on FB_CORE @@ -142,8 +142,8 @@ config FB_DMAMEM_HELPERS depends on FB_CORE select FB_SYS_COPYAREA select FB_SYS_FILLRECT - select FB_SYS_FOPS select FB_SYS_IMAGEBLIT + select FB_SYSMEM_FOPS config FB_IOMEM_FOPS tristate @@ -168,8 +168,8 @@ config FB_SYSMEM_HELPERS depends on FB_CORE select FB_SYS_COPYAREA select FB_SYS_FILLRECT - select FB_SYS_FOPS select FB_SYS_IMAGEBLIT + select FB_SYSMEM_FOPS config FB_SYSMEM_HELPERS_DEFERRED bool diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile index c1d657601b2be..d159747590869 100644 --- a/drivers/video/fbdev/core/Makefile +++ b/drivers/video/fbdev/core/Makefile @@ -32,6 +32,6 @@ obj-$(CONFIG_FB_IOMEM_FOPS)+= fb_io_fops.o obj-$(CONFIG_FB_SYS_FILLRECT) += sysfillrect.o obj-$(CONFIG_FB_SYS_COPYAREA) += syscopyarea.o obj-$(CONFIG_FB_SYS_IMAGEBLIT) += sysimgblt.o -obj-$(CONFIG_FB_SYS_FOPS) += fb_sys_fops.o +obj-$(CONFIG_FB_SYSMEM_FOPS) += fb_sys_fops.o obj-$(CONFIG_FB_SVGALIB) += svgalib.o obj-$(CONFIG_FB_DDC) += fb_ddc.o -- 2.43.0
[PATCH v2 16/32] fbdev/au1200fb: Set FBINFO_VIRTFB flag
The au1200fb driver operates on DMA-able system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/au1200fb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c index 98afd385c49cd..817c1ebb625b6 100644 --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1568,6 +1568,8 @@ static int au1200fb_init_fbinfo(struct au1200fb_device *fbdev) fbi->fix.mmio_len = 0; fbi->fix.accel = FB_ACCEL_NONE; + fbi->flags |= FBINFO_VIRTFB; + fbi->screen_buffer = fbdev->fb_mem; au1200fb_update_fbinfo(fbi); -- 2.43.0
[PATCH v2 19/32] fbdev/ps3fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-...@lists.ozlabs.org
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 5 +
drivers/video/fbdev/ps3fb.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4c82890887ba1..f9dab4c900332 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1715,10 +1715,7 @@ config FB_IBM_GXT4500
config FB_PS3
tristate "PS3 GPU framebuffer driver"
depends on FB && PS3_PS3AV
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_SYSMEM_HELPERS
help
Include support for the virtual frame buffer in the PS3 platform.
diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
index de81ad3a5d1ed..de8d78bf070a0 100644
--- a/drivers/video/fbdev/ps3fb.c
+++ b/drivers/video/fbdev/ps3fb.c
@@ -939,15 +939,12 @@ static const struct fb_ops ps3fb_ops = {
.owner = THIS_MODULE,
.fb_open= ps3fb_open,
.fb_release = ps3fb_release,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_SYSMEM_OPS_RDWR,
.fb_check_var = ps3fb_check_var,
.fb_set_par = ps3fb_set_par,
.fb_setcolreg = ps3fb_setcolreg,
.fb_pan_display = ps3fb_pan_display,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_SYSMEM_OPS_DRAW,
.fb_mmap= ps3fb_mmap,
.fb_blank = ps3fb_blank,
.fb_ioctl = ps3fb_ioctl,
--
2.43.0
[PATCH v2 07/32] auxdisplay/cfag12864bfb: Set FBINFO_VIRTFB flag
The cfag12864bfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Miguel Ojeda Reviewed-by: Javier Martinez Canillas Acked-by: Miguel Ojeda --- drivers/auxdisplay/cfag12864bfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/auxdisplay/cfag12864bfb.c b/drivers/auxdisplay/cfag12864bfb.c index 729845bcc803a..c0ba693845aaf 100644 --- a/drivers/auxdisplay/cfag12864bfb.c +++ b/drivers/auxdisplay/cfag12864bfb.c @@ -72,6 +72,7 @@ static int cfag12864bfb_probe(struct platform_device *device) if (!info) goto none; + info->flags = FBINFO_VIRTFB; info->screen_buffer = cfag12864b_buffer; info->screen_size = CFAG12864B_SIZE; info->fbops = _ops; -- 2.43.0
[PATCH v2 13/32] fbdev/sh_mobile_lcdcfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
The driver uses a mixture of DMA helpers and deferred I/O. That
probably needs fixing by a driver maintainer.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig| 7 ++-
drivers/video/fbdev/sh_mobile_lcdcfb.c | 10 +++---
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 44bf622fc8d74..1eab89a07bbc5 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1634,12 +1634,9 @@ config FB_SH_MOBILE_LCDC
depends on FB && HAVE_CLK && HAS_IOMEM
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
depends on FB_DEVICE
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
- select FB_DEFERRED_IO
select FB_BACKLIGHT
+ select FB_DEFERRED_IO
+ select FB_DMAMEM_HELPERS
help
Frame buffer driver for the on-chip SH-Mobile LCD controller.
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 5c99fc8a409fd..d84628de51893 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1488,13 +1488,10 @@ sh_mobile_lcdc_overlay_mmap(struct fb_info *info,
struct vm_area_struct *vma)
static const struct fb_ops sh_mobile_lcdc_overlay_ops = {
.owner = THIS_MODULE,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_blank = sh_mobile_lcdc_overlay_blank,
.fb_pan_display = sh_mobile_lcdc_overlay_pan,
+ __FB_DEFAULT_DMAMEM_OPS_DRAW,
.fb_ioctl = sh_mobile_lcdc_overlay_ioctl,
.fb_check_var = sh_mobile_lcdc_overlay_check_var,
.fb_set_par = sh_mobile_lcdc_overlay_set_par,
@@ -1966,8 +1963,7 @@ sh_mobile_lcdc_mmap(struct fb_info *info, struct
vm_area_struct *vma)
static const struct fb_ops sh_mobile_lcdc_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = sh_mobile_lcdc_setcolreg,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_fillrect= sh_mobile_lcdc_fillrect,
.fb_copyarea= sh_mobile_lcdc_copyarea,
.fb_imageblit = sh_mobile_lcdc_imageblit,
--
2.43.0
Re: [PATCH 1/6] dt-bindings: tc358775: Add support for tc358765
Hi, Am Montag, 27. November 2023, 13:44:30 CET schrieb Michael Walle: > Hi, > > > The tc358765 is similar to tc358775 except for the stdby-gpios. > > Bad timing (for me). I'm about to send a bigger patch series for the > tc358775 which fixes the (completely) broken initialialization. And also > contains some of your fixes. > > That being said, I intend to make the standby gpio optional also for the > tc358755, because it might just be hardwired on the board. > > But second, I'm really curious if this bridge is working for you correctly > as it is at the moment. One particular thing I've noticed is that you must > release the reset while both the clock and the data lanes are in LP11 mode. > Otherwise, the bridge won't work properly (i.e. horizontally shifted > picture, or no picture at all). Apparently this seems to be true for all Toshiba DSI bridges. The power on sequence for TC9595 (TC358767) also requires LP-11 before releasing the reset signal RESX. Additionally LP-11 is requires for using the DP AUX channel. This also relates to the patch set from Dmitry [1]. Best regards, Alexander [1] https://lore.kernel.org/dri-devel/20231016165355.1327217-1-dmitry.barysh...@linaro.org/ > What DSI host controller are you using? > > -michael -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider http://www.tq-group.com/
Re: [PATCH v2 13/17] drm/v3d: Create a CPU job extension for the timestamp query job
Hi Iago,
On 11/27/23 06:16, Iago Toral wrote:
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
(...)
+static void
+v3d_timestamp_query(struct v3d_cpu_job *job)
+{
+ struct v3d_timestamp_query_info *timestamp_query =
timestamp_query;
+ struct v3d_bo *bo = to_v3d_bo(job->base.bo[0]);
I presume there is an implicit expectation here that a timestamp query
job only has one BO where we are writing query results, right? Maybe we
should document this more explicitly in the uAPI and also check that we
have at least that one BO before trying to map it and write to it?
I'll do it.
Also, is there a reason why we take the job reference from job-
base.bo[0] instead of job->bo[0]?
job is a struct v3d_cpu_job, which has a struct v3d_job as base.
The BOs are stored on struct v3d_job, as this is a common functionality
of all job types.
Best Regards,
- Maíra
Iago
+ u8 *value_addr;
+
+ v3d_get_bo_vaddr(bo);
+
+ for (int i = 0; i < timestamp_query->count; i++) {
+ value_addr = ((u8 *) bo->vaddr) + timestamp_query-
queries[i].offset;
+ *((u64 *) value_addr) = i == 0 ? ktime_get_ns() :
0ull;
+
+ drm_syncobj_replace_fence(timestamp_query-
queries[i].syncobj,
+ job->base.done_fence);
+ }
+
+ v3d_put_bo_vaddr(bo);
+}
+
static struct dma_fence *
v3d_cpu_job_run(struct drm_sched_job *sched_job)
{
@@ -315,6 +352,7 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = {
[V3D_CPU_JOB_TYPE_INDIRECT_CSD] =
v3d_rewrite_csd_job_wg_counts_from_indirect,
+ [V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY] =
v3d_timestamp_query,
};
v3d->cpu_job = job;
@@ -504,7 +542,7 @@ static const struct drm_sched_backend_ops
v3d_cache_clean_sched_ops = {
static const struct drm_sched_backend_ops v3d_cpu_sched_ops = {
.run_job = v3d_cpu_job_run,
.timedout_job = v3d_generic_job_timedout,
- .free_job = v3d_sched_job_free
+ .free_job = v3d_cpu_job_free
};
int
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c
b/drivers/gpu/drm/v3d/v3d_submit.c
index b6707ef42706..2f03c8bca593 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -438,6 +438,64 @@ v3d_get_cpu_indirect_csd_params(struct drm_file
*file_priv,
NULL, >acquire_ctx);
}
+/* Get data for the query timestamp job submission. */
+static int
+v3d_get_cpu_timestamp_query_params(struct drm_file *file_priv,
+ struct drm_v3d_extension __user
*ext,
+ struct v3d_cpu_job *job)
+{
+ u32 __user *offsets, *syncs;
+ struct drm_v3d_timestamp_query timestamp;
+
+ if (!job) {
+ DRM_DEBUG("CPU job extension was attached to a GPU
job.\n");
+ return -EINVAL;
+ }
+
+ if (job->job_type) {
+ DRM_DEBUG("Two CPU job extensions were added to the
same CPU job.\n");
+ return -EINVAL;
+ }
+
+ if (copy_from_user(, ext, sizeof(timestamp)))
+ return -EFAULT;
+
+ if (timestamp.pad)
+ return -EINVAL;
+
+ job->job_type = V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY;
+
+ job->timestamp_query.queries =
kvmalloc_array(timestamp.count,
+ sizeof(struct
v3d_timestamp_query),
+ GFP_KERNEL);
+ if (!job->timestamp_query.queries)
+ return -ENOMEM;
+
+ offsets = u64_to_user_ptr(timestamp.offsets);
+ syncs = u64_to_user_ptr(timestamp.syncs);
+
+ for (int i = 0; i < timestamp.count; i++) {
+ u32 offset, sync;
+
+ if (copy_from_user(, offsets++,
sizeof(offset))) {
+ kvfree(job->timestamp_query.queries);
+ return -EFAULT;
+ }
+
+ job->timestamp_query.queries[i].offset = offset;
+
+ if (copy_from_user(, syncs++, sizeof(sync))) {
+ kvfree(job->timestamp_query.queries);
+ return -EFAULT;
+ }
+
+ job->timestamp_query.queries[i].syncobj =
drm_syncobj_find(file_priv, sync);
+ }
+ job->timestamp_query.count = timestamp.count;
+
+ return 0;
+}
+
/* Whenever userspace sets ioctl extensions, v3d_get_extensions
parses data
* according to the extension id (name).
*/
@@ -466,6 +524,9 @@ v3d_get_extensions(struct drm_file *file_priv,
case DRM_V3D_EXT_ID_CPU_INDIRECT_CSD:
ret =
v3d_get_cpu_indirect_csd_params(file_priv, user_ext, job);
break;
+ case DRM_V3D_EXT_ID_CPU_TIMESTAMP_QUERY:
+ ret =
v3d_get_cpu_timestamp_query_params(file_priv,
Re: [PATCH 3/4] arm64: dts: mediatek: mt8195: add DSI and MIPI DPHY nodes
Il 23/11/23 14:37, Michael Walle ha scritto: Add the two DSI controller node and the associated DPHY nodes. Individual boards have to enable them in the board device tree. Signed-off-by: Michael Walle Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v2 25/32] staging/sm750fb: Declare fb_ops as constant
On Mon, Nov 27, 2023 at 02:15:54PM +0100, Thomas Zimmermann wrote: > Split up lynxfb_ops and declare each as constant. The fb_ops > instance used to be modified while initializing the driver. It is > now constant and the driver picks the correct instance, depending > on the settings for acceleration and cursor support. > > Signed-off-by: Thomas Zimmermann > Cc: Sudip Mukherjee > Cc: Teddy Wang > Cc: Greg Kroah-Hartman > Cc: linux-stag...@lists.linux.dev > Acked-by: Javier Martinez Canillas > --- > drivers/staging/sm750fb/sm750.c | 59 +++-- > 1 file changed, 49 insertions(+), 10 deletions(-) Acked-by: Greg Kroah-Hartman
Re: [PATCH v2 26/32] staging/sm750fb: Initialize fb_ops with fbdev macros
On Mon, Nov 27, 2023 at 02:15:55PM +0100, Thomas Zimmermann wrote: > Initialize all instances of struct fb_ops with fbdev initializer > macros for framebuffers in I/O address space. Set the read/write, > draw and mmap callbacks to the correct implementation and avoid > implicit defaults. Also select the necessary helpers in Kconfig. > > Fbdev drivers sometimes rely on the callbacks being NULL for a > default I/O-memory-based implementation to be invoked; hence > requiring the I/O helpers to be built in any case. Setting all > callbacks in all drivers explicitly will allow to make the I/O > helpers optional. This benefits systems that do not use these > functions. > > Signed-off-by: Thomas Zimmermann > Cc: Sudip Mukherjee > Cc: Teddy Wang > Cc: Greg Kroah-Hartman > Cc: linux-stag...@lists.linux.dev > Reviewed-by: Javier Martinez Canillas Acked-by: Greg Kroah-Hartman
Re: [PATCH 1/2] drm/sched: Rename priority MIN to LOW
On 2023-11-27 08:55, Christian König wrote: > Hi Luben, > > Am 24.11.23 um 08:57 schrieb Christian König: >> Am 24.11.23 um 06:27 schrieb Luben Tuikov: >>> Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW. >>> >>> This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler >>> priorities >>> in ascending order, >>> DRM_SCHED_PRIORITY_LOW, >>> DRM_SCHED_PRIORITY_NORMAL, >>> DRM_SCHED_PRIORITY_HIGH, >>> DRM_SCHED_PRIORITY_KERNEL. >>> >>> Cc: Rob Clark >>> Cc: Abhinav Kumar >>> Cc: Dmitry Baryshkov >>> Cc: Danilo Krummrich >>> Cc: Alex Deucher >>> Cc: Christian König >>> Cc: linux-arm-...@vger.kernel.org >>> Cc: freedr...@lists.freedesktop.org >>> Cc: dri-devel@lists.freedesktop.org >>> Signed-off-by: Luben Tuikov >> >> Reviewed-by: Christian König > > Looks like you missed one usage in Nouveau: > > drivers/gpu/drm/nouveau/nouveau_sched.c:21:41: error: > ‘DRM_SCHED_PRIORITY_MIN’ undeclared here (not in a function); did you > mean ‘DRM_SCHED_PRIORITY_LOW’? > 21 | NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN, > | ^~ > | DRM_SCHED_PRIORITY_LOW > > This now results in a build error on drm-misc-next. I'm waiting for someone to R-B the fix I posted two days ago: https://lore.kernel.org/r/20231125192246.87268-2-ltuiko...@gmail.com -- Regards, Luben OpenPGP_0x4C15479431A334AF.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
TTM improvement and amdgpu fix
Hi guys, TTM has a feature which allows to specify placements for normal operation as well as when all domains are "busy" and don't have free space. Not very widely used since it was a bit inflexible and required making multiple placement lists. Replace the multiple lists with flags and start to use this in amdgpu as well. As future improvement we should probably re-work was "busy" means for a domain as well. Please comment and/or test. Thanks, Christian.
Re: [PATCH v2] drm/atomic-helpers: Invoke end_fb_access while owning plane state
Thomas Zimmermann writes:
> Invoke drm_plane_helper_funcs.end_fb_access before
> drm_atomic_helper_commit_hw_done(). The latter function hands over
> ownership of the plane state to the following commit, which might
> free it. Releasing resources in end_fb_access then operates on undefined
> state. This bug has been observed with non-blocking commits when they
> are being queued up quickly.
>
> Here is an example stack trace from the bug report. The plane state has
> been free'd already, so the pages for drm_gem_fb_vunmap() are gone.
>
> Unable to handle kernel paging request at virtual address 00010049
> [...]
> drm_gem_fb_vunmap+0x18/0x74
> drm_gem_end_shadow_fb_access+0x1c/0x2c
> drm_atomic_helper_cleanup_planes+0x58/0xd8
> drm_atomic_helper_commit_tail+0x90/0xa0
> commit_tail+0x15c/0x188
> commit_work+0x14/0x20
>
> For aborted commits, it is still ok to run end_fb_access as part of the
> plane's cleanup. Add a test to drm_atomic_helper_cleanup_planes().
>
> v2:
> * fix test in drm_atomic_helper_cleanup_planes()
>
> Reported-by: Alyssa Ross
> Closes: https://lore.kernel.org/dri-devel/87leazm0ya@alyssa.is/
> Suggested-by: Daniel Vetter
> Fixes: 94d879eaf7fb ("drm/atomic-helper: Add {begin,end}_fb_access to plane
> helpers")
> Signed-off-by: Thomas Zimmermann
> Cc: # v6.2+
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 17 +
> 1 file changed, 17 insertions(+)
Got this basically immediately. :(
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_init] Allocated
atomic state cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_plane_state]
Added [PLANE:31:plane-0] 4935bdca state to cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_crtc_state] Added
[CRTC:33:crtc-0] d25f613d state to cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_set_fb_for_plane] Set
[FB:38] for [PLANE:31:plane-0] state 4935bdca
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_connector_state]
Added [CONNECTOR:35:Unknown-1] 20d19f10 state to cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_check_only] checking
cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
Updating routing for [CONNECTOR:35:Unknown-1]
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
[CONNECTOR:35:Unknown-1] keeps [ENCODER:34:None-34], now on [CRTC:33:crtc-0]
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_nonblocking_commit]
committing cfb3f1f2 nonblocking
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_default_clear]
Clearing atomic state cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:__drm_atomic_state_free] Freeing
atomic state cfb3f1f2
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_init] Allocated
atomic state 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_plane_state]
Added [PLANE:31:plane-0] 83f22dc6 state to 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_crtc_state] Added
[CRTC:33:crtc-0] eec339c5 state to 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_set_fb_for_plane] Set
[FB:37] for [PLANE:31:plane-0] state 83f22dc6
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_connector_state]
Added [CONNECTOR:35:Unknown-1] 22495ce9 state to 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_check_only] checking
03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
Updating routing for [CONNECTOR:35:Unknown-1]
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
[CONNECTOR:35:Unknown-1] keeps [ENCODER:34:None-34], now on [CRTC:33:crtc-0]
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_default_clear]
Clearing atomic state 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:__drm_atomic_state_free] Freeing
atomic state 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_init] Allocated
atomic state 03dc0c0b
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_plane_state]
Added [PLANE:31:plane-0] 83f22dc6 state to 03dc0c0b
Re: [PATCH v2 0/2] drm/bridge: panel: Check device dependency before managing device link
On Mon, Nov 27, 2023 at 05:03:53PM +0100, Linus Walleij wrote: > On Mon, Nov 27, 2023 at 6:10 AM Liu Ying wrote: > > > This series aims to check panel device dependency upon DRM device before > > managing device link between them. It fixes eariler patches in v6.7-rc1 > > which tried to manage the link. Without this series, the link fails to > > be added for dependent panel devices and hence relevant panel bridges > > fail to be attached. A real broken panel is "novatek,nt35510" defined > > in arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts as reported by > > Linus Walleij. > > > > Patch 1 exports device_is_dependent() to modules as needed by patch 2. > > Patch 2 checks device dependency before managing the device link. > > > > Note that patch 2 is already in drm-misc/drm-misc-fixes and > > drm-misc/for-linux-next-fixes. Patch 1 needs to be reviewed and picked up. > > > > v2: > > * Introduce patch 1 to export device_is_dependent() to modules as needed by > > patch 2. > > > > Liu Ying (2): > > driver core: Export device_is_dependent() to modules > > drm/bridge: panel: Check device dependency before managing device link > > I just applied patch 1 directly to the drm-misc-fixes so we don't have to > revert and then re-apply patches, because that is a bigger evil. (We can't > rebase these branches...) Erm, you did wait for GKH or Rafael's ACK to do that, right? Maxime signature.asc Description: PGP signature
Re: [PATCH v2 1/2] driver core: Export device_is_dependent() to modules
Greg, Rafael, On Mon, Nov 27, 2023 at 01:14:13PM +0800, Liu Ying wrote: > Export device_is_dependent() since the drm_kms_helper module is starting > to use it. > > Signed-off-by: Liu Ying > --- > v2: > * Newly introduced as needed by patch 2. > > drivers/base/core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/base/core.c b/drivers/base/core.c > index 67ba592afc77..bfd2bf0364b7 100644 > --- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -328,6 +328,7 @@ int device_is_dependent(struct device *dev, void *target) > } > return ret; > } > +EXPORT_SYMBOL_GPL(device_is_dependent); So, a committer just applied this to drm-misc-fixes without your approval. Could you ack it? If you don't want to, we'll fix it. Maxime signature.asc Description: PGP signature
Re: [PATCH v9 07/12] clk: meson: add vclk driver
On Mon 27 Nov 2023 at 17:14, Neil Armstrong wrote:
> On 24/11/2023 15:41, Jerome Brunet wrote:
>> On Fri 24 Nov 2023 at 09:41, Neil Armstrong
>> wrote:
>>
>>> The VCLK and VCLK_DIV clocks have supplementary bits.
>>>
>>> The VCLK has a "SOFT RESET" bit to toggle after the whole
>>> VCLK sub-tree rate has been set, this is implemented in
>>> the gate enable callback.
>>>
>>> The VCLK_DIV clocks as enable and reset bits used to disable
>>> and reset the divider, associated with CLK_SET_RATE_GATE it ensures
>>> the rate is set while the divider is disabled and in reset mode.
>>>
>>> The VCLK_DIV enable bit isn't implemented as a gate since it's part
>>> of the divider logic and vendor does this exact sequence to ensure
>>> the divider is correctly set.
>>>
>>> Signed-off-by: Neil Armstrong
>>> ---
>>> drivers/clk/meson/Kconfig | 5 ++
>>> drivers/clk/meson/Makefile | 1 +
>>> drivers/clk/meson/vclk.c | 141
>>> +
>>> drivers/clk/meson/vclk.h | 51
>>> 4 files changed, 198 insertions(+)
>>>
>>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>>> index 29ffd14d267b..59a40a49f8e1 100644
>>> --- a/drivers/clk/meson/Kconfig
>>> +++ b/drivers/clk/meson/Kconfig
>>> @@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
>>> tristate
>>> select COMMON_CLK_MESON_REGMAP
>>> +config COMMON_CLK_MESON_VCLK
>>> + tristate
>>> + select COMMON_CLK_MESON_REGMAP
>>> +
>>> config COMMON_CLK_MESON_CLKC_UTILS
>>> tristate
>>> @@ -140,6 +144,7 @@ config COMMON_CLK_G12A
>>> select COMMON_CLK_MESON_EE_CLKC
>>> select COMMON_CLK_MESON_CPU_DYNDIV
>>> select COMMON_CLK_MESON_VID_PLL_DIV
>>> + select COMMON_CLK_MESON_VCLK
>> This particular line belong in the next patch
>>
>>> select MFD_SYSCON
>>> help
>>> Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
>>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>>> index 9ee4b954c896..9ba43fe7a07a 100644
>>> --- a/drivers/clk/meson/Makefile
>>> +++ b/drivers/clk/meson/Makefile
>>> @@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
>>> obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
>>> obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
>>> obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
>>> +obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
>>> # Amlogic Clock controllers
>>> diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
>>> new file mode 100644
>>> index ..47f08a52b49f
>>> --- /dev/null
>>> +++ b/drivers/clk/meson/vclk.c
>>> @@ -0,0 +1,141 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (c) 2023 Neil Armstrong
>>> + */
>>> +
>>> +#include
>>> +#include "vclk.h"
>>> +
>>> +/* The VCLK gate has a supplementary reset bit to pulse after ungating */
>>> +
>>> +static inline struct clk_regmap_vclk_data *
>>> +clk_get_regmap_vclk_data(struct clk_regmap *clk)
>>> +{
>>> + return (struct clk_regmap_vclk_data *)clk->data;
>>> +}
>>> +
>>> +static int clk_regmap_vclk_enable(struct clk_hw *hw)
>>> +{
>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>> + struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
>>> +
>>> + meson_parm_write(clk->map, >enable, 1);
>>> +
>>> + /* Do a reset pulse */
>>> + meson_parm_write(clk->map, >reset, 1);
>>> + meson_parm_write(clk->map, >reset, 0);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void clk_regmap_vclk_disable(struct clk_hw *hw)
>>> +{
>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>> + struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
>>> +
>>> + meson_parm_write(clk->map, >enable, 0);
>>> +}
>>> +
>>> +static int clk_regmap_vclk_is_enabled(struct clk_hw *hw)
>>> +{
>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>> + struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
>>> +
>>> + return meson_parm_read(clk->map, >enable);
>>> +}
>>> +
>>> +const struct clk_ops clk_regmap_vclk_ops = {
>>> + .enable = clk_regmap_vclk_enable,
>>> + .disable = clk_regmap_vclk_disable,
>>> + .is_enabled = clk_regmap_vclk_is_enabled,
>>> +};
>>> +EXPORT_SYMBOL_GPL(clk_regmap_vclk_ops);
>> s/clk_regmap_vclk/meson_vclk at least for what is exported, ideally most
>> all the code.
>> I get clk_regmap_ comes from code copied from clk_regmap.c.
>> The reason the this part is different (and not using parm) if that when
>> I converted amlogic to regmap, I hope we could make this generic,
>> possibly converging between aml and qcom (which was the only other
>> platform using regmap for clock at the time). This is why clk_regmap.c
>> is a bit different from the other driver.
>> For the aml specific drivers, best to look at the mpll or cpu-dyndiv one.
>>
>>> +
>>> +/* The VCLK Divider has supplementary reset & enable bits */
>>> +
>>> +static inline struct clk_regmap_vclk_div_data *
>>>
RE: [PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT
[AMD Official Use Only - General] -Original Message- From: amd-gfx On Behalf Of Hamza Mahfooz Sent: Monday, November 27, 2023 10:53 AM To: Christian König ; jani.nik...@linux.intel.com; kher...@redhat.com; d...@redhat.com; za...@vmware.com; Olsak, Marek ; linux-graphics-maintai...@vmware.com; amd-...@lists.freedesktop.org; nouv...@lists.freedesktop.org; intel-...@lists.freedesktop.org; virtualizat...@lists.linux.dev; spice-de...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Subject: Re: [PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT On 11/27/23 09:54, Christian König wrote: > Try to fill up VRAM as well by setting the busy flag on GTT allocations. > > This fixes the issue that when VRAM was evacuated for suspend it's > never filled up again unless the application is restarted. I found the subject description a bit misleading. Maybe use a Fixes tag describing it is a fix for suspend resume regression other than that, looks good to me. Acked-by: Rajneesh Bhardwaj > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2893 > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > index aa0dd6dad068..ddc8fb4db678 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > @@ -173,6 +173,12 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo > *abo, u32 domain) > abo->flags & AMDGPU_GEM_CREATE_PREEMPTIBLE ? > AMDGPU_PL_PREEMPT : TTM_PL_TT; > places[c].flags = 0; > + /* > + * When GTT is just an alternative to VRAM make sure that we > + * only use it as fallback and still try to fill up VRAM first. > + */ > + if (domain & AMDGPU_GEM_DOMAIN_VRAM) > + places[c].flags |= TTM_PL_FLAG_BUSY; > c++; > } > -- Hamza
Re: [Linaro-mm-sig] Re: [PATCH] dma-buf: fix check in dma_resv_add_fence
On 11/27/23 14:24, Christian König wrote:
Ping? Can I get an rb or acked-by for that?
Thanks,
Christian.
Am 15.11.23 um 10:30 schrieb Christian König:
It's valid to add the same fence multiple times to a dma-resv object and
we shouldn't need one extra slot for each.
Signed-off-by: Christian König
Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is
really later")
Cc: sta...@vger.kernel.org # v5.19+
Reviewed-by: Thomas Hellström
---
drivers/dma-buf/dma-resv.c | 2 +-
include/linux/dma-fence.h | 15 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 38b4110378de..eb8b733065b2 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -301,7 +301,7 @@ void dma_resv_add_fence(struct dma_resv *obj,
struct dma_fence *fence,
dma_resv_list_entry(fobj, i, obj, , _usage);
if ((old->context == fence->context && old_usage >= usage &&
- dma_fence_is_later(fence, old)) ||
+ dma_fence_is_later_or_same(fence, old)) ||
dma_fence_is_signaled(old)) {
dma_resv_list_set(fobj, i, fence, usage);
dma_fence_put(old);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index ebe78bd3d121..b3772edca2e6 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -498,6 +498,21 @@ static inline bool dma_fence_is_later(struct
dma_fence *f1,
return __dma_fence_is_later(f1->seqno, f2->seqno, f1->ops);
}
+/**
+ * dma_fence_is_later_or_same - return true if f1 is later or same
as f2
+ * @f1: the first fence from the same context
+ * @f2: the second fence from the same context
+ *
+ * Returns true if f1 is chronologically later than f2 or the same
fence. Both
+ * fences must be from the same context, since a seqno is not
re-used across
+ * contexts.
+ */
+static inline bool dma_fence_is_later_or_same(struct dma_fence *f1,
+ struct dma_fence *f2)
+{
+ return f1 == f2 || dma_fence_is_later(f1, f2);
+}
+
/**
* dma_fence_later - return the chronologically later fence
* @f1: the first fence from the same context
___
Linaro-mm-sig mailing list -- linaro-mm-...@lists.linaro.org
To unsubscribe send an email to linaro-mm-sig-le...@lists.linaro.org
Re: [PATCH 1/2] dt-bindings: display: bridge: samsung-dsim: Add i.MX7D support
On Mon, Nov 27, 2023 at 05:12:28PM +0100, Roland Hieber wrote: > From: Philipp Zabel > > Add support for the "fsl,imx7d-mipi-dsim" compatible used on i.MX7D. > > Signed-off-by: Philipp Zabel > Signed-off-by: Roland Hieber Acked-by: Conor Dooley Cheers, Conor. > --- > .../devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml | 4 > +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > index 4ed7a799ba26..e43fec560941 100644 > --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > @@ -27,7 +27,9 @@ properties: >- fsl,imx8mm-mipi-dsim >- fsl,imx8mp-mipi-dsim >- items: > - - const: fsl,imx8mn-mipi-dsim > + - enum: > + - fsl,imx7d-mipi-dsim > + - fsl,imx8mn-mipi-dsim >- const: fsl,imx8mm-mipi-dsim > >reg: > > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: mxsfb: Remove power-domains requirements for i.MX7D
On Mon, Nov 27, 2023 at 04:35:56PM +0100, Roland Hieber wrote:
> From: Philipp Zabel
>
> i.MX7D is documented as compatible with i.MX6SX, but it doesn't have the
> power-domain requirement. Limit the i.MX6SX power-domains requirement to
> i.MX6SX only.
I dont like this commit message tbh, I shouldn't have to go and dig out the
file to be able to understand what you are doing here - it should really be
explained that the imx7d falls back to the imx6sx, as otherwise this looks
like nothing at all to do with with imx7d.
Thanks,
Conor.
>
> Fixes: f62678a77d58 ("dt-bindings: mxsfb: Document i.MX8M/i.MX6SX/i.MX6SL
> power-domains property")
> Signed-off-by: Philipp Zabel
> Signed-off-by: Roland Hieber
> ---
> Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index fc11ab5fc465..83532959e51c 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -117,13 +117,19 @@ allOf:
>maxItems: 1
> clock-names:
>maxItems: 1
> + - if:
> + properties:
> +compatible:
> + const: fsl,imx6sx-lcdif
> +then:
> + required:
> +- power-domains
>- if:
>properties:
> compatible:
>contains:
> enum:
>- fsl,imx6sl-lcdif
> - - fsl,imx6sx-lcdif
>- fsl,imx8mm-lcdif
>- fsl,imx8mn-lcdif
>- fsl,imx8mp-lcdif
>
> ---
> base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
> change-id: 20231127-b4-dt-bindings-mxsfb-9a0676d08b4c
>
> Best regards,
> --
> Roland Hieber, Pengutronix e.K. | r...@pengutronix.de |
> Steuerwalder Str. 21 | https://www.pengutronix.de/ |
> 31137 Hildesheim, Germany| Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
>
signature.asc
Description: PGP signature
Re: [PATCH v2 06/17] drm/v3d: Decouple job allocation from job initiation
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
> We want to allow the IOCTLs to allocate the job without initiating
> it.
> This will be useful for the CPU job submission IOCTL, as the CPU job
> has
> the need to use information from the user extensions. Currently, the
> user extensions are parsed before the job allocation, making it
> impossible to fill the CPU job when parsing the user extensions.
> Therefore, decouple the job allocation from the job initiation.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/v3d/v3d_submit.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c
> b/drivers/gpu/drm/v3d/v3d_submit.c
> index fe46dd316ca0..ed1a310bbd2f 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
> @@ -135,6 +135,21 @@ void v3d_job_put(struct v3d_job *job)
> kref_put(>refcount, job->free);
> }
>
> +static int
> +v3d_job_allocate(void **container, size_t size)
> +{
> + if (*container)
> + return 0;
Mmm... is this really what we want? At least right now we expect
v3d_job_allocate to always allocate memory, is there any scenario in
which we would expect to call this with an already allocated container?
Iago
> +
> + *container = kcalloc(1, size, GFP_KERNEL);
> + if (!*container) {
> + DRM_ERROR("Cannot allocate memory for V3D job.\n");
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> static int
> v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
> void **container, size_t size, void (*free)(struct kref
> *ref),
> @@ -145,11 +160,9 @@ v3d_job_init(struct v3d_dev *v3d, struct
> drm_file *file_priv,
> bool has_multisync = se && (se->flags &
> DRM_V3D_EXT_ID_MULTI_SYNC);
> int ret, i;
>
> - *container = kcalloc(1, size, GFP_KERNEL);
> - if (!*container) {
> - DRM_ERROR("Cannot allocate memory for v3d job.");
> - return -ENOMEM;
> - }
> + ret = v3d_job_allocate(container, size);
> + if (ret)
> + return ret;
>
> job = *container;
> job->v3d = v3d;
Re: [PATCH v9 00/12] drm/meson: add support for MIPI DSI Display
Hi Vinod, On 24/11/2023 09:41, Neil Armstrong wrote: --- Neil Armstrong (12): dt-bindings: clk: g12a-clkc: add CTS_ENCL clock ids dt-bindings: soc: amlogic,meson-gx-hhi-sysctrl: add example covering meson-axg-hhi-sysctrl dt-bindings: phy: amlogic,meson-axg-mipi-pcie-analog: drop text about parent syscon and drop example dt-bindings: phy: amlogic,g12a-mipi-dphy-analog: drop unneeded reg property and example Could you pick patches 3 and 4 ? they are both reviewed. Thanks, Neil dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module clk: meson: g12a: add CTS_ENCL & CTS_ENCL_SEL clocks clk: meson: add vclk driver clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF drm/meson: gate px_clk when setting rate arm64: meson: g12-common: add the MIPI DSI nodes DONOTMERGE: arm64: meson: khadas-vim3l: add DSI panel arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + .../phy/amlogic,g12a-mipi-dphy-analog.yaml | 12 - .../phy/amlogic,meson-axg-mipi-pcie-analog.yaml| 17 - .../soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml | 33 ++ arch/arm64/boot/dts/amlogic/Makefile | 1 + arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 70 .../meson-g12b-bananapi-cm4-mnt-reform2.dts| 384 + .../boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi | 2 +- arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi | 74 .../boot/dts/amlogic/meson-sm1-khadas-vim3l.dts| 2 +- drivers/clk/meson/Kconfig | 5 + drivers/clk/meson/Makefile | 1 + drivers/clk/meson/g12a.c | 106 -- drivers/clk/meson/vclk.c | 141 drivers/clk/meson/vclk.h | 51 +++ drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 + include/dt-bindings/clock/g12a-clkc.h | 2 + 17 files changed, 858 insertions(+), 51 deletions(-) --- base-commit: b0b93834348aaf1a6e14693b4f1d17d3ec024257 change-id: 20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-b8e5217e1f4a Best regards,
Re: [PATCH v2 07/17] drm/v3d: Add a CPU job submission
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
> From: Melissa Wen
>
> Create a new type of job, a CPU job. A CPU job is a type of job that
> performs operations that requires CPU intervention. The overall idea
> is
> to use user extensions to enable different types of CPU job, allowing
> the
> CPU job to perform different operations according to the type of user
> externsion. The user extension ID identify the type of CPU job that
> must
> be dealt.
>
> Having a CPU job is interesting for synchronization purposes as a CPU
> job has a queue like any other V3D job and can be synchoronized by
> the
> multisync extension.
>
> Signed-off-by: Melissa Wen
> Co-developed-by: Maíra Canal
> Signed-off-by: Maíra Canal
> ---
>
(...)
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c
> b/drivers/gpu/drm/v3d/v3d_sched.c
> index fccbea2a5f2e..a32c91b94898 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -55,6 +55,12 @@ to_csd_job(struct drm_sched_job *sched_job)
> return container_of(sched_job, struct v3d_csd_job,
> base.base);
> }
>
> +static struct v3d_cpu_job *
> +to_cpu_job(struct drm_sched_job *sched_job)
> +{
> + return container_of(sched_job, struct v3d_cpu_job,
> base.base);
> +}
> +
> static void
> v3d_sched_job_free(struct drm_sched_job *sched_job)
> {
> @@ -262,6 +268,42 @@ v3d_csd_job_run(struct drm_sched_job *sched_job)
> return fence;
> }
>
> +static struct dma_fence *
> +v3d_cpu_job_run(struct drm_sched_job *sched_job)
> +{
> + struct v3d_cpu_job *job = to_cpu_job(sched_job);
> + struct v3d_dev *v3d = job->base.v3d;
> + struct v3d_file_priv *file = job->base.file->driver_priv;
> + u64 runtime;
> +
> + void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = { };
Shouldn't this be a static const? Also, maybe we want declare it
outside the function itself?
Iago
> +
> + v3d->cpu_job = job;
> +
> + if (job->job_type >= ARRAY_SIZE(v3d_cpu_job_fn)) {
> + DRM_DEBUG_DRIVER("Unknown CPU job: %d\n", job-
> >job_type);
> + return NULL;
> + }
> +
> + file->start_ns[V3D_CPU] = local_clock();
> + v3d->queue[V3D_CPU].start_ns = file->start_ns[V3D_CPU];
> +
> + v3d_cpu_job_fn[job->job_type](job);
> +
> + runtime = local_clock() - file->start_ns[V3D_CPU];
> +
> + file->enabled_ns[V3D_CPU] += runtime;
> + v3d->queue[V3D_CPU].enabled_ns += runtime;
> +
> + file->jobs_sent[V3D_CPU]++;
> + v3d->queue[V3D_CPU].jobs_sent++;
> +
> + file->start_ns[V3D_CPU] = 0;
> + v3d->queue[V3D_CPU].start_ns = 0;
> +
> + return NULL;
> +}
Re: [PATCH] drm/mxsfb: Switch to drmm_mode_config_init
Hi
Am 25.11.23 um 23:25 schrieb Marek Vasut:
Switch from deprecated unmanaged drm_mode_config_init() to
managed drmm_mode_config_init(). No functional change.
Signed-off-by: Marek Vasut
---
Cc: Daniel Vetter
Cc: David Airlie
Cc: Fabio Estevam
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: NXP Linux Team
Cc: Pengutronix Kernel Team
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: Stefan Agner
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 3bfa369b2507e..9f746852b8ff2 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -248,7 +248,11 @@ static int mxsfb_load(struct drm_device *drm,
pm_runtime_enable(drm->dev);
/* Modeset init */
- drm_mode_config_init(drm);
The corresponding call to drm_mode_config_cleanup() needs to be removed
as well.
Best regards
Thomas
+ ret = drmm_mode_config_init(drm);
+ if (ret) {
+ dev_err(drm->dev, "Failed to initialize mode config\n");
+ goto err_vblank;
+ }
ret = mxsfb_kms_init(mxsfb);
if (ret < 0) {
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH] drm/mxsfb: Drop extra space in request_irq args
Am 25.11.23 um 23:24 schrieb Marek Vasut: Drop extra space, no functional change. Signed-off-by: Marek Vasut --- Cc: Daniel Vetter Cc: David Airlie Cc: Fabio Estevam Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: NXP Linux Team Cc: Pengutronix Kernel Team Cc: Sascha Hauer Cc: Shawn Guo Cc: Stefan Agner Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Reviewed-by: Thomas Zimmermann --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 625c1bfc41733..3bfa369b2507e 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -197,7 +197,7 @@ static int mxsfb_irq_install(struct drm_device *dev, int irq) mxsfb_irq_disable(dev); - return request_irq(irq, mxsfb_irq_handler, 0, dev->driver->name, dev); + return request_irq(irq, mxsfb_irq_handler, 0, dev->driver->name, dev); } static void mxsfb_irq_uninstall(struct drm_device *dev) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH v9 08/12] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
>> >>> >>> I suspect mipi_dsi_pxclk_div was added to achieve fractional vclk/bitclk >>> ratios, >>> since it doesn't exist on AXG. Not sure we would ever need it... and none >>> of the other upstream DSI drivers supports such setups. >>> >>> The main reasons I set only mipi_dsi_pxclk in DT is because : >>> 1) the DSI controller requires a bitclk to respond, pclk is not enough >>> 2) GP0 is disabled with an invalid config at cold boot, thus we cannot >>> rely on a default/safe rate on an initial prepare_enable(). >>> This permits setting initial valid state for the DSI controller, while >>> the actual bitclk and vclk are calculated dynamically with panel/bridge >>> runtime parameters. >> Nothing against setting rate in DT when it is static. Setting it then >> overriding it is not easy to follow. > > Yup, would be simpler to only have parenting set in DT, since it must > stay static, I'm fine trying to move rate setup to code. > >> To work around GP0 not being set, assuming you want to keep rate >> propagation as it is, you could call clk_set_rate() on cts_encl (possibly w/o >> enabling it) to force a setup on gp0 then clk_prepare_enable() on >> pxclk. You'd get a your safe rate on GP0 and the clock you need on pxclk. >> It is a bit hackish. Might be better to claim gp0 in your driver to >> manage it directly, cutting rate propagation above it to control each >> branch of the subtree as you need. It seems you need to have control over >> that anyway and it would be clear GP0 is expected to belong to DSI. > > Controlling the PLL from the DSI controller seems violating too much layers, > DSI controller driver is not feed directly by the PLL so it's a non-sense > regarding DT properties. Not sure what you mean by this. You have shown in your the commit message that the DSI clocks make significant subtree. I don't see a problem if you need to manage the root of that subtree. I'd be great if you didn't need to, but it is what it is ... > > Setting a safe clock from the DSI controller probe is an idea, but again I > don't know which value I should use... You mentionned that the problem comes DSI bridges that needs to change at runtime. I don't know much about those TBH, but is there anyway you can come up with a static GP0 rate that would then be able to divide to serve all the rates bridge would need in your use case ? GP0 can go a lot higher than ~100MHz and there are dividers unused in the tree it seems. I suppose there is a finite number of required rate for each use case ? If there are not too many and there is a common divider that allows a common rate GP0 can do, it would solve your problem. It's a lot of if but It is worth checking. This is how audio works and DT assigned rate is a good match in this case. > > I'll review the clk parenting flags and try to hack something. > > Thanks, > Neil > >
Re: [PATCH 1/2] dt-bindings: display: simple: Add boe,bp101wx1-100 panel
On 27/11/2023 06:15, Tony Lindgren wrote: > This panel is found on Motorola mapphone tablets mz615 to mz617. > > Signed-off-by: Tony Lindgren Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v9 07/12] clk: meson: add vclk driver
On 24/11/2023 15:41, Jerome Brunet wrote:
On Fri 24 Nov 2023 at 09:41, Neil Armstrong wrote:
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 5 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141 +
drivers/clk/meson/vclk.h | 51
4 files changed, 198 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..59a40a49f8e1 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
@@ -140,6 +144,7 @@ config COMMON_CLK_G12A
select COMMON_CLK_MESON_EE_CLKC
select COMMON_CLK_MESON_CPU_DYNDIV
select COMMON_CLK_MESON_VID_PLL_DIV
+ select COMMON_CLK_MESON_VCLK
This particular line belong in the next patch
Indeed
select MFD_SYSCON
help
Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index ..47f08a52b49f
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Neil Armstrong
+ */
+
+#include
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct clk_regmap_vclk_data *
+clk_get_regmap_vclk_data(struct clk_regmap *clk)
+{
+ return (struct clk_regmap_vclk_data *)clk->data;
+}
+
+static int clk_regmap_vclk_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ meson_parm_write(clk->map, >enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, >reset, 1);
+ meson_parm_write(clk->map, >reset, 0);
+
+ return 0;
+}
+
+static void clk_regmap_vclk_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ meson_parm_write(clk->map, >enable, 0);
+}
+
+static int clk_regmap_vclk_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ return meson_parm_read(clk->map, >enable);
+}
+
+const struct clk_ops clk_regmap_vclk_ops = {
+ .enable = clk_regmap_vclk_enable,
+ .disable = clk_regmap_vclk_disable,
+ .is_enabled = clk_regmap_vclk_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_regmap_vclk_ops);
s/clk_regmap_vclk/meson_vclk at least for what is exported, ideally most
all the code.
I get clk_regmap_ comes from code copied from clk_regmap.c.
The reason the this part is different (and not using parm) if that when
I converted amlogic to regmap, I hope we could make this generic,
possibly converging between aml and qcom (which was the only other
platform using regmap for clock at the time). This is why clk_regmap.c
is a bit different from the other driver.
For the aml specific drivers, best to look at the mpll or cpu-dyndiv one.
Ack
+
+/* The VCLK Divider has supplementary reset & enable bits */
+
+static inline struct clk_regmap_vclk_div_data *
+clk_get_regmap_vclk_div_data(struct clk_regmap *clk)
+{
+ return (struct clk_regmap_vclk_div_data *)clk->data;
+}
+
+static unsigned long clk_regmap_vclk_div_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_div_data *vclk =
clk_get_regmap_vclk_div_data(clk);
+
+ return
Re: [PATCH v9 08/12] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
Hi, On 24/11/2023 16:32, Jerome Brunet wrote: On Fri 24 Nov 2023 at 16:15, Neil Armstrong wrote: On 24/11/2023 15:12, Jerome Brunet wrote: On Fri 24 Nov 2023 at 09:41, Neil Armstrong wrote: In order to setup the DSI clock, let's make the unused VCLK2 clock path configuration via CCF. The nocache option is removed from following clocks: - vclk2_sel - vclk2_input - vclk2_div - vclk2 - vclk_div1 - vclk2_div2_en - vclk2_div4_en - vclk2_div6_en - vclk2_div12_en - vclk2_div2 - vclk2_div4 - vclk2_div6 - vclk2_div12 - cts_encl_sel vclk2 and vclk2_div uses the newly introduced vclk regmap driver to handle the enable and reset bits. In order to set a rate on cts_encl via the vclk2 clock path, the NO_REPARENT flag is set on cts_encl_sel & vclk2_sel in order to keep CCF from selection a parent. The parents of cts_encl_sel & vclk2_sel are expected to be defined in DT. The following clock scheme is to be used for DSI: xtal \_ gp0_pll_dco \_ gp0_pll |- vclk2_sel | \_ vclk2_input | \_ vclk2_div |\_ vclk2 | \_ vclk2_div1 | \_ cts_encl_sel | \_ cts_encl -> to VPU LCD Encoder |- mipi_dsi_pxclk_sel \_ mipi_dsi_pxclk_div \_ mipi_dsi_pxclk-> to DSI controller The mipi_dsi_pxclk_div is set as RO in order to use the same GP0 for mipi_dsi_pxclk and vclk2_input. Could you explain a bit more this part of about the RO ops ? Maybe I'm missing something. You would be relying on the reset being always the way it. It is probable but not safe. A way to deal with the shared GP0 would be to: * cut rate propagation at mipi_dsi_pxclk_sel (already done) and (vclk2_sel - TBD) ... * Set GP0 base rate through assigned-clock-rate (which you already in patch 11) With this, I'm not sure anything needs to be RO for the rates to be set properly for each subtree. Also, with the subtree above and your example in patch 11, it looks odd that PXCLK is manually set through DT while ENCL is not. Both are input of dsi driver. So the deal is about dynamic setup of clocks for DSI bridges, not really for panels where we can probably know in advance the clock setup. In this particular case, we need to keep a ratio between the vclk and the DSI bitclk, the DSI bitclk is taken from mipi_dsi_pxclk and vclk is derived from gp0 via vclk2. If we set the bitclk rate via mipi_dsi_pxclk, CCF will try to use mipi_dsi_pxclk_div to achieve the rate, If you have CLK_RATE_PARENT on mipi_dsi_pxclk_sel, I'm not surprised it does that, but you don't :/ I'm quite surprised it would do that, or even could. Hmm, I need to recheck the clock tree again... seems I got lost in the different revisions... From your example setting 96Mhz on both gp0 and mipi_dsi_pxclk, since you've proposed RO-OPS, I suppose the divider is assumed to be 1 and stay like that forever. With rate propagation disabled mipi_dsi_pxclk_sel and GP0 is 96Mhz, CCF would have no choice but picking 1 as divider, so I don't understand how CCF would pick anything else and how RO-OPS help and it does it everytime I tried, breaking the vclk/bitclk ratio, and we have no way to know the gp0 rate in this case. If you really want to ensure the divider value is always 1, why not use a divider table allowing only 1 ? Adding a comment in the g12 clock driver would nice because this not obvious. It would be safer than relying on the reset value. Indeed, will switch to that I suspect mipi_dsi_pxclk_div was added to achieve fractional vclk/bitclk ratios, since it doesn't exist on AXG. Not sure we would ever need it... and none of the other upstream DSI drivers supports such setups. The main reasons I set only mipi_dsi_pxclk in DT is because : 1) the DSI controller requires a bitclk to respond, pclk is not enough 2) GP0 is disabled with an invalid config at cold boot, thus we cannot rely on a default/safe rate on an initial prepare_enable(). This permits setting initial valid state for the DSI controller, while the actual bitclk and vclk are calculated dynamically with panel/bridge runtime parameters. Nothing against setting rate in DT when it is static. Setting it then overriding it is not easy to follow. Yup, would be simpler to only have parenting set in DT, since it must stay static, I'm fine trying to move rate setup to code. To work around GP0 not being set, assuming you want to keep rate propagation as it is, you could call clk_set_rate() on cts_encl (possibly w/o enabling it) to force a setup on gp0 then clk_prepare_enable() on pxclk. You'd get a your safe rate on GP0 and the clock you need on pxclk. It is a bit hackish. Might be better to claim gp0 in your driver to manage it directly, cutting rate propagation above it to control each branch of the subtree as you need. It seems you need to have control over that anyway and it would be clear GP0 is expected to belong to DSI. Controlling the PLL from the DSI
Re: [PATCH v9 03/20] dt-bindings: gpu: Add Imagination Technologies PowerVR/IMG GPU
Hi Donald,
On Wed, Nov 22, 2023 at 5:36 PM Donald Robson wrote:
> From: Sarah Walker
>
> Add the device tree binding documentation for the IMG AXE GPU used in
> TI AM62 SoCs.
>
> Co-developed-by: Frank Binns
> Signed-off-by: Frank Binns
> Signed-off-by: Sarah Walker
> Signed-off-by: Donald Robson
Thanks for your patch, which is now commit 6a85c3b14728f0d5
("dt-bindings: gpu: Add Imagination Technologies PowerVR/IMG GPU") in
drm-misc/for-linux-next.
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +properties:
> + compatible:
> +items:
> + - enum:
> + - ti,am62-gpu
> + - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
Why the double "img", and not just "img,axe"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 07/17] drm/v3d: Add a CPU job submission
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
> From: Melissa Wen
>
> Create a new type of job, a CPU job. A CPU job is a type of job that
> performs operations that requires CPU intervention. The overall idea
> is
> to use user extensions to enable different types of CPU job, allowing
> the
> CPU job to perform different operations according to the type of user
> externsion. The user extension ID identify the type of CPU job that
s/externsion/extension
Iago
> must
> be dealt.
>
> Having a CPU job is interesting for synchronization purposes as a CPU
> job has a queue like any other V3D job and can be synchoronized by
> the
> multisync extension.
>
> Signed-off-by: Melissa Wen
> Co-developed-by: Maíra Canal
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/v3d/v3d_drv.c | 4 ++
> drivers/gpu/drm/v3d/v3d_drv.h | 14 +-
> drivers/gpu/drm/v3d/v3d_sched.c | 57 +++
> drivers/gpu/drm/v3d/v3d_submit.c | 79
>
> include/uapi/drm/v3d_drm.h | 17 +++
> 5 files changed, 170 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.c
> b/drivers/gpu/drm/v3d/v3d_drv.c
> index 44a1ca57d6a4..3debf37e7d9b 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.c
> +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> @@ -91,6 +91,9 @@ static int v3d_get_param_ioctl(struct drm_device
> *dev, void *data,
> case DRM_V3D_PARAM_SUPPORTS_MULTISYNC_EXT:
> args->value = 1;
> return 0;
> + case DRM_V3D_PARAM_SUPPORTS_CPU_QUEUE:
> + args->value = 1;
> + return 0;
> default:
> DRM_DEBUG("Unknown parameter %d\n", args->param);
> return -EINVAL;
> @@ -189,6 +192,7 @@ static const struct drm_ioctl_desc
> v3d_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(V3D_PERFMON_CREATE,
> v3d_perfmon_create_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(V3D_PERFMON_DESTROY,
> v3d_perfmon_destroy_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(V3D_PERFMON_GET_VALUES,
> v3d_perfmon_get_values_ioctl, DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(V3D_SUBMIT_CPU, v3d_submit_cpu_ioctl,
> DRM_RENDER_ALLOW | DRM_AUTH),
> };
>
> static const struct drm_driver v3d_drm_driver = {
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h
> b/drivers/gpu/drm/v3d/v3d_drv.h
> index 4db9ace66024..010b146140ad 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> @@ -19,7 +19,7 @@ struct reset_control;
>
> #define GMP_GRANULARITY (128 * 1024)
>
> -#define V3D_MAX_QUEUES (V3D_CACHE_CLEAN + 1)
> +#define V3D_MAX_QUEUES (V3D_CPU + 1)
>
> static inline char *v3d_queue_to_string(enum v3d_queue queue)
> {
> @@ -29,6 +29,7 @@ static inline char *v3d_queue_to_string(enum
> v3d_queue queue)
> case V3D_TFU: return "tfu";
> case V3D_CSD: return "csd";
> case V3D_CACHE_CLEAN: return "cache_clean";
> + case V3D_CPU: return "cpu";
> }
> return "UNKNOWN";
> }
> @@ -122,6 +123,7 @@ struct v3d_dev {
> struct v3d_render_job *render_job;
> struct v3d_tfu_job *tfu_job;
> struct v3d_csd_job *csd_job;
> + struct v3d_cpu_job *cpu_job;
>
> struct v3d_queue_state queue[V3D_MAX_QUEUES];
>
> @@ -312,6 +314,14 @@ struct v3d_csd_job {
> struct drm_v3d_submit_csd args;
> };
>
> +enum v3d_cpu_job_type {};
> +
> +struct v3d_cpu_job {
> + struct v3d_job base;
> +
> + enum v3d_cpu_job_type job_type;
> +};
> +
> struct v3d_submit_outsync {
> struct drm_syncobj *syncobj;
> };
> @@ -414,6 +424,8 @@ int v3d_submit_tfu_ioctl(struct drm_device *dev,
> void *data,
> struct drm_file *file_priv);
> int v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> +int v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
>
> /* v3d_irq.c */
> int v3d_irq_init(struct v3d_dev *v3d);
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c
> b/drivers/gpu/drm/v3d/v3d_sched.c
> index fccbea2a5f2e..a32c91b94898 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -55,6 +55,12 @@ to_csd_job(struct drm_sched_job *sched_job)
> return container_of(sched_job, struct v3d_csd_job,
> base.base);
> }
>
> +static struct v3d_cpu_job *
> +to_cpu_job(struct drm_sched_job *sched_job)
> +{
> + return container_of(sched_job, struct v3d_cpu_job,
> base.base);
> +}
> +
> static void
> v3d_sched_job_free(struct drm_sched_job *sched_job)
> {
> @@ -262,6 +268,42 @@ v3d_csd_job_run(struct drm_sched_job *sched_job)
> return fence;
> }
>
> +static struct dma_fence *
> +v3d_cpu_job_run(struct drm_sched_job *sched_job)
> +{
> + struct v3d_cpu_job *job = to_cpu_job(sched_job);
> + struct v3d_dev *v3d = job->base.v3d;
> + struct v3d_file_priv *file =
Re: [PATCH v1 0/3] Rockchip inno_hdmi update
Hi Johan, On Sun, Nov 26, 2023 at 11:55:03AM +0100, Johan Jonker wrote: > Combined update for the Rockchip inno_hdmi driver in a > somewhat similar way to what is proposed for the > "Create HDMI Connector infrastructure patch serie". > Keeping the inno_hdmi and rk3066_hdmi driver functions > comparable makes maintanance easier. It's not clear to me what your intent is exactly, these are my exact patches that you just sent again? Maxime signature.asc Description: PGP signature
