Re: [PATCH v4 12/18] staging: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
On Sat, Jul 15, 2023 at 08:51:54PM +0200, Thomas Zimmermann wrote: > The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct > fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do > not set it. > > Flags should signal differences from the default values. After cleaning > up all occurrences of FBINFO_DEFAULT, the token will be removed. > > v2: > * fix commit message (Miguel) > > Signed-off-by: Thomas Zimmermann > Acked-by: Sam Ravnborg > Cc: Greg Kroah-Hartman > Cc: Sudip Mukherjee > Cc: Teddy Wang Acked-by: Greg Kroah-Hartman
Re: [syzbot] [dri?] KMSAN: uninit-value in drm_mode_setcrtc
Hello, syzbot has tested the proposed patch and the reproducer did not trigger any issue: Reported-and-tested-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com Tested on: commit: d1d7f15c DO-NOT-SUBMIT: kmsan: add the kmsan_exceed_ma.. git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=101d3fdaa8 kernel config: https://syzkaller.appspot.com/x/.config?x=36e4a2f8150fbc62 dashboard link: https://syzkaller.appspot.com/bug?extid=4fad2e57beb6397ab2fc compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 patch: https://syzkaller.appspot.com/x/patch.diff?x=15430342a8 Note: testing is done by a robot and is best-effort only.
[PATCH] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc
The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.
#syz test: https://github.com/google/kmsan.git master
Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao
---
drivers/gpu/drm/drm_crtc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index df9bf3c9206e..d718c17ab1e9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -715,8 +715,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
- int ret;
- int i;
+ int ret, i, num_connectors;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -851,6 +850,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
+ num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned
long)crtc_req->set_connectors_ptr;
@@ -871,6 +871,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
connector_set[i] = connector;
+ num_connectors++;
}
}
@@ -879,7 +880,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
- set.num_connectors = crtc_req->count_connectors;
+ set.num_connectors = num_connectors;
set.fb = fb;
if (drm_drv_uses_atomic_modeset(dev))
@@ -892,7 +893,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
if (connector_set) {
- for (i = 0; i < crtc_req->count_connectors; i++) {
+ for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
--
2.34.1
[PATCH] drm/connector: mark enum counter value as private
Mark the DRM_MODE_COLORIMETRY_COUNT enum value as private in
kernel-doc to prevent a build warning:
include/drm/drm_connector.h:527: warning: Enum value
'DRM_MODE_COLORIMETRY_COUNT' not described in enum 'drm_colorspace'
Fixes: c627087cb164 ("drm/connector: Use common colorspace_names array")
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: Harry Wentland
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
---
include/drm/drm_connector.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20230714.orig/include/drm/drm_connector.h
+++ linux-next-20230714/include/drm/drm_connector.h
@@ -522,7 +522,7 @@ enum drm_colorspace {
DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED = 13,
DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT = 14,
DRM_MODE_COLORIMETRY_BT601_YCC = 15,
- /* not a valid value; merely used for counting */
+ /* private: not a valid value; merely used for counting */
DRM_MODE_COLORIMETRY_COUNT
};
Re: [PATCH] phy: Explicitly include correct DT includes
Am Freitag, 14. Juli 2023, 19:48:35 CEST schrieb Rob Herring: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring > --- > drivers/phy/rockchip/phy-rockchip-dphy-rx0.c | 1 - > drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 2 +- > drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 1 - > drivers/phy/rockchip/phy-rockchip-naneng-combphy.c| 3 ++- > drivers/phy/rockchip/phy-rockchip-snps-pcie3.c| 3 ++- Acked-by: Heiko Stuebner
[PATCH v4 16/18] fbdev/pxafb: Remove flag FBINFO_FLAG_DEFAULT
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Helge Deller --- drivers/video/fbdev/pxafb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c index c8c4677d06b4..beffb0602a2c 100644 --- a/drivers/video/fbdev/pxafb.c +++ b/drivers/video/fbdev/pxafb.c @@ -888,7 +888,6 @@ static void init_pxafb_overlay(struct pxafb_info *fbi, struct pxafb_layer *ofb, ofb->fb.var.vmode = FB_VMODE_NONINTERLACED; ofb->fb.fbops = &overlay_fb_ops; - ofb->fb.flags = FBINFO_FLAG_DEFAULT; ofb->fb.node= -1; ofb->fb.pseudo_palette = NULL; -- 2.41.0
[PATCH v4 17/18] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No
functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Helge Deller
---
include/linux/fb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d5c13f34b09..43458f582f35 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -383,7 +383,6 @@ struct fb_tile_ops {
#endif /* CONFIG_FB_TILEBLITTING */
/* FBINFO_* = fb_info.flags bit flags */
-#define FBINFO_DEFAULT 0
#define FBINFO_HWACCEL_DISABLED0x0002
/* When FBINFO_HWACCEL_DISABLED is set:
* Hardware acceleration is turned off. Software implementations
@@ -504,8 +503,6 @@ struct fb_info {
bool skip_vt_switch; /* no VT switch on suspend/resume required */
};
-#define FBINFO_FLAG_DEFAULTFBINFO_DEFAULT
-
/* This will go away
* fbset currently hacks in FB_ACCELF_TEXT into var.accel_flags
* when it wants to turn the acceleration engine on. This is
--
2.41.0
[PATCH v4 12/18] staging: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Greg Kroah-Hartman
Cc: Sudip Mukherjee
Cc: Teddy Wang
---
drivers/staging/fbtft/fbtft-core.c | 2 +-
drivers/staging/sm750fb/sm750.c| 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 3a4abf3bae40..eac1d570f437 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -684,7 +684,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct
fbtft_display *display,
info->var.transp.offset = 0;
info->var.transp.length = 0;
- info->flags = FBINFO_FLAG_DEFAULT | FBINFO_VIRTFB;
+ info->flags = FBINFO_VIRTFB;
par = info->par;
par->info = info;
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index c260f73cf570..79bcd5bd4938 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -807,7 +807,6 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int
index)
info->screen_base = crtc->v_screen;
pr_debug("screen_base vaddr = %p\n", info->screen_base);
info->screen_size = line_length * var->yres_virtual;
- info->flags = FBINFO_FLAG_DEFAULT | 0;
/* set info->fix */
fix->type = FB_TYPE_PACKED_PIXELS;
--
2.41.0
[PATCH v4 11/18] media: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Andy Walls Cc: Mauro Carvalho Chehab Cc: Hans Verkuil --- drivers/media/pci/ivtv/ivtvfb.c | 1 - drivers/media/test-drivers/vivid/vivid-osd.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c index 0aeb9daaee4c..23c8c094e791 100644 --- a/drivers/media/pci/ivtv/ivtvfb.c +++ b/drivers/media/pci/ivtv/ivtvfb.c @@ -1048,7 +1048,6 @@ static int ivtvfb_init_vidmode(struct ivtv *itv) /* Generate valid fb_info */ oi->ivtvfb_info.node = -1; - oi->ivtvfb_info.flags = FBINFO_FLAG_DEFAULT; oi->ivtvfb_info.par = itv; oi->ivtvfb_info.var = oi->ivtvfb_defined; oi->ivtvfb_info.fix = oi->ivtvfb_fix; diff --git a/drivers/media/test-drivers/vivid/vivid-osd.c b/drivers/media/test-drivers/vivid/vivid-osd.c index ec25edc679b3..051f1805a16d 100644 --- a/drivers/media/test-drivers/vivid/vivid-osd.c +++ b/drivers/media/test-drivers/vivid/vivid-osd.c @@ -310,7 +310,6 @@ static int vivid_fb_init_vidmode(struct vivid_dev *dev) /* Generate valid fb_info */ dev->fb_info.node = -1; - dev->fb_info.flags = FBINFO_FLAG_DEFAULT; dev->fb_info.par = dev; dev->fb_info.var = dev->fb_defined; dev->fb_info.fix = dev->fb_fix; -- 2.41.0
[PATCH v4 09/18] auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Acked-by: Miguel Ojeda Cc: Miguel Ojeda Cc: Robin van der Gracht --- drivers/auxdisplay/cfag12864bfb.c | 1 - drivers/auxdisplay/ht16k33.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/auxdisplay/cfag12864bfb.c b/drivers/auxdisplay/cfag12864bfb.c index c2cab7e2b126..729845bcc803 100644 --- a/drivers/auxdisplay/cfag12864bfb.c +++ b/drivers/auxdisplay/cfag12864bfb.c @@ -79,7 +79,6 @@ static int cfag12864bfb_probe(struct platform_device *device) info->var = cfag12864bfb_var; info->pseudo_palette = NULL; info->par = NULL; - info->flags = FBINFO_FLAG_DEFAULT; if (register_framebuffer(info) < 0) goto fballoced; diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c index edaf92b7ea77..df3f37651e45 100644 --- a/drivers/auxdisplay/ht16k33.c +++ b/drivers/auxdisplay/ht16k33.c @@ -646,7 +646,6 @@ static int ht16k33_fbdev_probe(struct device *dev, struct ht16k33_priv *priv, fbdev->info->var = ht16k33_fb_var; fbdev->info->bl_dev = bl; fbdev->info->pseudo_palette = NULL; - fbdev->info->flags = FBINFO_FLAG_DEFAULT; fbdev->info->par = priv; err = register_framebuffer(fbdev->info); -- 2.41.0
[PATCH v4 14/18] fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Jaya Kumar
Cc: Helge Deller
Cc: Peter Jones
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: Maik Broemme
Cc: Jingoo Han
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Michal Januszewski
---
drivers/video/fbdev/arcfb.c| 1 -
drivers/video/fbdev/aty/aty128fb.c | 1 -
drivers/video/fbdev/broadsheetfb.c | 2 +-
drivers/video/fbdev/da8xx-fb.c | 1 -
drivers/video/fbdev/efifb.c| 1 -
drivers/video/fbdev/goldfishfb.c | 1 -
drivers/video/fbdev/gxt4500.c | 3 +--
drivers/video/fbdev/hecubafb.c | 2 +-
drivers/video/fbdev/imxfb.c| 3 +--
drivers/video/fbdev/intelfb/intelfbdrv.c | 1 -
drivers/video/fbdev/metronomefb.c | 2 +-
drivers/video/fbdev/mx3fb.c| 1 -
drivers/video/fbdev/omap/omapfb_main.c | 1 -
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 1 -
drivers/video/fbdev/s3c-fb.c | 1 -
drivers/video/fbdev/sh_mobile_lcdcfb.c | 2 --
drivers/video/fbdev/sis/sis_main.c | 2 --
drivers/video/fbdev/sm501fb.c | 2 +-
drivers/video/fbdev/sm712fb.c | 1 -
drivers/video/fbdev/uvesafb.c | 3 +--
drivers/video/fbdev/vesafb.c | 2 +-
drivers/video/fbdev/vfb.c | 1 -
drivers/video/fbdev/vga16fb.c | 2 +-
drivers/video/fbdev/xen-fbfront.c | 2 +-
24 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
index 9aaea3be8281..cff11cb04a55 100644
--- a/drivers/video/fbdev/arcfb.c
+++ b/drivers/video/fbdev/arcfb.c
@@ -546,7 +546,6 @@ static int arcfb_probe(struct platform_device *dev)
par->c2io_addr = c2io_addr;
par->cslut[0] = 0x00;
par->cslut[1] = 0x06;
- info->flags = FBINFO_FLAG_DEFAULT;
spin_lock_init(&par->lock);
if (irq) {
par->irq = irq;
diff --git a/drivers/video/fbdev/aty/aty128fb.c
b/drivers/video/fbdev/aty/aty128fb.c
index 2d9320a52e51..b44fc78ccd4f 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -1927,7 +1927,6 @@ static int aty128_init(struct pci_dev *pdev, const struct
pci_device_id *ent)
/* fill in info */
info->fbops = &aty128fb_ops;
- info->flags = FBINFO_FLAG_DEFAULT;
par->lcd_on = default_lcd_on;
par->crt_on = default_crt_on;
diff --git a/drivers/video/fbdev/broadsheetfb.c
b/drivers/video/fbdev/broadsheetfb.c
index cb725a91b6bb..e51e14c29c55 100644
--- a/drivers/video/fbdev/broadsheetfb.c
+++ b/drivers/video/fbdev/broadsheetfb.c
@@ -1069,7 +1069,7 @@ static int broadsheetfb_probe(struct platform_device *dev)
mutex_init(&par->io_lock);
- info->flags = FBINFO_FLAG_DEFAULT | FBINFO_VIRTFB;
+ info->flags = FBINFO_VIRTFB;
info->fbdefio = &broadsheetfb_defio;
fb_deferred_io_init(info);
diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
index 60cd1286370f..988dedcf6be8 100644
--- a/drivers/video/fbdev/da8xx-fb.c
+++ b/drivers/video/fbdev/da8xx-fb.c
@@ -1463,7 +1463,6 @@ static int fb_probe(struct platform_device *device)
da8xx_fb_var.bits_per_pixel = lcd_cfg->bpp;
/* Initialize fbinfo */
- da8xx_fb_info->flags = FBINFO_FLAG_DEFAULT;
da8xx_fb_info->fix = da8xx_fb_fix;
da8xx_fb_info->var = da8xx_fb_var;
da8xx_fb_info->fbops = &da8xx_fb_ops;
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 3d7be69ab593..3391c8e84210 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -555,7 +555,6 @@ static int efifb_probe(struct platform_device *dev)
info->fbops = &efifb_ops;
info->var = efifb_defined;
info->fix = efifb_fix;
- info->flags = FBINFO_FLAG_DEFAULT;
orientation = drm_get_panel_orientation_quirk(efifb_defined.xres,
efifb_defined.yres);
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 6fa2108fd912..ef2528c3faa9 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -212,7 +212,6 @@ static int goldfish_fb_probe(struct platform_device *pdev)
height = readl(fb->reg_base + FB_GET_HEIGHT);
fb->fb.fbops= &goldfish_fb_ops;
-
[PATCH v4 18/18] fbdev: Document that framebuffer_alloc() returns zero'ed data
Most fbdev drivers depend on framebuffer_alloc() to initialize the allocated memory to 0. Document this guarantee. v3: * slightly reword the sentence (Miguel) Suggested-by: Miguel Ojeda Signed-off-by: Thomas Zimmermann Reviewed-by: Miguel Ojeda Reviewed-by: Sui Jingfeng Cc: Helge Deller --- drivers/video/fbdev/core/fb_info.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fb_info.c b/drivers/video/fbdev/core/fb_info.c index 8bdbefdd4b70..4847ebe50d7d 100644 --- a/drivers/video/fbdev/core/fb_info.c +++ b/drivers/video/fbdev/core/fb_info.c @@ -13,7 +13,8 @@ * * Creates a new frame buffer info structure. Also reserves @size bytes * for driver private data (info->par). info->par (if any) will be - * aligned to sizeof(long). + * aligned to sizeof(long). The new instances of struct fb_info and + * the driver private data are both cleared to zero. * * Returns the new structure, or NULL if an error occurred. * -- 2.41.0
[PATCH v4 05/18] fbdev: Remove FBINFO_DEFAULT from framebuffer_alloc()'ed structs
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Helge Deller
Cc: Nicolas Ferre
Cc: Benjamin Herrenschmidt
Cc: Ferenc Bakonyi
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Wei Liu
Cc: Dexuan Cui
Cc: Antonino Daplas
Cc: Maik Broemme
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Kristoffer Ericson
Cc: Hans de Goede
Cc: Steve Glendinning
Cc: Bernie Thompson
Cc: Florian Tobias Schandinat
---
drivers/video/fbdev/amifb.c | 5 ++---
drivers/video/fbdev/asiliantfb.c | 1 -
drivers/video/fbdev/atmel_lcdfb.c| 2 +-
drivers/video/fbdev/aty/atyfb_base.c | 3 +--
drivers/video/fbdev/aty/radeon_base.c| 3 +--
drivers/video/fbdev/bw2.c| 1 -
drivers/video/fbdev/carminefb.c | 1 -
drivers/video/fbdev/cg14.c | 2 +-
drivers/video/fbdev/cg3.c| 1 -
drivers/video/fbdev/cg6.c| 2 +-
drivers/video/fbdev/chipsfb.c| 1 -
drivers/video/fbdev/cirrusfb.c | 3 +--
drivers/video/fbdev/clps711x-fb.c| 1 -
drivers/video/fbdev/cobalt_lcdfb.c | 1 -
drivers/video/fbdev/ep93xx-fb.c | 1 -
drivers/video/fbdev/ffb.c| 3 +--
drivers/video/fbdev/fm2fb.c | 1 -
drivers/video/fbdev/gbefb.c | 1 -
drivers/video/fbdev/geode/gx1fb_core.c | 1 -
drivers/video/fbdev/geode/gxfb_core.c| 1 -
drivers/video/fbdev/geode/lxfb_core.c| 1 -
drivers/video/fbdev/grvga.c | 2 +-
drivers/video/fbdev/hgafb.c | 2 +-
drivers/video/fbdev/hitfb.c | 2 +-
drivers/video/fbdev/hyperv_fb.c | 2 --
drivers/video/fbdev/i740fb.c | 2 +-
drivers/video/fbdev/i810/i810_main.c | 4 ++--
drivers/video/fbdev/imsttfb.c| 3 +--
drivers/video/fbdev/intelfb/intelfbdrv.c | 4 ++--
drivers/video/fbdev/kyro/fbdev.c | 1 -
drivers/video/fbdev/leo.c| 1 -
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 2 +-
drivers/video/fbdev/mmp/fb/mmpfb.c | 2 +-
drivers/video/fbdev/neofb.c | 2 +-
drivers/video/fbdev/nvidia/nvidia.c | 4 ++--
drivers/video/fbdev/offb.c | 2 +-
drivers/video/fbdev/p9100.c | 1 -
drivers/video/fbdev/platinumfb.c | 1 -
drivers/video/fbdev/pm2fb.c | 3 +--
drivers/video/fbdev/pm3fb.c | 3 +--
drivers/video/fbdev/pmag-aa-fb.c | 1 -
drivers/video/fbdev/pmag-ba-fb.c | 1 -
drivers/video/fbdev/pmagb-b-fb.c | 1 -
drivers/video/fbdev/ps3fb.c | 2 +-
drivers/video/fbdev/pvr2fb.c | 2 +-
drivers/video/fbdev/pxa168fb.c | 2 +-
drivers/video/fbdev/q40fb.c | 1 -
drivers/video/fbdev/riva/fbdev.c | 3 +--
drivers/video/fbdev/s1d13xxxfb.c | 4 ++--
drivers/video/fbdev/savage/savagefb_driver.c | 3 +--
drivers/video/fbdev/simplefb.c | 1 -
drivers/video/fbdev/sis/sis_main.c | 3 +--
drivers/video/fbdev/skeletonfb.c | 2 +-
drivers/video/fbdev/smscufx.c| 2 +-
drivers/video/fbdev/sstfb.c | 1 -
drivers/video/fbdev/sunxvr1000.c | 1 -
drivers/video/fbdev/sunxvr2500.c | 1 -
drivers/video/fbdev/sunxvr500.c | 1 -
drivers/video/fbdev/tcx.c| 1 -
drivers/video/fbdev/tdfxfb.c | 2 +-
drivers/video/fbdev/tgafb.c | 2 +-
drivers/video/fbdev/tridentfb.c | 2 +-
drivers/video/fbdev/udlfb.c | 2 +-
drivers/video/fbdev/via/viafbdev.c | 2 +-
64 files changed, 41 insertions(+), 81 deletions(-)
diff --git a/drivers/video/fbdev/amifb.c b/drivers/video/fbdev/amifb.c
index d88265dbebf4..cea782283b9c 100644
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -2427,7 +2427,7 @@ static int amifb_set_par(struct fb_info *info)
info->fix.ywrapstep = 1;
info->fix.xpanstep = 0;
info->fix.ypanstep = 0;
- info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YWRAP |
+ info->flags = FBINFO_HWACCEL_YWRAP |
FBINFO_READS_FAST; /* override SCROLL_REDRAW */
} else {
info->fix.ywrapstep = 0;
@@ -2436,7 +2436,7 @@ static int amifb_set_par(struct fb_info *info)
else
info->fix.
[PATCH v4 15/18] fbdev/atafb: Remove flag FBINFO_FLAG_DEFAULT
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by a static declaration. So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Helge Deller --- drivers/video/fbdev/atafb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c index 2bc4089865e6..c4a420b791b9 100644 --- a/drivers/video/fbdev/atafb.c +++ b/drivers/video/fbdev/atafb.c @@ -3112,7 +3112,6 @@ static int __init atafb_probe(struct platform_device *pdev) #ifdef ATAFB_FALCON fb_info.pseudo_palette = current_par.hw.falcon.pseudo_palette; #endif - fb_info.flags = FBINFO_FLAG_DEFAULT; if (!fb_find_mode(&fb_info.var, &fb_info, mode_option, atafb_modedb, NUM_TOTAL_MODES, &atafb_modedb[defmode], -- 2.41.0
[PATCH v4 08/18] sh: mach-sh7763rdp: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flag
Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_.
v3:
* include board name in commit message (Adrian)
v2:
* assign FB_MODE_IS_UNKNOWN (Adrian)
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Acked-by: John Paul Adrian Glaubitz
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: John Paul Adrian Glaubitz
---
arch/sh/boards/mach-sh7763rdp/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sh/boards/mach-sh7763rdp/setup.c
b/arch/sh/boards/mach-sh7763rdp/setup.c
index 97e715e4e9b3..e25193001ea0 100644
--- a/arch/sh/boards/mach-sh7763rdp/setup.c
+++ b/arch/sh/boards/mach-sh7763rdp/setup.c
@@ -119,7 +119,7 @@ static struct fb_videomode sh7763fb_videomode = {
.vsync_len = 1,
.sync = 0,
.vmode = FB_VMODE_NONINTERLACED,
- .flag = FBINFO_FLAG_DEFAULT,
+ .flag = FB_MODE_IS_UNKNOWN,
};
static struct sh7760fb_platdata sh7763fb_def_pdata = {
--
2.41.0
[PATCH v4 07/18] vfio-mdev: Remove flag FBINFO_DEFAULT from fbdev sample driver
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Kirti Wankhede --- samples/vfio-mdev/mdpy-fb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c index 3c8001b9e407..cda477b28685 100644 --- a/samples/vfio-mdev/mdpy-fb.c +++ b/samples/vfio-mdev/mdpy-fb.c @@ -162,7 +162,6 @@ static int mdpy_fb_probe(struct pci_dev *pdev, } info->fbops = &mdpy_fb_ops; - info->flags = FBINFO_DEFAULT; info->pseudo_palette = par->palette; ret = register_framebuffer(info); -- 2.41.0
[PATCH v4 03/18] fbdev: Remove FBINFO_DEFAULT from kzalloc()'ed structs
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Helge Deller
Cc: Russell King
---
drivers/video/fbdev/controlfb.c | 2 +-
drivers/video/fbdev/cyber2000fb.c | 2 +-
drivers/video/fbdev/valkyriefb.c | 1 -
drivers/video/fbdev/vermilion/vermilion.c | 2 +-
drivers/video/fbdev/vt8500lcdfb.c | 3 +--
5 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 82eeb139c4eb..717134c141ff 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -775,7 +775,7 @@ static void __init control_init_info(struct fb_info *info,
struct fb_info_contro
info->par = &p->par;
info->fbops = &controlfb_ops;
info->pseudo_palette = p->pseudo_palette;
-info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
+ info->flags = FBINFO_HWACCEL_YPAN;
info->screen_base = p->frame_buffer + CTRLFB_OFF;
fb_alloc_cmap(&info->cmap, 256, 0);
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/drivers/video/fbdev/cyber2000fb.c
index 38c0a6866d76..98ea56a9abf1 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -1459,7 +1459,7 @@ static struct cfb_info *cyberpro_alloc_fb_info(unsigned
int id, char *name)
cfb->fb.var.accel_flags = FB_ACCELF_TEXT;
cfb->fb.fbops = &cyber2000fb_ops;
- cfb->fb.flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
+ cfb->fb.flags = FBINFO_HWACCEL_YPAN;
cfb->fb.pseudo_palette = cfb->pseudo_palette;
spin_lock_init(&cfb->reg_b0_lock);
diff --git a/drivers/video/fbdev/valkyriefb.c b/drivers/video/fbdev/valkyriefb.c
index b166b7cfe0e5..fd4488777032 100644
--- a/drivers/video/fbdev/valkyriefb.c
+++ b/drivers/video/fbdev/valkyriefb.c
@@ -535,7 +535,6 @@ static int __init valkyrie_init_info(struct fb_info *info,
{
info->fbops = &valkyriefb_ops;
info->screen_base = p->frame_buffer + 0x1000;
- info->flags = FBINFO_DEFAULT;
info->pseudo_palette = p->pseudo_palette;
info->par = &p->par;
return fb_alloc_cmap(&info->cmap, 256, 0);
diff --git a/drivers/video/fbdev/vermilion/vermilion.c
b/drivers/video/fbdev/vermilion/vermilion.c
index 32e74e02a02f..71584c775efd 100644
--- a/drivers/video/fbdev/vermilion/vermilion.c
+++ b/drivers/video/fbdev/vermilion/vermilion.c
@@ -477,7 +477,7 @@ static int vml_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
}
info = &vinfo->info;
- info->flags = FBINFO_DEFAULT | FBINFO_PARTIAL_PAN_OK;
+ info->flags = FBINFO_PARTIAL_PAN_OK;
err = vmlfb_enable_mmio(par);
if (err)
diff --git a/drivers/video/fbdev/vt8500lcdfb.c
b/drivers/video/fbdev/vt8500lcdfb.c
index 31d4e85b220c..42d39a9d5130 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -300,8 +300,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
fbi->fb.var.vmode = FB_VMODE_NONINTERLACED;
fbi->fb.fbops = &vt8500lcd_ops;
- fbi->fb.flags = FBINFO_DEFAULT
- | FBINFO_HWACCEL_COPYAREA
+ fbi->fb.flags = FBINFO_HWACCEL_COPYAREA
| FBINFO_HWACCEL_FILLRECT
| FBINFO_HWACCEL_YPAN
| FBINFO_VIRTFB
--
2.41.0
[PATCH v4 06/18] fbdev/fsl-diu-fb: Remove flag FBINFO_DEFAULT
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Timur Tabi Cc: Helge Deller --- drivers/video/fbdev/fsl-diu-fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c index 785eb8a06943..c62b48f27ba9 100644 --- a/drivers/video/fbdev/fsl-diu-fb.c +++ b/drivers/video/fbdev/fsl-diu-fb.c @@ -1476,7 +1476,7 @@ static int install_fb(struct fb_info *info) info->var.activate = FB_ACTIVATE_NOW; info->fbops = &fsl_diu_ops; - info->flags = FBINFO_DEFAULT | FBINFO_VIRTFB | FBINFO_PARTIAL_PAN_OK | + info->flags = FBINFO_VIRTFB | FBINFO_PARTIAL_PAN_OK | FBINFO_READS_FAST; info->pseudo_palette = mfbi->pseudo_palette; -- 2.41.0
[PATCH v4 13/18] fbdev: Remove FBINFO_FLAG_DEFAULT from kzalloc()'ed structs
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Helge Deller --- drivers/video/fbdev/amba-clcd.c | 1 - drivers/video/fbdev/matrox/matroxfb_crtc2.c | 5 ++--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c index e45338227be6..24d89e6fb780 100644 --- a/drivers/video/fbdev/amba-clcd.c +++ b/drivers/video/fbdev/amba-clcd.c @@ -461,7 +461,6 @@ static int clcdfb_register(struct clcd_fb *fb) } fb->fb.fbops= &clcdfb_ops; - fb->fb.flags= FBINFO_FLAG_DEFAULT; fb->fb.pseudo_palette = fb->cmap; strncpy(fb->fb.fix.id, clcd_name, sizeof(fb->fb.fix.id)); diff --git a/drivers/video/fbdev/matrox/matroxfb_crtc2.c b/drivers/video/fbdev/matrox/matroxfb_crtc2.c index 7655afa3fd50..372197c124de 100644 --- a/drivers/video/fbdev/matrox/matroxfb_crtc2.c +++ b/drivers/video/fbdev/matrox/matroxfb_crtc2.c @@ -603,9 +603,8 @@ static int matroxfb_dh_regit(const struct matrox_fb_info *minfo, void* oldcrtc2; m2info->fbcon.fbops = &matroxfb_dh_ops; - m2info->fbcon.flags = FBINFO_FLAG_DEFAULT; - m2info->fbcon.flags |= FBINFO_HWACCEL_XPAN | - FBINFO_HWACCEL_YPAN; + m2info->fbcon.flags = FBINFO_HWACCEL_XPAN | + FBINFO_HWACCEL_YPAN; m2info->fbcon.pseudo_palette = m2info->cmap; fb_alloc_cmap(&m2info->fbcon.cmap, 256, 1); -- 2.41.0
[PATCH v4 10/18] hid/picolcd: Remove flag FBINFO_FLAG_DEFAULT from fbdev driver
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Acked-by: Benjamin Tissoires Acked-by: Bruno Prémont Cc: "Bruno Prémont" Cc: Jiri Kosina Cc: Benjamin Tissoires --- drivers/hid/hid-picolcd_fb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c index dabcd054dad9..d726aaafb146 100644 --- a/drivers/hid/hid-picolcd_fb.c +++ b/drivers/hid/hid-picolcd_fb.c @@ -527,7 +527,6 @@ int picolcd_init_framebuffer(struct picolcd_data *data) info->var = picolcdfb_var; info->fix = picolcdfb_fix; info->fix.smem_len = PICOLCDFB_SIZE*8; - info->flags = FBINFO_FLAG_DEFAULT; fbdata = info->par; spin_lock_init(&fbdata->lock); -- 2.41.0
[PATCH v4 00/18] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special handling for driver modules. With
commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
and have no further effect.
Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
split this by the way the fb_info struct is being allocated. All flags
are cleared to zero during the allocation.
Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
an actual bug in how arch/sh uses the token for struct fb_videomode,
which is unrelated.
Patch 17 removes both flag constants from and patch 18
documents the zero'ed memory returned by framebuffer_alloc().
v4:
* clarify commit messages (Geert, Dan)
v3:
* sh: include board name in commit message (Adrian)
* docs: reword text (Miguel)
v2:
* sh: use FB_MODE_IS_UNKNOWN (Adrian)
* fix commit messages (Miguel)
* document framebuffer_alloc()'s zero'ed memory (Miguel)
[1]
https://lore.kernel.org/dri-devel/877crer8fm@minerva.mail-host-address-is-not-set/
Thomas Zimmermann (18):
drm: Remove flag FBINFO_DEFAULT from fbdev emulation
fbdev: Remove FBINFO_DEFAULT from static structs
fbdev: Remove FBINFO_DEFAULT from kzalloc()'ed structs
fbdev: Remove FBINFO_DEFAULT from devm_kzalloc()'ed structs
fbdev: Remove FBINFO_DEFAULT from framebuffer_alloc()'ed structs
fbdev/fsl-diu-fb: Remove flag FBINFO_DEFAULT
vfio-mdev: Remove flag FBINFO_DEFAULT from fbdev sample driver
sh: mach-sh7763rdp: Assign FB_MODE_IS_UNKNOWN to struct
fb_videomode.flag
auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
hid/picolcd: Remove flag FBINFO_FLAG_DEFAULT from fbdev driver
media: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
staging: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
fbdev: Remove FBINFO_FLAG_DEFAULT from kzalloc()'ed structs
fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs
fbdev/atafb: Remove flag FBINFO_FLAG_DEFAULT
fbdev/pxafb: Remove flag FBINFO_FLAG_DEFAULT
fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT
fbdev: Document that framebuffer_alloc() returns zero'ed data
arch/sh/boards/mach-sh7763rdp/setup.c | 2 +-
drivers/auxdisplay/cfag12864bfb.c | 1 -
drivers/auxdisplay/ht16k33.c | 1 -
drivers/gpu/drm/drm_fbdev_dma.c| 1 -
drivers/gpu/drm/drm_fbdev_generic.c| 1 -
drivers/gpu/drm/gma500/fbdev.c | 2 +-
drivers/gpu/drm/radeon/radeon_fbdev.c | 2 +-
drivers/hid/hid-picolcd_fb.c | 1 -
drivers/media/pci/ivtv/ivtvfb.c| 1 -
drivers/media/test-drivers/vivid/vivid-osd.c | 1 -
drivers/staging/fbtft/fbtft-core.c | 2 +-
drivers/staging/sm750fb/sm750.c| 1 -
drivers/video/fbdev/68328fb.c | 2 +-
drivers/video/fbdev/acornfb.c | 2 +-
drivers/video/fbdev/amba-clcd.c| 1 -
drivers/video/fbdev/amifb.c| 5 ++---
drivers/video/fbdev/arcfb.c| 1 -
drivers/video/fbdev/asiliantfb.c | 1 -
drivers/video/fbdev/atafb.c| 1 -
drivers/video/fbdev/atmel_lcdfb.c | 2 +-
drivers/video/fbdev/aty/aty128fb.c | 1 -
drivers/video/fbdev/aty/atyfb_base.c | 3 +--
drivers/video/fbdev/aty/radeon_base.c | 3 +--
drivers/video/fbdev/broadsheetfb.c | 2 +-
drivers/video/fbdev/bw2.c | 1 -
drivers/video/fbdev/carminefb.c| 1 -
drivers/video/fbdev/cg14.c | 2 +-
drivers/video/fbdev/cg3.c | 1 -
drivers/video/fbdev/cg6.c | 2 +-
drivers/video/fbdev/chipsfb.c | 1 -
drivers/video/fbdev/cirrusfb.c | 3 +--
drivers/video/fbdev/clps711x-fb.c | 1 -
drivers/video/fbdev/cobalt_lcdfb.c | 1 -
drivers/video/fbdev/controlfb.c| 2 +-
drivers/video/fbdev/core/fb_info.c | 3 ++-
drivers/video/fbdev/cyber2000fb.c | 2 +-
drivers/video/fbdev/da8xx-fb.c | 1 -
drivers/video/fbdev/efifb.c| 1 -
drivers/video/fbdev/ep93xx-fb.c| 1 -
drivers/video/fbdev/ffb.c | 3 +--
drivers/video/fbdev/fm2fb.c| 1 -
drivers/video/fbdev/fsl-diu-fb.c | 2 +-
drivers/video/fbdev/g364fb.c | 2 +-
drivers/video/fbdev/gbefb.c| 1 -
drivers/video/fbdev/geode/gx1fb_core.c | 1 -
drivers/video/fbdev/geode/gxfb_core.c | 1 -
drivers/video/fbdev/geode/lxfb_core.c | 1 -
drivers/video/fbdev/goldfishfb.c | 1 -
drivers/video/fbdev/grvga.c| 2 +-
drivers/video/fbdev/gxt4500.c | 3 +--
driv
[PATCH v4 02/18] fbdev: Remove FBINFO_DEFAULT from static structs
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by a static declaration. So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Helge Deller --- drivers/video/fbdev/68328fb.c | 2 +- drivers/video/fbdev/acornfb.c | 2 +- drivers/video/fbdev/g364fb.c | 2 +- drivers/video/fbdev/hpfb.c | 1 - drivers/video/fbdev/macfb.c| 1 - drivers/video/fbdev/maxinefb.c | 1 - 6 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/video/fbdev/68328fb.c b/drivers/video/fbdev/68328fb.c index 07d6e8dc686b..956dd2399cc0 100644 --- a/drivers/video/fbdev/68328fb.c +++ b/drivers/video/fbdev/68328fb.c @@ -448,7 +448,7 @@ static int __init mc68x328fb_init(void) fb_info.var.red.offset = fb_info.var.green.offset = fb_info.var.blue.offset = 0; } fb_info.pseudo_palette = &mc68x328fb_pseudo_palette; - fb_info.flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN; + fb_info.flags = FBINFO_HWACCEL_YPAN; if (fb_alloc_cmap(&fb_info.cmap, 256, 0)) return -ENOMEM; diff --git a/drivers/video/fbdev/acornfb.c b/drivers/video/fbdev/acornfb.c index 1b72edc01cfb..8fec21dfca09 100644 --- a/drivers/video/fbdev/acornfb.c +++ b/drivers/video/fbdev/acornfb.c @@ -694,7 +694,7 @@ static void acornfb_init_fbinfo(void) first = 0; fb_info.fbops = &acornfb_ops; - fb_info.flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN; + fb_info.flags = FBINFO_HWACCEL_YPAN; fb_info.pseudo_palette = current_par.pseudo_palette; strcpy(fb_info.fix.id, "Acorn"); diff --git a/drivers/video/fbdev/g364fb.c b/drivers/video/fbdev/g364fb.c index c5b7673ddc6c..0825cbde116e 100644 --- a/drivers/video/fbdev/g364fb.c +++ b/drivers/video/fbdev/g364fb.c @@ -219,7 +219,7 @@ int __init g364fb_init(void) fb_info.screen_base = (char *) G364_MEM_BASE; /* virtual kernel address */ fb_info.var = fb_var; fb_info.fix = fb_fix; - fb_info.flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN; + fb_info.flags = FBINFO_HWACCEL_YPAN; fb_alloc_cmap(&fb_info.cmap, 255, 0); diff --git a/drivers/video/fbdev/hpfb.c b/drivers/video/fbdev/hpfb.c index 77fbff47b1a8..406c1383cbda 100644 --- a/drivers/video/fbdev/hpfb.c +++ b/drivers/video/fbdev/hpfb.c @@ -287,7 +287,6 @@ static int hpfb_init_one(unsigned long phys_base, unsigned long virt_base) else strcat(fb_info.fix.id, "Catseye"); fb_info.fbops = &hpfb_ops; - fb_info.flags = FBINFO_DEFAULT; fb_info.var = hpfb_defined; fb_info.screen_base = (char *)fb_start; diff --git a/drivers/video/fbdev/macfb.c b/drivers/video/fbdev/macfb.c index 44ff860a3f37..5ca208d992cc 100644 --- a/drivers/video/fbdev/macfb.c +++ b/drivers/video/fbdev/macfb.c @@ -876,7 +876,6 @@ static int __init macfb_init(void) fb_info.var = macfb_defined; fb_info.fix = macfb_fix; fb_info.pseudo_palette = pseudo_palette; - fb_info.flags = FBINFO_DEFAULT; err = fb_alloc_cmap(&fb_info.cmap, video_cmap_len, 0); if (err) diff --git a/drivers/video/fbdev/maxinefb.c b/drivers/video/fbdev/maxinefb.c index 4e6b05232ae2..0ac1873b2acb 100644 --- a/drivers/video/fbdev/maxinefb.c +++ b/drivers/video/fbdev/maxinefb.c @@ -155,7 +155,6 @@ int __init maxinefb_init(void) fb_info.screen_base = (char *)maxinefb_fix.smem_start; fb_info.var = maxinefb_defined; fb_info.fix = maxinefb_fix; - fb_info.flags = FBINFO_DEFAULT; fb_alloc_cmap(&fb_info.cmap, 256, 0); -- 2.41.0
[PATCH v4 04/18] fbdev: Remove FBINFO_DEFAULT from devm_kzalloc()'ed structs
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Helge Deller --- drivers/video/fbdev/pxafb.c| 1 - drivers/video/fbdev/sa1100fb.c | 1 - drivers/video/fbdev/wm8505fb.c | 3 +-- drivers/video/fbdev/xilinxfb.c | 1 - 4 files changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c index 2a8b1dea3a67..c8c4677d06b4 100644 --- a/drivers/video/fbdev/pxafb.c +++ b/drivers/video/fbdev/pxafb.c @@ -1826,7 +1826,6 @@ static struct pxafb_info *pxafb_init_fbinfo(struct device *dev, fbi->fb.var.vmode = FB_VMODE_NONINTERLACED; fbi->fb.fbops = &pxafb_ops; - fbi->fb.flags = FBINFO_DEFAULT; fbi->fb.node= -1; addr = fbi; diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c index a2408bf00ca0..3d76ce111488 100644 --- a/drivers/video/fbdev/sa1100fb.c +++ b/drivers/video/fbdev/sa1100fb.c @@ -1089,7 +1089,6 @@ static struct sa1100fb_info *sa1100fb_init_fbinfo(struct device *dev) fbi->fb.var.vmode = FB_VMODE_NONINTERLACED; fbi->fb.fbops = &sa1100fb_ops; - fbi->fb.flags = FBINFO_DEFAULT; fbi->fb.monspecs= monspecs; fbi->fb.pseudo_palette = fbi->pseudo_palette; diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c index 10a8b1250103..5833147aa43d 100644 --- a/drivers/video/fbdev/wm8505fb.c +++ b/drivers/video/fbdev/wm8505fb.c @@ -285,8 +285,7 @@ static int wm8505fb_probe(struct platform_device *pdev) fbi->fb.fix.accel = FB_ACCEL_NONE; fbi->fb.fbops = &wm8505fb_ops; - fbi->fb.flags = FBINFO_DEFAULT - | FBINFO_HWACCEL_COPYAREA + fbi->fb.flags = FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN diff --git a/drivers/video/fbdev/xilinxfb.c b/drivers/video/fbdev/xilinxfb.c index 2aa3a528277f..768a281a8d2c 100644 --- a/drivers/video/fbdev/xilinxfb.c +++ b/drivers/video/fbdev/xilinxfb.c @@ -324,7 +324,6 @@ static int xilinxfb_assign(struct platform_device *pdev, drvdata->info.fix.line_length = pdata->xvirt * BYTES_PER_PIXEL; drvdata->info.pseudo_palette = drvdata->pseudo_palette; - drvdata->info.flags = FBINFO_DEFAULT; drvdata->info.var = xilinx_fb_var; drvdata->info.var.height = pdata->screen_height_mm; drvdata->info.var.width = pdata->screen_width_mm; -- 2.41.0
[PATCH v4 01/18] drm: Remove flag FBINFO_DEFAULT from fbdev emulation
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Patrik Jakobsson Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" --- drivers/gpu/drm/drm_fbdev_dma.c | 1 - drivers/gpu/drm/drm_fbdev_generic.c | 1 - drivers/gpu/drm/gma500/fbdev.c| 2 +- drivers/gpu/drm/radeon/radeon_fbdev.c | 2 +- 4 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_fbdev_dma.c b/drivers/gpu/drm/drm_fbdev_dma.c index f9b1f7cd31b7..ee7c265b0585 100644 --- a/drivers/gpu/drm/drm_fbdev_dma.c +++ b/drivers/gpu/drm/drm_fbdev_dma.c @@ -123,7 +123,6 @@ static int drm_fbdev_dma_helper_fb_probe(struct drm_fb_helper *fb_helper, drm_fb_helper_fill_info(info, fb_helper, sizes); info->fbops = &drm_fbdev_dma_fb_ops; - info->flags = FBINFO_DEFAULT; /* screen */ info->flags |= FBINFO_VIRTFB; /* system memory */ diff --git a/drivers/gpu/drm/drm_fbdev_generic.c b/drivers/gpu/drm/drm_fbdev_generic.c index b9343fb6cf13..a0ea042b1526 100644 --- a/drivers/gpu/drm/drm_fbdev_generic.c +++ b/drivers/gpu/drm/drm_fbdev_generic.c @@ -109,7 +109,6 @@ static int drm_fbdev_generic_helper_fb_probe(struct drm_fb_helper *fb_helper, drm_fb_helper_fill_info(info, fb_helper, sizes); info->fbops = &drm_fbdev_generic_fb_ops; - info->flags = FBINFO_DEFAULT; /* screen */ info->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST; diff --git a/drivers/gpu/drm/gma500/fbdev.c b/drivers/gpu/drm/gma500/fbdev.c index 054426549fc6..be8f5fbd5260 100644 --- a/drivers/gpu/drm/gma500/fbdev.c +++ b/drivers/gpu/drm/gma500/fbdev.c @@ -215,7 +215,7 @@ static int psb_fbdev_fb_probe(struct drm_fb_helper *fb_helper, } info->fbops = &psb_fbdev_fb_ops; - info->flags = FBINFO_DEFAULT; + /* Accessed stolen memory directly */ info->screen_base = dev_priv->vram_addr + backing->offset; info->screen_size = size; diff --git a/drivers/gpu/drm/radeon/radeon_fbdev.c b/drivers/gpu/drm/radeon/radeon_fbdev.c index f941e2e7cae6..68c06ac9acce 100644 --- a/drivers/gpu/drm/radeon/radeon_fbdev.c +++ b/drivers/gpu/drm/radeon/radeon_fbdev.c @@ -253,7 +253,7 @@ static int radeon_fbdev_fb_helper_fb_probe(struct drm_fb_helper *fb_helper, } info->fbops = &radeon_fbdev_fb_ops; - info->flags = FBINFO_DEFAULT; + /* radeon resume is fragile and needs a vt switch to help it along */ info->skip_vt_switch = false; -- 2.41.0
Re: [PATCH] fb: Explicitly include correct DT includes
Hi
Am 14.07.23 um 19:50 schrieb Rob Herring:
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring
[...]
@@ -48,7 +48,7 @@ int sbusfb_mmap_helper(struct sbus_mmap_map *map,
unsigned long map_offset = 0;
unsigned long off;
int i;
-
+
The various whitespace fixes should rather go into a separate patch. You
can add
Reviewed-by: Thomas Zimmermann
to the whitespace fix and the include cleanup.
Best regards
Thomas
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;
}
diff --git a/drivers/video/fbdev/sunxvr1000.c b/drivers/video/fbdev/sunxvr1000.c
index 490bd9a14763..17d61e1d11a6 100644
--- a/drivers/video/fbdev/sunxvr1000.c
+++ b/drivers/video/fbdev/sunxvr1000.c
@@ -8,7 +8,8 @@
#include
#include
#include
-#include
+#include
+#include
struct gfb_info {
struct fb_info *info;
diff --git a/drivers/video/fbdev/sunxvr2500.c b/drivers/video/fbdev/sunxvr2500.c
index 2cab4b9be68a..e64ec7d0caf9 100644
--- a/drivers/video/fbdev/sunxvr2500.c
+++ b/drivers/video/fbdev/sunxvr2500.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
diff --git a/drivers/video/fbdev/sunxvr500.c b/drivers/video/fbdev/sunxvr500.c
index 6ec358af1256..c4e01e871483 100644
--- a/drivers/video/fbdev/sunxvr500.c
+++ b/drivers/video/fbdev/sunxvr500.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
diff --git a/drivers/video/fbdev/tcx.c b/drivers/video/fbdev/tcx.c
index fc3ac2301b45..255eb57aefa2 100644
--- a/drivers/video/fbdev/tcx.c
+++ b/drivers/video/fbdev/tcx.c
@@ -17,7 +17,8 @@
#include
#include
#include
-#include
+#include
+#include
#include
#include
diff --git a/drivers/video/fbdev/xilinxfb.c b/drivers/video/fbdev/xilinxfb.c
index 2aa3a528277f..542baddd54ad 100644
--- a/drivers/video/fbdev/xilinxfb.c
+++ b/drivers/video/fbdev/xilinxfb.c
@@ -24,14 +24,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
-#include
-#include
+#include
#include
#include
--
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
Description: OpenPGP digital signature
[PATCH v5] Documentation/gpu: Add a VM_BIND async draft document
Add a motivation for and description of asynchronous VM_BIND operation v2: - Fix typos (Nirmoy Das) - Improve the description of a memory fence (Oak Zeng) - Add a reference to the document in the Xe RFC. - Add pointers to sample uAPI suggestions v3: - Address review comments (Danilo Krummrich) - Formatting fixes v4: - Address typos (Francois Dugast) - Explain why in-fences are not allowed for VM_BIND operations for long- running workloads (Matthew Brost) v5: - More typo- and style fixing - Further clarify the implications of disallowing in-fences for VM_BIND operations for long-running workloads (Matthew Brost) Signed-off-by: Thomas Hellström Acked-by: Nirmoy Das --- Documentation/gpu/drm-vm-bind-async.rst | 171 Documentation/gpu/rfc/xe.rst| 4 +- 2 files changed, 173 insertions(+), 2 deletions(-) create mode 100644 Documentation/gpu/drm-vm-bind-async.rst diff --git a/Documentation/gpu/drm-vm-bind-async.rst b/Documentation/gpu/drm-vm-bind-async.rst new file mode 100644 index ..d2b02a38198a --- /dev/null +++ b/Documentation/gpu/drm-vm-bind-async.rst @@ -0,0 +1,171 @@ + +Asynchronous VM_BIND + + +Nomenclature: += + +* ``VRAM``: On-device memory. Sometimes referred to as device local memory. + +* ``gpu_vm``: A GPU address space. Typically per process, but can be shared by + multiple processes. + +* ``VM_BIND``: An operation or a list of operations to modify a gpu_vm using + an IOCTL. The operations include mapping and unmapping system- or + VRAM memory. + +* ``syncobj``: A container that abstracts synchronization objects. The + synchronization objects can be either generic, like dma-fences or + driver specific. A syncobj typically indicates the type of the + underlying synchronization object. + +* ``in-syncobj``: Argument to a VM_BIND IOCTL, the VM_BIND operation waits + for these before starting. + +* ``out-syncobj``: Argument to a VM_BIND_IOCTL, the VM_BIND operation + signals these when the bind operation is complete. + +* ``memory fence``: A synchronization object, different from a dma-fence. + A memory fence uses the value of a specified memory location to determine + signaled status. A memory fence can be awaited and signaled by both + the GPU and CPU. Memory fences are sometimes referred to as + user-fences, userspace-fences or gpu futexes and do not necessarily obey + the dma-fence rule of signaling within a "reasonable amount of time". + The kernel should thus avoid waiting for memory fences with locks held. + +* ``long-running workload``: A workload that may take more than the + current stipulated dma-fence maximum signal delay to complete and + which therefore needs to set the gpu_vm or the GPU execution context in + a certain mode that disallows completion dma-fences. + +* ``exec function``: An exec function is a function that revalidates all + affected gpu_vmas, submits a GPU command batch and registers the + dma_fence representing the GPU command's activity with all affected + dma_resvs. For completeness, although not covered by this document, + it's worth mentioning that an exec function may also be the + revalidation worker that is used by some drivers in compute / + long-running mode. + +* ``bind context``: A context identifier used for the VM_BIND + operation. VM_BIND operations that use the same bind context can be + assumed, where it matters, to complete in order of submission. No such + assumptions can be made for VM_BIND operations using separate bind contexts. + +* ``UMD``: User-mode driver. + +* ``KMD``: Kernel-mode driver. + + +Synchronous / Asynchronous VM_BIND operation + + +Synchronous VM_BIND +___ +With Synchronous VM_BIND, the VM_BIND operations all complete before the +IOCTL returns. A synchronous VM_BIND takes neither in-fences nor +out-fences. Synchronous VM_BIND may block and wait for GPU operations; +for example swap-in or clearing, or even previous binds. + +Asynchronous VM_BIND + +Asynchronous VM_BIND accepts both in-syncobjs and out-syncobjs. While the +IOCTL may return immediately, the VM_BIND operations wait for the in-syncobjs +before modifying the GPU page-tables, and signal the out-syncobjs when +the modification is done in the sense that the next exec function that +awaits for the out-syncobjs will see the change. Errors are reported +synchronously assuming that the asynchronous part of the job never errors. +In low-memory situations the implementation may block, performing the +VM_BIND synchronously, because there might not be enough memory +immediately available for preparing the asynchronous operation. + +If the VM_BIND IOCTL takes a list or an array of operations as an argument, +the in-syncobjs needs to signal before the first operation starts to +execute, and the out-syncobjs signal after the last operation +completes. Operations in the opera
Re: [PATCH v2 0/2] DSIPHY RPM
On 11.07.2023 18:31, Dmitry Baryshkov wrote: > On 11/07/2023 17:21, Dmitry Baryshkov wrote: >> >> On Tue, 20 Jun 2023 13:43:19 +0200, Konrad Dybcio wrote: >>> Some recent SoCs use power rails that we model as GENPDs to power the >>> DSIPHY. This series attempts to make such configurations suspendable. >>> >>> Tested on SM6375. >>> >>> >> >> Applied, thanks! >> >> [1/2] drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks >> https://gitlab.freedesktop.org/lumag/msm/-/commit/a402e0e61b75 >> [2/2] drm/msm/dsi: Enable runtime PM >> https://gitlab.freedesktop.org/lumag/msm/-/commit/4e905c2acc9d > > Unfortunately this series breaks our CI, see [1], [2]. I had to remove these > patches for now. > > I suppose this is either because of a probe deferral or because of having > subset of drivers built as module. Konrad, could you please take a look? I see no reason why it would break things :/ You can see that rpmhpd sync_state has not completed, which means all PDs should still be pinned at max vote.. Can we somehow retest it? If it still fails, can you try enabling runtime pm on dispcc and hooking up vddcx? Konrad > > [1] https://gitlab.freedesktop.org/drm/msm/-/jobs/45271774 > [2] https://gitlab.freedesktop.org/drm/msm/-/jobs/45271775 >
Re: [PATCH 02/14] dt-bindings: display/msm/gmu: Allow passing QMP handle
On 4.07.2023 10:29, Krzysztof Kozlowski wrote: > On 28/06/2023 22:35, Konrad Dybcio wrote: >> When booting the GMU, the QMP mailbox should be pinged about some tunables >> (e.g. adaptive clock distribution state). To achieve that, a reference to >> it is necessary. Allow it and require it with A730. >> >> Signed-off-by: Konrad Dybcio >> --- >> Documentation/devicetree/bindings/display/msm/gmu.yaml | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml >> b/Documentation/devicetree/bindings/display/msm/gmu.yaml >> index 20ddb89a4500..9e6c4e0ab071 100644 >> --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml >> +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml >> @@ -64,6 +64,10 @@ properties: >>iommus: >> maxItems: 1 >> >> + qcom,qmp: >> +$ref: /schemas/types.yaml#/definitions/phandle >> +description: Phandle to the QMP mailbox > > mailbox would suggest you should use mailbox properties. That won't be a very strong argument at all, but the Linux mailbox framework did not at all fit the JSON-like nature of this mbox and it ended up being its own thing.. > Instead maybe > "Always On Subsystem (AOSS)" or just use existing description. I assume > it's exactly the same. I don't think I quite get what you mean. Konrad > > > Best regards, > Krzysztof >
Re: [PATCH 4/5] arm64: dts: qcom: qrb5165-rb5: enable displayport controller
On 9.07.2023 06:19, Dmitry Baryshkov wrote:
> Enable the onboard displayport controller, connect it to QMP PHY.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
Konrad
> arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> index a03f334a3d01..210c60025c32 100644
> --- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> +++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> @@ -656,6 +656,15 @@ &mdss {
> status = "okay";
> };
>
> +&mdss_dp {
> + status = "okay";
> +};
> +
> +&mdss_dp_out {
> + data-lanes = <0 1>;
> + remote-endpoint = <&usb_1_qmpphy_dp_in>;
> +};
> +
> &mdss_dsi0 {
> status = "okay";
> vdda-supply = <&vreg_l9a_1p2>;
> @@ -1436,3 +1445,7 @@ pm8150b_typec_sbu_out: endpoint {
> };
> };
> };
> +
> +&usb_1_qmpphy_dp_in {
> + remote-endpoint = <&mdss_dp_out>;
> +};
Re: [PATCH v3 00/19] Sitronix ST7789V improvements
Hi Sebastian, + Thomas s...@kernel.org wrote on Fri, 14 Jul 2023 03:37:37 +0200: > Hi, > > This adds panel support for Inanbo T28CP45TN89, which I found inside of a > handheld thermal camera. The panel is based on the st7789v controller. All > information is based on reverse engineering. I also appended the series > from Miquel Raynal adding EDT ET028013DMA panel support, so that I could > easily test it with my SPI_NO_RX setup. They are slightly different due > to rebasing. Thanks a lot! I'll continue following the series and provide my help when required. Cheers, Miquèl > > Changes since PATCHv2: > * https://lore.kernel.org/all/20230422205012.2464933-1-...@kernel.org/ > * > https://lore.kernel.org/all/20230616163255.2804163-1-miquel.ray...@bootlin.com/ > * Add Rob Herring's R-b for the DT binding > * Make panel info "static const" > * Add Michael Riesch's R-b to all my patches > * Rebase to 6.5-rc1 > * Append Miquel's series > > Changes since PATCHv1: > * https://lore.kernel.org/all/20230317232355.1554980-1-...@kernel.org/ > * Apply DT binding changes requested by Krzysztof Kozlowski and his Ack > * I changed the driver patches to avoid code duplication and splitted >the code a bit more > > Greetings, > > -- Sebastian > > Miquel Raynal (6): > dt-bindings: display: st7789v: Add the edt,et028013dma panel > compatible > dt-bindings: display: st7789v: bound the number of Rx data lines > drm/panel: sitronix-st7789v: Use 9 bits per spi word by default > drm/panel: sitronix-st7789v: Clarify a definition > drm/panel: sitronix-st7789v: Add EDT ET028013DMA panel support > drm/panel: sitronix-st7789v: Check display ID > > Sebastian Reichel (13): > dt-bindings: vendor-prefixes: add Inanbo > dt-bindings: display: st7789v: add Inanbo T28CP45TN89 > drm/panel: sitronix-st7789v: add SPI ID table > drm/panel: sitronix-st7789v: remove unused constants > drm/panel: sitronix-st7789v: make reset GPIO optional > drm/panel: sitronix-st7789v: simplify st7789v_spi_write > drm/panel: sitronix-st7789v: improve error handling > drm/panel: sitronix-st7789v: avoid hardcoding mode info > drm/panel: sitronix-st7789v: avoid hardcoding panel size > drm/panel: sitronix-st7789v: add media bus format > drm/panel: sitronix-st7789v: avoid hardcoding invert mode > drm/panel: sitronix-st7789v: avoid hardcoding polarity info > drm/panel: sitronix-st7789v: add Inanbo T28CP45TN89 support > > .../display/panel/sitronix,st7789v.yaml | 10 +- > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > .../gpu/drm/panel/panel-sitronix-st7789v.c| 262 +++--- > 3 files changed, 237 insertions(+), 37 deletions(-) >
Re: [BUG]: Getting a unique connector name when identical displays are connected
I have also seen this case... On Thu, Jul 13, 2023, 1:14 PM SUNIDHI DIXIT wrote: > Hello all, > > This is regarding an issue I have encountered recently in drm. When I > connect two identical HDMI display(with same resolution) there is no way to > distinguish them uniquely. > > I looked into that and found that the connector id, and connector_type_id > can be changed based on which connector appears first to the kernel. > > Is there any solution already implemented for this problem? > > I see following solution to this issue: > > Assigning a unique connector->name from drm_connector_init() and adding an > api drmModeGetConnectorName(). > > Please let me know what you think.. > > Thanks in advance! >
Re: [PATCH 2/3] drm/scheduler: Fix UAF in drm_sched_fence_get_timeline_name
15 July 2023 at 00:03, "Luben Tuikov" wrote: > > On 2023-07-14 05:57, Christian König wrote: > > > > > Am 14.07.23 um 11:49 schrieb Asahi Lina: > > > > > > > > On 14/07/2023 17.43, Christian König wrote: > > > > > > > Am 14.07.23 um 10:21 schrieb Asahi Lina: > > A signaled scheduler fence can outlive its scheduler, since fences are > > independencly reference counted. Therefore, we can't reference the > > scheduler in the get_timeline_name() implementation. > > > > Fixes oopses on `cat /sys/kernel/debug/dma_buf/bufinfo` when shared > > dma-bufs reference fences from GPU schedulers that no longer exist. > > > > Signed-off-by: Asahi Lina > > --- > > drivers/gpu/drm/scheduler/sched_entity.c | 7 ++- > > drivers/gpu/drm/scheduler/sched_fence.c | 4 +++- > > include/drm/gpu_scheduler.h | 5 + > > 3 files changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c > > b/drivers/gpu/drm/scheduler/sched_entity.c > > index b2bbc8a68b30..17f35b0b005a 100644 > > --- a/drivers/gpu/drm/scheduler/sched_entity.c > > +++ b/drivers/gpu/drm/scheduler/sched_entity.c > > @@ -389,7 +389,12 @@ static bool > > drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity) > > /* > > * Fence is from the same scheduler, only need to wait for > > - * it to be scheduled > > + * it to be scheduled. > > + * > > + * Note: s_fence->sched could have been freed and reallocated > > + * as another scheduler. This false positive case is okay, > > as if > > + * the old scheduler was freed all of its jobs must have > > + * signaled their completion fences. > > > > This is outright nonsense. As long as an entity for a scheduler exists > > it is not allowed to free up this scheduler. > > > > So this function can't be called like this. > > > > > > > > As I already explained, the fences can outlive their scheduler. That > > > means *this* entity certainly exists for *this* scheduler, but the > > > *dependency* fence might have come from a past scheduler that was > > > already destroyed along with all of its entities, and its address reused. > > > > > > > > > Well this is function is not about fences, this function is a callback > > for the entity. > > > > > > > > > > Christian, I'm really getting tired of your tone. I don't appreciate > > > being told my comments are "outright nonsense" when you don't even > > > take the time to understand what the issue is and what I'm trying to > > > do/document. If you aren't interested in working with me, I'm just > > > going to give up on drm_sched, wait until Rust gets workqueue support, > > > and reimplement it in Rust. You can keep your broken fence lifetime > > > semantics and I'll do my own thing. > > > > > > > > > I'm certainly trying to help here, but you seem to have unrealistic > > expectations. > > > > I perfectly understand what you are trying to do, but you don't seem to > > understand that this functionality here isn't made for your use case. > > > > We can adjust the functionality to better match your requirements, but > > you can't say it is broken because it doesn't work when you use it not > > in the way it is intended to be used. > > > > I believe "adjusting" functionality to fit some external requirements, > may have unintended consequences, requiring yet more and more "adjustments". > (Or may allow (new) drivers to do wild things which may lead to wild results. > :-) ) > > We need to be extra careful and wary of this. Either drm/scheduler is common code that we should use for our driver, in which case we need to "adjust" it to fit the requirements of a safe Rust abstraction usable for AGX. Or, drm/scheduler is not common code intended for drivers with our requirements, and then we need to be able to write our own scheduler. AMD has NAK'd both options, effectively NAK'ing the driver. I will ask a simple yes/no question: Should we use drm/sched? If yes, it will need patches like these, and AMD needs to be ok with that and stop NAK'ing them on sight becuase they don't match the existing requirements. If no, we will write our own scheduler in Rust, and AMD needs to be ok with that and not NAK it on sight because it's not drm/sched. Which is it? Note if we write a Rust scheduler, drm/sched and amdgpu will be unaffected. If we do that and AMD comes back and NAKs it -- as said in this thread would "probably" happen -- then it is impossible for us to upstream a driver regardless of whether we use drm/sched. Lina has been polite and accommodating while AMD calls her code "outright nonsense" and gets "outright NAK"s, and puts her into an impossible catch-22 where no matter what she does it's NAK'd. That's not ok.
[Bug 217664] Laptop doesnt wake up from suspend mode.
https://bugzilla.kernel.org/show_bug.cgi?id=217664 --- Comment #5 from popus_czy_to_ty (pentelja...@o2.pl) --- https://www.youtube.com/shorts/vuCrMdrtGdU - video of symptom BOE NV156FHM-N4G -display model NVIDIA-SMI 525.125.06 Driver Version: 525.125.06 CUDA Version: 12.0 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 12/12] drm/msm/adreno: Switch to chip-id for identifying GPU
On Sat, Jul 15, 2023 at 6:38 AM Konrad Dybcio wrote:
>
> On 7.07.2023 18:08, Rob Clark wrote:
> > On Thu, Jul 6, 2023 at 5:25 PM Konrad Dybcio
> > wrote:
> >>
> >> On 6.07.2023 23:10, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Since the revision becomes an opaque identifier with future GPUs, move
> >>> away from treating different ranges of bits as having a given meaning.
> >>> This means that we need to explicitly list different patch revisions in
> >>> the device table.
> >>>
> >>> Signed-off-by: Rob Clark
> >>> ---
> [...]
>
> >>> static inline int adreno_is_7c3(const struct adreno_gpu *gpu)
> >>> {
> >>> - /* The order of args is important here to handle ANY_ID correctly */
> >>> - return adreno_cmp_rev(ADRENO_REV(6, 3, 5, ANY_ID), gpu->rev);
> >>> + return gpu->info->chip_ids[0] == 0x06030500;
> >>> }
> >> I'm sorry, but this screams trouble.. and doesn't sound very maintainable
> >> :/
> >>
> >
> > why? It is intentionally checking the first chip-id so that nothing
> > breaks if later chip-ids are added
> checking for magic numbers and magic array indices at the same time is
> very prone to breaking, as breaking this check would not at all be easy
> to spot in code review.
It isn't like we can arbitrarily change the chip-id's.. they are abi
between dt/kernel/userspace. If they aren't changing, there isn't
anything to break.
> >
> >> Apart from all these comments, I don't really see the point of this patch,
> >> other than trying to tie together Qualcomm's almost-meaningless chipids on
> >> a7xx into the picture..
> >>
> >> Since they can't even be read back from the hardware, I don't think trying
> >> to force them into the upstream kernel makes any sense.
> >
> > Sure, we _could_ pick our own arbitrary identifiers, we don't have to
> > align with kgsl. But that would be a super huge PITA for mesa, which
> > has support for both kernels.
> Perhaps I'm biased towards keeping this kind of stuff out of the kernel,
> but I'd say that Linux should decide on one logical path.
The kernel is the small part of the driver stack, and we have two
drivers above in userspace (vk and gallium) which can work on top of
three different kernels (msm, kgsl, and virtgpu). So what sounds like
an easy/clean answer to you, is not necessarily easy/clean in the big
picture.
So wherever it comes from (and dt is fine, or socid or whatever, and
it's fine for it to just be an opaque 32b value as long as we don't
get conflicting values, I don't mind explicitly listing all of the
possible patch-id's for the legacy scheme) we need to stick with
CHIP_ID.
> In between us starting this discussion, Qualcomm managed to introduce
> yet another way of deciding what GPU is present on the system in their
> downstream driver[1]. We're at like 5 now. Do we wanna keep up each time?
> New ID rework for A8xx when that comes out one day?
What matters is how they expose it to userspace, not where they get
the value from.
BR,
-R
> >
> >> On a different note, I think we could try to blockify Adreno definitions a
> >> bit by splitting things into:
> >>
> >> - Core GPU propeties (revision, fw name, GMEM size)
> >>
> >> - G(P)MU properties
> >>
> >> - Family data (quirks, reg presets in some config struct which could be a
> >> union of config structs per generation, hwcg, maybe protected regs ptr
> >> should also be moved there)
> >
> > We do something like this on the mesa side. But we also get to use
> > python tricks to generate code as part of the build process which
> > makes things a bit more elegant.
> >
> > Fwiw, I was already thinking about splitting the gpu "hw catalog" from
> > a flat table, to probably something more like a table of tables, so
> > that we can split a2xx/a3xx/a4xx/a5xx/a6xx tables into separate files.
> > And then we could move hwcg/protect/etc tables into the same file.
> > But I thought that might be a bit too conflicty for the a7xx series so
> > was thinking to wait until after that landed.. unless you don't think
> > it will be a problem.
> Yeah I'd like to get a7xx landed this season..
>
> Konrad
>
> [1] they now read parts of socinfo from smem and decide the CHIPID and
> speedbin based on that, but it's not available on most existing SoCs,
> that was thrown in with SOCID v17
> >
> > BR,
> > -R
> >
> >> - Generation data (init function, a2xx and a6xx specifics)
> >>
> >> - Speedbin LUTs matched against socid
> >>
> >>
> >> or something like that.. there's a whole lot of duplicated data atm
> >>
> >> Konrad
> >>>
> >>> static inline int adreno_is_a660(const struct adreno_gpu *gpu)
> >>> @@ -358,8 +364,7 @@ static inline int adreno_is_a680(const struct
> >>> adreno_gpu *gpu)
> >>>
> >>> static inline int adreno_is_a690(const struct adreno_gpu *gpu)
> >>> {
> >>> - /* The order of args is important here to handle ANY_ID correctly */
> >>> - return adreno_cmp_rev(ADRENO_REV(6, 9, 0, ANY_ID), gpu->rev);
> >>> + return gpu->info->chip_ids[0] == 0x0609;
>
Re: [PATCH 12/12] drm/msm/adreno: Switch to chip-id for identifying GPU
On 7.07.2023 18:08, Rob Clark wrote:
> On Thu, Jul 6, 2023 at 5:25 PM Konrad Dybcio wrote:
>>
>> On 6.07.2023 23:10, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> Since the revision becomes an opaque identifier with future GPUs, move
>>> away from treating different ranges of bits as having a given meaning.
>>> This means that we need to explicitly list different patch revisions in
>>> the device table.
>>>
>>> Signed-off-by: Rob Clark
>>> ---
[...]
>>> static inline int adreno_is_7c3(const struct adreno_gpu *gpu)
>>> {
>>> - /* The order of args is important here to handle ANY_ID correctly */
>>> - return adreno_cmp_rev(ADRENO_REV(6, 3, 5, ANY_ID), gpu->rev);
>>> + return gpu->info->chip_ids[0] == 0x06030500;
>>> }
>> I'm sorry, but this screams trouble.. and doesn't sound very maintainable :/
>>
>
> why? It is intentionally checking the first chip-id so that nothing
> breaks if later chip-ids are added
checking for magic numbers and magic array indices at the same time is
very prone to breaking, as breaking this check would not at all be easy
to spot in code review.
>
>> Apart from all these comments, I don't really see the point of this patch,
>> other than trying to tie together Qualcomm's almost-meaningless chipids on
>> a7xx into the picture..
>>
>> Since they can't even be read back from the hardware, I don't think trying
>> to force them into the upstream kernel makes any sense.
>
> Sure, we _could_ pick our own arbitrary identifiers, we don't have to
> align with kgsl. But that would be a super huge PITA for mesa, which
> has support for both kernels.
Perhaps I'm biased towards keeping this kind of stuff out of the kernel,
but I'd say that Linux should decide on one logical path.
In between us starting this discussion, Qualcomm managed to introduce
yet another way of deciding what GPU is present on the system in their
downstream driver[1]. We're at like 5 now. Do we wanna keep up each time?
New ID rework for A8xx when that comes out one day?
>
>> On a different note, I think we could try to blockify Adreno definitions a
>> bit by splitting things into:
>>
>> - Core GPU propeties (revision, fw name, GMEM size)
>>
>> - G(P)MU properties
>>
>> - Family data (quirks, reg presets in some config struct which could be a
>> union of config structs per generation, hwcg, maybe protected regs ptr
>> should also be moved there)
>
> We do something like this on the mesa side. But we also get to use
> python tricks to generate code as part of the build process which
> makes things a bit more elegant.
>
> Fwiw, I was already thinking about splitting the gpu "hw catalog" from
> a flat table, to probably something more like a table of tables, so
> that we can split a2xx/a3xx/a4xx/a5xx/a6xx tables into separate files.
> And then we could move hwcg/protect/etc tables into the same file.
> But I thought that might be a bit too conflicty for the a7xx series so
> was thinking to wait until after that landed.. unless you don't think
> it will be a problem.
Yeah I'd like to get a7xx landed this season..
Konrad
[1] they now read parts of socinfo from smem and decide the CHIPID and
speedbin based on that, but it's not available on most existing SoCs,
that was thrown in with SOCID v17
>
> BR,
> -R
>
>> - Generation data (init function, a2xx and a6xx specifics)
>>
>> - Speedbin LUTs matched against socid
>>
>>
>> or something like that.. there's a whole lot of duplicated data atm
>>
>> Konrad
>>>
>>> static inline int adreno_is_a660(const struct adreno_gpu *gpu)
>>> @@ -358,8 +364,7 @@ static inline int adreno_is_a680(const struct
>>> adreno_gpu *gpu)
>>>
>>> static inline int adreno_is_a690(const struct adreno_gpu *gpu)
>>> {
>>> - /* The order of args is important here to handle ANY_ID correctly */
>>> - return adreno_cmp_rev(ADRENO_REV(6, 9, 0, ANY_ID), gpu->rev);
>>> + return gpu->info->chip_ids[0] == 0x0609;
>>> };
>>> /* check for a615, a616, a618, a619 or any a630 derivatives */
>>> static inline int adreno_is_a630_family(const struct adreno_gpu *gpu)
Re: [PATCH v2 7/8] drm/msm/mdss: Handle the reg bus ICC path
On 12.07.2023 14:11, Dmitry Baryshkov wrote:
> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
> another path that needs to be handled to ensure MDSS functions properly,
> namely the "reg bus", a.k.a the CPU-MDSS interconnect.
>
> Gating that path may have a variety of effects, from none to otherwise
> inexplicable DSI timeouts.
>
> Provide a way for MDSS driver to vote on this bus.
>
> A note regarding vote values. Newer platforms have corresponding
> bandwidth values in the vendor DT files. For the older platforms there
> was a static vote in the mdss_mdp and rotator drivers. I choose to be
> conservative here and choose this value as a default.
>
> Co-developed-by: Konrad Dybcio
> Signed-off-by: Konrad Dybcio
> Signed-off-by: Dmitry Baryshkov
> ---
We can store data in icc units (without the *1000).
Konrad
> drivers/gpu/drm/msm/msm_mdss.c | 51 +++---
> 1 file changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index b7765e63d549..ee31a9ab88d4 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -26,6 +26,8 @@
>
> #define MIN_IB_BW4UL /* Min ib vote 400MB */
>
> +#define DEFAULT_REG_BW 15360UL /* Used in mdss fbdev driver */
> +
> struct msm_mdss_data {
> u32 ubwc_version;
> /* can be read from register 0x58 */
> @@ -34,6 +36,8 @@ struct msm_mdss_data {
> u32 ubwc_static;
> u32 highest_bank_bit;
> u32 macrotile_mode;
> +
> + unsigned long reg_bus_bw;
> };
>
> struct msm_mdss {
> @@ -50,6 +54,7 @@ struct msm_mdss {
> const struct msm_mdss_data *mdss_data;
> struct icc_path *mdp_path[2];
> u32 num_mdp_paths;
> + struct icc_path *reg_bus_path;
> };
>
> static int msm_mdss_parse_data_bus_icc_path(struct device *dev,
> @@ -57,6 +62,7 @@ static int msm_mdss_parse_data_bus_icc_path(struct device
> *dev,
> {
> struct icc_path *path0;
> struct icc_path *path1;
> + struct icc_path *reg_bus_path;
>
> path0 = devm_of_icc_get(dev, "mdp0-mem");
> if (IS_ERR_OR_NULL(path0))
> @@ -71,6 +77,10 @@ static int msm_mdss_parse_data_bus_icc_path(struct device
> *dev,
> msm_mdss->num_mdp_paths++;
> }
>
> + reg_bus_path = of_icc_get(dev, "cpu-cfg");
> + if (!IS_ERR_OR_NULL(reg_bus_path))
> + msm_mdss->reg_bus_path = reg_bus_path;
> +
> return 0;
> }
>
> @@ -231,6 +241,13 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
> for (i = 0; i < msm_mdss->num_mdp_paths; i++)
> icc_set_bw(msm_mdss->mdp_path[i], 0, Bps_to_icc(MIN_IB_BW));
>
> + if (msm_mdss->mdss_data && msm_mdss->mdss_data->reg_bus_bw)
> + icc_set_bw(msm_mdss->reg_bus_path, 0,
> +Bps_to_icc(msm_mdss->mdss_data->reg_bus_bw));
> + else
> + icc_set_bw(msm_mdss->reg_bus_path, 0,
> +Bps_to_icc(DEFAULT_REG_BW));
> +
> ret = clk_bulk_prepare_enable(msm_mdss->num_clocks, msm_mdss->clocks);
> if (ret) {
> dev_err(msm_mdss->dev, "clock enable failed, ret:%d\n", ret);
> @@ -288,6 +305,9 @@ static int msm_mdss_disable(struct msm_mdss *msm_mdss)
> for (i = 0; i < msm_mdss->num_mdp_paths; i++)
> icc_set_bw(msm_mdss->mdp_path[i], 0, 0);
>
> + if (msm_mdss->reg_bus_path)
> + icc_set_bw(msm_mdss->reg_bus_path, 0, 0);
> +
> return 0;
> }
>
> @@ -374,6 +394,8 @@ static struct msm_mdss *msm_mdss_init(struct
> platform_device *pdev, bool is_mdp5
> if (!msm_mdss)
> return ERR_PTR(-ENOMEM);
>
> + msm_mdss->mdss_data = of_device_get_match_data(&pdev->dev);
> +
> msm_mdss->mmio = devm_platform_ioremap_resource_byname(pdev, is_mdp5 ?
> "mdss_phys" : "mdss");
> if (IS_ERR(msm_mdss->mmio))
> return ERR_CAST(msm_mdss->mmio);
> @@ -464,8 +486,6 @@ static int mdss_probe(struct platform_device *pdev)
> if (IS_ERR(mdss))
> return PTR_ERR(mdss);
>
> - mdss->mdss_data = of_device_get_match_data(&pdev->dev);
> -
> platform_set_drvdata(pdev, mdss);
>
> /*
> @@ -499,11 +519,13 @@ static const struct msm_mdss_data msm8998_data = {
> .ubwc_version = UBWC_1_0,
> .ubwc_dec_version = UBWC_1_0,
> .highest_bank_bit = 1,
> + .reg_bus_bw = 76800 * 1000,
> };
>
> static const struct msm_mdss_data qcm2290_data = {
> /* no UBWC */
> .highest_bank_bit = 0x2,
> + .reg_bus_bw = 76800 * 1000,
> };
>
> static const struct msm_mdss_data sc7180_data = {
> @@ -511,6 +533,7 @@ static const struct msm_mdss_data sc7180_data = {
> .ubwc_dec_version = UBWC_2_0,
> .ubwc_static = 0x1e,
> .highest_bank_bit = 0x3,
> + .reg_bus_bw = 76800 * 1000,
> };
>
> static const struct msm_mdss_data sc7280_data = {
> @@ -520,6 +543,7 @@ static const struct msm_mdss_dat
Re: [PATCH v4 02/17] dt-bindings: gpu: Add Imagination Technologies PowerVR GPU
Hey Sarah, Your series does not appear to be threaded. `git send-email` can be passed, for example, a directory containing a whole series & will set the correct in-reply-to headers so that the series is in a single thread. On Fri, Jul 14, 2023 at 03:25:26PM +0100, Sarah Walker wrote: > Add the device tree binding documentation for the Series AXE GPU used in > TI AM62 SoCs. > Changes since v3: > - Remove oneOf in compatible property > - Remove power-supply (not used on AM62) > > Changes since v2: > - Add commit message description > - Remove mt8173-gpu support (not currently supported) > - Drop quotes from $id and $schema > - Remove reg: minItems > - Drop _clk suffixes from clock-names > - Remove operating-points-v2 property and cooling-cells (not currently > used) > - Add additionalProperties: false > - Remove stray blank line at the end of file The changelog should go below the --- line. > Signed-off-by: Sarah Walker > --- > .../devicetree/bindings/gpu/img,powervr.yaml | 68 +++ > MAINTAINERS | 7 ++ > 2 files changed, 75 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr.yaml > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml > b/Documentation/devicetree/bindings/gpu/img,powervr.yaml > new file mode 100644 > index ..3292a0440465 > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml > @@ -0,0 +1,68 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright (c) 2022 Imagination Technologies Ltd. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/gpu/img,powervr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Imagination Technologies PowerVR GPU > + > +maintainers: > + - Sarah Walker > + interrupts: > +items: > + - description: GPU interrupt The description here doesn't add any value, since there is only one interrupt, so you can drop it and do maxItems: 1 as you have done elsewhere. > + interrupt-names: > +items: > + - const: gpu And this items: - const: gpu can just be const: gpu Although, if there is only one interrupt this is probably not particularly helpful. Are there other implementations of this IP that have more interrupts? Otherwise, this looks good to me. Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH] phy: Explicitly include correct DT includes
On Fri, Jul 14, 2023 at 7:49 PM Rob Herring wrote: > > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring > --- > drivers/phy/ralink/phy-mt7621-pci.c | 3 +-- Acked-by: Sergio Paracuellos Thanks, Sergio Paracuellos
Re: [PATCH] drm/nouveau/fifo:Fix Nineteen occurrences of the gk104.c error: ERROR: : trailing statements should be on next line
On Sat, Jul 15, 2023 at 1:07 AM Lyude Paul wrote:
>
> NAK - checkpatch.pl is a (strongish) guideline, but not a rule. In the cases
> corrected in the patch series here, we format the switch cases on single lines
> as it dramatically improves the readability of what is otherwise just a /long/
> list of slightly different static mappings. I don't believe we're the only
> part of the kernel to do this either.
>
I wished there was a place to document something like "patches whose
only reason is 'checkpatch.pl' said so" will be rejected.
I think following some checkpatch rules are sane, but then the
argument should be "makes code more clear" or "converts risky coding
practises to less risky ones". Or do we have such a place? Maybe we
should patch checkpatch.pl instead to throw a warning
> On Fri, 2023-07-14 at 14:58 +0800, huzhi...@208suo.com wrote:
> > Signed-off-by: ZhiHu
> > ---
> > .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++-
> > 1 file changed, 29 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> > b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> > index d8a4d773a58c..b99e0a7c96bb 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> > @@ -137,15 +137,29 @@ gk104_ectx_bind(struct nvkm_engn *engn, struct
> > nvkm_cctx *cctx, struct nvkm_chan
> > u64 addr = 0ULL;
> >
> > switch (engn->engine->subdev.type) {
> > -case NVKM_ENGINE_SW: return;
> > -case NVKM_ENGINE_GR: ptr0 = 0x0210; break;
> > -case NVKM_ENGINE_SEC : ptr0 = 0x0220; break;
> > -case NVKM_ENGINE_MSPDEC: ptr0 = 0x0250; break;
> > -case NVKM_ENGINE_MSPPP : ptr0 = 0x0260; break;
> > -case NVKM_ENGINE_MSVLD : ptr0 = 0x0270; break;
> > -case NVKM_ENGINE_VIC : ptr0 = 0x0280; break;
> > -case NVKM_ENGINE_MSENC : ptr0 = 0x0290; break;
> > -case NVKM_ENGINE_NVDEC :
> > +case NVKM_ENGINE_SW:
> > +return;
> > +case NVKM_ENGINE_GR:
> > +ptr0 = 0x0210;
> > +break;
> > +case NVKM_ENGINE_SEC:
> > +ptr0 = 0x0220;
> > +break;
> > +case NVKM_ENGINE_MSPDEC:
> > +ptr0 = 0x0250;
> > +break;
> > +case NVKM_ENGINE_MSPPP:
> > +ptr0 = 0x0260;
> > +break;
> > +case NVKM_ENGINE_MSVLD:
> > +ptr0 = 0x0270;
> > +break;
> > +case NVKM_ENGINE_VIC:
> > +ptr0 = 0x0280; break;
> > +case NVKM_ENGINE_MSENC:
> > +ptr0 = 0x0290;
> > +break;
> > +case NVKM_ENGINE_NVDEC:
> > ptr1 = 0x0270;
> > ptr0 = 0x0210;
> > break;
> > @@ -435,8 +449,12 @@ gk104_runl_commit(struct nvkm_runl *runl, struct
> > nvkm_memory *memory, u32 start,
> > int target;
> >
> > switch (nvkm_memory_target(memory)) {
> > -case NVKM_MEM_TARGET_VRAM: target = 0; break;
> > -case NVKM_MEM_TARGET_NCOH: target = 3; break;
> > +case NVKM_MEM_TARGET_VRAM:
> > +target = 0;
> > +break;
> > +case NVKM_MEM_TARGET_NCOH:
> > +target = 3;
> > +break;
>
> This one isn't very long, but I'd still say it's definitely a lot easier to
> read in the compact form. If anything, the only change I would make here is
> formatting the default: case to be on a single line as well
>
> > default:
> > WARN_ON(1);
> > return;
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
[PATCH] fbdev: au1200fb: Fix missing IRQ check in au1200fb_drv_probe
This func misses checking for platform_get_irq()'s call and may passes the
negative error codes to request_irq(), which takes unsigned IRQ #,
causing it to fail with -EINVAL, overriding an original error code.
Fix this by stop calling request_irq() with invalid IRQ #s.
Fixes: 1630d85a8312 ("au1200fb: fix hardcoded IRQ")
Signed-off-by: Zhang Shurong
---
drivers/video/fbdev/au1200fb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index 5c232eb13724..c137d6afe484 100644
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1732,6 +1732,9 @@ static int au1200fb_drv_probe(struct platform_device *dev)
/* Now hook interrupt too */
irq = platform_get_irq(dev, 0);
+ if (irq < 0)
+ return irq;
+
ret = request_irq(irq, au1200fb_handle_irq,
IRQF_SHARED, "lcd", (void *)dev);
if (ret) {
--
2.30.2
[PATCH] drm: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring --- drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 1 - drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c| 3 +-- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 - drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +- drivers/gpu/drm/bridge/display-connector.c| 1 - drivers/gpu/drm/bridge/fsl-ldb.c | 1 - drivers/gpu/drm/bridge/imx/imx8qm-ldb.c | 2 +- drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c | 1 + drivers/gpu/drm/bridge/lontium-lt9211.c | 1 - drivers/gpu/drm/bridge/lvds-codec.c | 1 - drivers/gpu/drm/bridge/nwl-dsi.c | 2 +- drivers/gpu/drm/bridge/parade-ps8622.c| 1 - drivers/gpu/drm/bridge/samsung-dsim.c | 3 ++- drivers/gpu/drm/bridge/simple-bridge.c| 3 ++- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 2 +- drivers/gpu/drm/drm_mipi_dsi.c| 1 + drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 1 - drivers/gpu/drm/exynos/exynos_drm_dsi.c | 3 ++- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 - drivers/gpu/drm/exynos/exynos_drm_rotator.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_scaler.c| 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/exynos/exynos_mixer.c | 1 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +- drivers/gpu/drm/imx/dcss/dcss-dev.c | 5 +++-- drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +- drivers/gpu/drm/ingenic/ingenic-ipu.c | 2 +- drivers/gpu/drm/lima/lima_drv.c | 3 ++- drivers/gpu/drm/logicvc/logicvc_drm.c | 2 +- drivers/gpu/drm/mcde/mcde_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_disp_aal.c | 3 +-- drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 3 +-- drivers/gpu/drm/mediatek/mtk_disp_color.c | 3 +-- drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 3 +-- drivers/gpu/drm/mediatek/mtk_disp_merge.c | 3 +-- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 3 +-- drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 3 ++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 3 +-- drivers/gpu/drm/mediatek/mtk_dpi.c| 1 - drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c| 3 ++- drivers/gpu/drm/mediatek/mtk_ethdr.c | 2 +- drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 3 +-- drivers/gpu/drm/meson/meson_drv.h | 1 - drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 ++- drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 3 ++- drivers/gpu/drm/meson/meson_encoder_dsi.c | 1 - drivers/gpu/drm/meson/meson_encoder_hdmi.c| 4 +++- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 ++ drivers/gpu/drm/msm/dp/dp_audio.c | 2 +- drivers/gpu/drm/msm/dsi/dsi_host.c| 2 +- drivers/gpu/drm/msm/hdmi/hdmi.c | 2 ++ drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 3 ++- drivers/gpu/drm/msm/msm_mdss.c| 2 ++ drivers/gpu/drm/mxsfb/lcdif_drv.c | 1 - drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 3 ++- drivers/gpu/drm/panel/panel-auo-a030jtn01.c | 2 +- drivers/gpu/drm/panel/panel-boe-himax8279d.c | 1 - drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c| 1 - drivers/gpu/drm/panel/panel-dsi-cm.c | 2 +- drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 1 - drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 2 +- drivers/gpu/drm/panel/panel-himax-hx8394.c| 2 +- drivers/gpu/drm/panel/panel-ilitek-
Re: [PATCH 3/3] drm/scheduler: Clean up jobs when the scheduler is torn down.
On 2023-07-14 04:21, Asahi Lina wrote:
> drm_sched_fini() currently leaves any pending jobs dangling, which
> causes segfaults and other badness when job completion fences are
> signaled after the scheduler is torn down.
If there are pending jobs, ideally we want to call into the driver,
so that it can release resources it may be holding for those.
The idea behind "pending" is that they are pending in the hardware
and we don't know their state until signalled/the callback called.
(Or unless the device is reset and we get a notification of that fact.)
> Explicitly detach all jobs from their completion callbacks and free
> them. This makes it possible to write a sensible safe abstraction for
> drm_sched, without having to externally duplicate the tracking of
> in-flight jobs.
>
> This shouldn't regress any existing drivers, since calling
> drm_sched_fini() with any pending jobs is broken and this change should
> be a no-op if there are no pending jobs.
While this statement is true on its own, it kind of contradicts
the premise of the first paragraph.
> Signed-off-by: Asahi Lina
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 32 ++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 1f3bc3606239..a4da4aac0efd 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1186,10 +1186,38 @@ EXPORT_SYMBOL(drm_sched_init);
> void drm_sched_fini(struct drm_gpu_scheduler *sched)
> {
> struct drm_sched_entity *s_entity;
> + struct drm_sched_job *s_job, *tmp;
> int i;
>
> - if (sched->thread)
> - kthread_stop(sched->thread);
> + if (!sched->thread)
> + return;
> +
> + /*
> + * Stop the scheduler, detaching all jobs from their hardware callbacks
> + * and cleaning up complete jobs.
> + */
> + drm_sched_stop(sched, NULL);
> +
> + /*
> + * Iterate through the pending job list and free all jobs.
> + * This assumes the driver has either guaranteed jobs are already
> stopped, or that
> + * otherwise it is responsible for keeping any necessary data
> structures for
> + * in-progress jobs alive even when the free_job() callback is called
> early (e.g. by
> + * putting them in its own queue or doing its own refcounting).
> + */
> + list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
> + spin_lock(&sched->job_list_lock);
> + list_del_init(&s_job->list);
> + spin_unlock(&sched->job_list_lock);
> +
> + dma_fence_set_error(&s_job->s_fence->finished, -ESRCH);
> + drm_sched_fence_finished(s_job->s_fence);
I'd imagine it's better to rebase this on top of drm-misc-next where
drm_sched_fence_finished() takes one more parameter--the error.
> +
> + WARN_ON(s_job->s_fence->parent);
> + sched->ops->free_job(s_job);
> + }
> +
> + kthread_stop(sched->thread);
>
> for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= DRM_SCHED_PRIORITY_MIN;
> i--) {
> struct drm_sched_rq *rq = &sched->sched_rq[i];
>
Conceptually I don't mind this patch--I see what it is trying to achieve,
but technically, we want the driver to detect GPU removal and return shared
resources back, such as "jobs", which DRM is also aware of.
In the case where we're initiating the tear, we should notify the driver that
we're about to forget jobs (resources), so that it knows to return them back
or that it shouldn't notify us for them (since we've notified we're forgetting
them.)
(Note also that in this latter case, traditionally, the device would be reset,
so that we can guarantee that it has forgotten all shared resources which
we are to tear up. This is somewhat more complicated with GPUs, thus the method
pointed out above.)
--
Regards,
Luben
