Re: [drm-misc:drm-misc-next 2/3] drivers/gpu/drm/loongson/lsdc_plane.c:199 lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 180)
Hi,
Thanks for testing,
What do you means about tell me this?
I means that would you like to help fixing this warning?
Or otherwise, I will fix this someday.
On 2023/7/10 14:29, Dan Carpenter wrote:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 8d1077cf2e43b15fefd76ebec2b71541eb27ef2c
commit: f39db26c54281da6a785259498ca74b5e470476f [2/3] drm: Add kms driver for
loongson display controller
config: i386-randconfig-m021-20230710
(https://download.01.org/0day-ci/archive/20230710/202307100423.rv7d05uq-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20230710/202307100423.rv7d05uq-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Reported-by: Dan Carpenter
| Closes: https://lore.kernel.org/r/202307100423.rv7d05uq-...@intel.com/
smatch warnings:
drivers/gpu/drm/loongson/lsdc_plane.c:199
lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced before check
'state' (see line 180)
vim +/state +199 drivers/gpu/drm/loongson/lsdc_plane.c
f39db26c54281d Sui Jingfeng 2023-06-15 174 static int
lsdc_cursor_plane_atomic_async_check(struct drm_plane *plane,
f39db26c54281d Sui Jingfeng 2023-06-15 175
struct drm_atomic_state *state)
f39db26c54281d Sui Jingfeng 2023-06-15 176 {
f39db26c54281d Sui Jingfeng 2023-06-15 177 struct drm_plane_state
*new_state;
f39db26c54281d Sui Jingfeng 2023-06-15 178 struct drm_crtc_state
*crtc_state;
f39db26c54281d Sui Jingfeng 2023-06-15 179
f39db26c54281d Sui Jingfeng 2023-06-15 @180 new_state =
drm_atomic_get_new_plane_state(state, plane);
^
state is dereferenced inside this function
f39db26c54281d Sui Jingfeng 2023-06-15 181
f39db26c54281d Sui Jingfeng 2023-06-15 182 if (!plane->state ||
!plane->state->fb) {
f39db26c54281d Sui Jingfeng 2023-06-15 183 drm_dbg(plane->dev, "%s: state
is NULL\n", plane->name);
f39db26c54281d Sui Jingfeng 2023-06-15 184 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 185 }
f39db26c54281d Sui Jingfeng 2023-06-15 186
f39db26c54281d Sui Jingfeng 2023-06-15 187 if (new_state->crtc_w !=
new_state->crtc_h) {
f39db26c54281d Sui Jingfeng 2023-06-15 188 drm_dbg(plane->dev,
"unsupported cursor size: %ux%u\n",
f39db26c54281d Sui Jingfeng 2023-06-15 189 new_state->crtc_w,
new_state->crtc_h);
f39db26c54281d Sui Jingfeng 2023-06-15 190 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 191 }
f39db26c54281d Sui Jingfeng 2023-06-15 192
f39db26c54281d Sui Jingfeng 2023-06-15 193 if (new_state->crtc_w != 64 &&
new_state->crtc_w != 32) {
f39db26c54281d Sui Jingfeng 2023-06-15 194 drm_dbg(plane->dev,
"unsupported cursor size: %ux%u\n",
f39db26c54281d Sui Jingfeng 2023-06-15 195 new_state->crtc_w,
new_state->crtc_h);
f39db26c54281d Sui Jingfeng 2023-06-15 196 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 197 }
f39db26c54281d Sui Jingfeng 2023-06-15 198
f39db26c54281d Sui Jingfeng 2023-06-15 @199 if (state) {
^
Checked too late
f39db26c54281d Sui Jingfeng 2023-06-15 200 crtc_state =
drm_atomic_get_existing_crtc_state(state, new_state->crtc);
f39db26c54281d Sui Jingfeng 2023-06-15 201 } else {
f39db26c54281d Sui Jingfeng 2023-06-15 202 crtc_state =
plane->crtc->state;
f39db26c54281d Sui Jingfeng 2023-06-15 203 drm_dbg(plane->dev, "%s: atomic
state is NULL\n", plane->name);
f39db26c54281d Sui Jingfeng 2023-06-15 204 }
f39db26c54281d Sui Jingfeng 2023-06-15 205
f39db26c54281d Sui Jingfeng 2023-06-15 206 if (!crtc_state->active)
f39db26c54281d Sui Jingfeng 2023-06-15 207 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 208
f39db26c54281d Sui Jingfeng 2023-06-15 209 if (plane->state->crtc !=
new_state->crtc ||
f39db26c54281d Sui Jingfeng 2023-06-15 210 plane->state->src_w !=
new_state->src_w ||
f39db26c54281d Sui Jingfeng 2023-06-15 211 plane->state->src_h !=
new_state->src_h ||
f39db26c54281d Sui Jingfeng 2023-06-15 212 plane->state->crtc_w !=
new_state->crtc_w ||
f39db26c54281d Sui Jingfeng 2023-06-15 213 plane->state->crtc_h !=
new_state->crtc_h)
f39db26c54281d Sui Jingfeng 2023-06-15 214 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 215
f39db26c54281d Sui Jingfeng 2023-06-15 216 if (new_state->visible !=
pl
Re: [PATCH] fbdev: imxfb: Convert to devm_platform_ioremap_resource()
Hi Yangtao,
On Tue, Jul 4, 2023 at 11:38 AM Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li
Thanks for your patch, which is now commit c1cd7a7a231a26c6 ("fbdev:
imxfb: Convert to devm_platform_ioremap_resource()") in fbdev/for-next
> --- a/drivers/video/fbdev/imxfb.c
> +++ b/drivers/video/fbdev/imxfb.c
> @@ -868,7 +868,6 @@ static int imxfb_probe(struct platform_device *pdev)
> struct imxfb_info *fbi;
> struct lcd_device *lcd;
> struct fb_info *info;
> - struct resource *res;
> struct imx_fb_videomode *m;
> const struct of_device_id *of_id;
> struct device_node *display_np;
> @@ -885,10 +884,6 @@ static int imxfb_probe(struct platform_device *pdev)
> if (of_id)
> pdev->id_entry = of_id->data;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res)
> - return -ENODEV;
> -
> info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
> if (!info)
> return -ENOMEM;
> @@ -970,7 +965,7 @@ static int imxfb_probe(struct platform_device *pdev)
> goto failed_getclock;
> }
>
> - fbi->regs = devm_ioremap_resource(&pdev->dev, res);
> + fbi->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(fbi->regs)) {
> ret = PTR_ERR(fbi->regs);
> goto failed_ioremap;
> @@ -1043,7 +1038,6 @@ static int imxfb_probe(struct platform_device *pdev)
> failed_map:
> failed_ioremap:
> failed_getclock:
> - release_mem_region(res->start, resource_size(res));
This part is not directly related, but a bug fix for commit
b083c22d51148f3d ("video: fbdev: imxfb: Convert request_mem_region +
ioremap to devm_ioremap_resource") in v6.0.
Please do not mix bug fixes with other changes.
The stable teams want to backport only bugfixes .
> failed_of_parse:
> kfree(info->pseudo_palette);
> failed_init:
> --
> 2.39.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [drm-misc:drm-misc-next 2/3] drivers/gpu/drm/loongson/lsdc_plane.c:199 lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 180)
Hi
Am 10.07.23 um 09:02 schrieb suijingfeng:
Hi,
Thanks for testing,
What do you means about tell me this?
I means that would you like to help fixing this warning?
The code in drm_atomic_get_new_plane_state() dereferences the state
parameter. Later in your function, you test for state to be non-NULL.
That's what the warning is about.
You should be able to silence this warning by removing the state test
from your function (and also delete that else branch). There should
always be an atomic state present and the atomic-check callbacks should
not be called without a state. If not, the driver most likely failed to
initialize correctly.
Best regards
Thomas
Or otherwise, I will fix this someday.
On 2023/7/10 14:29, Dan Carpenter wrote:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 8d1077cf2e43b15fefd76ebec2b71541eb27ef2c
commit: f39db26c54281da6a785259498ca74b5e470476f [2/3] drm: Add kms
driver for loongson display controller
config: i386-randconfig-m021-20230710
(https://download.01.org/0day-ci/archive/20230710/202307100423.rv7d05uq-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20230710/202307100423.rv7d05uq-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new
version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Reported-by: Dan Carpenter
| Closes: https://lore.kernel.org/r/202307100423.rv7d05uq-...@intel.com/
smatch warnings:
drivers/gpu/drm/loongson/lsdc_plane.c:199
lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced
before check 'state' (see line 180)
vim +/state +199 drivers/gpu/drm/loongson/lsdc_plane.c
f39db26c54281d Sui Jingfeng 2023-06-15 174 static int
lsdc_cursor_plane_atomic_async_check(struct drm_plane *plane,
f39db26c54281d Sui Jingfeng 2023-06-15 175
struct drm_atomic_state *state)
f39db26c54281d Sui Jingfeng 2023-06-15 176 {
f39db26c54281d Sui Jingfeng 2023-06-15 177 struct
drm_plane_state *new_state;
f39db26c54281d Sui Jingfeng 2023-06-15 178 struct drm_crtc_state
*crtc_state;
f39db26c54281d Sui Jingfeng 2023-06-15 179
f39db26c54281d Sui Jingfeng 2023-06-15 @180 new_state =
drm_atomic_get_new_plane_state(state, plane);
^
state is dereferenced inside this function
f39db26c54281d Sui Jingfeng 2023-06-15 181
f39db26c54281d Sui Jingfeng 2023-06-15 182 if (!plane->state ||
!plane->state->fb) {
f39db26c54281d Sui Jingfeng 2023-06-15 183
drm_dbg(plane->dev, "%s: state is NULL\n", plane->name);
f39db26c54281d Sui Jingfeng 2023-06-15 184 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 185 }
f39db26c54281d Sui Jingfeng 2023-06-15 186
f39db26c54281d Sui Jingfeng 2023-06-15 187 if (new_state->crtc_w
!= new_state->crtc_h) {
f39db26c54281d Sui Jingfeng 2023-06-15 188
drm_dbg(plane->dev, "unsupported cursor size: %ux%u\n",
f39db26c54281d Sui Jingfeng 2023-06-15 189
new_state->crtc_w, new_state->crtc_h);
f39db26c54281d Sui Jingfeng 2023-06-15 190 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 191 }
f39db26c54281d Sui Jingfeng 2023-06-15 192
f39db26c54281d Sui Jingfeng 2023-06-15 193 if (new_state->crtc_w
!= 64 && new_state->crtc_w != 32) {
f39db26c54281d Sui Jingfeng 2023-06-15 194
drm_dbg(plane->dev, "unsupported cursor size: %ux%u\n",
f39db26c54281d Sui Jingfeng 2023-06-15 195
new_state->crtc_w, new_state->crtc_h);
f39db26c54281d Sui Jingfeng 2023-06-15 196 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 197 }
f39db26c54281d Sui Jingfeng 2023-06-15 198
f39db26c54281d Sui Jingfeng 2023-06-15 @199 if (state) {
^
Checked too late
f39db26c54281d Sui Jingfeng 2023-06-15 200 crtc_state =
drm_atomic_get_existing_crtc_state(state, new_state->crtc);
f39db26c54281d Sui Jingfeng 2023-06-15 201 } else {
f39db26c54281d Sui Jingfeng 2023-06-15 202 crtc_state =
plane->crtc->state;
f39db26c54281d Sui Jingfeng 2023-06-15 203
drm_dbg(plane->dev, "%s: atomic state is NULL\n", plane->name);
f39db26c54281d Sui Jingfeng 2023-06-15 204 }
f39db26c54281d Sui Jingfeng 2023-06-15 205
f39db26c54281d Sui Jingfeng 2023-06-15 206 if (!crtc_state->active)
f39db26c54281d Sui Jingfeng 2023-06-15 207 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 208
f39db26c54281d Sui Jingfeng 2023-06-15 209 if
(plane->state->crtc != new_state->crtc ||
f39db26c54281d Sui Jingfeng 2023-06-15 210
plane->state->src_w != new_stat
Re: [drm-misc:drm-misc-next 2/3] drivers/gpu/drm/loongson/lsdc_plane.c:199 lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 180)
Hi,
On 2023/7/10 14:29, Dan Carpenter wrote:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 8d1077cf2e43b15fefd76ebec2b71541eb27ef2c
commit: f39db26c54281da6a785259498ca74b5e470476f [2/3] drm: Add kms driver for
loongson display controller
config: i386-randconfig-m021-20230710
(https://download.01.org/0day-ci/archive/20230710/202307100423.rv7d05uq-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20230710/202307100423.rv7d05uq-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Reported-by: Dan Carpenter
| Closes: https://lore.kernel.org/r/202307100423.rv7d05uq-...@intel.com/
smatch warnings:
drivers/gpu/drm/loongson/lsdc_plane.c:199
lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced before check
'state' (see line 180)
vim +/state +199 drivers/gpu/drm/loongson/lsdc_plane.c
f39db26c54281d Sui Jingfeng 2023-06-15 174 static int
lsdc_cursor_plane_atomic_async_check(struct drm_plane *plane,
f39db26c54281d Sui Jingfeng 2023-06-15 175
struct drm_atomic_state *state)
f39db26c54281d Sui Jingfeng 2023-06-15 176 {
f39db26c54281d Sui Jingfeng 2023-06-15 177 struct drm_plane_state
*new_state;
f39db26c54281d Sui Jingfeng 2023-06-15 178 struct drm_crtc_state
*crtc_state;
f39db26c54281d Sui Jingfeng 2023-06-15 179
f39db26c54281d Sui Jingfeng 2023-06-15 @180 new_state =
drm_atomic_get_new_plane_state(state, plane);
^
state is dereferenced inside this function
f39db26c54281d Sui Jingfeng 2023-06-15 181
f39db26c54281d Sui Jingfeng 2023-06-15 182 if (!plane->state ||
!plane->state->fb) {
f39db26c54281d Sui Jingfeng 2023-06-15 183 drm_dbg(plane->dev, "%s: state
is NULL\n", plane->name);
f39db26c54281d Sui Jingfeng 2023-06-15 184 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 185 }
f39db26c54281d Sui Jingfeng 2023-06-15 186
f39db26c54281d Sui Jingfeng 2023-06-15 187 if (new_state->crtc_w !=
new_state->crtc_h) {
f39db26c54281d Sui Jingfeng 2023-06-15 188 drm_dbg(plane->dev,
"unsupported cursor size: %ux%u\n",
f39db26c54281d Sui Jingfeng 2023-06-15 189 new_state->crtc_w,
new_state->crtc_h);
f39db26c54281d Sui Jingfeng 2023-06-15 190 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 191 }
f39db26c54281d Sui Jingfeng 2023-06-15 192
f39db26c54281d Sui Jingfeng 2023-06-15 193 if (new_state->crtc_w != 64 &&
new_state->crtc_w != 32) {
f39db26c54281d Sui Jingfeng 2023-06-15 194 drm_dbg(plane->dev,
"unsupported cursor size: %ux%u\n",
f39db26c54281d Sui Jingfeng 2023-06-15 195 new_state->crtc_w,
new_state->crtc_h);
f39db26c54281d Sui Jingfeng 2023-06-15 196 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 197 }
f39db26c54281d Sui Jingfeng 2023-06-15 198
f39db26c54281d Sui Jingfeng 2023-06-15 @199 if (state) {
^
Checked too late
Yes, there no need to check here, simply writing the code as following
is OK.
```
crtc_state = drm_atomic_get_existing_crtc_state(state,
new_state->crtc);
```
f39db26c54281d Sui Jingfeng 2023-06-15 200 crtc_state =
drm_atomic_get_existing_crtc_state(state, new_state->crtc);
f39db26c54281d Sui Jingfeng 2023-06-15 201 } else {
f39db26c54281d Sui Jingfeng 2023-06-15 202 crtc_state =
plane->crtc->state;
f39db26c54281d Sui Jingfeng 2023-06-15 203 drm_dbg(plane->dev, "%s: atomic
state is NULL\n", plane->name);
f39db26c54281d Sui Jingfeng 2023-06-15 204 }
f39db26c54281d Sui Jingfeng 2023-06-15 205
f39db26c54281d Sui Jingfeng 2023-06-15 206 if (!crtc_state->active)
f39db26c54281d Sui Jingfeng 2023-06-15 207 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 208
f39db26c54281d Sui Jingfeng 2023-06-15 209 if (plane->state->crtc !=
new_state->crtc ||
f39db26c54281d Sui Jingfeng 2023-06-15 210 plane->state->src_w !=
new_state->src_w ||
f39db26c54281d Sui Jingfeng 2023-06-15 211 plane->state->src_h !=
new_state->src_h ||
f39db26c54281d Sui Jingfeng 2023-06-15 212 plane->state->crtc_w !=
new_state->crtc_w ||
f39db26c54281d Sui Jingfeng 2023-06-15 213 plane->state->crtc_h !=
new_state->crtc_h)
f39db26c54281d Sui Jingfeng 2023-06-15 214 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 215
f39db26c54281d Sui Jingfeng 2023-06-15 216 if (new_sta
Re: [PATCH 4/4] vgacon, arch/*: remove unused screen_info definitions
On Fri, Jul 7, 2023 at 2:56 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > A number of architectures either kept the screen_info definition for > historical purposes as it used to be required by the generic VT code, or > they copied it from another architecture in order to build the VGA > console driver in an allmodconfig build. > > Now that vgacon no longer builds on these architectures, remove the > stale definitions. > > Signed-off-by: Arnd Bergmann > --- > arch/csky/kernel/setup.c | 12 > arch/hexagon/kernel/Makefile | 2 -- > arch/hexagon/kernel/screen_info.c | 3 --- > arch/nios2/kernel/setup.c | 5 - > arch/sh/kernel/setup.c| 5 - > arch/sparc/kernel/setup_32.c | 13 - > arch/sparc/kernel/setup_64.c | 13 - > arch/xtensa/kernel/setup.c| 12 For xtensa: Acked-by: Max Filippov -- Thanks. -- Max
[PATCH] dc_dmub_srv: Use max()/min() function for better coding conventions
It is advisable to utilize the max() function in the dc_dmub_srv.c file, as it conforms better to programming conventions. Signed-off-by: Yang Rong --- drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) mode change 100644 => 100755 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c index c753c6f30dd7..df79aea49a3c --- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c +++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c @@ -22,7 +22,7 @@ * Authors: AMD * */ - +#include #include "dc.h" #include "dc_dmub_srv.h" #include "../dmub/dmub_srv.h" @@ -481,7 +481,7 @@ static void populate_subvp_cmd_drr_info(struct dc *dc, max_drr_vblank_us = div64_u64((subvp_active_us - prefetch_us - dc->caps.subvp_fw_processing_delay_us - drr_active_us), 2) + drr_active_us; max_drr_mallregion_us = subvp_active_us - prefetch_us - mall_region_us - dc->caps.subvp_fw_processing_delay_us; - max_drr_supported_us = max_drr_vblank_us > max_drr_mallregion_us ? max_drr_vblank_us : max_drr_mallregion_us; + max_drr_supported_us = max(max_drr_vblank_us, max_drr_mallregion_us); max_vtotal_supported = div64_u64(((uint64_t)drr_timing->pix_clk_100hz * 100 * max_drr_supported_us), (((uint64_t)drr_timing->h_total * 100))); @@ -771,7 +771,7 @@ void dc_dmub_setup_subvp_dmub_command(struct dc *dc, wm_val_refclk = context->bw_ctx.bw.dcn.watermarks.a.cstate_pstate.pstate_change_ns * (dc->res_pool->ref_clocks.dchub_ref_clock_inKhz / 1000) / 1000; - cmd.fw_assisted_mclk_switch_v2.config_data.watermark_a_cache = wm_val_refclk < 0x ? wm_val_refclk : 0x; + cmd.fw_assisted_mclk_switch_v2.config_data.watermark_a_cache = min(wm_val_refclk, 0x); } dm_execute_dmub_cmd(dc->ctx, &cmd, DM_DMUB_WAIT_TYPE_WAIT); -- 2.35.3
Fwd: [PATCH] drm/nouveau/i2c: do not use assignment in if condition
Assignments in if condition are less readable and error-prone. Fixes also checkpatch warning: ERROR: do not use assignment in if condition Signed-off-by: Ran Sun --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c old mode 100755 new mode 100644
[PATCH] drm/nouveau/i2c: do not use assignment in if condition
Assignments in if condition are less readable and error-prone. Fixes also checkpatch warning: ERROR: do not use assignment in if condition Signed-off-by: Ran Sun --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c old mode 100755 new mode 100644
[PATCH] drm/nouveau/nvkm: do not use assignment in if condition
Assignments in if condition are less readable and error-prone. Fixes
also checkpatch warning:
ERROR: do not use assignment in if condition
Signed-off-by: Ran Sun
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
index 976539de4220..054fa42f1d04 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
@@ -286,7 +286,8 @@ nvkm_i2c_new_(const struct nvkm_i2c_func *func,
struct nvkm_device *device,
if (ccbE.share != DCB_I2C_UNUSED) {
const int id = NVKM_I2C_PAD_HYBRID(ccbE.share);
-if (!(pad = nvkm_i2c_pad_find(i2c, id)))
+pad = nvkm_i2c_pad_find(i2c, id);
+if (!pad)
ret = func->pad_s_new(i2c, id, &pad);
else
ret = 0;
[PATCH] drm/nouveau/i2c: do not use assignment in if condition
Assignments in if condition are less readable and error-prone. Fixes also checkpatch warning: ERROR: do not use assignment in if condition Signed-off-by: Ran Sun --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c old mode 100755 new mode 100644
[PATCH] drm/nouveau/i2c: do not use assignment in if condition
Assignments in if condition are less readable and error-prone. Fixes
also checkpatch warning:
ERROR: do not use assignment in if condition
Signed-off-by: Ran Sun
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c
index 96bbdda0f439..a1cf406ff141 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c
@@ -85,7 +85,8 @@ gf119_i2c_bus_new(struct nvkm_i2c_pad *pad, int id, u8
drive,
{
struct gf119_i2c_bus *bus;
-if (!(bus = kzalloc(sizeof(*bus), GFP_KERNEL)))
+bus = kzalloc(sizeof(*bus), GFP_KERNEL);
+if (!bus)
return -ENOMEM;
*pbus = &bus->base;
[PATCH] drm/nouveau/i2c: do not use assignment in if condition
Assignments in if condition are less readable and error-prone. Fixes also checkpatch warning: ERROR: do not use assignment in if condition Signed-off-by: Ran Sun --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad.c diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad.c old mode 100755 new mode 100644
[PATCH] drm/nouveau/pci: ERROR: "foo * bar" should be "foo *bar"
Signed-off-by: Ran Sun
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c
index 6be87ecffc89..bc51987c5f5f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c
@@ -147,7 +147,7 @@ gk104_pcie_set_link_speed(struct nvkm_pci *pci, enum
nvkm_pcie_speed speed)
}
static int
-gk104_pcie_init(struct nvkm_pci * pci)
+gk104_pcie_init(struct nvkm_pci *pci)
{
enum nvkm_pcie_speed lnkctl_speed, max_speed, cap_speed;
struct nvkm_subdev *subdev = &pci->subdev;
[PATCH] drm/nouveau/iccsense:
Fixed error: 'do not use assignment in if condition'
This patch fixes error: 'do not use assignment in if condition'
in drm/nouveau/iccsense
Signed-off-by: Ran Sun
---
drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
index 8f0ccd3664eb..2428f3d6e477 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
@@ -322,7 +322,8 @@ int
nvkm_iccsense_new_(struct nvkm_device *device, enum nvkm_subdev_type
type, int inst,
struct nvkm_iccsense **iccsense)
{
-if (!(*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL)))
+*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL);
+if (!*iccsense)
return -ENOMEM;
INIT_LIST_HEAD(&(*iccsense)->sensors);
INIT_LIST_HEAD(&(*iccsense)->rails);
[PATCH] drm/nouveau/i2c: do not use assignment in if condition
Assignments in if condition are less readable and error-prone. Fixes
also checkpatch warning:
ERROR: do not use assignment in if condition
Signed-off-by: Ran Sun
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
index d063d0dc13c5..098051d3755c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
@@ -209,7 +209,8 @@ nvkm_i2c_aux_new_(const struct nvkm_i2c_aux_func
*func,
struct nvkm_i2c_pad *pad, int id,
struct nvkm_i2c_aux **paux)
{
-if (!(*paux = kzalloc(sizeof(**paux), GFP_KERNEL)))
+*paux = kzalloc(sizeof(**paux), GFP_KERNEL);
+if (!*paux)
return -ENOMEM;
return nvkm_i2c_aux_ctor(func, pad, id, *paux);
}
[PATCH] drm/nouveau/nvkm: do not use assignment in if condition
Assignments in if condition are less readable and error-prone. Fixes
also checkpatch warning:
ERROR: do not use assignment in if condition
Signed-off-by:Ran Sun
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
index 976539de4220..054fa42f1d04 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
@@ -286,7 +286,8 @@ nvkm_i2c_new_(const struct nvkm_i2c_func *func,
struct nvkm_device *device,
if (ccbE.share != DCB_I2C_UNUSED) {
const int id = NVKM_I2C_PAD_HYBRID(ccbE.share);
-if (!(pad = nvkm_i2c_pad_find(i2c, id)))
+pad = nvkm_i2c_pad_find(i2c, id);
+if (!pad)
ret = func->pad_s_new(i2c, id, &pad);
else
ret = 0;
Re: [PATCH] fbdev: imxfb: Convert to devm_platform_ioremap_resource()
Hi Geert,
On 2023/7/10 15:10, Geert Uytterhoeven wrote:
[你通常不会收到来自 ge...@linux-m68k.org 的电子邮件。请访问
https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
Hi Yangtao,
On Tue, Jul 4, 2023 at 11:38 AM Yangtao Li wrote:
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li
Thanks for your patch, which is now commit c1cd7a7a231a26c6 ("fbdev:
imxfb: Convert to devm_platform_ioremap_resource()") in fbdev/for-next
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -868,7 +868,6 @@ static int imxfb_probe(struct platform_device *pdev)
struct imxfb_info *fbi;
struct lcd_device *lcd;
struct fb_info *info;
- struct resource *res;
struct imx_fb_videomode *m;
const struct of_device_id *of_id;
struct device_node *display_np;
@@ -885,10 +884,6 @@ static int imxfb_probe(struct platform_device *pdev)
if (of_id)
pdev->id_entry = of_id->data;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
-
info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
if (!info)
return -ENOMEM;
@@ -970,7 +965,7 @@ static int imxfb_probe(struct platform_device *pdev)
goto failed_getclock;
}
- fbi->regs = devm_ioremap_resource(&pdev->dev, res);
+ fbi->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(fbi->regs)) {
ret = PTR_ERR(fbi->regs);
goto failed_ioremap;
@@ -1043,7 +1038,6 @@ static int imxfb_probe(struct platform_device *pdev)
failed_map:
failed_ioremap:
failed_getclock:
- release_mem_region(res->start, resource_size(res));
This part is not directly related, but a bug fix for commit
b083c22d51148f3d ("video: fbdev: imxfb: Convert request_mem_region +
ioremap to devm_ioremap_resource") in v6.0.
IIUC, split this patch into two, remove release_mem_region in one and
mark it as Fixes: b083c22d51148f3d ("video: fbdev: imxfb: Convert
request_mem_region +
ioremap to devm_ioremap_resource")?
MBR,
Yangtao
Please do not mix bug fixes with other changes.
The stable teams want to backport only bugfixes .
failed_of_parse:
kfree(info->pseudo_palette);
failed_init:
--
2.39.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [drm-misc:drm-misc-next 2/3] drivers/gpu/drm/loongson/lsdc_plane.c:199 lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 180)
On Mon, Jul 10, 2023 at 03:02:05PM +0800, suijingfeng wrote: > Hi, > > > Thanks for testing, > > What do you means about tell me this? > > I means that would you like to help fixing this warning? > > Or otherwise, I will fix this someday. > These are automated emails from the kbuild (zero day) bot. I just look them over and hit forward. regards, dan carpenter
RE: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
Hi Dmitry,
Thanks for your comments,
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 2023年6月25日 2:02
> To: Sandor Yu ; andrzej.ha...@intel.com;
> neil.armstr...@linaro.org; robert.f...@linaro.org;
> laurent.pinch...@ideasonboard.com; jo...@kwiboo.se;
> jernej.skra...@gmail.com; airl...@gmail.com; dan...@ffwll.ch;
> robh...@kernel.org; krzysztof.kozlowski...@linaro.org;
> shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> vk...@kernel.org; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; linux-...@lists.infradead.org
> Cc: ker...@pengutronix.de; dl-linux-imx ; Oliver Brown
>
> Subject: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> On 15/06/2023 04:38, Sandor Yu wrote:
> > Allow HDMI PHYs to be configured through the generic functions through
> > a custom structure added to the generic union.
> >
> > The parameters added here are based on HDMI PHY implementation
> > practices. The current set of parameters should cover the potential
> > users.
> >
> > Signed-off-by: Sandor Yu
> > ---
> > include/linux/phy/phy-hdmi.h | 38
>
> > include/linux/phy/phy.h | 7 ++-
> > 2 files changed, 44 insertions(+), 1 deletion(-)
> > create mode 100644 include/linux/phy/phy-hdmi.h
> >
> > diff --git a/include/linux/phy/phy-hdmi.h
> > b/include/linux/phy/phy-hdmi.h new file mode 100644 index
> > ..5765aa5bc175
> > --- /dev/null
> > +++ b/include/linux/phy/phy-hdmi.h
> > @@ -0,0 +1,38 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2022 NXP
> > + */
> > +
> > +#ifndef __PHY_HDMI_H_
> > +#define __PHY_HDMI_H_
> > +
> > +/**
> > + * Pixel Encoding as HDMI Specification
> > + * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
> > + * YUV420: HDMI Specification 2.a Section 7.1 */ enum
> > +hdmi_phy_colorspace {
> > + HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
> > + HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
> > + HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
> > + HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
> > + HDMI_PHY_COLORSPACE_RESERVED4,
> > + HDMI_PHY_COLORSPACE_RESERVED5,
> > + HDMI_PHY_COLORSPACE_RESERVED6,
> > +};
>
> This enum duplicates enum hdmi_colorspace from HDMI 2.0
> defines '7' to be IDO-defined.
>
> Would it be better to use that enum instead?
Accept. I will create head file hdmi_colorspace.h to reuse enum hdmi_colorspace
in .
B.R
Sandor
>
> > +
> > +/**
> > + * struct phy_configure_opts_hdmi - HDMI configuration set
> > + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> > + * @bpc: Maximum bits per color channel.
> > + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> > + *
> > + * This structure is used to represent the configuration state of a HDMI
> > phy.
> > + */
> > +struct phy_configure_opts_hdmi {
> > + unsigned int pixel_clk_rate;
> > + unsigned int bpc;
> > + enum hdmi_phy_colorspace color_space; };
> > +
> > +#endif /* __PHY_HDMI_H_ */
>
> [skipped the rest]
>
> --
> With best wishes
> Dmitry
RE: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
Hi Vinod,
Thanks for your comments,
> -Original Message-
> From: Vinod Koul
> Sent: 2023年6月21日 19:22
> To: Sandor Yu
> Cc: andrzej.ha...@intel.com; neil.armstr...@linaro.org;
> robert.f...@linaro.org; laurent.pinch...@ideasonboard.com;
> jo...@kwiboo.se; jernej.skra...@gmail.com; airl...@gmail.com;
> dan...@ffwll.ch; robh...@kernel.org; krzysztof.kozlowski...@linaro.org;
> shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
> linux-...@lists.infradead.org; ker...@pengutronix.de; dl-linux-imx
> ; Oliver Brown
> Subject: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> On 15-06-23, 09:38, Sandor Yu wrote:
> > Allow HDMI PHYs to be configured through the generic functions through
> > a custom structure added to the generic union.
> >
> > The parameters added here are based on HDMI PHY implementation
> > practices. The current set of parameters should cover the potential
> > users.
> >
> > Signed-off-by: Sandor Yu
> > ---
> > include/linux/phy/phy-hdmi.h | 38
>
> > include/linux/phy/phy.h | 7 ++-
> > 2 files changed, 44 insertions(+), 1 deletion(-) create mode 100644
> > include/linux/phy/phy-hdmi.h
> >
> > diff --git a/include/linux/phy/phy-hdmi.h
> > b/include/linux/phy/phy-hdmi.h new file mode 100644 index
> > ..5765aa5bc175
> > --- /dev/null
> > +++ b/include/linux/phy/phy-hdmi.h
> > @@ -0,0 +1,38 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2022 NXP
> > + */
> > +
> > +#ifndef __PHY_HDMI_H_
> > +#define __PHY_HDMI_H_
> > +
> > +/**
> > + * Pixel Encoding as HDMI Specification
> > + * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
> > + * YUV420: HDMI Specification 2.a Section 7.1 */ enum
> > +hdmi_phy_colorspace {
> > + HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
> > + HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
> > + HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
> > + HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
>
> Better add this comments and above one as expected by kernel-doc for
> enum..
OK, I will add it and it will replace by enum hdmi_colorspace in
in the next version.
>
> > + HDMI_PHY_COLORSPACE_RESERVED4,
> > + HDMI_PHY_COLORSPACE_RESERVED5,
> > + HDMI_PHY_COLORSPACE_RESERVED6,
> > +};
> > +
> > +/**
> > + * struct phy_configure_opts_hdmi - HDMI configuration set
> > + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> > + * @bpc: Maximum bits per color channel.
> > + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> > + *
> > + * This structure is used to represent the configuration state of a HDMI
> > phy.
> > + */
> > +struct phy_configure_opts_hdmi {
> > + unsigned int pixel_clk_rate;
> > + unsigned int bpc;
> > + enum hdmi_phy_colorspace color_space; };
> > +
> > +#endif /* __PHY_HDMI_H_ */
> > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h index
> > 3a570bc59fc7..93d77d45b1d4 100644
> > --- a/include/linux/phy/phy.h
> > +++ b/include/linux/phy/phy.h
> > @@ -17,6 +17,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -42,7 +43,8 @@ enum phy_mode {
> > PHY_MODE_MIPI_DPHY,
> > PHY_MODE_SATA,
> > PHY_MODE_LVDS,
> > - PHY_MODE_DP
> > + PHY_MODE_DP,
> > + PHY_MODE_HDMI,
> > };
> >
> > enum phy_media {
> > @@ -60,11 +62,14 @@ enum phy_media {
> > * the DisplayPort protocol.
> > * @lvds:Configuration set applicable for phys supporting
> > * the LVDS phy mode.
> > + * @hdmi:Configuration set applicable for phys supporting
> > + * the HDMI phy mode.
> > */
> > union phy_configure_opts {
> > struct phy_configure_opts_mipi_dphy mipi_dphy;
> > struct phy_configure_opts_dpdp;
> > struct phy_configure_opts_lvds lvds;
> > + struct phy_configure_opts_hdmi hdmi;
> > };
> >
> > /**
> > --
> > 2.34.1
>
> --
> ~Vinod
B.R
Sandor
RE: [EXT] Re: [PATCH v6 7/8] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
Hi Vinod, Thanks for your comments, > -Original Message- > From: Vinod Koul > Sent: 2023年6月21日 19:24 > To: Sandor Yu > Cc: andrzej.ha...@intel.com; neil.armstr...@linaro.org; > robert.f...@linaro.org; laurent.pinch...@ideasonboard.com; > jo...@kwiboo.se; jernej.skra...@gmail.com; airl...@gmail.com; > dan...@ffwll.ch; robh...@kernel.org; krzysztof.kozlowski...@linaro.org; > shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com; > dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; > linux-...@lists.infradead.org; ker...@pengutronix.de; dl-linux-imx > ; Oliver Brown > Subject: [EXT] Re: [PATCH v6 7/8] phy: freescale: Add DisplayPort PHY driver > for i.MX8MQ > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > On 15-06-23, 09:38, Sandor Yu wrote: > > Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ > > > > Cadence HDP-TX PHY could be put in either DP mode or HDMI mode base > on > > the configuration chosen. > > DisplayPort PHY mode is configurated in the driver. > > > > Signed-off-by: Sandor Yu > > --- > > drivers/phy/freescale/Kconfig | 9 + > > drivers/phy/freescale/Makefile| 1 + > > drivers/phy/freescale/phy-fsl-imx8mq-dp.c | 697 > > ++ > > 3 files changed, 707 insertions(+) > > create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-dp.c > > > > diff --git a/drivers/phy/freescale/Kconfig > > b/drivers/phy/freescale/Kconfig index 853958fb2c06..a99ee370eda6 > > 100644 > > --- a/drivers/phy/freescale/Kconfig > > +++ b/drivers/phy/freescale/Kconfig > > @@ -35,6 +35,15 @@ config PHY_FSL_IMX8M_PCIE > > Enable this to add support for the PCIE PHY as found on > > i.MX8M family of SOCs. > > > > +config PHY_CADENCE_DP_PHY > > + tristate "Cadence HDPTX DP PHY support" > > + depends on OF && HAS_IOMEM > > + depends on COMMON_CLK > > + select GENERIC_PHY > > + help > > + Enable this to support the Cadence HDPTX DP PHY driver > > + on NXP's i.MX8MQ SOC. > > + > > endif > > > > config PHY_FSL_LYNX_28G > > diff --git a/drivers/phy/freescale/Makefile > > b/drivers/phy/freescale/Makefile index cedb328bc4d2..c3bdf3fa2e72 > > 100644 > > --- a/drivers/phy/freescale/Makefile > > +++ b/drivers/phy/freescale/Makefile > > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += > phy-fsl-imx8qm-lvds-phy.o > > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o > > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o > > obj-$(CONFIG_PHY_FSL_LYNX_28G) += > phy-fsl-lynx-28g.o > > +obj-$(CONFIG_PHY_CADENCE_DP_PHY) += phy-fsl-imx8mq-dp.o > > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > > b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > > new file mode 100644 > > index ..2bd6772a5d3b > > --- /dev/null > > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > > @@ -0,0 +1,697 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Cadence HDP-TX Display Port Interface (DP) PHY driver > > + * > > + * Copyright (C) 2022 NXP Semiconductor, Inc. > > + */ > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > + > > +#define ADDR_PHY_AFE 0x8 > > Is this always fixed for every phy generation? Yes, the offset is fixed for every cdns hdmi/dp external phy. > > + > > +/* PHY registers */ > > +#define CMN_SSM_BIAS_TMR0x0022 > > +#define CMN_PLLSM0_PLLEN_TMR0x0029 > > +#define CMN_PLLSM0_PLLPRE_TMR 0x002A > > +#define CMN_PLLSM0_PLLVREF_TMR 0x002B > > +#define CMN_PLLSM0_PLLLOCK_TMR 0x002C > > +#define CMN_PLLSM0_USER_DEF_CTRL0x002F > > +#define CMN_PSM_CLK_CTRL0x0061 > > +#define CMN_PLL0_VCOCAL_START 0x0081 > > +#define CMN_PLL0_VCOCAL_INIT_TMR0x0084 > > +#define CMN_PLL0_VCOCAL_ITER_TMR0x0085 > > +#define CMN_PLL0_INTDIV 0x0094 > > +#define CMN_PLL0_FRACDIV0x0095 > > +#define CMN_PLL0_HIGH_THR 0x0096 > > +#define CMN_PLL0_DSM_DIAG 0x0097 > > +#define CMN_PLL0_SS_CTRL2 0x0099 > > +#define CMN_ICAL_INIT_TMR 0x00C4 > > +#define CMN_ICAL_ITER_TMR 0x00C5 > > +#define CMN_RXCAL_INIT_TMR 0x00D4 > > +#define CMN_RXCAL_ITER_TMR 0x00D5 > > +#define CMN_TXPUCAL_INIT_TMR0x00E4 > > +#define CMN_TXPUCAL_ITER_TMR0x00E5 > > +#define CMN_TXPDCAL_INIT_TMR0x00F4 > > +#define CMN_TXPDCAL_ITER_TMR0x00F5 > > +#define CMN_ICAL_ADJ_INIT_TMR 0x0102 > > +#define CMN_ICAL_ADJ_ITER_TMR 0x0103 > > +#define CMN_RX_ADJ_INIT_TMR 0x0106 > > +#define CMN_RX_ADJ_ITER_TMR 0x0107 >
RE: [EXT] Re: [PATCH v6 8/8] phy: freescale: Add HDMI PHY driver for i.MX8MQ
Hi Vinod, Thanks for your comments, > -Original Message- > From: Vinod Koul > Sent: 2023年6月21日 19:58 > To: Sandor Yu > Cc: andrzej.ha...@intel.com; neil.armstr...@linaro.org; > robert.f...@linaro.org; laurent.pinch...@ideasonboard.com; > jo...@kwiboo.se; jernej.skra...@gmail.com; airl...@gmail.com; > dan...@ffwll.ch; robh...@kernel.org; krzysztof.kozlowski...@linaro.org; > shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com; > dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; > linux-...@lists.infradead.org; ker...@pengutronix.de; dl-linux-imx > ; Oliver Brown > Subject: [EXT] Re: [PATCH v6 8/8] phy: freescale: Add HDMI PHY driver for > i.MX8MQ > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > On 15-06-23, 09:38, Sandor Yu wrote: > > Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ. > > > > Cadence HDP-TX PHY could be put in either DP mode or HDMI mode base > on > > the configuration chosen. > > HDMI PHY mode is configurated in the driver. > > > > Signed-off-by: Sandor Yu > > --- > > drivers/phy/freescale/Kconfig | 9 + > > drivers/phy/freescale/Makefile | 1 + > > drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c | 889 > > > > 3 files changed, 899 insertions(+) > > create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > > > diff --git a/drivers/phy/freescale/Kconfig > > b/drivers/phy/freescale/Kconfig index a99ee370eda6..e007e15e503a > > 100644 > > --- a/drivers/phy/freescale/Kconfig > > +++ b/drivers/phy/freescale/Kconfig > > @@ -44,6 +44,15 @@ config PHY_CADENCE_DP_PHY > > Enable this to support the Cadence HDPTX DP PHY driver > > on NXP's i.MX8MQ SOC. > > > > +config PHY_CADENCE_HDMI_PHY > > + tristate "Cadence HDPTX HDMI PHY Driver" > > + depends on OF && HAS_IOMEM > > + depends on COMMON_CLK > > + select GENERIC_PHY > > + help > > + Enable this to support the Cadence HDPTX HDMI PHY driver. > > + on NXP's i.MX8MQ SOC. > > + > > endif > > > > config PHY_FSL_LYNX_28G > > diff --git a/drivers/phy/freescale/Makefile > > b/drivers/phy/freescale/Makefile index c3bdf3fa2e72..d25fafd91c53 > > 100644 > > --- a/drivers/phy/freescale/Makefile > > +++ b/drivers/phy/freescale/Makefile > > @@ -5,3 +5,4 @@ obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += > phy-fsl-imx8-mipi-dphy.o > > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o > > obj-$(CONFIG_PHY_FSL_LYNX_28G) += > phy-fsl-lynx-28g.o > > obj-$(CONFIG_PHY_CADENCE_DP_PHY) += phy-fsl-imx8mq-dp.o > > +obj-$(CONFIG_PHY_CADENCE_HDMI_PHY) += phy-fsl-imx8mq-hdmi.o > > Pls sort alphabetically (both Kconfig and Makefile) OK, and the name will be change to CONFIG_PHY_FSL_IMX8MQ_HDMI_PHY and CONFIG_PHY_FSL_IMX8MQ_DP_PHY. in the next version. > > > > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > new file mode 100644 > > index ..65aeb9835bb9 > > --- /dev/null > > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > @@ -0,0 +1,889 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Cadence High-Definition Multimedia Interface (HDMI) PHY driver > > + * > > + * Copyright (C) 2022 NXP Semiconductor, Inc. > > + */ > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > + > > +#define ADDR_PHY_AFE 0x8 > > +/* PHY registers */ > > +#define CMN_SSM_BIAS_TMR0x0022 > > +#define CMN_PLLSM0_USER_DEF_CTRL0x002F > > +#define CMN_PSM_CLK_CTRL0x0061 > > +#define CMN_CDIAG_REFCLK_CTRL 0x0062 > > +#define CMN_PLL0_VCOCAL_START 0x0081 > > +#define CMN_PLL0_VCOCAL_INIT_TMR0x0084 > > +#define CMN_PLL0_VCOCAL_ITER_TMR0x0085 > > +#define CMN_TXPUCAL_CTRL0x00E0 > > +#define CMN_TXPDCAL_CTRL0x00F0 > > +#define CMN_TXPU_ADJ_CTRL 0x0108 > > +#define CMN_TXPD_ADJ_CTRL 0x010c > > +#define CMN_DIAG_PLL0_FBH_OVRD 0x01C0 > > +#define CMN_DIAG_PLL0_FBL_OVRD 0x01C1 > > +#define CMN_DIAG_PLL0_OVRD 0x01C2 > > +#define CMN_DIAG_PLL0_TEST_MODE 0x01C4 > > +#define CMN_DIAG_PLL0_V2I_TUNE 0x01C5 > > +#define CMN_DIAG_PLL0_CP_TUNE 0x01C6 > > +#define CMN_DIAG_PLL0_LF_PROG 0x01C7 > > +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01C8 > > +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01C9 > > +#define CMN_DIAG_PLL0_INCLK_CTRL0x01CA > > +#define CMN_DIAG_PLL0_PXL_DIVH 0x01CB > > +#define CMN_DIAG_PLL0_PXL_DIVL 0x01CC > > +#define CMN_DIAG_HSCLK_SEL 0x01E0 > > +#define XCVR_PSM_RCTRL 0x4001 > > +#define TX_TXCC_CAL_SCLR_MULT_0 0x4047 >
Re: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
On Mon, 10 Jul 2023 at 10:28, Sandor Yu wrote:
>
> Hi Dmitry,
>
> Thanks for your comments,
>
> > -Original Message-
> > From: Dmitry Baryshkov
> > Sent: 2023年6月25日 2:02
> > To: Sandor Yu ; andrzej.ha...@intel.com;
> > neil.armstr...@linaro.org; robert.f...@linaro.org;
> > laurent.pinch...@ideasonboard.com; jo...@kwiboo.se;
> > jernej.skra...@gmail.com; airl...@gmail.com; dan...@ffwll.ch;
> > robh...@kernel.org; krzysztof.kozlowski...@linaro.org;
> > shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> > vk...@kernel.org; dri-devel@lists.freedesktop.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux-ker...@vger.kernel.org; linux-...@lists.infradead.org
> > Cc: ker...@pengutronix.de; dl-linux-imx ; Oliver Brown
> >
> > Subject: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
Is this part necessary?
> >
> > Caution: This is an external email. Please take care when clicking links or
> > opening attachments. When in doubt, report the message using the 'Report
> > this email' button
> >
> >
> > On 15/06/2023 04:38, Sandor Yu wrote:
> > > Allow HDMI PHYs to be configured through the generic functions through
> > > a custom structure added to the generic union.
> > >
> > > The parameters added here are based on HDMI PHY implementation
> > > practices. The current set of parameters should cover the potential
> > > users.
> > >
> > > Signed-off-by: Sandor Yu
> > > ---
> > > include/linux/phy/phy-hdmi.h | 38
> >
> > > include/linux/phy/phy.h | 7 ++-
> > > 2 files changed, 44 insertions(+), 1 deletion(-)
> > > create mode 100644 include/linux/phy/phy-hdmi.h
> > >
> > > diff --git a/include/linux/phy/phy-hdmi.h
> > > b/include/linux/phy/phy-hdmi.h new file mode 100644 index
> > > ..5765aa5bc175
> > > --- /dev/null
> > > +++ b/include/linux/phy/phy-hdmi.h
> > > @@ -0,0 +1,38 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Copyright 2022 NXP
> > > + */
> > > +
> > > +#ifndef __PHY_HDMI_H_
> > > +#define __PHY_HDMI_H_
> > > +
> > > +/**
> > > + * Pixel Encoding as HDMI Specification
> > > + * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
> > > + * YUV420: HDMI Specification 2.a Section 7.1 */ enum
> > > +hdmi_phy_colorspace {
> > > + HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
> > > + HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
> > > + HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
> > > + HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
> > > + HDMI_PHY_COLORSPACE_RESERVED4,
> > > + HDMI_PHY_COLORSPACE_RESERVED5,
> > > + HDMI_PHY_COLORSPACE_RESERVED6,
> > > +};
> >
> > This enum duplicates enum hdmi_colorspace from HDMI 2.0
> > defines '7' to be IDO-defined.
> >
> > Would it be better to use that enum instead?
> Accept. I will create head file hdmi_colorspace.h to reuse enum
> hdmi_colorspace in .
Hmm, you need another header file to reuse this enum.
>
> B.R
> Sandor
> >
> > > +
> > > +/**
> > > + * struct phy_configure_opts_hdmi - HDMI configuration set
> > > + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> > > + * @bpc: Maximum bits per color channel.
> > > + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> > > + *
> > > + * This structure is used to represent the configuration state of a HDMI
> > > phy.
> > > + */
> > > +struct phy_configure_opts_hdmi {
> > > + unsigned int pixel_clk_rate;
> > > + unsigned int bpc;
> > > + enum hdmi_phy_colorspace color_space; };
> > > +
> > > +#endif /* __PHY_HDMI_H_ */
> >
> > [skipped the rest]
> >
> > --
> > With best wishes
> > Dmitry
>
--
With best wishes
Dmitry
Re: [PATCH v2 3/3] ARM: dts: exynos/i9100: Fix LCD screen's physical size
Hi Krzysztof,
Le lundi 10 juillet 2023 à 08:59 +0200, Krzysztof Kozlowski a écrit :
> On 08/07/2023 10:40, Paul Cercueil wrote:
> > The previous values were completely bogus, and resulted in the
> > computed
> > DPI ratio being much lower than reality, causing applications and
> > UIs to
> > misbehave.
> >
> > The new values were measured by myself with a ruler.
> >
> > Signed-off-by: Paul Cercueil
> > Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the
> > Galaxy S2")
> > Cc: # v5.8+
> > ---
>
> This does not apply. You rebased your work on some older
> version/tree,
> without new layout. Please work on linux-next.
This patchset was based on drm-misc-next, because that's where I was
planning to apply it; and it was extremely unlikely (but not
impossible, apparently) that the i9100.dts would be modified in the
meantime.
I can rebase on linux-next, the problem then is that I then don't know
how/where to apply the patchset.
Cheers,
-Paul
Re: [drm-misc:drm-misc-next 2/3] drivers/gpu/drm/loongson/lsdc_plane.c:199 lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 180)
Hi,
On 2023/7/10 15:19, Thomas Zimmermann wrote:
Hi
Am 10.07.23 um 09:02 schrieb suijingfeng:
Hi,
Thanks for testing,
What do you means about tell me this?
I means that would you like to help fixing this warning?
The code in drm_atomic_get_new_plane_state() dereferences the state
parameter. Later in your function, you test for state to be non-NULL.
That's what the warning is about.
You should be able to silence this warning by removing the state test
from your function (and also delete that else branch). There should
always be an atomic state present and the atomic-check callbacks
should not be called without a state. If not, the driver most likely
failed to initialize correctly.
Yes, I will create a patch to fix this warning before tonight.
The driver works very well, it never print with kernel 'cmd drm.debug=0x02'.
I just feel interesting, thanks.
Best regards
Thomas
Or otherwise, I will fix this someday.
On 2023/7/10 14:29, Dan Carpenter wrote:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 8d1077cf2e43b15fefd76ebec2b71541eb27ef2c
commit: f39db26c54281da6a785259498ca74b5e470476f [2/3] drm: Add kms
driver for loongson display controller
config: i386-randconfig-m021-20230710
(https://download.01.org/0day-ci/archive/20230710/202307100423.rv7d05uq-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20230710/202307100423.rv7d05uq-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new
version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Reported-by: Dan Carpenter
| Closes:
https://lore.kernel.org/r/202307100423.rv7d05uq-...@intel.com/
smatch warnings:
drivers/gpu/drm/loongson/lsdc_plane.c:199
lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced
before check 'state' (see line 180)
vim +/state +199 drivers/gpu/drm/loongson/lsdc_plane.c
f39db26c54281d Sui Jingfeng 2023-06-15 174 static int
lsdc_cursor_plane_atomic_async_check(struct drm_plane *plane,
f39db26c54281d Sui Jingfeng 2023-06-15 175
struct drm_atomic_state *state)
f39db26c54281d Sui Jingfeng 2023-06-15 176 {
f39db26c54281d Sui Jingfeng 2023-06-15 177 struct
drm_plane_state *new_state;
f39db26c54281d Sui Jingfeng 2023-06-15 178 struct
drm_crtc_state *crtc_state;
f39db26c54281d Sui Jingfeng 2023-06-15 179
f39db26c54281d Sui Jingfeng 2023-06-15 @180 new_state =
drm_atomic_get_new_plane_state(state, plane);
^
state is dereferenced inside this function
f39db26c54281d Sui Jingfeng 2023-06-15 181
f39db26c54281d Sui Jingfeng 2023-06-15 182 if (!plane->state
|| !plane->state->fb) {
f39db26c54281d Sui Jingfeng 2023-06-15 183 drm_dbg(plane->dev, "%s:
state is NULL\n", plane->name);
f39db26c54281d Sui Jingfeng 2023-06-15 184 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 185 }
f39db26c54281d Sui Jingfeng 2023-06-15 186
f39db26c54281d Sui Jingfeng 2023-06-15 187 if
(new_state->crtc_w != new_state->crtc_h) {
f39db26c54281d Sui Jingfeng 2023-06-15 188 drm_dbg(plane->dev,
"unsupported cursor size: %ux%u\n",
f39db26c54281d Sui Jingfeng 2023-06-15 189 new_state->crtc_w,
new_state->crtc_h);
f39db26c54281d Sui Jingfeng 2023-06-15 190 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 191 }
f39db26c54281d Sui Jingfeng 2023-06-15 192
f39db26c54281d Sui Jingfeng 2023-06-15 193 if
(new_state->crtc_w != 64 && new_state->crtc_w != 32) {
f39db26c54281d Sui Jingfeng 2023-06-15 194 drm_dbg(plane->dev,
"unsupported cursor size: %ux%u\n",
f39db26c54281d Sui Jingfeng 2023-06-15 195 new_state->crtc_w,
new_state->crtc_h);
f39db26c54281d Sui Jingfeng 2023-06-15 196 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 197 }
f39db26c54281d Sui Jingfeng 2023-06-15 198
f39db26c54281d Sui Jingfeng 2023-06-15 @199 if (state) {
^
Checked too late
f39db26c54281d Sui Jingfeng 2023-06-15 200 crtc_state =
drm_atomic_get_existing_crtc_state(state, new_state->crtc);
f39db26c54281d Sui Jingfeng 2023-06-15 201 } else {
f39db26c54281d Sui Jingfeng 2023-06-15 202 crtc_state =
plane->crtc->state;
f39db26c54281d Sui Jingfeng 2023-06-15 203 drm_dbg(plane->dev, "%s:
atomic state is NULL\n", plane->name);
f39db26c54281d Sui Jingfeng 2023-06-15 204 }
f39db26c54281d Sui Jingfeng 2023-06-15 205
f39db26c54281d Sui Jingfeng 2023-06-15 206 if
(!crtc_state->active)
f39db26c54281d Sui Jingfeng 2023-06-15 207 return -EINVAL;
f39db26c54281d Sui Jingfeng 2023-06-15 208
f39db26c54281d Sui Jingfeng 2023-06-15 209 if
(plane->state->crtc != new_state->crtc ||
f39db26c54281d Sui J
Re: [PATCH v4 0/9] MediaTek DisplayPort: support eDP and aux-bus
Il 07/07/23 10:23, Chen-Yu Tsai ha scritto:
On Thu, Jul 6, 2023 at 8:30 PM AngeloGioacchino Del Regno
wrote:
Changes in v4:
- Set data lanes to idle to prevent stalls if bootloader didn't
properly close the eDP port
- Now using the .done_probing() callback for AUX bus to prevent
probe deferral loops in case the panel-edp driver is a module
as previously seen with another bridge driver (ANX7625) on
some other SoCs (MT8192 and others)
- Rebased over next-20230706
- Dropped Chen-Yu's T-b tag on last patch as some logic changed
(before, I wasn't using the .done_probing() callback).
Changes in v3:
- Added DPTX AUX block initialization before trying to communicate
to stop relying on the bootloader keeping it initialized before
booting Linux.
- Fixed commit description for patch [09/09] and removed commented
out code (that slipped from dev phase.. sorry!).
This series adds "real" support for eDP in the mtk-dp DisplayPort driver.
Explaining the "real":
Before this change, the DisplayPort driver did support eDP to some
extent, but it was treating it entirely like a regular DP interface
which is partially fine, after all, embedded DisplayPort *is* actually
DisplayPort, but there might be some differences to account for... and
this is for both small performance improvements and, more importantly,
for correct functionality in some systems.
Functionality first:
One of the common differences found in various boards implementing eDP
and machines using an eDP panel is that many times the HPD line is not
connected. This *must* be accounted for: at startup, this specific IP
will raise a HPD interrupt (which should maybe be ignored... as it does
not appear to be a "real" event...) that will make the eDP panel to be
detected and to actually work but, after a suspend-resume cycle, there
will be no HPD interrupt (as there's no HPD line in my case!) producing
a functionality issue - specifically, the DP Link Training fails because
the panel doesn't get powered up, then it stays black and won't work
until rebooting the machine (or removing and reinserting the module I
think, but I haven't tried that).
Now for.. both:
eDP panels are *e*DP because they are *not* removable (in the sense that
you can't unplug the cable without disassembling the machine, in which
case, the machine shall be powered down..!): this (correct) assumption
makes us able to solve some issues and to also gain a little performance
during PM operations.
What was done here is:
- Caching the EDID if the panel is eDP: we're always going to read the
same data everytime, so we can just cache that (as it's small enough)
shortening PM resume times for the eDP driver instance;
- Always return connector_status_connected if it's eDP: non-removable
means connector_status_disconnected can't happen during runtime...
this also saves us some time and even power, as we won't have to
perform yet another power cycle of the HW;
- Added aux-bus support!
This makes us able to rely on panel autodetection from the EDID,
avoiding to add more and more panel timings to panel-edp and, even
better, allowing to use one panel node in devicetrees for multiple
variants of the same machine since, at that point, it's not important
to "preventively know" what panel we have (eh, it's autodetected...!).
This was tested on a MT8195 Cherry Tomato Chromebook (panel-edp on aux-bus)
Do you have panel-edp built as a module? If I have it built in, the panel
can correctly display stuff. If I have it built as a module, the panel is
correctly detected, but the panel stays black even if DRM thinks it is
displaying stuff.
I tested both. I'll recheck on a clean tree just to be sure...
And it looks like EDID reading and panel power sequencing is still not
working correctly, i.e. needs regulator-always-on?
Yeah that's still needed with this version, I'm still trying to get *at least*
some support upstreamed before refining it.
Cheers,
Angelo
ChenYu
P.S.: For your own testing commodity, here's a reference devicetree:
&edp_tx {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&edptx_pins_default>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
edp_in: endpoint {
remote-endpoint = <&dp_intf0_out>;
};
};
port@1 {
reg = <1>;
edp_out: endpoint {
data-lanes = <0 1 2 3>;
remote-endpoint = <&panel_in>;
};
};
};
aux-bus {
panel: panel {
compatible = "edp-panel";
power-supply = <&pp3300_disp_x>;
[PATCH] drm/radeon: ERROR: "foo * bar" should be "foo *bar"
Fix nine occurrences of the checkpatch.pl error:
ERROR: "foo * bar" should be "foo *bar"
Signed-off-by: Ran Sun
---
drivers/gpu/drm/radeon/atom.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c
b/drivers/gpu/drm/radeon/atom.c
index c1bbfbe28bda..11a1940bb26d 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -1156,7 +1156,7 @@ static struct {
atom_op_shr, ATOM_ARG_MC}, {
atom_op_debug, 0},};
-static int atom_execute_table_locked(struct atom_context *ctx, int
index, uint32_t * params)
+static int atom_execute_table_locked(struct atom_context *ctx, int
index, uint32_t *params)
{
int base = CU16(ctx->cmd_table + 4 + 2 * index);
int len, ws, ps, ptr;
@@ -1216,7 +1216,7 @@ static int atom_execute_table_locked(struct
atom_context *ctx, int index, uint32
return ret;
}
-int atom_execute_table_scratch_unlocked(struct atom_context *ctx, int
index, uint32_t * params)
+int atom_execute_table_scratch_unlocked(struct atom_context *ctx, int
index, uint32_t *params)
{
int r;
@@ -1237,7 +1237,7 @@ int atom_execute_table_scratch_unlocked(struct
atom_context *ctx, int index, uin
return r;
}
-int atom_execute_table(struct atom_context *ctx, int index, uint32_t *
params)
+int atom_execute_table(struct atom_context *ctx, int index, uint32_t
*params)
{
int r;
mutex_lock(&ctx->scratch_mutex);
@@ -1359,8 +1359,8 @@ void atom_destroy(struct atom_context *ctx)
}
bool atom_parse_data_header(struct atom_context *ctx, int index,
-uint16_t * size, uint8_t * frev, uint8_t * crev,
-uint16_t * data_start)
+uint16_t *size, uint8_t *frev, uint8_t *crev,
+uint16_t *data_start)
{
int offset = index * 2 + 4;
int idx = CU16(ctx->data_table + offset);
@@ -1379,8 +1379,8 @@ bool atom_parse_data_header(struct atom_context
*ctx, int index,
return true;
}
-bool atom_parse_cmd_header(struct atom_context *ctx, int index, uint8_t
* frev,
- uint8_t * crev)
+bool atom_parse_cmd_header(struct atom_context *ctx, int index, uint8_t
*frev,
+ uint8_t *crev)
{
int offset = index * 2 + 4;
int idx = CU16(ctx->cmd_table + offset);
Re: [PATCH] fbdev: imxfb: Convert to devm_platform_ioremap_resource()
Hi Yangtao,
On Mon, Jul 10, 2023 at 9:25 AM Yangtao Li wrote:
> On 2023/7/10 15:10, Geert Uytterhoeven wrote:
> > [你通常不会收到来自 ge...@linux-m68k.org 的电子邮件。请访问
> > https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
> > On Tue, Jul 4, 2023 at 11:38 AM Yangtao Li wrote:
> >> Use devm_platform_ioremap_resource() to simplify code.
> >>
> >> Signed-off-by: Yangtao Li
> > Thanks for your patch, which is now commit c1cd7a7a231a26c6 ("fbdev:
> > imxfb: Convert to devm_platform_ioremap_resource()") in fbdev/for-next
> >
> >> --- a/drivers/video/fbdev/imxfb.c
> >> +++ b/drivers/video/fbdev/imxfb.c
> >> @@ -868,7 +868,6 @@ static int imxfb_probe(struct platform_device *pdev)
> >> struct imxfb_info *fbi;
> >> struct lcd_device *lcd;
> >> struct fb_info *info;
> >> - struct resource *res;
> >> struct imx_fb_videomode *m;
> >> const struct of_device_id *of_id;
> >> struct device_node *display_np;
> >> @@ -885,10 +884,6 @@ static int imxfb_probe(struct platform_device *pdev)
> >> if (of_id)
> >> pdev->id_entry = of_id->data;
> >>
> >> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> - if (!res)
> >> - return -ENODEV;
> >> -
> >> info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
> >> if (!info)
> >> return -ENOMEM;
> >> @@ -970,7 +965,7 @@ static int imxfb_probe(struct platform_device *pdev)
> >> goto failed_getclock;
> >> }
> >>
> >> - fbi->regs = devm_ioremap_resource(&pdev->dev, res);
> >> + fbi->regs = devm_platform_ioremap_resource(pdev, 0);
> >> if (IS_ERR(fbi->regs)) {
> >> ret = PTR_ERR(fbi->regs);
> >> goto failed_ioremap;
> >> @@ -1043,7 +1038,6 @@ static int imxfb_probe(struct platform_device *pdev)
> >> failed_map:
> >> failed_ioremap:
> >> failed_getclock:
> >> - release_mem_region(res->start, resource_size(res));
> > This part is not directly related, but a bug fix for commit
> > b083c22d51148f3d ("video: fbdev: imxfb: Convert request_mem_region +
> > ioremap to devm_ioremap_resource") in v6.0.
>
>
> IIUC, split this patch into two, remove release_mem_region in one and
>
> mark it as Fixes: b083c22d51148f3d ("video: fbdev: imxfb: Convert
> request_mem_region +
>
> ioremap to devm_ioremap_resource")?
Exactly. But as Helge has already applied this patch to his tree, we have
to check with him if this is still feasible...
> > Please do not mix bug fixes with other changes.
> > The stable teams want to backport only bugfixes .
> >
> >> failed_of_parse:
> >> kfree(info->pseudo_palette);
> >> failed_init:
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 2023年7月10日 15:30
> To: Sandor Yu
> Cc: andrzej.ha...@intel.com; neil.armstr...@linaro.org;
> robert.f...@linaro.org; laurent.pinch...@ideasonboard.com;
> jo...@kwiboo.se; jernej.skra...@gmail.com; airl...@gmail.com;
> dan...@ffwll.ch; robh...@kernel.org; krzysztof.kozlowski...@linaro.org;
> shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> vk...@kernel.org; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; linux-...@lists.infradead.org;
> ker...@pengutronix.de; dl-linux-imx ; Oliver Brown
>
> Subject: Re: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
>
>
> On Mon, 10 Jul 2023 at 10:28, Sandor Yu wrote:
> >
> > Hi Dmitry,
> >
> > Thanks for your comments,
> >
> > > -Original Message-
> > > From: Dmitry Baryshkov
> > > Sent: 2023年6月25日 2:02
> > > To: Sandor Yu ; andrzej.ha...@intel.com;
> > > neil.armstr...@linaro.org; robert.f...@linaro.org;
> > > laurent.pinch...@ideasonboard.com; jo...@kwiboo.se;
> > > jernej.skra...@gmail.com; airl...@gmail.com; dan...@ffwll.ch;
> > > robh...@kernel.org; krzysztof.kozlowski...@linaro.org;
> > > shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> > > vk...@kernel.org; dri-devel@lists.freedesktop.org;
> > > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > linux-ker...@vger.kernel.org; linux-...@lists.infradead.org
> > > Cc: ker...@pengutronix.de; dl-linux-imx ; Oliver
> > > Brown
> > > Subject: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration
> > > options
>
> Is this part necessary?
No, forgot to remove the Caution it is auto added by mail system.
>
> > >
> > > Caution: This is an external email. Please take care when clicking
> > > links or opening attachments. When in doubt, report the message
> > > using the 'Report this email' button
> > >
> > >
> > > On 15/06/2023 04:38, Sandor Yu wrote:
> > > > Allow HDMI PHYs to be configured through the generic functions
> > > > through a custom structure added to the generic union.
> > > >
> > > > The parameters added here are based on HDMI PHY implementation
> > > > practices. The current set of parameters should cover the
> > > > potential users.
> > > >
> > > > Signed-off-by: Sandor Yu
> > > > ---
> > > > include/linux/phy/phy-hdmi.h | 38
> > >
> > > > include/linux/phy/phy.h | 7 ++-
> > > > 2 files changed, 44 insertions(+), 1 deletion(-)
> > > > create mode 100644 include/linux/phy/phy-hdmi.h
> > > >
> > > > diff --git a/include/linux/phy/phy-hdmi.h
> > > > b/include/linux/phy/phy-hdmi.h new file mode 100644 index
> > > > ..5765aa5bc175
> > > > --- /dev/null
> > > > +++ b/include/linux/phy/phy-hdmi.h
> > > > @@ -0,0 +1,38 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +/*
> > > > + * Copyright 2022 NXP
> > > > + */
> > > > +
> > > > +#ifndef __PHY_HDMI_H_
> > > > +#define __PHY_HDMI_H_
> > > > +
> > > > +/**
> > > > + * Pixel Encoding as HDMI Specification
> > > > + * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
> > > > + * YUV420: HDMI Specification 2.a Section 7.1 */ enum
> > > > +hdmi_phy_colorspace {
> > > > + HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
> > > > + HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
> > > > + HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
> > > > + HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
> > > > + HDMI_PHY_COLORSPACE_RESERVED4,
> > > > + HDMI_PHY_COLORSPACE_RESERVED5,
> > > > + HDMI_PHY_COLORSPACE_RESERVED6, };
> > >
> > > This enum duplicates enum hdmi_colorspace from HDMI
> > > 2.0 defines '7' to be IDO-defined.
> > >
> > > Would it be better to use that enum instead?
> > Accept. I will create head file hdmi_colorspace.h to reuse enum
> hdmi_colorspace in .
>
> Hmm, you need another header file to reuse this enum.
>
> >
> > B.R
> > Sandor
> > >
> > > > +
> > > > +/**
> > > > + * struct phy_configure_opts_hdmi - HDMI configuration set
> > > > + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> > > > + * @bpc: Maximum bits per color channel.
> > > > + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> > > > + *
> > > > + * This structure is used to represent the configuration state of a
> > > > HDMI
> phy.
> > > > + */
> > > > +struct phy_configure_opts_hdmi {
> > > > + unsigned int pixel_clk_rate;
> > > > + unsigned int bpc;
> > > > + enum hdmi_phy_colorspace color_space; };
> > > > +
> > > > +#endif /* __PHY_HDMI_H_ */
> > >
> > > [skipped the rest]
> > >
> > > --
> > > With best wishes
> > > Dmitry
> >
>
>
> --
> With best wishes
> Dmitry
B.R
Sandor
[syzbot] [dri?] KASAN: slab-use-after-free Read in drm_atomic_helper_wait_for_vblanks
Hello, syzbot found the following issue on: HEAD commit:03275585cabd afs: Fix accidental truncation when storing d.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16db258ca8 kernel config: https://syzkaller.appspot.com/x/.config?x=d576750da57ebbb5 dashboard link: https://syzkaller.appspot.com/bug?extid=380dcf72caf0b5ef5537 compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-03275585.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/6d035553cd50/vmlinux-03275585.xz kernel image: https://storage.googleapis.com/syzbot-assets/2fd7f855c25e/bzImage-03275585.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+380dcf72caf0b5ef5...@syzkaller.appspotmail.com BUG: KASAN: slab-use-after-free in drm_atomic_helper_wait_for_vblanks.part.0+0x77a/0x860 drivers/gpu/drm/drm_atomic_helper.c:1650 Read of size 1 at addr 888023f61009 by task kworker/u17:6/4248 CPU: 3 PID: 4248 Comm: kworker/u17:6 Not tainted 6.4.0-syzkaller-11472-g03275585cabd #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: events_unbound commit_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:364 print_report mm/kasan/report.c:475 [inline] kasan_report+0x11d/0x130 mm/kasan/report.c:588 drm_atomic_helper_wait_for_vblanks.part.0+0x77a/0x860 drivers/gpu/drm/drm_atomic_helper.c:1650 drm_atomic_helper_wait_for_vblanks drivers/gpu/drm/drm_atomic_helper.c:1646 [inline] drm_atomic_helper_commit_tail+0xc7/0xf0 drivers/gpu/drm/drm_atomic_helper.c:1746 commit_tail+0x32d/0x420 drivers/gpu/drm/drm_atomic_helper.c:1823 process_one_work+0xa34/0x16f0 kernel/workqueue.c:2597 worker_thread+0x67d/0x10c0 kernel/workqueue.c:2748 kthread+0x344/0x440 kernel/kthread.c:389 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 Allocated by task 28853: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_kmalloc mm/kasan/common.c:374 [inline] kasan_kmalloc mm/kasan/common.c:333 [inline] __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383 kmalloc include/linux/slab.h:579 [inline] drm_atomic_helper_crtc_duplicate_state+0x6f/0xc0 drivers/gpu/drm/drm_atomic_state_helper.c:177 drm_simple_kms_crtc_duplicate_state+0x8b/0xb0 drivers/gpu/drm/drm_simple_kms_helper.c:166 drm_atomic_get_crtc_state+0x179/0x470 drivers/gpu/drm/drm_atomic.c:353 page_flip_common+0x57/0x310 drivers/gpu/drm/drm_atomic_helper.c:3589 drm_atomic_helper_page_flip+0xb8/0x190 drivers/gpu/drm/drm_atomic_helper.c:3650 drm_mode_page_flip_ioctl+0xf20/0x12a0 drivers/gpu/drm/drm_plane.c:1373 drm_ioctl_kernel+0x281/0x4e0 drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0x577/0xb30 drivers/gpu/drm/drm_ioctl.c:891 drm_compat_ioctl+0x375/0x4b0 drivers/gpu/drm/drm_ioc32.c:988 __do_compat_sys_ioctl+0x25b/0x2b0 fs/ioctl.c:968 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Freed by task 28850: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:521 kasan_slab_free mm/kasan/common.c:236 [inline] kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200 kasan_slab_free include/linux/kasan.h:162 [inline] slab_free_hook mm/slub.c:1792 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1818 slab_free mm/slub.c:3801 [inline] __kmem_cache_free+0xb8/0x2d0 mm/slub.c:3814 drm_simple_kms_crtc_destroy_state+0x8c/0xb0 drivers/gpu/drm/drm_simple_kms_helper.c:177 drm_atomic_state_default_clear+0x3a7/0xdd0 drivers/gpu/drm/drm_atomic.c:219 drm_atomic_state_clear drivers/gpu/drm/drm_atomic.c:288 [inline] __drm_atomic_state_free+0x176/0x2b0 drivers/gpu/drm/drm_atomic.c:304 kref_put include/linux/kref.h:65 [inline] drm_atomic_state_put include/drm/drm_atomic.h:490 [inline] drm_client_modeset_commit_atomic+0x6b0/0x7e0 drivers/gpu/drm/drm_client_modeset.c:1051 drm_client_modeset_commit_locked+0x149/0x580 drivers/gpu/drm/drm_client_modeset.c:1148 drm_client_modeset_commit+0x51/0x80 drivers/gpu/drm/drm_client_modeset.c:1174 __drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:251 [inline] __drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:230 [inline] drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:278 [inline] drm_fb_helper_lastclose+0xc5/0x170 drivers/gpu/drm/drm_fb_helper.c:2005
Re: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
On 10/07/2023 10:28, Sandor Yu wrote:
Hi Dmitry,
Thanks for your comments,
From: Dmitry Baryshkov
On 15/06/2023 04:38, Sandor Yu wrote:
Allow HDMI PHYs to be configured through the generic functions through
a custom structure added to the generic union.
The parameters added here are based on HDMI PHY implementation
practices. The current set of parameters should cover the potential
users.
Signed-off-by: Sandor Yu
---
include/linux/phy/phy-hdmi.h | 38
include/linux/phy/phy.h | 7 ++-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 include/linux/phy/phy-hdmi.h
diff --git a/include/linux/phy/phy-hdmi.h
b/include/linux/phy/phy-hdmi.h new file mode 100644 index
..5765aa5bc175
--- /dev/null
+++ b/include/linux/phy/phy-hdmi.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2022 NXP
+ */
+
+#ifndef __PHY_HDMI_H_
+#define __PHY_HDMI_H_
+
+/**
+ * Pixel Encoding as HDMI Specification
+ * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
+ * YUV420: HDMI Specification 2.a Section 7.1 */ enum
+hdmi_phy_colorspace {
+ HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
+ HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
+ HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
+ HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
+ HDMI_PHY_COLORSPACE_RESERVED4,
+ HDMI_PHY_COLORSPACE_RESERVED5,
+ HDMI_PHY_COLORSPACE_RESERVED6,
+};
This enum duplicates enum hdmi_colorspace from HDMI 2.0
defines '7' to be IDO-defined.
Would it be better to use that enum instead?
Accept. I will create head file hdmi_colorspace.h to reuse enum hdmi_colorspace in
.
Excuse me, it was supposed to be a question.
Do you need another header file to reuse this enum?
B.R
Sandor
+
+/**
+ * struct phy_configure_opts_hdmi - HDMI configuration set
+ * @pixel_clk_rate: Pixel clock of video modes in KHz.
+ * @bpc: Maximum bits per color channel.
+ * @color_space: Colorspace in enum hdmi_phy_colorspace.
+ *
+ * This structure is used to represent the configuration state of a HDMI phy.
+ */
+struct phy_configure_opts_hdmi {
+ unsigned int pixel_clk_rate;
+ unsigned int bpc;
+ enum hdmi_phy_colorspace color_space; };
+
+#endif /* __PHY_HDMI_H_ */
[skipped the rest]
--
With best wishes
Dmitry
--
With best wishes
Dmitry
Re: [PATCH v2 3/3] ARM: dts: exynos/i9100: Fix LCD screen's physical size
On 10/07/2023 09:35, Paul Cercueil wrote:
> Hi Krzysztof,
>
> Le lundi 10 juillet 2023 à 08:59 +0200, Krzysztof Kozlowski a écrit :
>> On 08/07/2023 10:40, Paul Cercueil wrote:
>>> The previous values were completely bogus, and resulted in the
>>> computed
>>> DPI ratio being much lower than reality, causing applications and
>>> UIs to
>>> misbehave.
>>>
>>> The new values were measured by myself with a ruler.
>>>
>>> Signed-off-by: Paul Cercueil
>>> Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the
>>> Galaxy S2")
>>> Cc: # v5.8+
>>> ---
>>
>> This does not apply. You rebased your work on some older
>> version/tree,
>> without new layout. Please work on linux-next.
>
> This patchset was based on drm-misc-next, because that's where I was
> planning to apply it; and it was extremely unlikely (but not
> impossible, apparently) that the i9100.dts would be modified in the
> meantime.
>
> I can rebase on linux-next, the problem then is that I then don't know
> how/where to apply the patchset.
DTS cannot go via drm-misc-next, so if that's your intention please
always split the patchset into separate ones. *Always*.
Best regards,
Krzysztof
Re: [PATCH 1/1] drm/bridge: Fix handling of bridges with pre_enable_prev_first flag
On 07.07.23 21:00, Vladimir Lypak wrote:
> [Sie erhalten nicht häufig E-Mails von vladimir.ly...@gmail.com. Weitere
> Informationen, warum dies wichtig ist, finden Sie unter
> https://aka.ms/LearnAboutSenderIdentification ]
>
> In function drm_atomic_bridge_chain_post_disable handling of
> pre_enable_prev_first flag is broken because "next" variable will always
> end up set to value of "bridge". This breaks loop which should disable
> bridges in reverse:
>
> next = list_next_entry(bridge, chain_node);
>
> if (next->pre_enable_prev_first) {
> /* next bridge had requested that prev
> * was enabled first, so disabled last
> */
> limit = next;
>
> /* Find the next bridge that has NOT requested
> * prev to be enabled first / disabled last
> */
> list_for_each_entry_from(next, &encoder->bridge_chain,
> chain_node) {
> // Next condition is always true. It is likely meant to be inversed
> // according to comment above. But doing this uncovers another problem:
> // it won't work if there are few bridges with this flag set at the end.
> if (next->pre_enable_prev_first) {
> next = list_prev_entry(next, chain_node);
> limit = next;
> // Here we always set next = limit = branch at first iteration.
> break;
> }
> }
>
> /* Call these bridges in reverse order */
> list_for_each_entry_from_reverse(next, &encoder->bridge_chain,
> chain_node) {
> // This loop never executes past this branch.
> if (next == bridge)
> break;
>
> drm_atomic_bridge_call_post_disable(next, old_state);
>
> In this patch logic for handling the flag is simplified. Temporary
> "iter" variable is introduced instead of "next" which is used only
> inside inner loops.
>
> Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
> bridge init order")
> Signed-off-by: Vladimir Lypak
I haven't had a chance to look at this, but I still want to reference
another patch by Jagan that intends to fix some bug in this area:
https://patchwork.kernel.org/project/dri-devel/patch/20230328170752.1102347-1-ja...@amarulasolutions.com/
+Cc: Jagan
Dave, as you introduced this feature, did you have a chance to look at
Jagan's and Vladimir's patches?
[PATCH 00/11] drm: kunit: Switch to kunit actions
Hi, Since v6.5-rc1, kunit gained a devm/drmm-like mechanism that makes tests resources much easier to cleanup. This series converts the existing tests to use those new actions were relevant. Let me know what you think, Maxime Signed-off-by: Maxime Ripard --- Maxime Ripard (11): drm/tests: helpers: Switch to kunit actions drm/tests: client-modeset: Remove call to drm_kunit_helper_free_device() drm/tests: modes: Remove call to drm_kunit_helper_free_device() drm/tests: probe-helper: Remove call to drm_kunit_helper_free_device() drm/tests: helpers: Create an helper to allocate a locking ctx drm/tests: helpers: Create an helper to allocate an atomic state drm/vc4: tests: pv-muxing: Remove call to drm_kunit_helper_free_device() drm/vc4: tests: mock: Use a kunit action to unregister DRM device drm/vc4: tests: pv-muxing: Switch to managed locking init drm/vc4: tests: Switch to atomic state allocation helper drm/vc4: tests: pv-muxing: Document test scenario drivers/gpu/drm/tests/drm_client_modeset_test.c | 8 -- drivers/gpu/drm/tests/drm_kunit_helpers.c | 112 ++- drivers/gpu/drm/tests/drm_modes_test.c | 8 -- drivers/gpu/drm/tests/drm_probe_helper_test.c | 8 -- drivers/gpu/drm/vc4/tests/vc4_mock.c| 5 ++ drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 115 +--- include/drm/drm_kunit_helpers.h | 7 ++ 7 files changed, 162 insertions(+), 101 deletions(-) --- base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5 change-id: 20230710-kms-kunit-actions-rework-5d163762c93b Best regards, -- Maxime Ripard
[PATCH 01/11] drm/tests: helpers: Switch to kunit actions
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 32 +++
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 4df47071dc88..38211fea9ae6 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -35,8 +35,8 @@ static struct platform_driver fake_platform_driver = {
* able to leverage the usual infrastructure and most notably the
* device-managed resources just like a "real" device.
*
- * Callers need to make sure drm_kunit_helper_free_device() on the
- * device when done.
+ * Resources will be cleaned up automatically, but the removal can be
+ * forced using @drm_kunit_helper_free_device.
*
* Returns:
* A pointer to the new device, or an ERR_PTR() otherwise.
@@ -49,12 +49,31 @@ struct device *drm_kunit_helper_alloc_device(struct kunit
*test)
ret = platform_driver_register(&fake_platform_driver);
KUNIT_ASSERT_EQ(test, ret, 0);
+ ret = kunit_add_action_or_reset(test,
+ (kunit_action_t
*)platform_driver_unregister,
+ &fake_platform_driver);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
pdev = platform_device_alloc(KUNIT_DEVICE_NAME, PLATFORM_DEVID_NONE);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
+ ret = kunit_add_action_or_reset(test,
+ (kunit_action_t *)platform_device_put,
+ pdev);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
ret = platform_device_add(pdev);
KUNIT_ASSERT_EQ(test, ret, 0);
+ kunit_remove_action(test,
+ (kunit_action_t *)platform_device_put,
+ pdev);
+
+ ret = kunit_add_action_or_reset(test,
+ (kunit_action_t
*)platform_device_unregister,
+ pdev);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
return &pdev->dev;
}
EXPORT_SYMBOL_GPL(drm_kunit_helper_alloc_device);
@@ -70,8 +89,13 @@ void drm_kunit_helper_free_device(struct kunit *test, struct
device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
- platform_device_unregister(pdev);
- platform_driver_unregister(&fake_platform_driver);
+ kunit_release_action(test,
+(kunit_action_t *)platform_device_unregister,
+pdev);
+
+ kunit_release_action(test,
+(kunit_action_t *)platform_driver_unregister,
+&fake_platform_driver);
}
EXPORT_SYMBOL_GPL(drm_kunit_helper_free_device);
--
2.41.0
[PATCH 02/11] drm/tests: client-modeset: Remove call to drm_kunit_helper_free_device()
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 416a279b6dae..7516f6cb36e4 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -82,13 +82,6 @@ static int drm_client_modeset_test_init(struct kunit *test)
return 0;
}
-static void drm_client_modeset_test_exit(struct kunit *test)
-{
- struct drm_client_modeset_test_priv *priv = test->priv;
-
- drm_kunit_helper_free_device(test, priv->dev);
-}
-
static void drm_test_pick_cmdline_res_1920_1080_60(struct kunit *test)
{
struct drm_client_modeset_test_priv *priv = test->priv;
@@ -188,7 +181,6 @@ static struct kunit_case drm_test_pick_cmdline_tests[] = {
static struct kunit_suite drm_test_pick_cmdline_test_suite = {
.name = "drm_test_pick_cmdline",
.init = drm_client_modeset_test_init,
- .exit = drm_client_modeset_test_exit,
.test_cases = drm_test_pick_cmdline_tests
};
--
2.41.0
[PATCH 03/11] drm/tests: modes: Remove call to drm_kunit_helper_free_device()
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_modes_test.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_modes_test.c
b/drivers/gpu/drm/tests/drm_modes_test.c
index bc4aa2ce78be..1e9f63fbfead 100644
--- a/drivers/gpu/drm/tests/drm_modes_test.c
+++ b/drivers/gpu/drm/tests/drm_modes_test.c
@@ -36,13 +36,6 @@ static int drm_test_modes_init(struct kunit *test)
return 0;
}
-static void drm_test_modes_exit(struct kunit *test)
-{
- struct drm_test_modes_priv *priv = test->priv;
-
- drm_kunit_helper_free_device(test, priv->dev);
-}
-
static void drm_test_modes_analog_tv_ntsc_480i(struct kunit *test)
{
struct drm_test_modes_priv *priv = test->priv;
@@ -148,7 +141,6 @@ static struct kunit_case drm_modes_analog_tv_tests[] = {
static struct kunit_suite drm_modes_analog_tv_test_suite = {
.name = "drm_modes_analog_tv",
.init = drm_test_modes_init,
- .exit = drm_test_modes_exit,
.test_cases = drm_modes_analog_tv_tests,
};
--
2.41.0
[PATCH 04/11] drm/tests: probe-helper: Remove call to drm_kunit_helper_free_device()
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_probe_helper_test.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_probe_helper_test.c
b/drivers/gpu/drm/tests/drm_probe_helper_test.c
index 0ee65828623e..1a2044070a6c 100644
--- a/drivers/gpu/drm/tests/drm_probe_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_probe_helper_test.c
@@ -60,13 +60,6 @@ static int drm_probe_helper_test_init(struct kunit *test)
return 0;
}
-static void drm_probe_helper_test_exit(struct kunit *test)
-{
- struct drm_probe_helper_test_priv *priv = test->priv;
-
- drm_kunit_helper_free_device(test, priv->dev);
-}
-
typedef struct drm_display_mode *(*expected_mode_func_t)(struct drm_device *);
struct drm_connector_helper_tv_get_modes_test {
@@ -208,7 +201,6 @@ static struct kunit_case
drm_test_connector_helper_tv_get_modes_tests[] = {
static struct kunit_suite drm_test_connector_helper_tv_get_modes_suite = {
.name = "drm_connector_helper_tv_get_modes",
.init = drm_probe_helper_test_init,
- .exit = drm_probe_helper_test_exit,
.test_cases = drm_test_connector_helper_tv_get_modes_tests,
};
--
2.41.0
[PATCH 05/11] drm/tests: helpers: Create an helper to allocate a locking ctx
As we get more and more tests, the locking context initialisation
creates more and more boilerplate, both at creation and destruction.
Let's create a helper that will allocate, initialise a context, and
register kunit actions to clean up once the test is done.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 41 +++
include/drm/drm_kunit_helpers.h | 2 ++
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 38211fea9ae6..40a27c78d692 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -124,5 +124,46 @@ __drm_kunit_helper_alloc_drm_device_with_driver(struct
kunit *test,
}
EXPORT_SYMBOL_GPL(__drm_kunit_helper_alloc_drm_device_with_driver);
+static void action_drm_release_context(void *ptr)
+{
+ struct drm_modeset_acquire_ctx *ctx = ptr;
+
+ drm_modeset_drop_locks(ctx);
+ drm_modeset_acquire_fini(ctx);
+}
+
+/**
+ * drm_kunit_helper_context_alloc - Allocates an acquire context
+ * @test: The test context object
+ *
+ * Allocates and initializes a modeset acquire context.
+ *
+ * The context is tied to the kunit test context, so we must not call
+ * drm_modeset_acquire_fini() on it, it will be done so automatically.
+ *
+ * Returns:
+ * An ERR_PTR on error, a pointer to the newly allocated context otherwise
+ */
+struct drm_modeset_acquire_ctx *
+drm_kunit_helper_acquire_ctx_alloc(struct kunit *test)
+{
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
+
+ ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, ctx);
+
+ drm_modeset_acquire_init(ctx, 0);
+
+ ret = kunit_add_action_or_reset(test,
+ action_drm_release_context,
+ ctx);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return ctx;
+}
+EXPORT_SYMBOL_GPL(drm_kunit_helper_acquire_ctx_alloc);
+
MODULE_AUTHOR("Maxime Ripard ");
MODULE_LICENSE("GPL");
diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index ed013fdcc1ff..4ba5e10653c6 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/include/drm/drm_kunit_helpers.h
@@ -87,5 +87,7 @@ __drm_kunit_helper_alloc_drm_device(struct kunit *test,
sizeof(_type),
\
offsetof(_type, _member),
\
_feat))
+struct drm_modeset_acquire_ctx *
+drm_kunit_helper_acquire_ctx_alloc(struct kunit *test);
#endif // DRM_KUNIT_HELPERS_H_
--
2.41.0
[PATCH 06/11] drm/tests: helpers: Create an helper to allocate an atomic state
As we gain more tests, boilerplate to allocate an atomic state and free
it starts to be there more and more as well.
In order to reduce the allocation boilerplate, we can create an helper
to create that atomic state, and call an action when the test is done.
This will also clean up the exit path.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 39 +++
include/drm/drm_kunit_helpers.h | 5
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 40a27c78d692..3f3331bc389f 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
+#include
#include
#include
#include
@@ -165,5 +166,43 @@ drm_kunit_helper_acquire_ctx_alloc(struct kunit *test)
}
EXPORT_SYMBOL_GPL(drm_kunit_helper_acquire_ctx_alloc);
+/**
+ * drm_kunit_helper_atomic_state_alloc - Allocates an atomic state
+ * @test: The test context object
+ * @drm: The device to alloc the state for
+ * @ctx: Locking context for that atomic update
+ *
+ * Allocates a empty atomic state.
+ *
+ * The state is tied to the kunit test context, so we must not call
+ * drm_atomic_state_put() on it, it will be done so automatically.
+ *
+ * Returns:
+ * An ERR_PTR on error, a pointer to the newly allocated state otherwise
+ */
+struct drm_atomic_state *
+drm_kunit_helper_atomic_state_alloc(struct kunit *test,
+ struct drm_device *drm,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ struct drm_atomic_state *state;
+ int ret;
+
+ state = drm_atomic_state_alloc(drm);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ ret = kunit_add_action_or_reset(test,
+ (kunit_action_t *)drm_atomic_state_put,
+ state);
+ if (ret)
+ return ERR_PTR(ret);
+
+ state->acquire_ctx = ctx;
+
+ return state;
+}
+EXPORT_SYMBOL_GPL(drm_kunit_helper_atomic_state_alloc);
+
MODULE_AUTHOR("Maxime Ripard ");
MODULE_LICENSE("GPL");
diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index 4ba5e10653c6..514c8a7a32f0 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/include/drm/drm_kunit_helpers.h
@@ -90,4 +90,9 @@ __drm_kunit_helper_alloc_drm_device(struct kunit *test,
struct drm_modeset_acquire_ctx *
drm_kunit_helper_acquire_ctx_alloc(struct kunit *test);
+struct drm_atomic_state *
+drm_kunit_helper_atomic_state_alloc(struct kunit *test,
+ struct drm_device *drm,
+ struct drm_modeset_acquire_ctx *ctx);
+
#endif // DRM_KUNIT_HELPERS_H_
--
2.41.0
[PATCH 07/11] drm/vc4: tests: pv-muxing: Remove call to drm_kunit_helper_free_device()
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
index ae0bd0f81698..6c982e72cae8 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
@@ -762,7 +762,6 @@ static void vc4_pv_muxing_test_exit(struct kunit *test)
drm_modeset_drop_locks(&priv->ctx);
drm_modeset_acquire_fini(&priv->ctx);
drm_dev_unregister(drm);
- drm_kunit_helper_free_device(test, vc4->dev);
}
static struct kunit_case vc4_pv_muxing_tests[] = {
@@ -873,7 +872,6 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
drm_dev_unregister(drm);
- drm_kunit_helper_free_device(test, vc4->dev);
}
static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct kunit *test)
@@ -963,7 +961,6 @@ static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct
kunit *test)
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
drm_dev_unregister(drm);
- drm_kunit_helper_free_device(test, vc4->dev);
}
static void
@@ -1017,7 +1014,6 @@
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable_too_many_crtc_state(struct ku
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
drm_dev_unregister(drm);
- drm_kunit_helper_free_device(test, vc4->dev);
}
static struct kunit_case vc5_pv_muxing_bugs_tests[] = {
--
2.41.0
[PATCH 08/11] drm/vc4: tests: mock: Use a kunit action to unregister DRM device
The *_mock_device functions allocate a DRM device that needs to be
released using drm_dev_unregister.
Now that we have a kunit release action API, we can switch to it and
don't require any kind of garbage collection from the caller.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock.c | 5 +
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 6 --
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock.c
b/drivers/gpu/drm/vc4/tests/vc4_mock.c
index a4bed26af32f..00825ddc52f0 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_mock.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock.c
@@ -186,6 +186,11 @@ static struct vc4_dev *__mock_device(struct kunit *test,
bool is_vc5)
ret = drm_dev_register(drm, 0);
KUNIT_ASSERT_EQ(test, ret, 0);
+ ret = kunit_add_action_or_reset(test,
+ (kunit_action_t *)drm_dev_unregister,
+ drm);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
return vc4;
}
diff --git a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
index 6c982e72cae8..776a7b01608f 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
@@ -754,14 +754,11 @@ static int vc4_pv_muxing_test_init(struct kunit *test)
static void vc4_pv_muxing_test_exit(struct kunit *test)
{
struct pv_muxing_priv *priv = test->priv;
- struct vc4_dev *vc4 = priv->vc4;
- struct drm_device *drm = &vc4->base;
struct drm_atomic_state *state = priv->state;
drm_atomic_state_put(state);
drm_modeset_drop_locks(&priv->ctx);
drm_modeset_acquire_fini(&priv->ctx);
- drm_dev_unregister(drm);
}
static struct kunit_case vc4_pv_muxing_tests[] = {
@@ -871,7 +868,6 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
drm_atomic_state_put(state);
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
- drm_dev_unregister(drm);
}
static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct kunit *test)
@@ -960,7 +956,6 @@ static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct
kunit *test)
drm_atomic_state_put(state);
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
- drm_dev_unregister(drm);
}
static void
@@ -1013,7 +1008,6 @@
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable_too_many_crtc_state(struct ku
drm_atomic_state_put(state);
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
- drm_dev_unregister(drm);
}
static struct kunit_case vc5_pv_muxing_bugs_tests[] = {
--
2.41.0
[PATCH 10/11] drm/vc4: tests: Switch to atomic state allocation helper
Now that we have a helper that takes care of an atomic state allocation
and cleanup, we can migrate to it to simplify our tests.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 55 --
1 file changed, 8 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
index ff1deaed0cab..5f9f5626329d 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
@@ -725,7 +725,6 @@ static int vc4_pv_muxing_test_init(struct kunit *test)
{
const struct pv_muxing_param *params = test->param_value;
struct drm_modeset_acquire_ctx *ctx;
- struct drm_atomic_state *state;
struct pv_muxing_priv *priv;
struct drm_device *drm;
struct vc4_dev *vc4;
@@ -742,24 +741,12 @@ static int vc4_pv_muxing_test_init(struct kunit *test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
drm = &vc4->base;
- state = drm_atomic_state_alloc(drm);
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
-
- state->acquire_ctx = ctx;
-
- priv->state = state;
+ priv->state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->state);
return 0;
}
-static void vc4_pv_muxing_test_exit(struct kunit *test)
-{
- struct pv_muxing_priv *priv = test->priv;
- struct drm_atomic_state *state = priv->state;
-
- drm_atomic_state_put(state);
-}
-
static struct kunit_case vc4_pv_muxing_tests[] = {
KUNIT_CASE_PARAM(drm_vc4_test_pv_muxing,
vc4_test_pv_muxing_gen_params),
@@ -771,7 +758,6 @@ static struct kunit_case vc4_pv_muxing_tests[] = {
static struct kunit_suite vc4_pv_muxing_test_suite = {
.name = "vc4-pv-muxing-combinations",
.init = vc4_pv_muxing_test_init,
- .exit = vc4_pv_muxing_test_exit,
.test_cases = vc4_pv_muxing_tests,
};
@@ -786,7 +772,6 @@ static struct kunit_case vc5_pv_muxing_tests[] = {
static struct kunit_suite vc5_pv_muxing_test_suite = {
.name = "vc5-pv-muxing-combinations",
.init = vc4_pv_muxing_test_init,
- .exit = vc4_pv_muxing_test_exit,
.test_cases = vc5_pv_muxing_tests,
};
@@ -814,11 +799,9 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
drm = &vc4->base;
- state = drm_atomic_state_alloc(drm);
+ state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = ctx;
-
ret = vc4_mock_atomic_add_output(test, state, VC4_ENCODER_TYPE_HDMI0);
KUNIT_ASSERT_EQ(test, ret, 0);
@@ -839,13 +822,9 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
ret = drm_atomic_helper_swap_state(state, false);
KUNIT_ASSERT_EQ(test, ret, 0);
- drm_atomic_state_put(state);
-
- state = drm_atomic_state_alloc(drm);
+ state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = ctx;
-
ret = vc4_mock_atomic_add_output(test, state, VC4_ENCODER_TYPE_HDMI1);
KUNIT_ASSERT_EQ(test, ret, 0);
@@ -864,8 +843,6 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
KUNIT_ASSERT_TRUE(test,
new_hvs_state->fifo_state[hdmi1_channel].in_use);
KUNIT_EXPECT_NE(test, hdmi0_channel, hdmi1_channel);
-
- drm_atomic_state_put(state);
}
static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct kunit *test)
@@ -887,11 +864,9 @@ static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct
kunit *test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
drm = &vc4->base;
- state = drm_atomic_state_alloc(drm);
+ state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = ctx;
-
ret = vc4_mock_atomic_add_output(test, state, VC4_ENCODER_TYPE_HDMI0);
KUNIT_ASSERT_EQ(test, ret, 0);
@@ -923,13 +898,9 @@ static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct
kunit *test)
ret = drm_atomic_helper_swap_state(state, false);
KUNIT_ASSERT_EQ(test, ret, 0);
- drm_atomic_state_put(state);
-
- state = drm_atomic_state_alloc(drm);
+ state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = ctx;
-
ret = vc4_mock_atomic_del_output(test, state, VC4_ENCODER_TYPE_HDMI0);
KUNIT_ASSERT_EQ(test, ret, 0);
@@ -951,8 +922,6 @@ static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct
kunit *test)
KUNIT_EXPECT_EQ(test, old_hdmi1_channel, hdmi1_channel);
}
-
- drm_
[PATCH 09/11] drm/vc4: tests: pv-muxing: Switch to managed locking init
The new helper to init the locking context allows to remove some
boilerplate.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 42 --
1 file changed, 19 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
index 776a7b01608f..ff1deaed0cab 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
@@ -20,7 +20,6 @@
struct pv_muxing_priv {
struct vc4_dev *vc4;
- struct drm_modeset_acquire_ctx ctx;
struct drm_atomic_state *state;
};
@@ -725,6 +724,7 @@ static void drm_vc4_test_pv_muxing_invalid(struct kunit
*test)
static int vc4_pv_muxing_test_init(struct kunit *test)
{
const struct pv_muxing_param *params = test->param_value;
+ struct drm_modeset_acquire_ctx *ctx;
struct drm_atomic_state *state;
struct pv_muxing_priv *priv;
struct drm_device *drm;
@@ -738,13 +738,14 @@ static int vc4_pv_muxing_test_init(struct kunit *test)
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, vc4);
priv->vc4 = vc4;
- drm_modeset_acquire_init(&priv->ctx, 0);
+ ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
drm = &vc4->base;
state = drm_atomic_state_alloc(drm);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = &priv->ctx;
+ state->acquire_ctx = ctx;
priv->state = state;
@@ -757,8 +758,6 @@ static void vc4_pv_muxing_test_exit(struct kunit *test)
struct drm_atomic_state *state = priv->state;
drm_atomic_state_put(state);
- drm_modeset_drop_locks(&priv->ctx);
- drm_modeset_acquire_fini(&priv->ctx);
}
static struct kunit_case vc4_pv_muxing_tests[] = {
@@ -798,7 +797,7 @@ static struct kunit_suite vc5_pv_muxing_test_suite = {
*/
static void drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit
*test)
{
- struct drm_modeset_acquire_ctx ctx;
+ struct drm_modeset_acquire_ctx *ctx;
struct drm_atomic_state *state;
struct vc4_crtc_state *new_vc4_crtc_state;
struct vc4_hvs_state *new_hvs_state;
@@ -811,13 +810,14 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
vc4 = vc5_mock_device(test);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, vc4);
- drm_modeset_acquire_init(&ctx, 0);
+ ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
drm = &vc4->base;
state = drm_atomic_state_alloc(drm);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = &ctx;
+ state->acquire_ctx = ctx;
ret = vc4_mock_atomic_add_output(test, state, VC4_ENCODER_TYPE_HDMI0);
KUNIT_ASSERT_EQ(test, ret, 0);
@@ -844,7 +844,7 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
state = drm_atomic_state_alloc(drm);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = &ctx;
+ state->acquire_ctx = ctx;
ret = vc4_mock_atomic_add_output(test, state, VC4_ENCODER_TYPE_HDMI1);
KUNIT_ASSERT_EQ(test, ret, 0);
@@ -866,13 +866,11 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
KUNIT_EXPECT_NE(test, hdmi0_channel, hdmi1_channel);
drm_atomic_state_put(state);
- drm_modeset_drop_locks(&ctx);
- drm_modeset_acquire_fini(&ctx);
}
static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct kunit *test)
{
- struct drm_modeset_acquire_ctx ctx;
+ struct drm_modeset_acquire_ctx *ctx;
struct drm_atomic_state *state;
struct vc4_crtc_state *new_vc4_crtc_state;
struct vc4_hvs_state *new_hvs_state;
@@ -885,13 +883,14 @@ static void
drm_test_vc5_pv_muxing_bugs_stable_fifo(struct kunit *test)
vc4 = vc5_mock_device(test);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, vc4);
- drm_modeset_acquire_init(&ctx, 0);
+ ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
drm = &vc4->base;
state = drm_atomic_state_alloc(drm);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = &ctx;
+ state->acquire_ctx = ctx;
ret = vc4_mock_atomic_add_output(test, state, VC4_ENCODER_TYPE_HDMI0);
KUNIT_ASSERT_EQ(test, ret, 0);
@@ -929,7 +928,7 @@ static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct
kunit *test)
state = drm_atomic_state_alloc(drm);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
- state->acquire_ctx = &ctx;
+ state->acquire_ctx = ctx;
ret = vc4_mock_atomic_del_output(test, state, VC4_ENCODER_TYPE_HDMI0);
KUNIT_ASSERT_EQ(test, ret, 0);
@@ -954,14 +953,12 @@ static void
drm_test_vc5_pv_muxing_bugs_
[PATCH 11/11] drm/vc4: tests: pv-muxing: Document test scenario
We've had a couple of tests that weren't really obvious, nor did they
document what they were supposed to test. Document that to make it
hopefully more obvious.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
index 5f9f5626329d..61622e951031 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
@@ -845,6 +845,13 @@ static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable(struct kunit *tes
KUNIT_EXPECT_NE(test, hdmi0_channel, hdmi1_channel);
}
+/*
+ * This test makes sure that we never change the FIFO of an active HVS
+ * channel if we disable a FIFO with a lower index.
+ *
+ * Doing so would result in a FIFO stall and would disrupt an output
+ * supposed to be unaffected by the commit.
+ */
static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct kunit *test)
{
struct drm_modeset_acquire_ctx *ctx;
@@ -924,6 +931,21 @@ static void drm_test_vc5_pv_muxing_bugs_stable_fifo(struct
kunit *test)
}
}
+/*
+ * Test that if we affect a single output, only the CRTC state of that
+ * output will be pulled in the global atomic state.
+ *
+ * This is relevant for two things:
+ *
+ * - If we don't have that state at all, we are unlikely to affect the
+ * FIFO muxing. This is somewhat redundant with
+ * drm_test_vc5_pv_muxing_bugs_stable_fifo()
+ *
+ * - KMS waits for page flips to occur on all the CRTC found in the
+ * CRTC state. Since the CRTC is unaffected, we would over-wait, but
+ * most importantly run into corner cases like waiting on an
+ * inactive CRTC that never completes.
+ */
static void
drm_test_vc5_pv_muxing_bugs_subsequent_crtc_enable_too_many_crtc_state(struct
kunit *test)
{
--
2.41.0
[PATCH] drm/radeon: ERROR: "(foo*)" should be "(foo *)"
Fix four occurrences of the checkpatch.pl error: ERROR: "(foo*)" should be "(foo *)" Signed-off-by: Ran Sun --- drivers/gpu/drm/radeon/radeon_test.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_test.c b/drivers/gpu/drm/radeon/radeon_test.c index a5e1d2139e80..c9fef9b61ced 100644 --- a/drivers/gpu/drm/radeon/radeon_test.c +++ b/drivers/gpu/drm/radeon/radeon_test.c @@ -156,10 +156,10 @@ static void radeon_do_test_moves(struct radeon_device *rdev, int flag) i, *vram_start, gtt_start, (unsigned long long) (gtt_addr - rdev->mc.gtt_start + - (void*)gtt_start - gtt_map), + (void *)gtt_start - gtt_map), (unsigned long long) (vram_addr - rdev->mc.vram_start + - (void*)gtt_start - gtt_map)); + (void *)gtt_start - gtt_map)); radeon_bo_kunmap(vram_obj); goto out_lclean_unpin; } @@ -207,10 +207,10 @@ static void radeon_do_test_moves(struct radeon_device *rdev, int flag) i, *gtt_start, vram_start, (unsigned long long) (vram_addr - rdev->mc.vram_start + - (void*)vram_start - vram_map), + (void *)vram_start - vram_map), (unsigned long long) (gtt_addr - rdev->mc.gtt_start + - (void*)vram_start - vram_map)); + (void *)vram_start - vram_map)); radeon_bo_kunmap(gtt_obj[i]); goto out_lclean_unpin; }
Re: [PATCH v2 3/3] ARM: dts: exynos/i9100: Fix LCD screen's physical size
Le lundi 10 juillet 2023 à 09:45 +0200, Krzysztof Kozlowski a écrit :
> On 10/07/2023 09:35, Paul Cercueil wrote:
> > Hi Krzysztof,
> >
> > Le lundi 10 juillet 2023 à 08:59 +0200, Krzysztof Kozlowski a
> > écrit :
> > > On 08/07/2023 10:40, Paul Cercueil wrote:
> > > > The previous values were completely bogus, and resulted in the
> > > > computed
> > > > DPI ratio being much lower than reality, causing applications
> > > > and
> > > > UIs to
> > > > misbehave.
> > > >
> > > > The new values were measured by myself with a ruler.
> > > >
> > > > Signed-off-by: Paul Cercueil
> > > > Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for
> > > > the
> > > > Galaxy S2")
> > > > Cc: # v5.8+
> > > > ---
> > >
> > > This does not apply. You rebased your work on some older
> > > version/tree,
> > > without new layout. Please work on linux-next.
> >
> > This patchset was based on drm-misc-next, because that's where I
> > was
> > planning to apply it; and it was extremely unlikely (but not
> > impossible, apparently) that the i9100.dts would be modified in the
> > meantime.
> >
> > I can rebase on linux-next, the problem then is that I then don't
> > know
> > how/where to apply the patchset.
>
> DTS cannot go via drm-misc-next, so if that's your intention please
> always split the patchset into separate ones. *Always*.
Noted.
Then I'll apply the patches [1/3] and [2/3] to drm-misc-next since I
have my ACKs, and re-send patch [3/3] as standalone and rebased on
linux-next.
Cheers,
-Paul
[PATCH] fbdev/hyperv_fb: Include
Include to get the global screen_info state.
Fixes the following errors:
>> drivers/video/fbdev/hyperv_fb.c:1033:10: error: use of undeclared identifier
>> 'screen_info'
1033 | base = screen_info.lfb_base;
|^
drivers/video/fbdev/hyperv_fb.c:1034:10: error: use of undeclared identifier
'screen_info'
1034 | size = screen_info.lfb_size;
|^
>> drivers/video/fbdev/hyperv_fb.c:1080:3: error: must use 'struct' tag to
>> refer to type 'screen_info'
1080 | screen_info.lfb_size = 0;
| ^
| struct
>> drivers/video/fbdev/hyperv_fb.c:1080:14: error: expected identifier or '('
1080 | screen_info.lfb_size = 0;
|^
drivers/video/fbdev/hyperv_fb.c:1081:3: error: must use 'struct' tag to
refer to type 'screen_info'
1081 | screen_info.lfb_base = 0;
| ^
| struct
drivers/video/fbdev/hyperv_fb.c:1081:14: error: expected identifier or '('
1081 | screen_info.lfb_base = 0;
|^
drivers/video/fbdev/hyperv_fb.c:1082:3: error: must use 'struct' tag to
refer to type 'screen_info'
1082 | screen_info.orig_video_isVGA = 0;
| ^
| struct
drivers/video/fbdev/hyperv_fb.c:1082:14: error: expected identifier or '('
1082 | screen_info.orig_video_isVGA = 0;
|^
8 errors generated.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202307101042.rqehuauj-...@intel.com/
Fixes: 8b0d13545b09 ("efi: Do not include from EFI
header")
Signed-off-by: Thomas Zimmermann
Cc: "K. Y. Srinivasan" (supporter:Hyper-V/Azure CORE AND
DRIVERS)
Cc: Haiyang Zhang (supporter:Hyper-V/Azure CORE AND
DRIVERS)
Cc: Wei Liu (supporter:Hyper-V/Azure CORE AND DRIVERS)
Cc: Dexuan Cui (supporter:Hyper-V/Azure CORE AND DRIVERS)
Cc: Helge Deller (maintainer:FRAMEBUFFER LAYER)
Cc: Javier Martinez Canillas
Cc: Sui Jingfeng
Cc: Ard Biesheuvel
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Arnd Bergmann
Cc: linux-...@vger.kernel.org
Cc: linux-hyp...@vger.kernel.org (open list:Hyper-V/Azure CORE AND DRIVERS)
Cc: linux-fb...@vger.kernel.org (open list:FRAMEBUFFER LAYER)
Cc: dri-devel@lists.freedesktop.org (open list:FRAMEBUFFER LAYER)
---
drivers/video/fbdev/hyperv_fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 1ae35ab62b29..b331452aab4f 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.41.0
RE: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 2023年7月10日 15:44
> To: Sandor Yu ; andrzej.ha...@intel.com;
> neil.armstr...@linaro.org; robert.f...@linaro.org;
> laurent.pinch...@ideasonboard.com; jo...@kwiboo.se;
> jernej.skra...@gmail.com; airl...@gmail.com; dan...@ffwll.ch;
> robh...@kernel.org; krzysztof.kozlowski...@linaro.org;
> shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> vk...@kernel.org; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; linux-...@lists.infradead.org
> Cc: ker...@pengutronix.de; dl-linux-imx ; Oliver Brown
>
> Subject: Re: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
>
>
> On 10/07/2023 10:28, Sandor Yu wrote:
> > Hi Dmitry,
> >
> > Thanks for your comments,
> >
> >> From: Dmitry Baryshkov On 15/06/2023
> >> 04:38, Sandor Yu wrote:
> >>> Allow HDMI PHYs to be configured through the generic functions
> >>> through a custom structure added to the generic union.
> >>>
> >>> The parameters added here are based on HDMI PHY implementation
> >>> practices. The current set of parameters should cover the potential
> >>> users.
> >>>
> >>> Signed-off-by: Sandor Yu
> >>> ---
> >>>include/linux/phy/phy-hdmi.h | 38
> >>
> >>>include/linux/phy/phy.h | 7 ++-
> >>>2 files changed, 44 insertions(+), 1 deletion(-)
> >>>create mode 100644 include/linux/phy/phy-hdmi.h
> >>>
> >>> diff --git a/include/linux/phy/phy-hdmi.h
> >>> b/include/linux/phy/phy-hdmi.h new file mode 100644 index
> >>> ..5765aa5bc175
> >>> --- /dev/null
> >>> +++ b/include/linux/phy/phy-hdmi.h
> >>> @@ -0,0 +1,38 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>> +/*
> >>> + * Copyright 2022 NXP
> >>> + */
> >>> +
> >>> +#ifndef __PHY_HDMI_H_
> >>> +#define __PHY_HDMI_H_
> >>> +
> >>> +/**
> >>> + * Pixel Encoding as HDMI Specification
> >>> + * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
> >>> + * YUV420: HDMI Specification 2.a Section 7.1 */ enum
> >>> +hdmi_phy_colorspace {
> >>> + HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
> >>> + HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
> >>> + HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
> >>> + HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
> >>> + HDMI_PHY_COLORSPACE_RESERVED4,
> >>> + HDMI_PHY_COLORSPACE_RESERVED5,
> >>> + HDMI_PHY_COLORSPACE_RESERVED6, };
> >>
> >> This enum duplicates enum hdmi_colorspace from HDMI
> >> 2.0 defines '7' to be IDO-defined.
> >>
> >> Would it be better to use that enum instead?
> > Accept. I will create head file hdmi_colorspace.h to reuse enum
> hdmi_colorspace in .
>
> Excuse me, it was supposed to be a question.
>
> Do you need another header file to reuse this enum?
I'm not sure community whether would accept the patch that simply include
in phy-hdmi.h
because there are lots of other definition in that not need by
phy-hdmi.h.
If the answer is yes, I happy to follow.
>
> >
> > B.R
> > Sandor
> >>
> >>> +
> >>> +/**
> >>> + * struct phy_configure_opts_hdmi - HDMI configuration set
> >>> + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> >>> + * @bpc: Maximum bits per color channel.
> >>> + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> >>> + *
> >>> + * This structure is used to represent the configuration state of a HDMI
> phy.
> >>> + */
> >>> +struct phy_configure_opts_hdmi {
> >>> + unsigned int pixel_clk_rate;
> >>> + unsigned int bpc;
> >>> + enum hdmi_phy_colorspace color_space; };
> >>> +
> >>> +#endif /* __PHY_HDMI_H_ */
> >>
> >> [skipped the rest]
> >>
> >> --
> >> With best wishes
> >> Dmitry
> >
>
> --
> With best wishes
> Dmitry
B.R
Sandor
Re: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
On Mon, 10 Jul 2023 at 11:01, Sandor Yu wrote:
>
>
>
> > -Original Message-
> > From: Dmitry Baryshkov
> > Sent: 2023年7月10日 15:44
> > To: Sandor Yu ; andrzej.ha...@intel.com;
> > neil.armstr...@linaro.org; robert.f...@linaro.org;
> > laurent.pinch...@ideasonboard.com; jo...@kwiboo.se;
> > jernej.skra...@gmail.com; airl...@gmail.com; dan...@ffwll.ch;
> > robh...@kernel.org; krzysztof.kozlowski...@linaro.org;
> > shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> > vk...@kernel.org; dri-devel@lists.freedesktop.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux-ker...@vger.kernel.org; linux-...@lists.infradead.org
> > Cc: ker...@pengutronix.de; dl-linux-imx ; Oliver Brown
> >
> > Subject: Re: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
> >
> >
> > On 10/07/2023 10:28, Sandor Yu wrote:
> > > Hi Dmitry,
> > >
> > > Thanks for your comments,
> > >
> > >> From: Dmitry Baryshkov On 15/06/2023
> > >> 04:38, Sandor Yu wrote:
> > >>> Allow HDMI PHYs to be configured through the generic functions
> > >>> through a custom structure added to the generic union.
> > >>>
> > >>> The parameters added here are based on HDMI PHY implementation
> > >>> practices. The current set of parameters should cover the potential
> > >>> users.
> > >>>
> > >>> Signed-off-by: Sandor Yu
> > >>> ---
> > >>>include/linux/phy/phy-hdmi.h | 38
> > >>
> > >>>include/linux/phy/phy.h | 7 ++-
> > >>>2 files changed, 44 insertions(+), 1 deletion(-)
> > >>>create mode 100644 include/linux/phy/phy-hdmi.h
> > >>>
> > >>> diff --git a/include/linux/phy/phy-hdmi.h
> > >>> b/include/linux/phy/phy-hdmi.h new file mode 100644 index
> > >>> ..5765aa5bc175
> > >>> --- /dev/null
> > >>> +++ b/include/linux/phy/phy-hdmi.h
> > >>> @@ -0,0 +1,38 @@
> > >>> +/* SPDX-License-Identifier: GPL-2.0 */
> > >>> +/*
> > >>> + * Copyright 2022 NXP
> > >>> + */
> > >>> +
> > >>> +#ifndef __PHY_HDMI_H_
> > >>> +#define __PHY_HDMI_H_
> > >>> +
> > >>> +/**
> > >>> + * Pixel Encoding as HDMI Specification
> > >>> + * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
> > >>> + * YUV420: HDMI Specification 2.a Section 7.1 */ enum
> > >>> +hdmi_phy_colorspace {
> > >>> + HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
> > >>> + HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
> > >>> + HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
> > >>> + HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
> > >>> + HDMI_PHY_COLORSPACE_RESERVED4,
> > >>> + HDMI_PHY_COLORSPACE_RESERVED5,
> > >>> + HDMI_PHY_COLORSPACE_RESERVED6, };
> > >>
> > >> This enum duplicates enum hdmi_colorspace from HDMI
> > >> 2.0 defines '7' to be IDO-defined.
> > >>
> > >> Would it be better to use that enum instead?
> > > Accept. I will create head file hdmi_colorspace.h to reuse enum
> > hdmi_colorspace in .
> >
> > Excuse me, it was supposed to be a question.
> >
> > Do you need another header file to reuse this enum?
> I'm not sure community whether would accept the patch that simply include
> in phy-hdmi.h
> because there are lots of other definition in that not need by
> phy-hdmi.h.
> If the answer is yes, I happy to follow.
In my opinion it's a better alternative to creating yet another header.
>
> >
> > >
> > > B.R
> > > Sandor
> > >>
> > >>> +
> > >>> +/**
> > >>> + * struct phy_configure_opts_hdmi - HDMI configuration set
> > >>> + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> > >>> + * @bpc: Maximum bits per color channel.
> > >>> + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> > >>> + *
> > >>> + * This structure is used to represent the configuration state of a
> > >>> HDMI
> > phy.
> > >>> + */
> > >>> +struct phy_configure_opts_hdmi {
> > >>> + unsigned int pixel_clk_rate;
> > >>> + unsigned int bpc;
> > >>> + enum hdmi_phy_colorspace color_space; };
> > >>> +
> > >>> +#endif /* __PHY_HDMI_H_ */
> > >>
> > >> [skipped the rest]
> > >>
> > >> --
> > >> With best wishes
> > >> Dmitry
> > >
> >
> > --
> > With best wishes
> > Dmitry
>
> B.R
> Sandor
>
--
With best wishes
Dmitry
Re: [PATCH v2 1/2] drm/mediatek: Fix iommu fault by swapping FBs after updating plane state
Il 09/07/23 18:26, Jason-JH.Lin ha scritto:
According to the comment in drm_atomic_helper_async_commit(),
we should make sure FBs have been swapped, so that cleanups in the
new_state performs a cleanup in the old FB.
So we should move swapping FBs after calling mtk_plane_update_new_state(),
to avoid using the old FB which could be freed.
Fixes: 1a64a7aff8da ("drm/mediatek: Fix cursor plane no update")
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v2 2/2] drm/mediatek: Fix iommu fault during crtc enabling
Il 09/07/23 18:26, Jason-JH.Lin ha scritto: OVL layer should not be enabled before crtc is enabled. The plane_state of drm_atomic_state is not sync to the plane_state stored in mtk_crtc during crtc enabling, so just set all planes to disabled. Please add the relevant Fixes tag and resend. Thanks, Angelo Signed-off-by: Jason-JH.Lin > --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c index d40142842f85..51d10e65004e 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c @@ -410,6 +410,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc) unsigned int local_layer; plane_state = to_mtk_plane_state(plane->state); + + /* should not enable layer before crtc enabled */ + plane_state->pending.enable = false; comp = mtk_drm_ddp_comp_for_plane(crtc, plane, &local_layer); if (comp) mtk_ddp_comp_layer_config(comp, local_layer,
Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP
On 07/07/2023 09:30, Thomas Zimmermann wrote: Hi Am 06.07.23 um 18:37 schrieb Jocelyn Falempe: [...] You could out-comment the VGA code in the ast driver for testing. Oh, Thanks for the idea, I will try that. The result is that I get a black screen on the remote BMC. So maybe adding a remote/bmc connector will solve that. Could work. That would be a connector and encoder of type 'virtual'? Not all ast devices have a BMC. Do you know how to detect its presence? Hum, I though all ast devices have a BMC, and I don't see a way to detect that BMC is active or present. (It would be even better to know the browser's size, and automatically resize, like when using a VM. But I'm not sure the hardware/firmware is able to do this). On the other hand, are there any drawback to present a BMC connector even when the hardware doesn't have it ? Best regards Thomas Best regards, -- Jocelyn
RE: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration options
>
>
> On Mon, 10 Jul 2023 at 11:01, Sandor Yu wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Dmitry Baryshkov
> > > Sent: 2023年7月10日 15:44
> > > To: Sandor Yu ; andrzej.ha...@intel.com;
> > > neil.armstr...@linaro.org; robert.f...@linaro.org;
> > > laurent.pinch...@ideasonboard.com; jo...@kwiboo.se;
> > > jernej.skra...@gmail.com; airl...@gmail.com; dan...@ffwll.ch;
> > > robh...@kernel.org; krzysztof.kozlowski...@linaro.org;
> > > shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> > > vk...@kernel.org; dri-devel@lists.freedesktop.org;
> > > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > linux-ker...@vger.kernel.org; linux-...@lists.infradead.org
> > > Cc: ker...@pengutronix.de; dl-linux-imx ; Oliver
> > > Brown
> > > Subject: Re: [EXT] Re: [PATCH v6 4/8] phy: Add HDMI configuration
> > > options
> > >
> > >
> > > On 10/07/2023 10:28, Sandor Yu wrote:
> > > > Hi Dmitry,
> > > >
> > > > Thanks for your comments,
> > > >
> > > >> From: Dmitry Baryshkov On
> > > >> 15/06/2023 04:38, Sandor Yu wrote:
> > > >>> Allow HDMI PHYs to be configured through the generic functions
> > > >>> through a custom structure added to the generic union.
> > > >>>
> > > >>> The parameters added here are based on HDMI PHY implementation
> > > >>> practices. The current set of parameters should cover the
> > > >>> potential users.
> > > >>>
> > > >>> Signed-off-by: Sandor Yu
> > > >>> ---
> > > >>>include/linux/phy/phy-hdmi.h | 38
> > > >>
> > > >>>include/linux/phy/phy.h | 7 ++-
> > > >>>2 files changed, 44 insertions(+), 1 deletion(-)
> > > >>>create mode 100644 include/linux/phy/phy-hdmi.h
> > > >>>
> > > >>> diff --git a/include/linux/phy/phy-hdmi.h
> > > >>> b/include/linux/phy/phy-hdmi.h new file mode 100644 index
> > > >>> ..5765aa5bc175
> > > >>> --- /dev/null
> > > >>> +++ b/include/linux/phy/phy-hdmi.h
> > > >>> @@ -0,0 +1,38 @@
> > > >>> +/* SPDX-License-Identifier: GPL-2.0 */
> > > >>> +/*
> > > >>> + * Copyright 2022 NXP
> > > >>> + */
> > > >>> +
> > > >>> +#ifndef __PHY_HDMI_H_
> > > >>> +#define __PHY_HDMI_H_
> > > >>> +
> > > >>> +/**
> > > >>> + * Pixel Encoding as HDMI Specification
> > > >>> + * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
> > > >>> + * YUV420: HDMI Specification 2.a Section 7.1 */ enum
> > > >>> +hdmi_phy_colorspace {
> > > >>> + HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
> > > >>> + HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
> > > >>> + HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
> > > >>> + HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
> > > >>> + HDMI_PHY_COLORSPACE_RESERVED4,
> > > >>> + HDMI_PHY_COLORSPACE_RESERVED5,
> > > >>> + HDMI_PHY_COLORSPACE_RESERVED6, };
> > > >>
> > > >> This enum duplicates enum hdmi_colorspace from
> > > >> HDMI
> > > >> 2.0 defines '7' to be IDO-defined.
> > > >>
> > > >> Would it be better to use that enum instead?
> > > > Accept. I will create head file hdmi_colorspace.h to reuse enum
> > > hdmi_colorspace in .
> > >
> > > Excuse me, it was supposed to be a question.
> > >
> > > Do you need another header file to reuse this enum?
> > I'm not sure community whether would accept the patch that simply
> > include in phy-hdmi.h because there are lots of other
> definition in that not need by phy-hdmi.h.
> > If the answer is yes, I happy to follow.
>
> In my opinion it's a better alternative to creating yet another header.
OK, I will try include in phy-hdmi.h in the next version.
Thanks for your comments.
B,R
Sandor
>
> >
> > >
> > > >
> > > > B.R
> > > > Sandor
> > > >>
> > > >>> +
> > > >>> +/**
> > > >>> + * struct phy_configure_opts_hdmi - HDMI configuration set
> > > >>> + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> > > >>> + * @bpc: Maximum bits per color channel.
> > > >>> + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> > > >>> + *
> > > >>> + * This structure is used to represent the configuration state
> > > >>> +of a HDMI
> > > phy.
> > > >>> + */
> > > >>> +struct phy_configure_opts_hdmi {
> > > >>> + unsigned int pixel_clk_rate;
> > > >>> + unsigned int bpc;
> > > >>> + enum hdmi_phy_colorspace color_space; };
> > > >>> +
> > > >>> +#endif /* __PHY_HDMI_H_ */
> > > >>
> > > >> [skipped the rest]
> > > >>
> > > >> --
> > > >> With best wishes
> > > >> Dmitry
> > > >
> > >
> > > --
> > > With best wishes
> > > Dmitry
> >
> > B.R
> > Sandor
> >
>
>
> --
> With best wishes
> Dmitry
Re: [PATCH v2] drm/ast: report connection status on Display Port.
On 06/07/2023 15:03, Linux regression tracking (Thorsten Leemhuis) wrote:
On 06.07.23 11:58, Jocelyn Falempe wrote:
Aspeed always report the display port as "connected", because it
doesn't set a .detect callback.
Fix this by providing the proper detect callback for astdp and dp501.
This also fixes the following regression:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the remote BMC resolution to 640x480,
which is inconvenient, and breaks the anaconda installer.
v2: Add .detect callback to the dp/dp501 connector (Jani Nikula)
Signed-off-by: Jocelyn Falempe
So if this "also fixes a regression" how about a Fixes: tag and a CC:
In this case, the regression only affect one userspace program
(anaconda), and the fix looks too risky to backport to all stable kernels.
I've to prepare a v3, as this one breaks on hardware were there is only
one Display Port connector and no VGA connector.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
Best regards,
--
Jocelyn
Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots
On Fri, 7 Jul 2023 13:54:21 -0700 Michael Banack wrote: > On 7/7/23 01:38, Pekka Paalanen wrote: ... > >>> The question of which input device corresponds to which cursor plane > >>> might be good to answer too. I presume the VM runner is configured to > >>> expose exactly one of each, so there can be only one association? > >> As far as I know, all of the VM consoles are written as though they > >> taking the place of what would the the physical monitors and input > >> devices on a native machine. So they assume that there is one user, > >> sitting in front of one console, and all monitors/input devices are > >> being used by that user. > > Ok, but having a single user does not mean that there cannot be > > multiple independent pointers, especially on Wayland. The same with > > keyboards. > True, and if the userspace is doing anything complicated here, the > hypervisor has to be responsible for ensuring that whatever it's doing > works with that, or else this system won't work. I don't know that the > kernel is in a good position to police that. > >>> What do you mean by policing here? > >>> > >>> Isn't it the hypervisor that determines what virtual input devices will > >>> be available to the guest OS? Therefore, the hypervisor is in a > >>> position to expose exactly one pointer device and exactly one > >>> cursor plane to guest OS which means the guest OS cannot get the > >>> association wrong. If that's the general and expected hypervisor > >>> policy, then there is no need to design explicit device association in > >>> the guest kernel UAPI. If so, I'd like it to be mentioned in the kernel > >>> docs, too. > >> I'm not entirely sure how to fit what you're calling a "pointer" into my > >> mental model of what the hypervisor is doing... > > My definition: A pointer is a pointing input device that requires a > > cursor image to be drawn at the right location for it to be usable. > Right, but normal desktops (and our consoles) expect multiple input > devices to feed into a single cursor. So the connection between the > on-screen cursor and the corresponding input-devices is not clear to me > when you start talking about multiple pointers, even without any > hypervisors in the picture. The connection is simple: there is an independent on-screen cursor for each logical pointer. How that cursor is drawn is irrelevant to the end user, and Wayland compositors (a type of a display server) will use any means necessary to draw it. Each logical pointer has one cursor that is independent from all other logical pointers. Each logical pointer can have any number of input devices controlling it. The assignments are decided by the userspace and implemented in a display (window system) server. This has been ingrained into the fundamental design of Wayland, even if the feature is rarely used in practise. The window system may expose multiple independent pointers to applications, and each pointer may also interact with the same window simultaneously. This naturally leads to the question "which cursor goes with which input device?", and the kernel, or anything below it, does not know that if there are multiple possibilities. > >> So I guess I'm not clear on what kind of usermode<=>kernel contract you > >> want here if the kernel isn't what's owning the translation between the > >> mouse input and the cursor position. The hypervisor awkwardly has to > >> straddle both the input/graphics domain, and we do so by making > >> assumptions about how the user desktop is going to behave. > > Correct. In order to reduce that awkwardness, I encourage you to write > > down the expectations and requirements in this new Linux UAPI (the KMS > > cursor place hotspot property). Then you can be much more confident on > > how a random Linux desktop will behave. > > > > It will also help the reviewers here to understand what the new UAPI is > > and how it is supposed to work. > > The cursor hotspot is I think fairly straightforward, as far as what > that means for how hypervisor clients are expected to draw the mouse, > and Zack's working on that part. > > My point was that how the hypervisor then sends input is sort of outside > the scope of the graphics portion here, and I think probably outside the > current Linux UAPI entirely (unless there's some other input/topology > system somewhere else I'm not familiar with). I would not say that the hotspot property is in any way obvious. I've spent my whole Wayland and compositor developer career of over 10 years never seeing the need of the kernel knowing the hotspot myself, because I never use VMWare like tools. You cannot describe why hotspot property is needed or how it works without explaining the input side. The hotspot property is actually really weird, because its existence requires combining the input system with the graphics system for it to make sense. The input system used to be
Re: [PATCH v2] drm/ast: report connection status on Display Port.
On 10.07.23 10:12, Jocelyn Falempe wrote:
> On 06/07/2023 15:03, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 06.07.23 11:58, Jocelyn Falempe wrote:
>>> Aspeed always report the display port as "connected", because it
>>> doesn't set a .detect callback.
>>> Fix this by providing the proper detect callback for astdp and dp501.
>>>
>>> This also fixes the following regression:
>>> Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
>>> EDID on DP")
>>> The default resolution is now 640x480 when no monitor is connected.
>>> But Aspeed graphics is mostly used in servers, where no monitor
>>> is attached. This also affects the remote BMC resolution to 640x480,
>>> which is inconvenient, and breaks the anaconda installer.
>>>
>>> v2: Add .detect callback to the dp/dp501 connector (Jani Nikula)
>>>
>>> Signed-off-by: Jocelyn Falempe
>>
>> So if this "also fixes a regression" how about a Fixes: tag and a CC:
>> > also in all affected stable and longterm kernels?
>
> In this case, the regression only affect one userspace program
> (anaconda),
That is (mostly) irrelevant when it comes to regressions.
> and the fix looks too risky to backport to all stable kernels.
Not sure, but I tend to thing that decision would better be left to the
stable team. Each developer will have a different opinion about what's
too risky or not and they might be in the better position to judge what
they want for their trees. A "Fixes:" tag thus still seems appropriate
here; will also tell downstream distros that might want to pick this up.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
[PATCH] drm/radeon: ERROR: "(foo*)" should be "(foo *)"
Fix four occurrences of the checkpatch.pl error:
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Ran Sun
---
drivers/gpu/drm/radeon/radeon_atombios.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index bf3c411a55c5..85c4bb186203 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -1389,7 +1389,7 @@ bool radeon_atombios_get_ppll_ss_info(struct
radeon_device *rdev,
num_indices = (size - sizeof(ATOM_COMMON_TABLE_HEADER)) /
sizeof(ATOM_SPREAD_SPECTRUM_ASSIGNMENT);
-ss_assign = (struct _ATOM_SPREAD_SPECTRUM_ASSIGNMENT*)
+ss_assign = (struct _ATOM_SPREAD_SPECTRUM_ASSIGNMENT *)
((u8 *)&ss_info->asSS_Info[0]);
for (i = 0; i < num_indices; i++) {
if (ss_assign->ucSS_Id == id) {
@@ -1402,7 +1402,7 @@ bool radeon_atombios_get_ppll_ss_info(struct
radeon_device *rdev,
ss->refdiv = ss_assign->ucRecommendedRef_Div;
return true;
}
-ss_assign = (struct _ATOM_SPREAD_SPECTRUM_ASSIGNMENT*)
+ss_assign = (struct _ATOM_SPREAD_SPECTRUM_ASSIGNMENT *)
((u8 *)ss_assign + sizeof(struct
_ATOM_SPREAD_SPECTRUM_ASSIGNMENT));
}
}
@@ -3406,7 +3406,7 @@ static ATOM_VOLTAGE_OBJECT_V2
*atom_lookup_voltage_object_v2(ATOM_VOLTAGE_OBJECT
{
u32 size = le16_to_cpu(v2->sHeader.usStructureSize);
u32 offset = offsetof(ATOM_VOLTAGE_OBJECT_INFO_V2,
asVoltageObj[0]);
-u8 *start = (u8*)v2;
+u8 *start = (u8 *)v2;
while (offset < size) {
ATOM_VOLTAGE_OBJECT_V2 *vo = (ATOM_VOLTAGE_OBJECT_V2 *)(start +
offset);
@@ -3423,7 +3423,7 @@ static ATOM_VOLTAGE_OBJECT_V3
*atom_lookup_voltage_object_v3(ATOM_VOLTAGE_OBJECT
{
u32 size = le16_to_cpu(v3->sHeader.usStructureSize);
u32 offset = offsetof(ATOM_VOLTAGE_OBJECT_INFO_V3_1,
asVoltageObj[0]);
-u8 *start = (u8*)v3;
+u8 *start = (u8 *)v3;
while (offset < size) {
ATOM_VOLTAGE_OBJECT_V3 *vo = (ATOM_VOLTAGE_OBJECT_V3 *)(start +
offset);
Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set
On Fri, 7 Jul 2023 19:40:59 -0300 André Almeida wrote: > From: Pekka Paalanen > > Specify how the atomic state is maintained between userspace and > kernel, plus the special case for async flips. > > Signed-off-by: Pekka Paalanen > Signed-off-by: André Almeida > --- > v4: total rework by Pekka > --- > Documentation/gpu/drm-uapi.rst | 41 ++ > 1 file changed, 41 insertions(+) Thank you for polishing that email into a proper patch! For patches 1 and 2: Acked-by: Pekka Paalanen Thanks, pq > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 65fb3036a580..6a1662c08901 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -486,3 +486,44 @@ and the CRTC index is its position in this array. > > .. kernel-doc:: include/uapi/drm/drm_mode.h > :internal: > + > +KMS atomic state > + > + > +An atomic commit can change multiple KMS properties in an atomic fashion, > +without ever applying intermediate or partial state changes. Either the > whole > +commit succeeds or fails, and it will never be applied partially. This is the > +fundamental improvement of the atomic API over the older non-atomic API > which is > +referred to as the "legacy API". Applying intermediate state could > unexpectedly > +fail, cause visible glitches, or delay reaching the final state. > + > +An atomic commit can be flagged with DRM_MODE_ATOMIC_TEST_ONLY, which means > the > +complete state change is validated but not applied. Userspace should use > this > +flag to validate any state change before asking to apply it. If validation > fails > +for any reason, userspace should attempt to fall back to another, perhaps > +simpler, final state. This allows userspace to probe for various > configurations > +without causing visible glitches on screen and without the need to undo a > +probing change. > + > +The changes recorded in an atomic commit apply on top the current KMS state > in > +the kernel. Hence, the complete new KMS state is the complete old KMS state > with > +the committed property settings done on top. The kernel will automatically > avoid > +no-operation changes, so it is safe and even expected for userspace to send > +redundant property settings. No-operation changes do not count towards > actually > +needed changes, e.g. setting MODE_ID to a different blob with identical > +contents as the current KMS state shall not be a modeset on its own. > + > +A "modeset" is a change in KMS state that might enable, disable, or > temporarily > +disrupt the emitted video signal, possibly causing visible glitches on > screen. A > +modeset may also take considerably more time to complete than other kinds of > +changes, and the video sink might also need time to adapt to the new signal > +properties. Therefore a modeset must be explicitly allowed with the flag > +DRM_MODE_ATOMIC_ALLOW_MODESET. This in combination with > +DRM_MODE_ATOMIC_TEST_ONLY allows userspace to determine if a state change is > +likely to cause visible disruption on screen and avoid such changes when end > +users do not expect them. > + > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is allowed to > +effectively change only the FB_ID property on any planes. No-operation > changes > +are ignored as always. Changing any other property will cause the commit to > be > +rejected. pgpIDxgRD4g7v.pgp Description: OpenPGP digital signature
[PATCH V6 0/9] Enable Wifi RFI interference mitigation feature support
Due to electrical and mechanical constraints in certain platform designs there may be likely interference of relatively high-powered harmonics of the (G-)DDR memory clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate possible RFI interference producers can advertise the frequencies in use and consumers can use this information to avoid using these frequencies for sensitive features. The whole patch set is based on Linux 6.4. With some brief introductions as below: Patch1 - 2: Core functionality setup for WBRF feature support Patch3 - 4: Bring WBRF support to wifi subsystem. Patch5 - 9: Bring WBRF support to AMD graphics driver. Evan Quan (9): drivers core: Add support for Wifi band RF mitigations driver core: add ACPI based WBRF mechanism introduced by AMD cfg80211: expose nl80211_chan_width_to_mhz for wide sharing wifi: mac80211: Add support for ACPI WBRF drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature drm/amd/pm: setup the framework to support Wifi RFI mitigation feature drm/amd/pm: add flood detection for wbrf events drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0 drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7 drivers/acpi/Makefile | 2 + drivers/acpi/amd_wbrf.c | 269 ++ drivers/base/Kconfig | 37 +++ drivers/base/Makefile | 1 + drivers/base/wbrf.c | 250 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 19 ++ drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 213 ++ drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 33 +++ .../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +- .../inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +- .../pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h | 3 +- .../pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h | 3 +- drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +- drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 + .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 9 + .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 60 .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + include/linux/acpi_amd_wbrf.h | 24 ++ include/linux/ieee80211.h | 1 + include/linux/wbrf.h | 72 + include/net/cfg80211.h| 8 + net/mac80211/Makefile | 2 + net/mac80211/chan.c | 9 + net/mac80211/ieee80211_i.h| 19 ++ net/mac80211/main.c | 2 + net/mac80211/wbrf.c | 103 +++ net/wireless/chan.c | 3 +- 29 files changed, 1233 insertions(+), 6 deletions(-) create mode 100644 drivers/acpi/amd_wbrf.c create mode 100644 drivers/base/wbrf.c create mode 100644 include/linux/acpi_amd_wbrf.h create mode 100644 include/linux/wbrf.h create mode 100644 net/mac80211/wbrf.c -- 2.34.1
[PATCH V6 1/9] drivers core: Add support for Wifi band RF mitigations
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced a mechanism that devices can use to
notify active use of particular frequencies so that other devices can make
relative internal adjustments as necessary to avoid this resonance.
In order for a device to support this, the expected flow for device
driver or subsystems:
Drivers/subsystems contributing frequencies:
1) During probe, check `wbrf_supported_producer` to see if WBRF supported
for the device.
2) If adding frequencies, then call `wbrf_add_exclusion` with the
start and end ranges of the frequencies.
3) If removing frequencies, then call `wbrf_remove_exclusion` with
start and end ranges of the frequencies.
Drivers/subsystems responding to frequencies:
1) During probe, check `wbrf_supported_consumer` to see if WBRF is supported
for the device.
2) Call the `wbrf_retrieve_exclusions` to retrieve the current
exclusions on receiving an ACPI notification for a new frequency
change.
Co-developed-by: Mario Limonciello
Signed-off-by: Mario Limonciello
Co-developed-by: Evan Quan
Signed-off-by: Evan Quan
--
v4->v5:
- promote this to be a more generic solution with input argument taking
`struct device` and provide better scalability to support non-ACPI
scenarios(Andrew)
- update the APIs naming and some other minor fixes(Rafael)
---
drivers/base/Kconfig | 8 ++
drivers/base/Makefile | 1 +
drivers/base/wbrf.c | 227 ++
include/linux/wbrf.h | 70 +
4 files changed, 306 insertions(+)
create mode 100644 drivers/base/wbrf.c
create mode 100644 include/linux/wbrf.h
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 2b8fd6bb7da0..5b441017b225 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -242,4 +242,12 @@ config FW_DEVLINK_SYNC_STATE_TIMEOUT
command line option on every system/board your kernel is expected to
work on.
+config WBRF
+ bool "Wifi band RF mitigation mechanism"
+ default n
+ help
+ Wifi band RF mitigation mechanism allows multiple drivers from
+ different domains to notify the frequencies in use so that hardware
+ can be reconfigured to avoid harmonic conflicts.
+
endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 3079bfe53d04..c844f68a6830 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_GENERIC_MSI_IRQ) += platform-msi.o
obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
obj-$(CONFIG_GENERIC_ARCH_NUMA) += arch_numa.o
obj-$(CONFIG_ACPI) += physical_location.o
+obj-$(CONFIG_WBRF) += wbrf.o
obj-y += test/
diff --git a/drivers/base/wbrf.c b/drivers/base/wbrf.c
new file mode 100644
index ..2163a8ec8a9a
--- /dev/null
+++ b/drivers/base/wbrf.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Wifi Band Exclusion Interface
+ * Copyright (C) 2023 Advanced Micro Devices
+ *
+ */
+
+#include
+
+static BLOCKING_NOTIFIER_HEAD(wbrf_chain_head);
+static DEFINE_MUTEX(wbrf_mutex);
+static struct exclusion_range_pool wbrf_pool;
+
+static int _wbrf_add_exclusion_ranges(struct wbrf_ranges_in *in)
+{
+ int i, j;
+
+ for (i = 0; i < ARRAY_SIZE(in->band_list); i++) {
+ if (!in->band_list[i].start &&
+ !in->band_list[i].end)
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(wbrf_pool.band_list); j++) {
+ if (wbrf_pool.band_list[j].start ==
in->band_list[i].start &&
+ wbrf_pool.band_list[j].end == in->band_list[i].end)
{
+ wbrf_pool.ref_counter[j]++;
+ break;
+ }
+ }
+ if (j < ARRAY_SIZE(wbrf_pool.band_list))
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(wbrf_pool.band_list); j++) {
+ if (!wbrf_pool.band_list[j].start &&
+ !wbrf_pool.band_list[j].end) {
+ wbrf_pool.band_list[j].start =
in->band_list[i].start;
+ wbrf_pool.band_list[j].end =
in->band_list[i].end;
+ wbrf_pool.ref_counter[j] = 1;
+ break;
+ }
+ }
+ if (j >= ARRAY_SIZE(wbrf_pool.band_list))
+ return -ENOSPC;
+ }
+
+ return 0;
+}
+
+static int _wbrf_remove_exclusion_ranges(struct wbrf_ranges_in *in)
+{
+ int i, j;
+
+ for (i = 0; i < ARRAY_SIZE(in->band_list); i++) {
+ if (!in->band_list[i].start &&
+ !in->band_list[i].end)
+
[PATCH V6 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD
AMD has introduced an ACPI based mechanism to support WBRF for some
platforms with AMD dGPU + WLAN. This needs support from BIOS equipped
with necessary AML implementations and dGPU firmwares.
For those systems without the ACPI mechanism and developing solutions,
user can use the generic WBRF solution for diagnosing potential
interference issues.
Co-developed-by: Mario Limonciello
Signed-off-by: Mario Limonciello
Co-developed-by: Evan Quan
Signed-off-by: Evan Quan
--
v4->v5:
- promote this to be a more generic solution with input argument taking
`struct device` and provide better scalability to support non-ACPI
scenarios(Andrew)
- update the APIs naming and some other minor fixes(Rafael)
v5->v6:
- make the code more readable and some other fixes(Andrew)
---
drivers/acpi/Makefile | 2 +
drivers/acpi/amd_wbrf.c | 269 ++
drivers/base/Kconfig | 29
drivers/base/wbrf.c | 35 -
include/linux/acpi_amd_wbrf.h | 24 +++
include/linux/wbrf.h | 2 +
6 files changed, 355 insertions(+), 6 deletions(-)
create mode 100644 drivers/acpi/amd_wbrf.c
create mode 100644 include/linux/acpi_amd_wbrf.h
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index feb36c0b9446..94b940ddbf88 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -131,3 +131,5 @@ obj-y += dptf/
obj-$(CONFIG_ARM64)+= arm64/
obj-$(CONFIG_ACPI_VIOT)+= viot.o
+
+obj-$(CONFIG_WBRF_AMD_ACPI)+= amd_wbrf.o
diff --git a/drivers/acpi/amd_wbrf.c b/drivers/acpi/amd_wbrf.c
new file mode 100644
index ..481b1c180a09
--- /dev/null
+++ b/drivers/acpi/amd_wbrf.c
@@ -0,0 +1,269 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Wifi Band Exclusion Interface (AMD ACPI Implementation)
+ * Copyright (C) 2023 Advanced Micro Devices
+ *
+ */
+
+#include
+#include
+
+/*
+ * Functions bit vector for WBRF method
+ *
+ * Bit 0: Supported for any functions other than function 0.
+ * Bit 1: Function 1 (Add / Remove frequency) is supported.
+ * Bit 2: Function 2 (Get frequency list) is supported.
+ */
+#define WBRF_SUPPORT_OTHER_FUNCTION0x0
+#define WBRF_RECORD0x1
+#define WBRF_RETRIEVE 0x2
+
+/* record actions */
+#define WBRF_RECORD_ADD0x0
+#define WBRF_RECORD_REMOVE 0x1
+
+#define WBRF_REVISION 0x1
+
+static const guid_t wifi_acpi_dsm_guid =
+ GUID_INIT(0x7b7656cf, 0xdc3d, 0x4c1c,
+ 0x83, 0xe9, 0x66, 0xe7, 0x21, 0xde, 0x30, 0x70);
+
+static int wbrf_dsm(struct acpi_device *adev, u8 fn,
+ union acpi_object *argv4,
+ union acpi_object **out)
+{
+ union acpi_object *obj;
+ int rc;
+
+ obj = acpi_evaluate_dsm(adev->handle, &wifi_acpi_dsm_guid,
+ WBRF_REVISION, fn, argv4);
+ if (!obj)
+ return -ENXIO;
+
+ switch (obj->type) {
+ case ACPI_TYPE_BUFFER:
+ *out = obj;
+ return 0;
+
+ case ACPI_TYPE_INTEGER:
+ rc = obj->integer.value ? -EINVAL : 0;
+ break;
+
+ default:
+ rc = -EOPNOTSUPP;
+ }
+
+ ACPI_FREE(obj);
+
+ return rc;
+}
+
+static int wbrf_record(struct acpi_device *adev, uint8_t action,
+ struct wbrf_ranges_in *in)
+{
+ union acpi_object argv4;
+ union acpi_object *tmp;
+ u32 num_of_ranges = 0;
+ u32 num_of_elements;
+ u32 arg_idx = 0;
+ u32 loop_idx;
+ int ret;
+
+ if (!in)
+ return -EINVAL;
+
+ for (loop_idx = 0; loop_idx < ARRAY_SIZE(in->band_list);
+loop_idx++)
+ if (in->band_list[loop_idx].start &&
+ in->band_list[loop_idx].end)
+ num_of_ranges++;
+
+ /*
+* Every range comes with two end points(start and end) and
+* each of them is accounted as an element. Meanwhile the range
+* count and action type are accounted as an element each.
+* So, the total element count = 2 * num_of_ranges + 1 + 1.
+*/
+ num_of_elements = 2 * num_of_ranges + 1 + 1;
+
+ tmp = kcalloc(num_of_elements, sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
+ argv4.package.type = ACPI_TYPE_PACKAGE;
+ argv4.package.count = num_of_elements;
+ argv4.package.elements = tmp;
+
+ tmp[arg_idx].integer.type = ACPI_TYPE_INTEGER;
+ tmp[arg_idx++].integer.value = num_of_ranges;
+ tmp[arg_idx].integer.type = ACPI_TYPE_INTEGER;
+ tmp[arg_idx++].integer.value = action;
+
+ for (loop_idx = 0; loop_idx < ARRAY_SIZE(in->band_list);
+loop_idx++) {
+ if (!in->band_list[loop_idx].start ||
+ !in->band_list[loop_idx].end)
+ continue;
+
+
[PATCH V6 3/9] cfg80211: expose nl80211_chan_width_to_mhz for wide sharing
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9e04f69712b1..c6dc337eafce 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
cfg80211_chandef_compatible(const struct cfg80211_chan_def *chandef1,
const struct cfg80211_chan_def *chandef2);
+/**
+ * nl80211_chan_width_to_mhz - get the channel width in Mhz
+ * @chan_width: the channel width from &enum nl80211_chan_width
+ * Return: channel width in Mhz if the chan_width from &enum nl80211_chan_width
+ * is valid. -1 otherwise.
+ */
+int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width);
+
/**
* cfg80211_chandef_valid - check if a channel definition is valid
* @chandef: the channel definition to check
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 0b7e81db383d..227db04eac42 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -141,7 +141,7 @@ static bool cfg80211_edmg_chandef_valid(const struct
cfg80211_chan_def *chandef)
return true;
}
-static int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width)
+int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width)
{
int mhz;
@@ -190,6 +190,7 @@ static int nl80211_chan_width_to_mhz(enum
nl80211_chan_width chan_width)
}
return mhz;
}
+EXPORT_SYMBOL(nl80211_chan_width_to_mhz);
static int cfg80211_chandef_get_width(const struct cfg80211_chan_def *c)
{
--
2.34.1
[PATCH V6 4/9] wifi: mac80211: Add support for ACPI WBRF
To support AMD's WBRF interference mitigation mechanism, Wifi adapters
utilized in the system must register the frequencies in use(or unregister
those frequencies no longer used) via the dedicated APCI calls. So that,
other drivers responding to the frequencies can take proper actions to
mitigate possible interference.
Co-developed-by: Mario Limonciello
Signed-off-by: Mario Limonciello
Co-developed-by: Evan Quan
Signed-off-by: Evan Quan
--
v1->v2:
- place the new added member(`wbrf_supported`) in
ieee80211_local(Johannes)
- handle chandefs change scenario properly(Johannes)
- some minor fixes around code sharing and possible invalid input
checks(Johannes)
v2->v3:
- drop unnecessary input checks and intermediate APIs(Mario)
- Separate some mac80211 common code(Mario, Johannes)
v3->v4:
- some minor fixes around return values(Johannes)
---
include/linux/ieee80211.h | 1 +
net/mac80211/Makefile | 2 +
net/mac80211/chan.c| 9
net/mac80211/ieee80211_i.h | 19 +++
net/mac80211/main.c| 2 +
net/mac80211/wbrf.c| 103 +
6 files changed, 136 insertions(+)
create mode 100644 net/mac80211/wbrf.c
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index c4cf296e7eaf..0703921547f5 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -4319,6 +4319,7 @@ static inline int ieee80211_get_tdls_action(struct
sk_buff *skb, u32 hdr_size)
/* convert frequencies */
#define MHZ_TO_KHZ(freq) ((freq) * 1000)
#define KHZ_TO_MHZ(freq) ((freq) / 1000)
+#define KHZ_TO_HZ(freq) ((freq) * 1000)
#define PR_KHZ(f) KHZ_TO_MHZ(f), f % 1000
#define KHZ_F "%d.%03d"
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index b8de44da1fb8..8f8ac567e7c8 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -65,4 +65,6 @@ rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS) += \
mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-y)
+mac80211-$(CONFIG_WBRF) += wbrf.o
+
ccflags-y += -DDEBUG
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 77c90ed8f5d7..9887471028dc 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -506,11 +506,16 @@ static void _ieee80211_change_chanctx(struct
ieee80211_local *local,
WARN_ON(!cfg80211_chandef_compatible(&ctx->conf.def, chandef));
+ ieee80211_remove_wbrf(local, &ctx->conf.def);
+
ctx->conf.def = *chandef;
/* check if min chanctx also changed */
changed = IEEE80211_CHANCTX_CHANGE_WIDTH |
_ieee80211_recalc_chanctx_min_def(local, ctx, rsvd_for);
+
+ ieee80211_add_wbrf(local, &ctx->conf.def);
+
drv_change_chanctx(local, ctx, changed);
if (!local->use_chanctx) {
@@ -668,6 +673,8 @@ static int ieee80211_add_chanctx(struct ieee80211_local
*local,
lockdep_assert_held(&local->mtx);
lockdep_assert_held(&local->chanctx_mtx);
+ ieee80211_add_wbrf(local, &ctx->conf.def);
+
if (!local->use_chanctx)
local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
@@ -748,6 +755,8 @@ static void ieee80211_del_chanctx(struct ieee80211_local
*local,
}
ieee80211_recalc_idle(local);
+
+ ieee80211_remove_wbrf(local, &ctx->conf.def);
}
static void ieee80211_free_chanctx(struct ieee80211_local *local,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4159fb65038b..fb984ce7038c 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1591,6 +1591,10 @@ struct ieee80211_local {
/* extended capabilities provided by mac80211 */
u8 ext_capa[8];
+
+#if IS_ENABLED(CONFIG_WBRF)
+ bool wbrf_supported;
+#endif
};
static inline struct ieee80211_sub_if_data *
@@ -2615,4 +2619,19 @@ ieee80211_eht_cap_ie_to_sta_eht_cap(struct
ieee80211_sub_if_data *sdata,
const struct ieee80211_eht_cap_elem
*eht_cap_ie_elem,
u8 eht_cap_len,
struct link_sta_info *link_sta);
+
+#if IS_ENABLED(CONFIG_WBRF)
+void ieee80211_check_wbrf_support(struct ieee80211_local *local);
+void ieee80211_add_wbrf(struct ieee80211_local *local,
+ struct cfg80211_chan_def *chandef);
+void ieee80211_remove_wbrf(struct ieee80211_local *local,
+ struct cfg80211_chan_def *chandef);
+#else
+static inline void ieee80211_check_wbrf_support(struct ieee80211_local *local)
{ }
+static inline void ieee80211_add_wbrf(struct ieee80211_local *local,
+ struct cfg80211_chan_def *chandef) { }
+static inline void ieee80211_remove_wbrf(struct ieee80211_local *local,
+struct cfg80211_chan_def *chandef) { }
+#endif /* CONFIG_WBRF */
+
#endif /* IEEE80211_I_H */
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 55cdfaef0f5d..0a55626b1546 100644
-
[PATCH V6 5/9] drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
.../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h | 3 ++-
.../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h | 3 ++-
4 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
index b686fb68a6e7..d64188fb5839 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
@@ -388,6 +388,17 @@ typedef struct {
EccInfo_t EccInfo[24];
} EccInfoTable_t;
+typedef struct {
+ uint16_t LowFreq;
+ uint16_t HighFreq;
+} WifiOneBand_t;
+
+typedef struct {
+ uint32_t WifiBandEntryNum;
+ WifiOneBand_tWifiBandEntry[11];
+ uint32_t MmHubPadding[8];
+} WifiBandEntryTable_t;
+
//D3HOT sequences
typedef enum {
BACO_SEQUENCE,
@@ -1592,7 +1603,8 @@ typedef struct {
#define TABLE_I2C_COMMANDS9
#define TABLE_DRIVER_INFO 10
#define TABLE_ECCINFO 11
-#define TABLE_COUNT 12
+#define TABLE_WIFIBAND12
+#define TABLE_COUNT 13
//IH Interupt ID
#define IH_INTERRUPT_ID_TO_DRIVER 0xFE
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
index 4c46a0392451..77483e8485e7 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
@@ -392,6 +392,17 @@ typedef struct {
EccInfo_t EccInfo[24];
} EccInfoTable_t;
+typedef struct {
+ uint16_t LowFreq;
+ uint16_t HighFreq;
+} WifiOneBand_t;
+
+typedef struct {
+ uint32_t WifiBandEntryNum;
+ WifiOneBand_tWifiBandEntry[11];
+ uint32_t MmHubPadding[8];
+} WifiBandEntryTable_t;
+
//D3HOT sequences
typedef enum {
BACO_SEQUENCE,
@@ -1624,7 +1635,8 @@ typedef struct {
#define TABLE_I2C_COMMANDS9
#define TABLE_DRIVER_INFO 10
#define TABLE_ECCINFO 11
-#define TABLE_COUNT 12
+#define TABLE_WIFIBAND12
+#define TABLE_COUNT 13
//IH Interupt ID
#define IH_INTERRUPT_ID_TO_DRIVER 0xFE
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
index 10cff75b44d5..c98cc32d11bd 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
@@ -138,7 +138,8 @@
#define PPSMC_MSG_SetBadMemoryPagesRetiredFlagsPerChannel 0x4A
#define PPSMC_MSG_SetPriorityDeltaGain 0x4B
#define PPSMC_MSG_AllowIHHostInterrupt 0x4C
-#define PPSMC_Message_Count 0x4D
+#define PPSMC_MSG_EnableUCLKShadow 0x51
+#define PPSMC_Message_Count 0x52
//Debug Dump Message
#define DEBUGSMC_MSG_TestMessage0x1
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
index 6aaefca9b595..a6bf9cdd130e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
@@ -134,6 +134,7 @@
#define PPSMC_MSG_SetBadMemoryPagesRetiredFlagsPerChannel 0x4A
#define PPSMC_MSG_SetPriorityDeltaGain 0x4B
#define PPSMC_MSG_AllowIHHostInterrupt 0x4C
-#define PPSMC_Message_Count 0x4D
+#define PPSMC_MSG_EnableUCLKShadow 0x51
+#define PPSMC_Message_Count 0x52
#endif
--
2.34.1
[PATCH V6 6/9] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
--
v1->v2:
- update the prompt for feature support(Lijo)
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 19 ++
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 194 ++
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 23 +++
drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 +
5 files changed, 240 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 02b827785e39..785d9b43f0c4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -241,6 +241,7 @@ extern int amdgpu_num_kcq;
#define AMDGPU_VCNFW_LOG_SIZE (32 * 1024)
extern int amdgpu_vcnfw_log;
extern int amdgpu_sg_display;
+extern int amdgpu_wbrf;
#define AMDGPU_VM_MAX_NUM_CTX 4096
#define AMDGPU_SG_THRESHOLD(256*1024*1024)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 393b6fb7a71d..d4f3921509a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -191,6 +191,7 @@ int amdgpu_smartshift_bias;
int amdgpu_use_xgmi_p2p = 1;
int amdgpu_vcnfw_log;
int amdgpu_sg_display = -1; /* auto */
+int amdgpu_wbrf = -1;
static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
@@ -948,6 +949,24 @@ MODULE_PARM_DESC(smu_pptable_id,
"specify pptable id to be used (-1 = auto(default) value, 0 = use
pptable from vbios, > 0 = soft pptable id)");
module_param_named(smu_pptable_id, amdgpu_smu_pptable_id, int, 0444);
+#if IS_ENABLED(CONFIG_WBRF)
+/**
+ * DOC: wbrf (int)
+ * Enable Wifi RFI interference mitigation feature.
+ * Due to electrical and mechanical constraints there may be likely
interference of
+ * relatively high-powered harmonics of the (G-)DDR memory clocks with local
radio
+ * module frequency bands used by Wifi 6/6e/7. To mitigate the possible RFI
interference,
+ * with this feature enabled, PMFW will use either “shadowed P-State” or
“P-State” based
+ * on active list of frequencies in-use (to be avoided) as part of initial
setting or
+ * P-state transition. However, there may be potential performance impact with
this
+ * feature enabled.
+ * (0 = disabled, 1 = enabled, -1 = auto (default setting, will be enabled if
supported))
+ */
+MODULE_PARM_DESC(wbrf,
+ "Enable Wifi RFI interference mitigation (0 = disabled, 1 = enabled, -1
= auto(default)");
+module_param_named(wbrf, amdgpu_wbrf, int, 0444);
+#endif
+
/* These devices are not supported by amdgpu.
* They are supported by the mach64, r128, radeon drivers
*/
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 2ddf5198e5c4..83d428e890df 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1188,6 +1188,173 @@ static int smu_get_thermal_temperature_range(struct
smu_context *smu)
return ret;
}
+/**
+ * smu_wbrf_handle_exclusion_ranges - consume the wbrf exclusion ranges
+ *
+ * @smu: smu_context pointer
+ *
+ * Retrieve the wbrf exclusion ranges and send them to PMFW for proper
handling.
+ * Returns 0 on success, error on failure.
+ */
+static int smu_wbrf_handle_exclusion_ranges(struct smu_context *smu)
+{
+ struct wbrf_ranges_out wbrf_exclusion = {0};
+ struct exclusion_range *wifi_bands = wbrf_exclusion.band_list;
+ struct amdgpu_device *adev = smu->adev;
+ uint64_t start, end;
+ int ret, i, j;
+
+ ret = wbrf_retrieve_exclusions(adev->dev, &wbrf_exclusion);
+ if (ret) {
+ dev_err(adev->dev, "Failed to retrieve exclusion ranges!\n");
+ return ret;
+ }
+
+ /*
+* The exclusion ranges array we got might be filled with holes and
duplicate
+* entries. For example:
+* {(2400, 2500), (0, 0), (6882, 6962), (2400, 2500), (0, 0), (6117,
6189), (0, 0)...}
+* We need to do some sortups to eliminate those holes and duplicate
entries.
+* Expected output: {(2400, 2500), (6117, 6189), (6882, 6962), (0,
0)...}
+*/
+ for (i = 0; i < MAX_NUM_OF_WBRF_RANGES; i++) {
+ start = wifi_bands[i].start;
+ end = wifi_bands[i].end;
+
+ /* get the last valid entry to fill the intermediate hole */
+ if (!start && !end) {
+ for (j = MAX_NUM_OF_WBRF_RANGES - 1; j > i; j--)
+ if (wifi_bands[j].start &&
+ wifi_bands[j].end)
+ break;
+
+
[PATCH V6 7/9] drm/amd/pm: add flood detection for wbrf events
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 31 +++
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 83d428e890df..aa7faeafc86b 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1278,7 +1278,8 @@ static int smu_wbrf_event_handler(struct notifier_block
*nb,
switch (action) {
case WBRF_CHANGED:
- smu_wbrf_handle_exclusion_ranges(smu);
+ schedule_delayed_work(&smu->wbrf_delayed_work,
+
msecs_to_jiffies(SMU_WBRF_EVENT_HANDLING_PACE));
break;
default:
return NOTIFY_DONE;
@@ -1287,6 +1288,21 @@ static int smu_wbrf_event_handler(struct notifier_block
*nb,
return NOTIFY_OK;
}
+/**
+ * smu_wbrf_delayed_work_handler - callback on delayed work timer expired
+ *
+ * @work: struct work_struct pointer
+ *
+ * Flood is over and driver will consume the latest exclusion ranges.
+ */
+static void smu_wbrf_delayed_work_handler(struct work_struct *work)
+{
+ struct smu_context *smu =
+ container_of(work, struct smu_context, wbrf_delayed_work.work);
+
+ smu_wbrf_handle_exclusion_ranges(smu);
+}
+
/**
* smu_wbrf_support_check - check wbrf support
*
@@ -1317,12 +1333,14 @@ static void smu_wbrf_support_check(struct smu_context
*smu)
*/
static int smu_wbrf_init(struct smu_context *smu)
{
- struct amdgpu_device *adev = smu->adev;
int ret;
if (!smu->wbrf_supported)
return 0;
+ INIT_DELAYED_WORK(&smu->wbrf_delayed_work,
+ smu_wbrf_delayed_work_handler);
+
smu->wbrf_notifier.notifier_call = smu_wbrf_event_handler;
ret = wbrf_register_notifier(&smu->wbrf_notifier);
if (ret)
@@ -1333,11 +1351,10 @@ static int smu_wbrf_init(struct smu_context *smu)
* before our driver loaded. To make sure our driver
* is awared of those exclusion ranges.
*/
- ret = smu_wbrf_handle_exclusion_ranges(smu);
- if (ret)
- dev_err(adev->dev, "Failed to handle wbrf exclusion ranges\n");
+ schedule_delayed_work(&smu->wbrf_delayed_work,
+ msecs_to_jiffies(SMU_WBRF_EVENT_HANDLING_PACE));
- return ret;
+ return 0;
}
/**
@@ -1353,6 +1370,8 @@ static void smu_wbrf_fini(struct smu_context *smu)
return;
wbrf_unregister_notifier(&smu->wbrf_notifier);
+
+ cancel_delayed_work_sync(&smu->wbrf_delayed_work);
}
static int smu_smc_hw_setup(struct smu_context *smu)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
index 5b2343cfc69b..5df28d4a8c30 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
@@ -480,6 +480,12 @@ struct stb_context {
#define WORKLOAD_POLICY_MAX 7
+/*
+ * Configure wbrf event handling pace as there can be only one
+ * event processed every SMU_WBRF_EVENT_HANDLING_PACE ms.
+ */
+#define SMU_WBRF_EVENT_HANDLING_PACE 10
+
struct smu_context
{
struct amdgpu_device*adev;
@@ -579,6 +585,7 @@ struct smu_context
/* data structures for wbrf feature support */
boolwbrf_supported;
struct notifier_block wbrf_notifier;
+ struct delayed_work wbrf_delayed_work;
};
struct i2c_adapter;
--
2.34.1
[PATCH V6 8/9] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 +
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 9 +++
.../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 60 +++
5 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
index 5df28d4a8c30..32764c509ba8 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
@@ -325,6 +325,7 @@ enum smu_table_id
SMU_TABLE_PACE,
SMU_TABLE_ECCINFO,
SMU_TABLE_COMBO_PPTABLE,
+ SMU_TABLE_WIFIBAND,
SMU_TABLE_COUNT,
};
@@ -1499,6 +1500,8 @@ enum smu_baco_seq {
__dst_size); \
})
+#define HZ_IN_MHZ 100U
+
#if !defined(SWSMU_CODE_LAYER_L2) && !defined(SWSMU_CODE_LAYER_L3) &&
!defined(SWSMU_CODE_LAYER_L4)
int smu_get_power_limit(void *handle,
uint32_t *limit,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
index 297b70b9388f..5bbb60289a79 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
@@ -245,7 +245,8 @@
__SMU_DUMMY_MAP(AllowGpo), \
__SMU_DUMMY_MAP(Mode2Reset),\
__SMU_DUMMY_MAP(RequestI2cTransaction), \
- __SMU_DUMMY_MAP(GetMetricsTable),
+ __SMU_DUMMY_MAP(GetMetricsTable), \
+ __SMU_DUMMY_MAP(EnableUCLKShadow),
#undef __SMU_DUMMY_MAP
#define __SMU_DUMMY_MAP(type) SMU_MSG_##type
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
index df3baaab0037..b6fae9b92303 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
@@ -303,5 +303,8 @@ int smu_v13_0_get_pptable_from_firmware(struct smu_context
*smu,
uint32_t *size,
uint32_t pptable_id);
+int smu_v13_0_enable_uclk_shadow(struct smu_context *smu,
+bool enablement);
+
#endif
#endif
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
index ca379181081c..7cb24c862720 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
@@ -2453,3 +2453,12 @@ int smu_v13_0_mode1_reset(struct smu_context *smu)
return ret;
}
+
+int smu_v13_0_enable_uclk_shadow(struct smu_context *smu,
+bool enablement)
+{
+ return smu_cmn_send_smc_msg_with_param(smu,
+ SMU_MSG_EnableUCLKShadow,
+ enablement,
+ NULL);
+}
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
index 08577d1b84ec..3e864bd2c5a4 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -155,6 +155,7 @@ static struct cmn2asic_msg_mapping
smu_v13_0_0_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(AllowGpo, PPSMC_MSG_SetGpoAllow,
0),
MSG_MAP(AllowIHHostInterrupt, PPSMC_MSG_AllowIHHostInterrupt,
0),
MSG_MAP(ReenableAcDcInterrupt,
PPSMC_MSG_ReenableAcDcInterrupt, 0),
+ MSG_MAP(EnableUCLKShadow, PPSMC_MSG_EnableUCLKShadow,
0),
};
static struct cmn2asic_mapping smu_v13_0_0_clk_map[SMU_CLK_COUNT] = {
@@ -235,6 +236,7 @@ static struct cmn2asic_mapping
smu_v13_0_0_table_map[SMU_TABLE_COUNT] = {
TAB_MAP(DRIVER_SMU_CONFIG),
TAB_MAP(ACTIVITY_MONITOR_COEFF),
[SMU_TABLE_COMBO_PPTABLE] = {1, TABLE_COMBO_PPTABLE},
+ TAB_MAP(WIFIBAND),
TAB_MAP(I2C_COMMANDS),
TAB_MAP(ECCINFO),
};
@@ -472,6 +474,9 @@ static int smu_v13_0_0_tables_init(struct smu_context *smu)
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
SMU_TABLE_INIT(tables, SMU_TABLE_ECCINFO, sizeof(EccInfoTable_t),
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
+ SMU_TABLE_INIT(tables, SMU_TABLE_WIFIBAND,
+ sizeof(WifiBandEntryTable_t), PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_VRAM);
smu_table->metrics_table = kzalloc(sizeof(SmuMetricsExternal_t),
GFP_KERNEL);
if (!smu_table->metrics_table)
@@ -2141,6 +2146,58 @@ static ssize_t smu_v13_0_0_get_ecc_info(struct
smu_context *smu,
return ret;
}
+static bool smu_v13_0_0_wbrf_su
[PATCH V6 9/9] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index bba621615abf..4a680756208b 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -126,6 +126,7 @@ static struct cmn2asic_msg_mapping
smu_v13_0_7_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(AllowGpo, PPSMC_MSG_SetGpoAllow,
0),
MSG_MAP(GetPptLimit,PPSMC_MSG_GetPptLimit,
0),
MSG_MAP(NotifyPowerSource, PPSMC_MSG_NotifyPowerSource,
0),
+ MSG_MAP(EnableUCLKShadow, PPSMC_MSG_EnableUCLKShadow,
0),
};
static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = {
@@ -206,6 +207,7 @@ static struct cmn2asic_mapping
smu_v13_0_7_table_map[SMU_TABLE_COUNT] = {
TAB_MAP(DRIVER_SMU_CONFIG),
TAB_MAP(ACTIVITY_MONITOR_COEFF),
[SMU_TABLE_COMBO_PPTABLE] = {1, TABLE_COMBO_PPTABLE},
+ TAB_MAP(WIFIBAND),
};
static struct cmn2asic_mapping smu_v13_0_7_pwr_src_map[SMU_POWER_SOURCE_COUNT]
= {
@@ -488,6 +490,9 @@ static int smu_v13_0_7_tables_init(struct smu_context *smu)
AMDGPU_GEM_DOMAIN_VRAM);
SMU_TABLE_INIT(tables, SMU_TABLE_COMBO_PPTABLE,
MP0_MP1_DATA_REGION_SIZE_COMBOPPTABLE,
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
+ SMU_TABLE_INIT(tables, SMU_TABLE_WIFIBAND,
+ sizeof(WifiBandEntryTable_t), PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_VRAM);
smu_table->metrics_table = kzalloc(sizeof(SmuMetricsExternal_t),
GFP_KERNEL);
if (!smu_table->metrics_table)
@@ -1722,6 +1727,57 @@ static int smu_v13_0_7_set_df_cstate(struct smu_context
*smu,
NULL);
}
+static bool smu_v13_0_7_wbrf_support_check(struct smu_context *smu)
+{
+ return smu->smc_fw_version > 0x00524600;
+}
+
+static int smu_v13_0_7_set_wbrf_exclusion_ranges(struct smu_context *smu,
+struct exclusion_range
*exclusion_ranges)
+{
+ WifiBandEntryTable_t wifi_bands;
+ int valid_entries = 0;
+ int ret, i;
+
+ memset(&wifi_bands, 0, sizeof(wifi_bands));
+ for (i = 0; i < ARRAY_SIZE(wifi_bands.WifiBandEntry); i++) {
+ if (!exclusion_ranges[i].start &&
+ !exclusion_ranges[i].end)
+ break;
+
+ /* PMFW expects the inputs to be in Mhz unit */
+ wifi_bands.WifiBandEntry[valid_entries].LowFreq =
+ DIV_ROUND_DOWN_ULL(exclusion_ranges[i].start,
HZ_IN_MHZ);
+ wifi_bands.WifiBandEntry[valid_entries++].HighFreq =
+ DIV_ROUND_UP_ULL(exclusion_ranges[i].end, HZ_IN_MHZ);
+ }
+ wifi_bands.WifiBandEntryNum = valid_entries;
+
+ /*
+* Per confirm with PMFW team, WifiBandEntryNum = 0 is a valid setting.
+* Considering the scenarios below:
+* - At first the wifi device adds an exclusion range e.g. (2400,2500)
to
+* BIOS and our driver gets notified. We will set WifiBandEntryNum = 1
+* and pass the WifiBandEntry (2400, 2500) to PMFW.
+*
+* - Later the wifi device removes the wifiband list added above and
+* our driver gets notified again. At this time, driver will set
+* WifiBandEntryNum = 0 and pass an empty WifiBandEntry list to PMFW.
+* - PMFW may still need to do some uclk shadow update(e.g. switching
+* from shadow clock back to primary clock) on receiving this.
+*/
+
+ ret = smu_cmn_update_table(smu,
+ SMU_TABLE_WIFIBAND,
+ 0,
+ (void *)(&wifi_bands),
+ true);
+ if (ret)
+ dev_err(smu->adev->dev, "Failed to set wifiband!");
+
+ return ret;
+}
+
static const struct pptable_funcs smu_v13_0_7_ppt_funcs = {
.get_allowed_feature_mask = smu_v13_0_7_get_allowed_feature_mask,
.set_default_dpm_table = smu_v13_0_7_set_default_dpm_table,
@@ -1787,6 +1843,9 @@ static const struct pptable_funcs smu_v13_0_7_ppt_funcs =
{
.set_mp1_state = smu_v13_0_7_set_mp1_state,
.set_df_cstate = smu_v13_0_7_set_df_cstate,
.gpo_control = smu_v13_0_gpo_control,
+ .is_asic_wbrf_supported = smu_v13_0_7_wbrf_support_check,
+ .enable_uclk_shadow = smu_v13_0_enable_uclk_shadow,
+ .set_wbrf_exclusion_ranges = smu_v13_0_7_set_wbrf_exclusion_ranges,
};
void smu_v13_0_7_set_ppt_funcs(struct smu_cont
Re: [PATCH] fbdev/hyperv_fb: Include
Thomas Zimmermann writes:
> Include to get the global screen_info state.
> Fixes the following errors:
>
>>> drivers/video/fbdev/hyperv_fb.c:1033:10: error: use of undeclared
>>> identifier 'screen_info'
> 1033 | base = screen_info.lfb_base;
> |^
>drivers/video/fbdev/hyperv_fb.c:1034:10: error: use of undeclared
> identifier 'screen_info'
> 1034 | size = screen_info.lfb_size;
>|^
>>> drivers/video/fbdev/hyperv_fb.c:1080:3: error: must use 'struct' tag to
>>> refer to type 'screen_info'
> 1080 | screen_info.lfb_size = 0;
>| ^
>| struct
>>> drivers/video/fbdev/hyperv_fb.c:1080:14: error: expected identifier or '('
> 1080 | screen_info.lfb_size = 0;
>|^
>drivers/video/fbdev/hyperv_fb.c:1081:3: error: must use 'struct' tag to
> refer to type 'screen_info'
> 1081 | screen_info.lfb_base = 0;
>| ^
>| struct
>drivers/video/fbdev/hyperv_fb.c:1081:14: error: expected identifier or '('
> 1081 | screen_info.lfb_base = 0;
>|^
>drivers/video/fbdev/hyperv_fb.c:1082:3: error: must use 'struct' tag to
> refer to type 'screen_info'
> 1082 | screen_info.orig_video_isVGA = 0;
>| ^
>| struct
> drivers/video/fbdev/hyperv_fb.c:1082:14: error: expected identifier or '('
> 1082 | screen_info.orig_video_isVGA = 0;
>|^
> 8 errors generated.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202307101042.rqehuauj-...@intel.com/
> Fixes: 8b0d13545b09 ("efi: Do not include from EFI
> header")
> Signed-off-by: Thomas Zimmermann
> Cc: "K. Y. Srinivasan" (supporter:Hyper-V/Azure CORE AND
> DRIVERS)
> Cc: Haiyang Zhang (supporter:Hyper-V/Azure CORE AND
> DRIVERS)
> Cc: Wei Liu (supporter:Hyper-V/Azure CORE AND DRIVERS)
> Cc: Dexuan Cui (supporter:Hyper-V/Azure CORE AND
> DRIVERS)
> Cc: Helge Deller (maintainer:FRAMEBUFFER LAYER)
> Cc: Javier Martinez Canillas
> Cc: Sui Jingfeng
> Cc: Ard Biesheuvel
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Arnd Bergmann
> Cc: linux-...@vger.kernel.org
> Cc: linux-hyp...@vger.kernel.org (open list:Hyper-V/Azure CORE AND DRIVERS)
> Cc: linux-fb...@vger.kernel.org (open list:FRAMEBUFFER LAYER)
> Cc: dri-devel@lists.freedesktop.org (open list:FRAMEBUFFER LAYER)
> ---
> drivers/video/fbdev/hyperv_fb.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH v2] drm/ast: report connection status on Display Port.
On 10/07/2023 08:57, Thomas Zimmermann wrote:
Hi Jocelyn
Am 06.07.23 um 11:58 schrieb Jocelyn Falempe:
Aspeed always report the display port as "connected", because it
doesn't set a .detect callback.
Fix this by providing the proper detect callback for astdp and dp501.
This also fixes the following regression:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the remote BMC resolution to 640x480,
which is inconvenient, and breaks the anaconda installer.
The formating of these paraghraphs looks off.
Ok
v2: Add .detect callback to the dp/dp501 connector (Jani Nikula)
Signed-off-by: Jocelyn Falempe
Maybe add Fixes with the patch that added the DP default resolution.
It's not really correct, but at least tells people to consider your patch.
I assume that you'll send another patch with the BMC connector?
Yes, this patch alone will break more systems than what it tries to fix.
---
drivers/gpu/drm/ast/ast_dp.c | 9
drivers/gpu/drm/ast/ast_dp501.c | 37 ++---
drivers/gpu/drm/ast/ast_drv.h | 2 ++
drivers/gpu/drm/ast/ast_mode.c | 24 +
4 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c
index 6dc1a09504e1..fbc154930fdf 100644
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -7,6 +7,15 @@
#include
#include "ast_drv.h"
+bool ast_astdp_is_connected(struct ast_device *ast)
+{
+ if (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
ASTDP_MCU_FW_EXECUTING) &&
+ ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDC,
ASTDP_LINK_SUCCESS) &&
+ ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDF, ASTDP_HPD))
The indention of those two lines is off.
You could also rewrite this as
if (!a)
return false;
if (!b)
return false;
if (!c)
return false;
return true;
ok
+ return true;
+ return false;
+}
+
int ast_astdp_read_edid(struct drm_device *dev, u8 *ediddata)
{
struct ast_device *ast = to_ast_device(dev);
diff --git a/drivers/gpu/drm/ast/ast_dp501.c
b/drivers/gpu/drm/ast/ast_dp501.c
index a5d285850ffb..f10d53b0c94f 100644
--- a/drivers/gpu/drm/ast/ast_dp501.c
+++ b/drivers/gpu/drm/ast/ast_dp501.c
@@ -272,11 +272,9 @@ static bool ast_launch_m68k(struct drm_device *dev)
return true;
}
-bool ast_dp501_read_edid(struct drm_device *dev, u8 *ediddata)
+bool ast_dp501_is_connected(struct ast_device *ast)
{
- struct ast_device *ast = to_ast_device(dev);
- u32 i, boot_address, offset, data;
- u32 *pEDIDidx;
+ u32 boot_address, offset, data;
if (ast->config_mode == ast_use_p2a) {
boot_address = get_fw_base(ast);
@@ -292,14 +290,6 @@ bool ast_dp501_read_edid(struct drm_device *dev,
u8 *ediddata)
data = ast_mindwm(ast, boot_address + offset);
if (!(data & AST_DP501_PNP_CONNECTED))
return false;
-
- /* Read EDID */
- offset = AST_DP501_EDID_DATA;
- for (i = 0; i < 128; i += 4) {
- data = ast_mindwm(ast, boot_address + offset + i);
- pEDIDidx = (u32 *)(ediddata + i);
- *pEDIDidx = data;
- }
} else {
if (!ast->dp501_fw_buf)
return false;
@@ -319,7 +309,30 @@ bool ast_dp501_read_edid(struct drm_device *dev,
u8 *ediddata)
data = readl(ast->dp501_fw_buf + offset);
if (!(data & AST_DP501_PNP_CONNECTED))
return false;
+ }
+ return true;
+}
+
+bool ast_dp501_read_edid(struct drm_device *dev, u8 *ediddata)
+{
+ struct ast_device *ast = to_ast_device(dev);
+ u32 i, boot_address, offset, data;
+ u32 *pEDIDidx;
+
+ if (!ast_dp501_is_connected(ast))
+ return false;
+
+ if (ast->config_mode == ast_use_p2a) {
+ boot_address = get_fw_base(ast);
+ /* Read EDID */
+ offset = AST_DP501_EDID_DATA;
+ for (i = 0; i < 128; i += 4) {
+ data = ast_mindwm(ast, boot_address + offset + i);
+ pEDIDidx = (u32 *)(ediddata + i);
+ *pEDIDidx = data;
+ }
+ } else {
/* Read EDID */
offset = AST_DP501_EDID_DATA;
for (i = 0; i < 128; i += 4) {
diff --git a/drivers/gpu/drm/ast/ast_drv.h
b/drivers/gpu/drm/ast/ast_drv.h
index 3f6e0c984523..99a24d779b9c 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -510,6 +510,7 @@ void ast_patch_ahb_2500(struct ast_device *ast);
/* ast dp501 */
void ast_set_dp501_video_output(struct drm_device *dev, u8 mode);
bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32 size);
+bool ast_dp501_is_connected(struct ast_device *ast);
bool ast_dp501_read_edid(struct drm_device *dev, u8 *ediddata);
u8 ast_get_dp501_max_clk(struc
Re: [PATCH v5] drm/vkms: Add support to 1D gamma LUT
On Sat, 8 Jul 2023 22:38:35 -0300 Arthur Grillo wrote: > Support a 1D gamma LUT with interpolation for each color channel on the > VKMS driver. Add a check for the LUT length by creating > vkms_atomic_check(). > > Enable VKMS to run the test igt@kms_plane@pixel-format. > > Tested with: > igt@kms_color@gamma > igt@kms_color@legacy-gamma > igt@kms_color@invalid-gamma-lut-sizes > > v2: > - Add interpolation between the values of the LUT (Simon Ser) > > v3: > - s/ratio/delta (Pekka) > - s/color_channel/channel_value (Pekka) > - s/lut_area/lut_channel > - Store the `drm_color_lut`, `lut_length`, and > `channel_value2index_ratio` inside a struct called `vkms_lut` > (Pekka) > - Pre-compute some constants values used through the LUT procedure > (Pekka) > - Change the switch statement to a cast to __u16* (Pekka) > - Make the apply_lut_to_channel_value return the computation result > (Pekka) > > v4: > - Add a comment explaining that `enum lut_area` depends on the > layout of `struct drm_color_lut` (Pekka) > - Remove unused variable (kernel test robot) > > v5: > - Mention that this will make it possible to run the test > igt@kms_plane@pixel-format (Maíra) > - s/had/has (Maíra) > > Signed-off-by: Arthur Grillo > Acked-by: Pekka Paalanen > Reviewed-by: Maíra Canal > --- > Maíra asked me to run a benchmark on some IGT tests: > > Each test ran 100 times. The result with 'X' are tests that were not able to > run because of the absence of gamma LUT. > > +--+---+-+---+ > | Test | No LUT | Unoptimized > LUT | Optimized LUT | > + > -+---+-+---+ > | igt@kms_rotation@primary-rotation-180| 174.298s |181.130s >| 178.800s| > + > -+---+-+---+ > | igt@kms_plane@pixel-format |X |1420.453s >| 1218.229s | > + > -+---+-+---+ > | igt@kms_plane@pixel-format-source-clamping |X |704.236s >| 612.318s| > + > -+---+-+---+ > | igt@kms_plane@plane-position-covered | 12.535s |12.864s >| 12.025s | > + > -+---+-+---+ > | igt@kms_plane@plane-position-hole| 11.752s |12.873s >| 11.202s | > + > -+---+-+---+ > | igt@kms_plane@plane-position-hole-dpms | 15.188s |15.238s >| 15.652s | > + > -+---+-+---+ > | igt@kms_plane@plane-panning-top-left | 10.797s |11.873s >| 11.041s | > + > -+---+-+---+ > | igt@kms_plane@plane-bottom-right | 10.764s |11.613s >| 10.053s | > + > -+---+-+---+ > | igt@kms_plane@plane-panning-bottom-right-suspend | 2011.344s |2009.410s >| 2011.496s | > + > -+---+-+---+ > | igt@kms_cursor_crc@cursor-onscreen-512x5112 | 359.209s |337.830s >| 308.168s| > + > -+---+-+---+ > | igt@kms_color@gamma |X |137.702s >| 118.139s| > + > -+---+-+---+ Hi Arthur, comparing "No LUT" with "Optimized LUT", both have essentially the same numbers where "No LUT" has a number to begin with. This is good, because it means that adding the new feature does not penalize cases where the new feature is not used. On the other hand, there is a small chance that these measurements could be dominated by something we do not expect, meaning that they are not measuring what we are interested in. The cases where "Optimized LUT" is faster than "No LUT" hint that there could be significant overhead and variance included in the measurements, because adding this feature should not make anything faster AFAICT. It's impossible to evalute the difference between "Unoptimized LUT" vs. "Optimized LUT" other than it is in the right direction at least, because we have no idea how much of the total time is spen
Re: [PATCH 1/5] dt-bindings: display: msm: dp-controller: document SM8250 compatible
On 09/07/2023 06:19, Dmitry Baryshkov wrote: > It looks like DP controlled on SM8250 is the same as DP controller on > SM8350. Use the SM8350 compatible as fallback for SM8250. > > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH v2] drm/bridge: anx7625: Drop device lock before drm_helper_hpd_irq_event()
The device lock is used to serialize the low level power sequencing
operations. Since drm_helper_hpd_irq_event() could end up calling
.atomic_enable, which also calls power sequencing functions through
runtime PM, this results in a real deadlock. This was observed on an
MT8192-based Chromebook's external display (with appropriate patches [1]
and DT changes applied).
Move the drm_helper_hpd_irq_event() call outside of the lock range. The
lock only needs to be held so that the device status can be read back.
This is the bare minimum change to avoid the deadlock. The lock could
be dropped completely and have pm_runtime_get_if_in_use() increase the
reference count, but this is not the same as pm_runtime_suspended().
Dropping the lock completely also causes the internal display of the
same device to not function correctly if the internal bridge's
interrupt line is added in the device tree. Both the internal and
external display of said device each use one anx7625 bridge.
[1]
https://lore.kernel.org/dri-devel/20230112042104.4107253-1-treapk...@chromium.org/
Fixes: 60487584a79a ("drm/bridge: anx7625: refactor power control to use
runtime PM framework")
Signed-off-by: Chen-Yu Tsai
---
Changes since v1:
- restore early return if event < 0
drivers/gpu/drm/bridge/analogix/anx7625.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 866d018f4bb1..e93eba89d5ee 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1593,18 +1593,20 @@ static void anx7625_work_func(struct work_struct *work)
mutex_lock(&ctx->lock);
- if (pm_runtime_suspended(&ctx->client->dev))
- goto unlock;
+ if (pm_runtime_suspended(&ctx->client->dev)) {
+ mutex_unlock(&ctx->lock);
+ return;
+ }
event = anx7625_hpd_change_detect(ctx);
+
+ mutex_unlock(&ctx->lock);
+
if (event < 0)
- goto unlock;
+ return;
if (ctx->bridge_attached)
drm_helper_hpd_irq_event(ctx->bridge.dev);
-
-unlock:
- mutex_unlock(&ctx->lock);
}
static irqreturn_t anx7625_intr_hpd_isr(int irq, void *data)
--
2.41.0.255.g8b1d071c50-goog
[PATCH] drm/radeon: ERROR: that open brace { should be on the previous line
Fix eleven occurrences of the checkpatch.pl error:
ERROR: that open brace { should be on the previous line
Signed-off-by: Ran Sun
---
drivers/gpu/drm/radeon/rv770.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rv770.c
b/drivers/gpu/drm/radeon/rv770.c
index a5ce59d4a485..9ce12fa3c356 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -136,7 +136,7 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev,
u32 vclk, u32 dclk)
return 0;
}
-static const u32 r7xx_golden_registers[] ={
+static const u32 r7xx_golden_registers[] = {
0x8d00, 0x, 0x0e0e0074,
0x8d04, 0x, 0x013a2b34,
0x9508, 0x, 0x0002,
@@ -151,7 +151,7 @@ static const u32 r7xx_golden_registers[] ={
0x7300, 0x, 0x001000f0
};
-static const u32 r7xx_golden_dyn_gpr_registers[] ={
+static const u32 r7xx_golden_dyn_gpr_registers[] = {
0x8db0, 0x, 0x98989898,
0x8db4, 0x, 0x98989898,
0x8db8, 0x, 0x98989898,
@@ -163,7 +163,7 @@ static const u32 r7xx_golden_dyn_gpr_registers[] ={
0x88c4, 0x, 0x0082
};
-static const u32 rv770_golden_registers[] ={
+static const u32 rv770_golden_registers[] = {
0x562c, 0x, 0,
0x3f90, 0x, 0,
0x9148, 0x, 0,
@@ -172,7 +172,7 @@ static const u32 rv770_golden_registers[] ={
0x9698, 0x1800, 0x1800
};
-static const u32 rv770ce_golden_registers[] ={
+static const u32 rv770ce_golden_registers[] = {
0x562c, 0x, 0,
0x3f90, 0x, 0x00cc,
0x9148, 0x, 0x00cc,
@@ -183,7 +183,7 @@ static const u32 rv770ce_golden_registers[] ={
0x9698, 0x1800, 0x1800
};
-static const u32 rv770_mgcg_init[] ={
+static const u32 rv770_mgcg_init[] = {
0x8bcc, 0x, 0x130300f9,
0x5448, 0x, 0x100,
0x55e4, 0x, 0x100,
@@ -340,7 +340,7 @@ static const u32 rv770_mgcg_init[] ={
0x92a4, 0x, 0x00080007
};
-static const u32 rv710_golden_registers[] ={
+static const u32 rv710_golden_registers[] = {
0x3f90, 0x00ff, 0x00fc,
0x9148, 0x00ff, 0x00fc,
0x3f94, 0x00ff, 0x00fc,
@@ -349,7 +349,7 @@ static const u32 rv710_golden_registers[] ={
0xa180, 0x, 0x3f3f
};
-static const u32 rv710_mgcg_init[] ={
+static const u32 rv710_mgcg_init[] = {
0x8bcc, 0x, 0x13030040,
0x5448, 0x, 0x100,
0x55e4, 0x, 0x100,
@@ -407,7 +407,7 @@ static const u32 rv710_mgcg_init[] ={
0x9150, 0x, 0x4d94
};
-static const u32 rv730_golden_registers[] ={
+static const u32 rv730_golden_registers[] = {
0x3f90, 0x00ff, 0x00f0,
0x9148, 0x00ff, 0x00f0,
0x3f94, 0x00ff, 0x00f0,
@@ -417,7 +417,7 @@ static const u32 rv730_golden_registers[] ={
0xa180, 0x, 0x3f3f
};
-static const u32 rv730_mgcg_init[] ={
+static const u32 rv730_mgcg_init[] = {
0x8bcc, 0x, 0x130300f9,
0x5448, 0x, 0x100,
0x55e4, 0x, 0x100,
@@ -538,7 +538,7 @@ static const u32 rv730_mgcg_init[] ={
0x92a4, 0x, 0x0005
};
-static const u32 rv740_golden_registers[] ={
+static const u32 rv740_golden_registers[] = {
0x88c4, 0x, 0x0082,
0x28a50, 0xfffc, 0x0004,
0x2650, 0x0004, 0,
@@ -574,7 +574,7 @@ static const u32 rv740_golden_registers[] ={
0x9698, 0x1800, 0x1800
};
-static const u32 rv740_mgcg_init[] ={
+static const u32 rv740_mgcg_init[] = {
0x8bcc, 0x, 0x13030100,
0x5448, 0x, 0x100,
0x55e4, 0x, 0x100,
Re: [PATCH] drm/nouveau/iccsense:
On Mon, Jul 10, 2023 at 03:06:47PM +0800, sunran...@208suo.com wrote:
> Fixed error: 'do not use assignment in if condition'
>
> This patch fixes error: 'do not use assignment in if condition'
> in drm/nouveau/iccsense
I guess this is checkpatch fix, right?
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> index 8f0ccd3664eb..2428f3d6e477 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> @@ -322,7 +322,8 @@ int
> nvkm_iccsense_new_(struct nvkm_device *device, enum nvkm_subdev_type type,
> int inst,
> struct nvkm_iccsense **iccsense)
> {
> -if (!(*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL)))
> +*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL);
> +if (!*iccsense)
> return -ENOMEM;
> INIT_LIST_HEAD(&(*iccsense)->sensors);
> INIT_LIST_HEAD(&(*iccsense)->rails);
Your patch is corrupted (tabs converted to spaces) because you're using
Roundcube. Please use git-send-mail(1) instead.
Thanks.
--
An old man doll... just what I always wanted! - Clara
signature.asc
Description: PGP signature
[PATCH] drm/client: Send hotplug event after registering a client
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receiving events from the DRM
core. The bug is present in the fbdev emulation of all drivers.
The fbdev emulation currently generates a hotplug event before
registering the client to the device. For each new output, the DRM
core sends an additional hotplug event to each registered client.
If the DRM core detects first output between sending the artificial
hotplug and registering the device, the output's hotplug event gets
lost. If this is the first output, the fbdev console display remains
dark. This has been observed with amdgpu and fbdev-generic.
Fix this by adding hotplug generation directly to the client's
register helper drm_client_register(). Registering the client and
receiving events are serialized by struct drm_device.clientlist_mutex.
So an output is either configured by the initial hotplug event, or
the client has already been registered.
The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper:
generic: Call drm_client_add() after setup is done"), in which adding
a client and receiving a hotplug event switched order. It was hidden,
as most hardware and drivers have at least on static output configured.
Other drivers didn't use the internal DRM client or still had struct
drm_mode_config_funcs.output_poll_changed set. That callback handled
hotplug events as well. After not setting the callback in amdgpu in
commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct
drm_driver.output_poll_changed"), amdgpu did not show a framebuffer
console if output events got lost. The bug got copy-pasted from
fbdev-generic into the other fbdev emulation.
Reported-by: Moritz Duge
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649
Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup
is done")
Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA
helpers")
Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel
client")
Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel
client")
Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation")
Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client")
Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel
client")
Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation")
Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client")
Signed-off-by: Thomas Zimmermann
Tested-by: Moritz Duge
Tested-by: Torsten Krah
Tested-by: Paul Schyska
Cc: Daniel Vetter
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Javier Martinez Canillas
Cc: Russell King
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Patrik Jakobsson
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Tomi Valkeinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.2+
---
drivers/gpu/drm/armada/armada_fbdev.c | 4
drivers/gpu/drm/drm_client.c | 21 +
drivers/gpu/drm/drm_fbdev_dma.c | 4
drivers/gpu/drm/drm_fbdev_generic.c | 4
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4
drivers/gpu/drm/gma500/fbdev.c| 4
drivers/gpu/drm/msm/msm_fbdev.c | 4
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4
drivers/gpu/drm/radeon/radeon_fbdev.c | 4
drivers/gpu/drm/tegra/fbdev.c | 4
10 files changed, 21 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 3943e89cc06c..e40a95e51785 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -209,10 +209,6 @@ void armada_fbdev_setup(struct drm_device *dev)
goto err_drm_client_init;
}
- ret = armada_fbdev_client_hotplug(&fbh->client);
- if (ret)
- drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
-
drm_client_register(&fbh->client);
return;
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index f6292ba0e6fc..037e36f2049c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -122,13 +122,34 @@ EXPORT_SYMBOL(drm_client_init);
* dr
[PATCH RESEND] drm/bridge: anx7625: Use common macros for DP power sequencing commands
The DRM DP code has macros for the DP power sequencing commands. Use
them in the anx7625 driver instead of raw numbers.
Fixes: 548b512e144f ("drm/bridge: anx7625: send DPCD command to downstream")
Fixes: 27f26359de9b ("drm/bridge: anx7625: Set downstream sink into normal
status")
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Nícolas F. R. A. Prado
---
Collected tags and rebased on v6.5-rc1.
drivers/gpu/drm/bridge/analogix/anx7625.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 8b985efdc086..9db3784cb554 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -931,8 +931,8 @@ static void anx7625_dp_start(struct anx7625_data *ctx)
dev_dbg(dev, "set downstream sink into normal\n");
/* Downstream sink enter into normal mode */
- data = 1;
- ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, &data);
+ data = DP_SET_POWER_D0;
+ ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, DP_SET_POWER, 1,
&data);
if (ret < 0)
dev_err(dev, "IO error : set sink into normal mode fail\n");
@@ -971,8 +971,8 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
dev_dbg(dev, "notify downstream enter into standby\n");
/* Downstream monitor enter into standby mode */
- data = 2;
- ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, &data);
+ data = DP_SET_POWER_D3;
+ ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, DP_SET_POWER, 1,
&data);
if (ret < 0)
DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
--
2.41.0.255.g8b1d071c50-goog
[PATCH] drm/bridge: anx7625: Use common macros for HDCP capabilities
The DRM DP code has macros for the DP HDCP capabilities. Use them in the
anx7625 driver instead of raw numbers.
Fixes: cd1637c7e480 ("drm/bridge: anx7625: add HDCP support")
Suggested-by: Nícolas F. R. A. Prado
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 9db3784cb554..866d018f4bb1 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -872,11 +872,11 @@ static int anx7625_hdcp_enable(struct anx7625_data *ctx)
}
/* Read downstream capability */
- ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, &bcap);
+ ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_READ, DP_AUX_HDCP_BCAPS, 1,
&bcap);
if (ret < 0)
return ret;
- if (!(bcap & 0x01)) {
+ if (!(bcap & DP_BCAPS_HDCP_CAPABLE)) {
pr_warn("downstream not support HDCP 1.4, cap(%x).\n", bcap);
return 0;
}
--
2.41.0.255.g8b1d071c50-goog
Re: [Intel-gfx] [PATCH] drm/i915: Fix one wrong caching mode enum usage
On 07/07/2023 14:23, Upadhyay, Tejas wrote:
-Original Message-
From: Intel-gfx On Behalf Of
Tvrtko Ursulin
Sent: Friday, July 7, 2023 6:25 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: Fix one wrong caching mode enum
usage
From: Tvrtko Ursulin
Commit a4d86249c773 ("drm/i915/gt: Provide a utility to create a scratch
buffer") mistakenly passed in uapi I915_CACHING_CACHED as argument to
i915_gem_object_set_cache_coherency(), which actually takes internal enum
i915_cache_level.
No functional issue since the value matches I915_CACHE_LLC (1 == 1), which
is the intended caching mode, but lets clean it up nevertheless.
Signed-off-by: Tvrtko Ursulin
Fixes: a4d86249c773 ("drm/i915/gt: Provide a utility to create a scratch
buffer")
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 126269a0d728..065099362a98 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -676,7 +676,7 @@ __vm_create_scratch_for_read(struct
i915_address_space *vm, unsigned long size)
if (IS_ERR(obj))
return ERR_CAST(obj);
- i915_gem_object_set_cache_coherency(obj,
I915_CACHING_CACHED);
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
Yes.
Reviewed-by: Tejas Upadhyay
Pushed, thanks for the review!
Regards,
Tvrtko
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma)) {
--
2.39.2
Re: [Intel-gfx] [PATCH] drm/i915: Remove dead code from gen8_pte_encode
On 07/07/2023 15:17, Rodrigo Vivi wrote:
On Fri, Jul 07, 2023 at 01:46:44PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
added a dedicated gen12_pte_encode but forgot to remove the Gen12 specific
bit from gen8_pte_encode.
Signed-off-by: Tvrtko Ursulin
Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
Cc: Fei Yang
Cc: Andi Shyti
Cc: Matt Roper
Reviewed-by: Rodrigo Vivi
Pushed, thanks for the reviews!
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index f948d33e5ec5..c8568e5d1147 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -37,9 +37,6 @@ static u64 gen8_pte_encode(dma_addr_t addr,
if (unlikely(flags & PTE_READ_ONLY))
pte &= ~GEN8_PAGE_RW;
- if (flags & PTE_LM)
- pte |= GEN12_PPGTT_PTE_LM;
-
/*
* For pre-gen12 platforms pat_index is the same as enum
* i915_cache_level, so the switch-case here is still valid.
--
2.39.2
Re: [PATCH v2 2/2] drm/mediatek: Fix iommu fault during crtc enabling
[PATCH v3 0/2] Fix OVL iommu fault in cursor plane
Fix some IGT tests fail at iommu fault in OVL cursor plane. Jason-JH.Lin (2): drm/mediatek: Fix iommu fault by swapping FBs after updating plane state drm/mediatek: Fix iommu fault during crtc enabling drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++ drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) -- 2.18.0
[PATCH v3 1/2] drm/mediatek: Fix iommu fault by swapping FBs after updating plane state
According to the comment in drm_atomic_helper_async_commit(),
we should make sure FBs have been swapped, so that cleanups in the
new_state performs a cleanup in the old FB.
So we should move swapping FBs after calling mtk_plane_update_new_state(),
to avoid using the old FB which could be freed.
Fixes: 1a64a7aff8da ("drm/mediatek: Fix cursor plane no update")
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 31f9420aff6f..b1a918ffe457 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -210,9 +210,9 @@ static void mtk_plane_atomic_async_update(struct drm_plane
*plane,
plane->state->src_y = new_state->src_y;
plane->state->src_h = new_state->src_h;
plane->state->src_w = new_state->src_w;
- swap(plane->state->fb, new_state->fb);
mtk_plane_update_new_state(new_state, new_plane_state);
+ swap(plane->state->fb, new_state->fb);
wmb(); /* Make sure the above parameters are set before update */
new_plane_state->pending.async_dirty = true;
mtk_drm_crtc_async_update(new_state->crtc, plane, state);
--
2.18.0
[PATCH v3 2/2] drm/mediatek: Fix iommu fault during crtc enabling
OVL layer should not be enabled before crtc is enabled.
The plane_state of drm_atomic_state is not sync to
the plane_state stored in mtk_crtc during crtc enabling,
so just set all planes to disabled.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index d40142842f85..51d10e65004e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -410,6 +410,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
unsigned int local_layer;
plane_state = to_mtk_plane_state(plane->state);
+
+ /* should not enable layer before crtc enabled */
+ plane_state->pending.enable = false;
comp = mtk_drm_ddp_comp_for_plane(crtc, plane, &local_layer);
if (comp)
mtk_ddp_comp_layer_config(comp, local_layer,
--
2.18.0
Re: [PATCH] drm/i915: Remove dead code from gen8_pte_encode
Hi Tvrtko,
> Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> added a dedicated gen12_pte_encode but forgot to remove the Gen12 specific
> bit from gen8_pte_encode.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> Cc: Fei Yang
> Cc: Andi Shyti
> Cc: Matt Roper
Reviewed-by: Andi Shyti
Andi
Re: [PATCH v3] drm/bridge: tc358767: Use devm_clk_get_enabled() helper
On Sat, 8 Jul 2023 08:05:35 +0200, Christophe JAILLET wrote: > The devm_clk_get_enabled() helper: >- calls devm_clk_get() >- calls clk_prepare_enable() and registers what is needed in order to > call clk_disable_unprepare() when needed, as a managed resource. > > This simplifies the code and avoids the need of a dedicated function used > with devm_add_action_or_reset(). > > [...] Applied, thanks! [1/1] drm/bridge: tc358767: Use devm_clk_get_enabled() helper https://cgit.freedesktop.org/drm/drm-misc/commit/?id=70d3c92d852f Rob
Re: [PATCH] fbdev: imxfb: Convert to devm_platform_ioremap_resource()
On 7/10/23 09:41, Geert Uytterhoeven wrote:
Hi Yangtao,
On Mon, Jul 10, 2023 at 9:25 AM Yangtao Li wrote:
On 2023/7/10 15:10, Geert Uytterhoeven wrote:
[你通常不会收到来自 ge...@linux-m68k.org 的电子邮件。请访问
https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
On Tue, Jul 4, 2023 at 11:38 AM Yangtao Li wrote:
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li
Thanks for your patch, which is now commit c1cd7a7a231a26c6 ("fbdev:
imxfb: Convert to devm_platform_ioremap_resource()") in fbdev/for-next
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -868,7 +868,6 @@ static int imxfb_probe(struct platform_device *pdev)
struct imxfb_info *fbi;
struct lcd_device *lcd;
struct fb_info *info;
- struct resource *res;
struct imx_fb_videomode *m;
const struct of_device_id *of_id;
struct device_node *display_np;
@@ -885,10 +884,6 @@ static int imxfb_probe(struct platform_device *pdev)
if (of_id)
pdev->id_entry = of_id->data;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
-
info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
if (!info)
return -ENOMEM;
@@ -970,7 +965,7 @@ static int imxfb_probe(struct platform_device *pdev)
goto failed_getclock;
}
- fbi->regs = devm_ioremap_resource(&pdev->dev, res);
+ fbi->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(fbi->regs)) {
ret = PTR_ERR(fbi->regs);
goto failed_ioremap;
@@ -1043,7 +1038,6 @@ static int imxfb_probe(struct platform_device *pdev)
failed_map:
failed_ioremap:
failed_getclock:
- release_mem_region(res->start, resource_size(res));
This part is not directly related, but a bug fix for commit
b083c22d51148f3d ("video: fbdev: imxfb: Convert request_mem_region +
ioremap to devm_ioremap_resource") in v6.0.
IIUC, split this patch into two, remove release_mem_region in one and
mark it as Fixes: b083c22d51148f3d ("video: fbdev: imxfb: Convert
request_mem_region +
ioremap to devm_ioremap_resource")?
Exactly. But as Helge has already applied this patch to his tree, we have
to check with him if this is still feasible...
Sure. Just send them to the list and I apply those patches instead.
Thanks!
Helge
Re: [PATCH] drm/client: Send hotplug event after registering a client
Thomas Zimmermann writes:
Hello Thomas,
> Generate a hotplug event after registering a client to allow the
> client to configure its display. Remove the hotplug calls from the
> existing clients for fbdev emulation. This change fixes a concurrency
> bug between registering a client and receiving events from the DRM
> core. The bug is present in the fbdev emulation of all drivers.
>
> The fbdev emulation currently generates a hotplug event before
> registering the client to the device. For each new output, the DRM
> core sends an additional hotplug event to each registered client.
>
> If the DRM core detects first output between sending the artificial
> hotplug and registering the device, the output's hotplug event gets
> lost. If this is the first output, the fbdev console display remains
> dark. This has been observed with amdgpu and fbdev-generic.
>
> Fix this by adding hotplug generation directly to the client's
> register helper drm_client_register(). Registering the client and
> receiving events are serialized by struct drm_device.clientlist_mutex.
> So an output is either configured by the initial hotplug event, or
> the client has already been registered.
>
> The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper:
> generic: Call drm_client_add() after setup is done"), in which adding
> a client and receiving a hotplug event switched order. It was hidden,
> as most hardware and drivers have at least on static output configured.
> Other drivers didn't use the internal DRM client or still had struct
> drm_mode_config_funcs.output_poll_changed set. That callback handled
> hotplug events as well. After not setting the callback in amdgpu in
> commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct
> drm_driver.output_poll_changed"), amdgpu did not show a framebuffer
> console if output events got lost. The bug got copy-pasted from
> fbdev-generic into the other fbdev emulation.
>
> Reported-by: Moritz Duge
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649
Aren't you missing a Fixes: for 0e3172bac3f4 too? Since that's the commit
that unmasked the bug for amdgpu, IMO that is the most important to list.
> Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after
> setup is done")
> Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into
> separate source file")
> Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA
> helpers")
> Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel
> client")
> Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel
> client")
> Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation")
> Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client")
> Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel
> client")
> Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation")
> Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel
> client")
> Signed-off-by: Thomas Zimmermann
> Tested-by: Moritz Duge
> Tested-by: Torsten Krah
> Tested-by: Paul Schyska
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Noralf Trønnes
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Javier Martinez Canillas
> Cc: Russell King
> Cc: Inki Dae
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Krzysztof Kozlowski
> Cc: Patrik Jakobsson
> Cc: Rob Clark
> Cc: Abhinav Kumar
> Cc: Dmitry Baryshkov
> Cc: Tomi Valkeinen
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: Thierry Reding
> Cc: Mikko Perttunen
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: # v5.2+
While it's true that the but was introduced by commit 6e3f17ee73f7 and that
landed in v5.2, I wonder if this patch could even be applied to such olders
Linux versions. Probably in practice it would be at most backported to
v6.2, which is the release that exposed the bug for the amdgpu driver.
Your explanation makes sense to me and the patch looks good.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH] drm/client: Send hotplug event after registering a client
Hi
Am 10.07.23 um 11:52 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receiving events from the DRM
core. The bug is present in the fbdev emulation of all drivers.
The fbdev emulation currently generates a hotplug event before
registering the client to the device. For each new output, the DRM
core sends an additional hotplug event to each registered client.
If the DRM core detects first output between sending the artificial
hotplug and registering the device, the output's hotplug event gets
lost. If this is the first output, the fbdev console display remains
dark. This has been observed with amdgpu and fbdev-generic.
Fix this by adding hotplug generation directly to the client's
register helper drm_client_register(). Registering the client and
receiving events are serialized by struct drm_device.clientlist_mutex.
So an output is either configured by the initial hotplug event, or
the client has already been registered.
The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper:
generic: Call drm_client_add() after setup is done"), in which adding
a client and receiving a hotplug event switched order. It was hidden,
as most hardware and drivers have at least on static output configured.
Other drivers didn't use the internal DRM client or still had struct
drm_mode_config_funcs.output_poll_changed set. That callback handled
hotplug events as well. After not setting the callback in amdgpu in
commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct
drm_driver.output_poll_changed"), amdgpu did not show a framebuffer
console if output events got lost. The bug got copy-pasted from
fbdev-generic into the other fbdev emulation.
Reported-by: Moritz Duge
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649
Aren't you missing a Fixes: for 0e3172bac3f4 too? Since that's the commit
that unmasked the bug for amdgpu, IMO that is the most important to list.
Well, OK.
Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is
done")
Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA
helpers")
Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel
client")
Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel
client")
Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation")
Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client")
Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel
client")
Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation")
Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client")
Signed-off-by: Thomas Zimmermann
Tested-by: Moritz Duge
Tested-by: Torsten Krah
Tested-by: Paul Schyska
Cc: Daniel Vetter
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Javier Martinez Canillas
Cc: Russell King
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Patrik Jakobsson
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Tomi Valkeinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.2+
While it's true that the but was introduced by commit 6e3f17ee73f7 and that
landed in v5.2, I wonder if this patch could even be applied to such olders
Linux versions. Probably in practice it would be at most backported to
v6.2, which is the release that exposed the bug for the amdgpu driver.
No idea. The fix looks simple enough, but a lot has changed in the
surrounding code.
Best regards
Thomas
Your explanation makes sense to me and the patch looks good.
Reviewed-by: Javier Martinez Canillas
--
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] drm/nouveau/iccsense: do not use assignment in if condition
checkpatch.pl does not like assignment in if condition
Signed-off-by: Ran Sun
---
drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
index 8f0ccd3664eb..2428f3d6e477 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
@@ -322,7 +322,8 @@ int
nvkm_iccsense_new_(struct nvkm_device *device, enum nvkm_subdev_type
type, int inst,
struct nvkm_iccsense **iccsense)
{
-if (!(*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL)))
+*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL);
+if (!*iccsense)
return -ENOMEM;
INIT_LIST_HEAD(&(*iccsense)->sensors);
INIT_LIST_HEAD(&(*iccsense)->rails);
[PATCH] drm/radeon: ERROR: "(foo*)" should be "(foo *)"
Fix five occurrences of the checkpatch.pl error:
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Ran Sun
---
drivers/gpu/drm/radeon/radeon_kms.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index e0214cf1b43b..a16590c6247f 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -444,7 +444,7 @@ int radeon_info_ioctl(struct drm_device *dev, void
*data, struct drm_file *filp)
DRM_DEBUG_KMS("timestamp is r6xx+ only!\n");
return -EINVAL;
}
-value = (uint32_t*)&value64;
+value = (uint32_t *)&value64;
value_size = sizeof(uint64_t);
value64 = radeon_get_gpu_clock_counter(rdev);
break;
@@ -543,18 +543,18 @@ int radeon_info_ioctl(struct drm_device *dev, void
*data, struct drm_file *filp)
*value = rdev->vce.fb_version;
break;
case RADEON_INFO_NUM_BYTES_MOVED:
-value = (uint32_t*)&value64;
+value = (uint32_t *)&value64;
value_size = sizeof(uint64_t);
value64 = atomic64_read(&rdev->num_bytes_moved);
break;
case RADEON_INFO_VRAM_USAGE:
-value = (uint32_t*)&value64;
+value = (uint32_t *)&value64;
value_size = sizeof(uint64_t);
man = ttm_manager_type(&rdev->mman.bdev, TTM_PL_VRAM);
value64 = ttm_resource_manager_usage(man);
break;
case RADEON_INFO_GTT_USAGE:
-value = (uint32_t*)&value64;
+value = (uint32_t *)&value64;
value_size = sizeof(uint64_t);
man = ttm_manager_type(&rdev->mman.bdev, TTM_PL_TT);
value64 = ttm_resource_manager_usage(man);
@@ -614,7 +614,7 @@ int radeon_info_ioctl(struct drm_device *dev, void
*data, struct drm_file *filp)
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
}
-if (copy_to_user(value_ptr, (char*)value, value_size)) {
+if (copy_to_user(value_ptr, (char *)value, value_size)) {
DRM_ERROR("copy_to_user %s:%u\n", __func__, __LINE__);
return -EFAULT;
}
Re: [PATCH v3 2/2] drm/mediatek: Fix iommu fault during crtc enabling
Il 10/07/23 11:32, Jason-JH.Lin ha scritto:
OVL layer should not be enabled before crtc is enabled.
The plane_state of drm_atomic_state is not sync to
the plane_state stored in mtk_crtc during crtc enabling,
so just set all planes to disabled.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index d40142842f85..51d10e65004e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -410,6 +410,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
unsigned int local_layer;
plane_state = to_mtk_plane_state(plane->state);
+
+ /* should not enable layer before crtc enabled */
+ plane_state->pending.enable = false;
comp = mtk_drm_ddp_comp_for_plane(crtc, plane, &local_layer);
if (comp)
mtk_ddp_comp_layer_config(comp, local_layer,
[PATCH] drm/loongson: Fix two warnings because of passing wrong type
When accessing I/O memory, we should pass '__iomem *' type instead of 'void *' simply, otherwise sparse tests will complain. After applied this patch, the following two sparse warnings got fixed. 1) drivers/gpu/drm/loongson/lsdc_benchmark.c:27:35: sparse: expected void volatile [noderef] __iomem * sparse: got void *kptr 2) drivers/gpu/drm/loongson/lsdc_benchmark.c:42:51: sparse: expected void const volatile [noderef] __iomem * sparse: got void *kptr Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202307100243.v3hv6aes-...@intel.com/ Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/loongson/lsdc_benchmark.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/loongson/lsdc_benchmark.c b/drivers/gpu/drm/loongson/lsdc_benchmark.c index b088646a2ff9..36e352820bdb 100644 --- a/drivers/gpu/drm/loongson/lsdc_benchmark.c +++ b/drivers/gpu/drm/loongson/lsdc_benchmark.c @@ -24,7 +24,7 @@ static void lsdc_copy_gtt_to_vram_cpu(struct lsdc_bo *src_bo, lsdc_bo_kmap(dst_bo); while (n--) - memcpy_toio(dst_bo->kptr, src_bo->kptr, size); + memcpy_toio((void __iomem *)dst_bo->kptr, src_bo->kptr, size); lsdc_bo_kunmap(src_bo); lsdc_bo_kunmap(dst_bo); @@ -39,7 +39,7 @@ static void lsdc_copy_vram_to_gtt_cpu(struct lsdc_bo *src_bo, lsdc_bo_kmap(dst_bo); while (n--) - memcpy_fromio(dst_bo->kptr, src_bo->kptr, size); + memcpy_fromio(dst_bo->kptr, (void __iomem *)src_bo->kptr, size); lsdc_bo_kunmap(src_bo); lsdc_bo_kunmap(dst_bo); -- 2.34.1
[PATCH] drm/loongson: Remove a useless check in cursor_plane_atomic_async_check()
Because smatch warnings:
drivers/gpu/drm/loongson/lsdc_plane.c:199
lsdc_cursor_plane_atomic_async_check()
warn: variable dereferenced before check 'state' (see line 180)
vim +/state +199 drivers/gpu/drm/loongson/lsdc_plane.c
174 static int
lsdc_cursor_plane_atomic_async_check(struct drm_plane *plane,
175 struct drm_atomic_state *state)
176 {
177 struct drm_plane_state *new_state;
178 struct drm_crtc_state *crtc_state;
179
180 new_state = drm_atomic_get_new_plane_state(state, plane);
^
state is dereferenced inside this function
181
182 if (!plane->state || !plane->state->fb) {
183 drm_dbg(plane->dev, "%s: state is NULL\n", plane->name);
184 return -EINVAL;
185 }
186
187 if (new_state->crtc_w != new_state->crtc_h) {
188 drm_dbg(plane->dev, "unsupported cursor size: %ux%u\n",
189 new_state->crtc_w, new_state->crtc_h);
190 return -EINVAL;
191 }
192
193 if (new_state->crtc_w != 64 && new_state->crtc_w != 32) {
194 drm_dbg(plane->dev, "unsupported cursor size: %ux%u\n",
195 new_state->crtc_w, new_state->crtc_h);
196 return -EINVAL;
197 }
198
199 if (state) {
^
Checked too late!
Reported-by: Dan Carpenter
Closes: https://lore.kernel.org/r/202307100423.rv7d05uq-...@intel.com/
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/loongson/lsdc_plane.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/loongson/lsdc_plane.c
b/drivers/gpu/drm/loongson/lsdc_plane.c
index 2ab3db982aa3..0d5094633222 100644
--- a/drivers/gpu/drm/loongson/lsdc_plane.c
+++ b/drivers/gpu/drm/loongson/lsdc_plane.c
@@ -196,13 +196,7 @@ static int lsdc_cursor_plane_atomic_async_check(struct
drm_plane *plane,
return -EINVAL;
}
- if (state) {
- crtc_state = drm_atomic_get_existing_crtc_state(state,
new_state->crtc);
- } else {
- crtc_state = plane->crtc->state;
- drm_dbg(plane->dev, "%s: atomic state is NULL\n", plane->name);
- }
-
+ crtc_state = drm_atomic_get_existing_crtc_state(state, new_state->crtc);
if (!crtc_state->active)
return -EINVAL;
--
2.34.1
Re: [PATCH] drm/loongson: Fix two warnings because of passing wrong type
On Mon, 10 Jul 2023, Sui Jingfeng wrote: > When accessing I/O memory, we should pass '__iomem *' type instead of > 'void *' simply, otherwise sparse tests will complain. After applied > this patch, the following two sparse warnings got fixed. Usually the commit message should explain why it's okay to cast away the warning. Because realistically this doesn't "fix" the warning, this merely hides it. BR, Jani. > > 1) drivers/gpu/drm/loongson/lsdc_benchmark.c:27:35: >sparse: expected void volatile [noderef] __iomem * >sparse: got void *kptr > > 2) drivers/gpu/drm/loongson/lsdc_benchmark.c:42:51: >sparse: expected void const volatile [noderef] __iomem * >sparse: got void *kptr > > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202307100243.v3hv6aes-...@intel.com/ > Signed-off-by: Sui Jingfeng > --- > drivers/gpu/drm/loongson/lsdc_benchmark.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/loongson/lsdc_benchmark.c > b/drivers/gpu/drm/loongson/lsdc_benchmark.c > index b088646a2ff9..36e352820bdb 100644 > --- a/drivers/gpu/drm/loongson/lsdc_benchmark.c > +++ b/drivers/gpu/drm/loongson/lsdc_benchmark.c > @@ -24,7 +24,7 @@ static void lsdc_copy_gtt_to_vram_cpu(struct lsdc_bo > *src_bo, > lsdc_bo_kmap(dst_bo); > > while (n--) > - memcpy_toio(dst_bo->kptr, src_bo->kptr, size); > + memcpy_toio((void __iomem *)dst_bo->kptr, src_bo->kptr, size); > > lsdc_bo_kunmap(src_bo); > lsdc_bo_kunmap(dst_bo); > @@ -39,7 +39,7 @@ static void lsdc_copy_vram_to_gtt_cpu(struct lsdc_bo > *src_bo, > lsdc_bo_kmap(dst_bo); > > while (n--) > - memcpy_fromio(dst_bo->kptr, src_bo->kptr, size); > + memcpy_fromio(dst_bo->kptr, (void __iomem *)src_bo->kptr, size); > > lsdc_bo_kunmap(src_bo); > lsdc_bo_kunmap(dst_bo); -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH RESEND] drm/bridge: anx7625: Use common macros for DP power sequencing commands
On Mon, 10 Jul 2023, Chen-Yu Tsai wrote:
> The DRM DP code has macros for the DP power sequencing commands. Use
> them in the anx7625 driver instead of raw numbers.
>
> Fixes: 548b512e144f ("drm/bridge: anx7625: send DPCD command to downstream")
> Fixes: 27f26359de9b ("drm/bridge: anx7625: Set downstream sink into normal
> status")
> Signed-off-by: Chen-Yu Tsai
> Reviewed-by: Nícolas F. R. A. Prado
> ---
> Collected tags and rebased on v6.5-rc1.
>
> drivers/gpu/drm/bridge/analogix/anx7625.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 8b985efdc086..9db3784cb554 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -931,8 +931,8 @@ static void anx7625_dp_start(struct anx7625_data *ctx)
>
> dev_dbg(dev, "set downstream sink into normal\n");
> /* Downstream sink enter into normal mode */
> - data = 1;
> - ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, &data);
> + data = DP_SET_POWER_D0;
> + ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, DP_SET_POWER, 1,
> &data);
So you have code to implement the drm dp aux abstractions, why aren't
you using drm_dp_dpcd_writeb() and friends here?
BR,
Jani.
> if (ret < 0)
> dev_err(dev, "IO error : set sink into normal mode fail\n");
>
> @@ -971,8 +971,8 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
>
> dev_dbg(dev, "notify downstream enter into standby\n");
> /* Downstream monitor enter into standby mode */
> - data = 2;
> - ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, &data);
> + data = DP_SET_POWER_D3;
> + ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, DP_SET_POWER, 1,
> &data);
> if (ret < 0)
> DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v3] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset
Hi,
On Thu, Jun 15, 2023 at 02:15:42PM -0700, Zhanjun Dong wrote:
> This attempts to avoid circular locking dependency between flush delayed work
> and intel_gt_reset.
> Switched from cancel_delayed_work_sync to cancel_delayed_work, the non-sync
> version for reset path, it is safe as the worker has the trylock code to
> handle the lock; Meanwhile keep the sync version for park/fini to ensure the
> worker is not still running during suspend or shutdown.
>
> WARNING: possible circular locking dependency detected
> 6.4.0-rc1-drmtip_1340-g31e3463b0edb+ #1 Not tainted
> --
> kms_pipe_crc_ba/6415 is trying to acquire lock:
> 88813e6cc640
> ((work_completion)(&(&guc->timestamp.work)->work)){+.+.}-{0:0}, at:
> __flush_work+0x42/0x530
>
> but task is already holding lock:
> 88813e6cce90 (>->reset.mutex){+.+.}-{3:3}, at:
> intel_gt_reset+0x19e/0x470 [i915]
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (>->reset.mutex){+.+.}-{3:3}:
> lock_acquire+0xd8/0x2d0
> i915_gem_shrinker_taints_mutex+0x31/0x50 [i915]
> intel_gt_init_reset+0x65/0x80 [i915]
> intel_gt_common_init_early+0xe1/0x170 [i915]
> intel_root_gt_init_early+0x48/0x60 [i915]
> i915_driver_probe+0x671/0xcb0 [i915]
> i915_pci_probe+0xdc/0x210 [i915]
> pci_device_probe+0x95/0x120
> really_probe+0x164/0x3c0
> __driver_probe_device+0x73/0x160
> driver_probe_device+0x19/0xa0
> __driver_attach+0xb6/0x180
> bus_for_each_dev+0x77/0xd0
> bus_add_driver+0x114/0x210
> driver_register+0x5b/0x110
> __pfx_vgem_open+0x3/0x10 [vgem]
> do_one_initcall+0x57/0x270
> do_init_module+0x5f/0x220
> load_module+0x1ca4/0x1f00
> __do_sys_finit_module+0xb4/0x130
> do_syscall_64+0x3c/0x90
> entry_SYSCALL_64_after_hwframe+0x72/0xdc
>
> -> #2 (fs_reclaim){+.+.}-{0:0}:
> lock_acquire+0xd8/0x2d0
> fs_reclaim_acquire+0xac/0xe0
> kmem_cache_alloc+0x32/0x260
> i915_vma_instance+0xb2/0xc60 [i915]
> i915_gem_object_ggtt_pin_ww+0x175/0x370 [i915]
> vm_fault_gtt+0x22d/0xf60 [i915]
> __do_fault+0x2f/0x1d0
> do_pte_missing+0x4a/0xd20
> __handle_mm_fault+0x5b0/0x790
> handle_mm_fault+0xa2/0x230
> do_user_addr_fault+0x3ea/0xa10
> exc_page_fault+0x68/0x1a0
> asm_exc_page_fault+0x26/0x30
>
> -> #1 (>->reset.backoff_srcu){}-{0:0}:
> lock_acquire+0xd8/0x2d0
> _intel_gt_reset_lock+0x57/0x330 [i915]
> guc_timestamp_ping+0x35/0x130 [i915]
> process_one_work+0x250/0x510
> worker_thread+0x4f/0x3a0
> kthread+0xff/0x130
> ret_from_fork+0x29/0x50
>
> -> #0 ((work_completion)(&(&guc->timestamp.work)->work)){+.+.}-{0:0}:
> check_prev_add+0x90/0xc60
> __lock_acquire+0x1998/0x2590
> lock_acquire+0xd8/0x2d0
> __flush_work+0x74/0x530
> __cancel_work_timer+0x14f/0x1f0
> intel_guc_submission_reset_prepare+0x81/0x4b0 [i915]
> intel_uc_reset_prepare+0x9c/0x120 [i915]
> reset_prepare+0x21/0x60 [i915]
> intel_gt_reset+0x1dd/0x470 [i915]
> intel_gt_reset_global+0xfb/0x170 [i915]
> intel_gt_handle_error+0x368/0x420 [i915]
> intel_gt_debugfs_reset_store+0x5c/0xc0 [i915]
> i915_wedged_set+0x29/0x40 [i915]
> simple_attr_write_xsigned.constprop.0+0xb4/0x110
> full_proxy_write+0x52/0x80
> vfs_write+0xc5/0x4f0
> ksys_write+0x64/0xe0
> do_syscall_64+0x3c/0x90
> entry_SYSCALL_64_after_hwframe+0x72/0xdc
>
> other info that might help us debug this:
> Chain exists of:
> (work_completion)(&(&guc->timestamp.work)->work) --> fs_reclaim -->
> >->reset.mutex
> Possible unsafe locking scenario:
> CPU0CPU1
>
>lock(>->reset.mutex);
> lock(fs_reclaim);
> lock(>->reset.mutex);
>lock((work_completion)(&(&guc->timestamp.work)->work));
>
> *** DEADLOCK ***
> 3 locks held by kms_pipe_crc_ba/6415:
> #0: 888101541430 (sb_writers#15){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
> #1: 888136c7eab8 (&attr->mutex){+.+.}-{3:3}, at:
> simple_attr_write_xsigned.constprop.0+0x47/0x110
> #2: 88813e6cce90 (>->reset.mutex){+.+.}-{3:3}, at:
> intel_gt_reset+0x19e/0x470 [i915]
>
> v2: Add sync flag to guc_cancel_busyness_worker to ensure reset path calls
> asynchronous cancel.
> v3: Add sync flag to intel_guc_submission_disable to ensure reset path calls
> asynchronous cancel.
>
> Signed-off-by: Zhanjun Dong
Acked-by: Andi Shyti
Any further comment on this?
Andi
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 ++---
> .../gpu/drm/i915/gt/uc/intel_
Re: [PATCH] drm/loongson: Fix two warnings because of passing wrong type
Hi
Am 10.07.23 um 12:09 schrieb Sui Jingfeng:
When accessing I/O memory, we should pass '__iomem *' type instead of
'void *' simply, otherwise sparse tests will complain. After applied
this patch, the following two sparse warnings got fixed.
1) drivers/gpu/drm/loongson/lsdc_benchmark.c:27:35:
sparse: expected void volatile [noderef] __iomem *
sparse: got void *kptr
2) drivers/gpu/drm/loongson/lsdc_benchmark.c:42:51:
sparse: expected void const volatile [noderef] __iomem *
sparse: got void *kptr
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202307100243.v3hv6aes-...@intel.com/
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/loongson/lsdc_benchmark.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/loongson/lsdc_benchmark.c
b/drivers/gpu/drm/loongson/lsdc_benchmark.c
index b088646a2ff9..36e352820bdb 100644
--- a/drivers/gpu/drm/loongson/lsdc_benchmark.c
+++ b/drivers/gpu/drm/loongson/lsdc_benchmark.c
@@ -24,7 +24,7 @@ static void lsdc_copy_gtt_to_vram_cpu(struct lsdc_bo *src_bo,
lsdc_bo_kmap(dst_bo);
while (n--)
- memcpy_toio(dst_bo->kptr, src_bo->kptr, size);
+ memcpy_toio((void __iomem *)dst_bo->kptr, src_bo->kptr, size);
If this is I/O memory, better add the __iomem qualifier to dst_bo->kptr
rather than casting here. If if can be both, you could use an unnamed
union like this:
struct lscd_bo {
union {
void __iomem *kptr_iomem;
void *kptr;
};
};
Best regards
Thomas
lsdc_bo_kunmap(src_bo);
lsdc_bo_kunmap(dst_bo);
@@ -39,7 +39,7 @@ static void lsdc_copy_vram_to_gtt_cpu(struct lsdc_bo *src_bo,
lsdc_bo_kmap(dst_bo);
while (n--)
- memcpy_fromio(dst_bo->kptr, src_bo->kptr, size);
+ memcpy_fromio(dst_bo->kptr, (void __iomem *)src_bo->kptr, size);
lsdc_bo_kunmap(src_bo);
lsdc_bo_kunmap(dst_bo);
--
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
Re: [PATCH] drm/loongson: Remove a useless check in cursor_plane_atomic_async_check()
Am 10.07.23 um 12:24 schrieb Sui Jingfeng:
Because smatch warnings:
drivers/gpu/drm/loongson/lsdc_plane.c:199
lsdc_cursor_plane_atomic_async_check()
warn: variable dereferenced before check 'state' (see line 180)
vim +/state +199 drivers/gpu/drm/loongson/lsdc_plane.c
174 static int
lsdc_cursor_plane_atomic_async_check(struct drm_plane *plane,
175 struct drm_atomic_state *state)
176 {
177 struct drm_plane_state *new_state;
178 struct drm_crtc_state *crtc_state;
179
180 new_state = drm_atomic_get_new_plane_state(state, plane);
^
state is dereferenced inside this function
181
182 if (!plane->state || !plane->state->fb) {
183 drm_dbg(plane->dev, "%s: state is NULL\n", plane->name);
184 return -EINVAL;
185 }
186
187 if (new_state->crtc_w != new_state->crtc_h) {
188 drm_dbg(plane->dev, "unsupported cursor size: %ux%u\n",
189 new_state->crtc_w, new_state->crtc_h);
190 return -EINVAL;
191 }
192
193 if (new_state->crtc_w != 64 && new_state->crtc_w != 32) {
194 drm_dbg(plane->dev, "unsupported cursor size: %ux%u\n",
195 new_state->crtc_w, new_state->crtc_h);
196 return -EINVAL;
197 }
198
199 if (state) {
^
Checked too late!
Reported-by: Dan Carpenter
Closes: https://lore.kernel.org/r/202307100423.rv7d05uq-...@intel.com/
Signed-off-by: Sui Jingfeng
Acked-by: Thomas Zimmermann
BTW, you're posting these patches for loongson, but that driver is not
yet in our tree?
Best regards
Thomas
---
drivers/gpu/drm/loongson/lsdc_plane.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/loongson/lsdc_plane.c
b/drivers/gpu/drm/loongson/lsdc_plane.c
index 2ab3db982aa3..0d5094633222 100644
--- a/drivers/gpu/drm/loongson/lsdc_plane.c
+++ b/drivers/gpu/drm/loongson/lsdc_plane.c
@@ -196,13 +196,7 @@ static int lsdc_cursor_plane_atomic_async_check(struct
drm_plane *plane,
return -EINVAL;
}
- if (state) {
- crtc_state = drm_atomic_get_existing_crtc_state(state,
new_state->crtc);
- } else {
- crtc_state = plane->crtc->state;
- drm_dbg(plane->dev, "%s: atomic state is NULL\n", plane->name);
- }
-
+ crtc_state = drm_atomic_get_existing_crtc_state(state, new_state->crtc);
if (!crtc_state->active)
return -EINVAL;
--
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
