Re: [PATCH v6 47/57] video: Remove dev_err() usage after platform_get_irq()
Hi,
Sorry for the late reply.
On 7/30/19 8:15 PM, Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
This patch changes handling of -EPROBE_DEFER in the modified drivers
(most don't support it and error message will no longer be printed).
I cannot apply it as it is (seems that -EPROBE_DEFER handling should
be audited/fixed in the affected drivers first).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> //
> @@
> expression ret;
> struct platform_device *E;
> @@
>
> ret =
> (
> platform_get_irq(E, ...)
> |
> platform_get_irq_byname(E, ...)
> );
>
> if ( \( ret < 0 \| ret <= 0 \) )
> {
> (
> -if (ret != -EPROBE_DEFER)
> -{ ...
> -dev_err(...);
> -... }
> |
> ...
> -dev_err(...);
> )
> ...
> }
> //
>
> While we're here, remove braces on if statements that only have one
> statement (manually).
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
>
> Please apply directly to subsystem trees
>
> drivers/video/fbdev/atmel_lcdfb.c | 1 -
> drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 1 -
> drivers/video/fbdev/nuc900fb.c| 4 +---
> drivers/video/fbdev/pxa168fb.c| 4 +---
> drivers/video/fbdev/pxa3xx-gcu.c | 4 +---
> drivers/video/fbdev/pxafb.c | 1 -
> drivers/video/fbdev/s3c2410fb.c | 4 +---
> drivers/video/fbdev/vt8500lcdfb.c | 1 -
> 8 files changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c
> b/drivers/video/fbdev/atmel_lcdfb.c
> index 5ff8e0320d95..4a16354d65c8 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -1114,7 +1114,6 @@ static int __init atmel_lcdfb_probe(struct
> platform_device *pdev)
>
> sinfo->irq_base = platform_get_irq(pdev, 0);
> if (sinfo->irq_base < 0) {
> - dev_err(dev, "unable to get irq\n");
> ret = sinfo->irq_base;
> goto stop_clk;
> }
> diff --git a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
> b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
> index 17174cd7a5bb..d6124976139b 100644
> --- a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
> +++ b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
> @@ -447,7 +447,6 @@ static int mmphw_probe(struct platform_device *pdev)
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> - dev_err(&pdev->dev, "%s: no IRQ defined\n", __func__);
> ret = -ENOENT;
> goto failed;
> }
> diff --git a/drivers/video/fbdev/nuc900fb.c b/drivers/video/fbdev/nuc900fb.c
> index 4fd851598584..c4606c734f44 100644
> --- a/drivers/video/fbdev/nuc900fb.c
> +++ b/drivers/video/fbdev/nuc900fb.c
> @@ -526,10 +526,8 @@ static int nuc900fb_probe(struct platform_device *pdev)
> display = mach_info->displays + mach_info->default_display;
>
> irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(&pdev->dev, "no irq for device\n");
> + if (irq < 0)
> return -ENOENT;
> - }
>
> fbinfo = framebuffer_alloc(sizeof(struct nuc900fb_info), &pdev->dev);
> if (!fbinfo)
> diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
> index 1410f476e135..d9e5258503f0 100644
> --- a/drivers/video/fbdev/pxa168fb.c
> +++ b/drivers/video/fbdev/pxa168fb.c
> @@ -625,10 +625,8 @@ static int pxa168fb_probe(struct platform_device *pdev)
> }
>
> irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(&pdev->dev, "no IRQ defined\n");
> + if (irq < 0)
> return -ENOENT;
> - }
>
> info = framebuffer_alloc(sizeof(struct pxa168fb_info), &pdev->dev);
> if (info == NULL) {
> diff --git a/drivers/video/fbdev/pxa3xx-gcu.c
> b/drivers/video/fbdev/pxa3xx-gcu.c
> index 74ffb446e00c..07414d43cb3f 100644
> --- a/drivers/video/fbdev/pxa3xx-gcu.c
> +++ b/drivers/video/fbdev/pxa3xx-gcu.c
> @@ -614,10 +614,8 @@ static int pxa3xx_gcu_probe(struct platform_device *pdev)
>
> /* request the IRQ */
> irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(dev, "no IRQ defined: %d\n", irq);
> + if (irq < 0)
> return irq;
> - }
>
> ret = devm_request_irq(dev, irq, pxa3xx_gcu_handle_irq,
> 0, DRV_NAME, priv);
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index 4282cb117b92..b44f402ce552 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -2353,7 +2353,6 @@ static int pxafb_probe(struct platform_device *dev)
>
> irq = platform_get_irq(dev, 0);
> if (irq < 0) {
> - dev_err(&dev->dev, "no IRQ defined\n");
>
Re: [PATCH 1/3] video: fbdev: mmp: remove duplicated MMP_DISP dependency
On 8/20/19 11:55 AM, Andrzej Hajda wrote: > On 27.06.2019 16:07, Bartlomiej Zolnierkiewicz wrote: >> This dependency is already present in higher level Kconfig file >> (drivers/video/fbdev/mmp/Kconfig). >> >> Signed-off-by: Bartlomiej Zolnierkiewicz > > > Reviewed-by: Andrzej Hajda Thanks, I've queued the patch for v5.6. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > -- > Regards > Andrzej > > >> --- >> drivers/video/fbdev/mmp/fb/Kconfig |4 >> drivers/video/fbdev/mmp/hw/Kconfig |4 >> 2 files changed, 8 deletions(-) >> >> Index: b/drivers/video/fbdev/mmp/fb/Kconfig >> === >> --- a/drivers/video/fbdev/mmp/fb/Kconfig >> +++ b/drivers/video/fbdev/mmp/fb/Kconfig >> @@ -1,6 +1,4 @@ >> # SPDX-License-Identifier: GPL-2.0-only >> -if MMP_DISP >> - >> config MMP_FB >> tristate "fb driver for Marvell MMP Display Subsystem" >> depends on FB >> @@ -10,5 +8,3 @@ config MMP_FB >> default y >> help >> fb driver for Marvell MMP Display Subsystem >> - >> -endif >> Index: b/drivers/video/fbdev/mmp/hw/Kconfig >> === >> --- a/drivers/video/fbdev/mmp/hw/Kconfig >> +++ b/drivers/video/fbdev/mmp/hw/Kconfig >> @@ -1,6 +1,4 @@ >> # SPDX-License-Identifier: GPL-2.0-only >> -if MMP_DISP >> - >> config MMP_DISP_CONTROLLER >> bool "mmp display controller hw support" >> depends on CPU_PXA910 || CPU_MMP2 >> @@ -16,5 +14,3 @@ config MMP_DISP_SPI >> help >> Marvell MMP display hw controller spi port support >> will register as a spi master for panel usage >> - >> -endif >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] video: fbdev: mmp: add COMPILE_TEST support
On 8/20/19 11:56 AM, Andrzej Hajda wrote: > On 27.06.2019 16:07, Bartlomiej Zolnierkiewicz wrote: >> Add COMPILE_TEST support to mmp display subsystem for better compile >> testing coverage. >> >> Signed-off-by: Bartlomiej Zolnierkiewicz > > > Reviewed-by: Andrzej Hajda Thanks, I've queued the patch for v5.6. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > -- > Regards > Andrzej > > >> --- >> drivers/video/fbdev/mmp/Kconfig|2 +- >> drivers/video/fbdev/mmp/hw/Kconfig |3 ++- >> 2 files changed, 3 insertions(+), 2 deletions(-) >> >> Index: b/drivers/video/fbdev/mmp/Kconfig >> === >> --- a/drivers/video/fbdev/mmp/Kconfig >> +++ b/drivers/video/fbdev/mmp/Kconfig >> @@ -1,7 +1,7 @@ >> # SPDX-License-Identifier: GPL-2.0-only >> menuconfig MMP_DISP >> tristate "Marvell MMP Display Subsystem support" >> -depends on CPU_PXA910 || CPU_MMP2 >> +depends on CPU_PXA910 || CPU_MMP2 || COMPILE_TEST >> help >>Marvell Display Subsystem support. >> >> Index: b/drivers/video/fbdev/mmp/hw/Kconfig >> === >> --- a/drivers/video/fbdev/mmp/hw/Kconfig >> +++ b/drivers/video/fbdev/mmp/hw/Kconfig >> @@ -1,7 +1,8 @@ >> # SPDX-License-Identifier: GPL-2.0-only >> config MMP_DISP_CONTROLLER >> bool "mmp display controller hw support" >> -depends on CPU_PXA910 || CPU_MMP2 >> +depends on HAVE_CLK && HAS_IOMEM >> +depends on CPU_PXA910 || CPU_MMP2 || COMPILE_TEST >> help >> Marvell MMP display hw controller support >> this controller is used on Marvell PXA910 and >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] video: fbdev: mmp: fix sparse warnings about using incorrect types
On 8/20/19 1:07 PM, Andrzej Hajda wrote:
> On 27.06.2019 16:08, Bartlomiej Zolnierkiewicz wrote:
>> Use ->screen_buffer instead of ->screen_base in mmpfb driver.
>>
>> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
>> pointer") for details. ]
>>
>> Also fix all other sparse warnings about using incorrect types in
>> mmp display subsystem.
>>
>> Signed-off-by: Bartlomiej Zolnierkiewicz
>
>
> Reviewed-by: Andrzej Hajda
Thanks, I've queued the patch for v5.6.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> --
> Regards
> Andrzej
>
>
>> ---
>> drivers/video/fbdev/mmp/fb/mmpfb.c|2 -
>> drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 55
>> +++---
>> drivers/video/fbdev/mmp/hw/mmp_ctrl.h | 10 +++---
>> drivers/video/fbdev/mmp/hw/mmp_spi.c |6 +--
>> 4 files changed, 41 insertions(+), 32 deletions(-)
>>
>> Index: b/drivers/video/fbdev/mmp/fb/mmpfb.c
>> ===
>> --- a/drivers/video/fbdev/mmp/fb/mmpfb.c
>> +++ b/drivers/video/fbdev/mmp/fb/mmpfb.c
>> @@ -522,7 +522,7 @@ static int fb_info_setup(struct fb_info
>> info->var.bits_per_pixel / 8;
>> info->fbops = &mmpfb_ops;
>> info->pseudo_palette = fbi->pseudo_palette;
>> -info->screen_base = fbi->fb_start;
>> +info->screen_buffer = fbi->fb_start;
>> info->screen_size = fbi->fb_size;
>>
>> /* For FB framework: Allocate color map and Register framebuffer*/
>> Index: b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
>> ===
>> --- a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
>> +++ b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
>> @@ -136,19 +136,26 @@ static void overlay_set_win(struct mmp_o
>> mutex_lock(&overlay->access_ok);
>>
>> if (overlay_is_vid(overlay)) {
>> -writel_relaxed(win->pitch[0], ®s->v_pitch_yc);
>> -writel_relaxed(win->pitch[2] << 16 |
>> -win->pitch[1], ®s->v_pitch_uv);
>> -
>> -writel_relaxed((win->ysrc << 16) | win->xsrc, ®s->v_size);
>> -writel_relaxed((win->ydst << 16) | win->xdst, ®s->v_size_z);
>> -writel_relaxed(win->ypos << 16 | win->xpos, ®s->v_start);
>> +writel_relaxed(win->pitch[0],
>> +(void __iomem *)®s->v_pitch_yc);
>> +writel_relaxed(win->pitch[2] << 16 | win->pitch[1],
>> +(void __iomem *)®s->v_pitch_uv);
>> +
>> +writel_relaxed((win->ysrc << 16) | win->xsrc,
>> +(void __iomem *)®s->v_size);
>> +writel_relaxed((win->ydst << 16) | win->xdst,
>> +(void __iomem *)®s->v_size_z);
>> +writel_relaxed(win->ypos << 16 | win->xpos,
>> +(void __iomem *)®s->v_start);
>> } else {
>> -writel_relaxed(win->pitch[0], ®s->g_pitch);
>> +writel_relaxed(win->pitch[0], (void __iomem *)®s->g_pitch);
>>
>> -writel_relaxed((win->ysrc << 16) | win->xsrc, ®s->g_size);
>> -writel_relaxed((win->ydst << 16) | win->xdst, ®s->g_size_z);
>> -writel_relaxed(win->ypos << 16 | win->xpos, ®s->g_start);
>> +writel_relaxed((win->ysrc << 16) | win->xsrc,
>> +(void __iomem *)®s->g_size);
>> +writel_relaxed((win->ydst << 16) | win->xdst,
>> +(void __iomem *)®s->g_size_z);
>> +writel_relaxed(win->ypos << 16 | win->xpos,
>> +(void __iomem *)®s->g_start);
>> }
>>
>> dmafetch_set_fmt(overlay);
>> @@ -233,11 +240,11 @@ static int overlay_set_addr(struct mmp_o
>> memcpy(&overlay->addr, addr, sizeof(struct mmp_addr));
>>
>> if (overlay_is_vid(overlay)) {
>> -writel_relaxed(addr->phys[0], ®s->v_y0);
>> -writel_relaxed(addr->phys[1], ®s->v_u0);
>> -writel_relaxed(addr->phys[2], ®s->v_v0);
>> +writel_relaxed(addr->phys[0], (void __iomem *)®s->v_y0);
>> +writel_relaxed(addr->phys[1], (void __iomem *)®s->v_u0);
>> +writel_relaxed(addr->phys[2], (void __iomem *)®s->v_v0);
>> } else
>> -writel_relaxed(addr->phys[0], ®s->g_0);
>> +writel_relaxed(addr->phys[0], (void __iomem *)®s->g_0);
>>
>> return overlay->addr.phys[0];
>> }
>> @@ -268,16 +275,18 @@ static void path_set_mode(struct mmp_pat
>> tmp |= dsi_rbswap & CFG_INTFRBSWAP_MASK;
>> writel_relaxed(tmp, ctrl_regs(path) + intf_rbswap_ctrl(path->id));
>>
>> -writel_relaxed((mode->yres << 16) | mode->xres, ®s->screen_active);
>> +writel_relaxed((mode->yres << 16) | mode->xres,
>> +(void __iomem *)®s->screen_active);
>> writel_relaxed((mode->left_margin << 16) | mode->right_margin,
>> -®s->screen_h_porch);
>> +
Re: [PATCH v3 1/3] fbdev: fix numbering of fbcon options
On 8/27/19 1:09 PM, Peter Rosin wrote:
> Three shall be the number thou shalt count, and the number of the
> counting shall be three. Four shalt thou not count...
>
> One! Two! Five!
>
> Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer
> console documentation")
> Signed-off-by: Peter Rosin
Thanks, patch queued for v5.6 (also sorry for the delay).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Documentation/fb/fbcon.rst | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
> index ebca41785abe..65ba40255137 100644
> --- a/Documentation/fb/fbcon.rst
> +++ b/Documentation/fb/fbcon.rst
> @@ -127,7 +127,7 @@ C. Boot options
> is typically located on the same video card. Thus, the consoles that
> are controlled by the VGA console will be garbled.
>
> -4. fbcon=rotate:
> +5. fbcon=rotate:
>
> This option changes the orientation angle of the console display. The
> value 'n' accepts the following:
> @@ -152,21 +152,21 @@ C. Boot options
> Actually, the underlying fb driver is totally ignorant of console
> rotation.
>
> -5. fbcon=margin:
> +6. fbcon=margin:
>
> This option specifies the color of the margins. The margins are the
> leftover area at the right and the bottom of the screen that are not
> used by text. By default, this area will be black. The 'color' value
> is an integer number that depends on the framebuffer driver being used.
>
> -6. fbcon=nodefer
> +7. fbcon=nodefer
>
> If the kernel is compiled with deferred fbcon takeover support, normally
> the framebuffer contents, left in place by the firmware/bootloader, will
> be preserved until there actually is some text is output to the console.
> This option causes fbcon to bind immediately to the fbdev device.
>
> -7. fbcon=logo-pos:
> +8. fbcon=logo-pos:
>
> The only possible 'location' is 'center' (without quotes), and when
> given, the bootup logo is moved from the default top-left corner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] fbdev: fbmem: allow overriding the number of bootup logos
On 8/27/19 1:09 PM, Peter Rosin wrote:
> Probably most useful if you want no logo at all, or if you only want one
> logo regardless of how many CPU cores you have.
>
> Signed-off-by: Peter Rosin
Thanks, patch queued for v5.6 (also sorry for the delay).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Documentation/fb/fbcon.rst | 5 +
> drivers/video/fbdev/core/fbcon.c | 7 +++
> drivers/video/fbdev/core/fbmem.c | 12 +---
> include/linux/fb.h | 1 +
> 4 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
> index 65ba40255137..e57a3d1d085a 100644
> --- a/Documentation/fb/fbcon.rst
> +++ b/Documentation/fb/fbcon.rst
> @@ -174,6 +174,11 @@ C. Boot options
> displayed due to multiple CPUs, the collected line of logos is moved
> as a whole.
>
> +9. fbcon=logo-count:
> +
> + The value 'n' overrides the number of bootup logos. 0 disables the
> + logo, and -1 gives the default which is the number of online CPUs.
> +
> C. Attaching, Detaching and Unloading
>
> Before going on to how to attach, detach and unload the framebuffer console,
> an
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index c9235a2f42f8..bb6ae995c2e5 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -536,6 +536,13 @@ static int __init fb_console_setup(char *this_opt)
> fb_center_logo = true;
> continue;
> }
> +
> + if (!strncmp(options, "logo-count:", 11)) {
> + options += 11;
> + if (*options)
> + fb_logo_count = simple_strtol(options,
> &options, 0);
> + continue;
> + }
> }
> return 1;
> }
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 64dd732021d8..c7ddcb72025b 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -56,6 +56,8 @@ EXPORT_SYMBOL(num_registered_fb);
> bool fb_center_logo __read_mostly;
> EXPORT_SYMBOL(fb_center_logo);
>
> +int fb_logo_count __read_mostly = -1;
> +
> static struct fb_info *get_fb_info(unsigned int idx)
> {
> struct fb_info *fb_info;
> @@ -620,7 +622,7 @@ int fb_prepare_logo(struct fb_info *info, int rotate)
> memset(&fb_logo, 0, sizeof(struct logo_data));
>
> if (info->flags & FBINFO_MISC_TILEBLITTING ||
> - info->fbops->owner)
> + info->fbops->owner || !fb_logo_count)
> return 0;
>
> if (info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> @@ -686,10 +688,14 @@ int fb_prepare_logo(struct fb_info *info, int rotate)
>
> int fb_show_logo(struct fb_info *info, int rotate)
> {
> + unsigned int count;
> int y;
>
> - y = fb_show_logo_line(info, rotate, fb_logo.logo, 0,
> - num_online_cpus());
> + if (!fb_logo_count)
> + return 0;
> +
> + count = fb_logo_count < 0 ? num_online_cpus() : fb_logo_count;
> + y = fb_show_logo_line(info, rotate, fb_logo.logo, 0, count);
> y = fb_show_extra_logos(info, y, rotate);
>
> return y;
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 303771264644..e37f72b2efca 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -630,6 +630,7 @@ extern int fb_new_modelist(struct fb_info *info);
> extern struct fb_info *registered_fb[FB_MAX];
> extern int num_registered_fb;
> extern bool fb_center_logo;
> +extern int fb_logo_count;
> extern struct class *fb_class;
>
> #define for_each_registered_fb(i)\
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] fbdev: fbmem: avoid exporting fb_center_logo
On 8/29/19 9:08 AM, Peter Rosin wrote: > On 2019-08-27 13:35, Geert Uytterhoeven wrote: >> Hi Peter, >> >> On Tue, Aug 27, 2019 at 1:09 PM Peter Rosin wrote: >>> The variable is only ever used from fbcon.c which is linked into the >>> same module. Therefore, the export is not needed. >>> >>> Signed-off-by: Peter Rosin >> >> Reviewed-by: Geert Uytterhoeven Thanks, patch queued for v5.6 (also sorry for the delay). >> But note that the same is true for fb_class, so perhaps it can be added >> (or better, removed ;-)? > > Right. Someone please let me know if 3/3 needs to be extended. I'm also > happy to just drop it... Please send incremental patch for fb_class. >> Once drivers/staging/olpc_dcon/olpc_dcon.c stops abusing registered_fb[] >> and num_registered_fb, those can go, too. >> >> Does anyone remembe why au1200fb calls fb_prepare_logo() and fb_show_logo() >> itself? > > Maybe there should be a small drivers/video/fbdev/core/fbmem.h file (or > something) with these "internal" declarations, to hide some clutter currently > in include/linux/fb.h? Sounds like a good idea. > Feels like that could be done later, after these other cleanups you mention, > so that the new file has a few more things to declare. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] pxa168fb: Fix the function used to release some memory in an error handling path
On 9/2/19 11:10 AM, Lubomir Rintel wrote:
> On Sat, 2019-08-31 at 12:00 +0200, Christophe JAILLET wrote:
>> In the probe function, some resources are allocated using 'dma_alloc_wc()',
>> they should be released with 'dma_free_wc()', not 'dma_free_coherent()'.
>>
>> We already use 'dma_free_wc()' in the remove function, but not in the
>> error handling path of the probe function.
>>
>> Also, remove a useless 'PAGE_ALIGN()'. 'info->fix.smem_len' is already
>> PAGE_ALIGNed.
>>
>> Fixes: 638772c7553f ("fb: add support of LCD display controller on
>> pxa168/910 (base layer)")
>> Signed-off-by: Christophe JAILLET
>
> Reviewed-by: Lubomir Rintel
Thanks, patch queued for v5.6 (also sorry for the delay).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Thanks,
> Lubo
>
>> ---
>> The change about PAGE_ALIGN should probably be part of a separate commit.
>> However, git history for this driver is really quiet. If you think it
>> REALLY deserves a separate patch, either split it by yourself or axe this
>> part of the patch. I won't bother resubmitting for this lonely cleanup.
>> Hoping for your understanding.
>> ---
>> drivers/video/fbdev/pxa168fb.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
>> index 1410f476e135..1fc50fc0694b 100644
>> --- a/drivers/video/fbdev/pxa168fb.c
>> +++ b/drivers/video/fbdev/pxa168fb.c
>> @@ -766,8 +766,8 @@ static int pxa168fb_probe(struct platform_device *pdev)
>> failed_free_clk:
>> clk_disable_unprepare(fbi->clk);
>> failed_free_fbmem:
>> -dma_free_coherent(fbi->dev, info->fix.smem_len,
>> -info->screen_base, fbi->fb_start_dma);
>> +dma_free_wc(fbi->dev, info->fix.smem_len,
>> +info->screen_base, fbi->fb_start_dma);
>> failed_free_info:
>> kfree(info);
>>
>> @@ -801,7 +801,7 @@ static int pxa168fb_remove(struct platform_device *pdev)
>>
>> irq = platform_get_irq(pdev, 0);
>>
>> -dma_free_wc(fbi->dev, PAGE_ALIGN(info->fix.smem_len),
>> +dma_free_wc(fbi->dev, info->fix.smem_len,
>> info->screen_base, info->fix.smem_start);
>>
>> clk_disable_unprepare(fbi->clk);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video/fbdev/68328fb: Remove dead code
On 9/2/19 2:49 PM, Souptick Joarder wrote:
> This is dead code since 3.15. If their is no plan to
> use it further, these can be removed forever.
>
> Signed-off-by: Souptick Joarder
Thanks, patch queued for v5.6 (also sorry for the delay).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/68328fb.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/68328fb.c b/drivers/video/fbdev/68328fb.c
> index d48e960..02d22b7 100644
> --- a/drivers/video/fbdev/68328fb.c
> +++ b/drivers/video/fbdev/68328fb.c
> @@ -405,20 +405,8 @@ static int mc68x328fb_mmap(struct fb_info *info, struct
> vm_area_struct *vma)
>
> int __init mc68x328fb_setup(char *options)
> {
> -#if 0
> - char *this_opt;
> -#endif
> -
> if (!options || !*options)
> return 1;
> -#if 0
> - while ((this_opt = strsep(&options, ",")) != NULL) {
> - if (!*this_opt)
> - continue;
> - if (!strncmp(this_opt, "disable", 7))
> - mc68x328fb_enable = 0;
> - }
> -#endif
> return 1;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] fbdev: da8xx-fb: use devm_platform_ioremap_resource() to simplify code
On 9/4/19 1:50 PM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
This has been already fixed by:
commit c957c88f7be109a14294289f013b03bbe94e8af5
Author: Bartosz Golaszewski
AuthorDate: Mon Jul 22 15:44:21 2019 +0200
Commit: Sekhar Nori
CommitDate: Mon Aug 26 17:53:59 2019 +0530
fbdev: da8xx-fb: use devm_platform_ioremap_resource()
Shrink the code a bit by using the new helper wrapping the calls to
platform_get_resource() and devm_ioremap_resource() together.
Signed-off-by: Bartosz Golaszewski
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sekhar Nori
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/da8xx-fb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
> index b1cf248..57518d7 100644
> --- a/drivers/video/fbdev/da8xx-fb.c
> +++ b/drivers/video/fbdev/da8xx-fb.c
> @@ -1328,7 +1328,6 @@ static int fb_probe(struct platform_device *device)
> {
> struct da8xx_lcdc_platform_data *fb_pdata =
> dev_get_platdata(&device->dev);
> - struct resource *lcdc_regs;
> struct lcd_ctrl_config *lcd_cfg;
> struct fb_videomode *lcdc_info;
> struct fb_info *da8xx_fb_info;
> @@ -1346,8 +1345,7 @@ static int fb_probe(struct platform_device *device)
> if (lcdc_info == NULL)
> return -ENODEV;
>
> - lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
> - da8xx_fb_reg_base = devm_ioremap_resource(&device->dev, lcdc_regs);
> + da8xx_fb_reg_base = devm_platform_ioremap_resource(device, 0);
> if (IS_ERR(da8xx_fb_reg_base))
> return PTR_ERR(da8xx_fb_reg_base);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] fbdev: omapfb: use devm_platform_ioremap_resource() to simplify code
On 9/4/19 1:54 PM, YueHaibing wrote: > Use devm_platform_ioremap_resource() to simplify the code a bit. > This is detected by coccinelle. > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing Thanks, patch queued for v5.6 (also sorry for the delay). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > drivers/video/fbdev/omap2/omapfb/vrfb.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/video/fbdev/omap2/omapfb/vrfb.c > b/drivers/video/fbdev/omap2/omapfb/vrfb.c > index 819e0bc..ee0dd4c 100644 > --- a/drivers/video/fbdev/omap2/omapfb/vrfb.c > +++ b/drivers/video/fbdev/omap2/omapfb/vrfb.c > @@ -339,9 +339,7 @@ static int __init vrfb_probe(struct platform_device *pdev) > int i; > > /* first resource is the register res, the rest are vrfb contexts */ > - > - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - vrfb_base = devm_ioremap_resource(&pdev->dev, mem); > + vrfb_base = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(vrfb_base)) > return PTR_ERR(vrfb_base); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] fbdev: s3c-fb: use devm_platform_ioremap_resource() to simplify code
On 9/17/19 9:21 PM, Jingoo Han wrote:
>
>
> On 9/4/19, 7:57 AM, YueHaibing wrote:
>
>> Use devm_platform_ioremap_resource() to simplify the code a bit.
>> This is detected by coccinelle.
>>
>> Reported-by: Hulk Robot
>> Signed-off-by: YueHaibing
>>
> Acked-by: Jingoo Han
Thanks, patch queued for v5.6 (also sorry for the delay).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
>> ---
>> drivers/video/fbdev/s3c-fb.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
>> index ba04d7a..43ac8d7 100644
>> --- a/drivers/video/fbdev/s3c-fb.c
>> +++ b/drivers/video/fbdev/s3c-fb.c
>> @@ -1411,8 +1411,7 @@ static int s3c_fb_probe(struct platform_device *pdev)
>>
>> pm_runtime_enable(sfb->dev);
>>
>> -res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> -sfb->regs = devm_ioremap_resource(dev, res);
>> +sfb->regs = devm_platform_ioremap_resource(pdev, 0);
>> if (IS_ERR(sfb->regs)) {
>> ret = PTR_ERR(sfb->regs);
>> goto err_lcd_clk;
>> --
>> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] fbdev/sa1100fb: use devm_platform_ioremap_resource() to simplify code
On 9/4/19 1:57 PM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Thanks, patch queued for v5.6 (also sorry for the delay).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/sa1100fb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
> index ae2bcfe..4428cef 100644
> --- a/drivers/video/fbdev/sa1100fb.c
> +++ b/drivers/video/fbdev/sa1100fb.c
> @@ -1156,7 +1156,6 @@ static struct sa1100fb_info
> *sa1100fb_init_fbinfo(struct device *dev)
> static int sa1100fb_probe(struct platform_device *pdev)
> {
> struct sa1100fb_info *fbi;
> - struct resource *res;
> int ret, irq;
>
> if (!dev_get_platdata(&pdev->dev)) {
> @@ -1172,8 +1171,7 @@ static int sa1100fb_probe(struct platform_device *pdev)
> if (!fbi)
> return -ENOMEM;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - fbi->base = devm_ioremap_resource(&pdev->dev, res);
> + fbi->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(fbi->base))
> return PTR_ERR(fbi->base);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: matrox: make array wtst_xlat static const, makes object smaller
On 9/6/19 8:17 PM, Ville Syrjälä wrote:
> On Fri, Sep 06, 2019 at 07:11:14PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> Don't populate the array wtst_xlat on the stack but instead make it
>> static const. Makes the object code smaller by 89 bytes.
>>
>> Before:
>>text data bss dec hex filename
>> 14347 840 0 151873b53 fbdev/matrox/matroxfb_misc.o
>>
>> After:
>>text data bss dec hex filename
>> 14162 936 0 150983afa fbdev/matrox/matroxfb_misc.o
>>
>> (gcc version 9.2.1, amd64)
>>
>> Signed-off-by: Colin Ian King
Thanks, patch queued for v5.6 (also sorry for the delay).
>> ---
>> drivers/video/fbdev/matrox/matroxfb_misc.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/matrox/matroxfb_misc.c
>> b/drivers/video/fbdev/matrox/matroxfb_misc.c
>> index c7aaca12805e..feb0977c82eb 100644
>> --- a/drivers/video/fbdev/matrox/matroxfb_misc.c
>> +++ b/drivers/video/fbdev/matrox/matroxfb_misc.c
>> @@ -673,7 +673,10 @@ static int parse_pins5(struct matrox_fb_info *minfo,
>> if (bd->pins[115] & 4) {
>> minfo->values.reg.mctlwtst_core = minfo->values.reg.mctlwtst;
>> } else {
>> -u_int32_t wtst_xlat[] = { 0, 1, 5, 6, 7, 5, 2, 3 };
>> +static const u_int32_t wtst_xlat[] = {
>> +0, 1, 5, 6, 7, 5, 2, 3
>
> All of those would easily fit in u8 as well.
Good idea, I've converted the table to u8 while applying the patch.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
>> +};
>> +
>> minfo->values.reg.mctlwtst_core = (minfo->values.reg.mctlwtst &
>> ~7) |
>>
>> wtst_xlat[minfo->values.reg.mctlwtst & 7];
>> }
>> --
>> 2.20.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: fsl-diu-fb: mark expected switch fall-throughs
On 9/11/19 1:36 PM, Gustavo A. R. Silva wrote: > Mark switch cases where we are expecting to fall through. > > Fix the following warnings (Building: mpc512x_defconfig powerpc): > > drivers/video/fbdev/fsl-diu-fb.c: In function ‘fsl_diu_ioctl’: > ./include/linux/device.h:1750:2: warning: this statement may fall through > [-Wimplicit-fallthrough=] > _dev_warn(dev, dev_fmt(fmt), ##__VA_ARGS__) > ^~~ > drivers/video/fbdev/fsl-diu-fb.c:1287:3: note: in expansion of macro > ‘dev_warn’ >dev_warn(info->dev, >^~~~ > drivers/video/fbdev/fsl-diu-fb.c:1290:2: note: here > case MFB_SET_PIXFMT: > ^~~~ > In file included from ./include/linux/acpi.h:15:0, > from ./include/linux/i2c.h:13, > from ./include/uapi/linux/fb.h:6, > from ./include/linux/fb.h:6, > from drivers/video/fbdev/fsl-diu-fb.c:20: > ./include/linux/device.h:1750:2: warning: this statement may fall through > [-Wimplicit-fallthrough=] > _dev_warn(dev, dev_fmt(fmt), ##__VA_ARGS__) > ^~~ > drivers/video/fbdev/fsl-diu-fb.c:1296:3: note: in expansion of macro > ‘dev_warn’ >dev_warn(info->dev, >^~~~ > drivers/video/fbdev/fsl-diu-fb.c:1299:2: note: here > case MFB_GET_PIXFMT: > ^~~~ > > Reported-by: kbuild test robot > Signed-off-by: Gustavo A. R. Silva Thanks, patch queued for v5.6 (also sorry for the delay). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > drivers/video/fbdev/fsl-diu-fb.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/video/fbdev/fsl-diu-fb.c > b/drivers/video/fbdev/fsl-diu-fb.c > index d19f58263b4e..3e410b9eb272 100644 > --- a/drivers/video/fbdev/fsl-diu-fb.c > +++ b/drivers/video/fbdev/fsl-diu-fb.c > @@ -1287,6 +1287,7 @@ static int fsl_diu_ioctl(struct fb_info *info, unsigned > int cmd, > dev_warn(info->dev, >"MFB_SET_PIXFMT value of 0x%08x is deprecated.\n", >MFB_SET_PIXFMT_OLD); > + /* fall through */ > case MFB_SET_PIXFMT: > if (copy_from_user(&pix_fmt, buf, sizeof(pix_fmt))) > return -EFAULT; > @@ -1296,6 +1297,7 @@ static int fsl_diu_ioctl(struct fb_info *info, unsigned > int cmd, > dev_warn(info->dev, >"MFB_GET_PIXFMT value of 0x%08x is deprecated.\n", >MFB_GET_PIXFMT_OLD); > + /* fall through */ > case MFB_GET_PIXFMT: > pix_fmt = ad->pix_fmt; > if (copy_to_user(buf, &pix_fmt, sizeof(pix_fmt))) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: ocfb: Use devm_platform_ioremap_resource() in ocfb_probe()
On 9/19/19 4:33 PM, Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 19 Sep 2019 16:26:56 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Thanks, patch queued for v5.6 (also sorry for the delay).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ocfb.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/ocfb.c b/drivers/video/fbdev/ocfb.c
> index a970edc2a6f8..be308b4dc91d 100644
> --- a/drivers/video/fbdev/ocfb.c
> +++ b/drivers/video/fbdev/ocfb.c
> @@ -297,7 +297,6 @@ static int ocfb_probe(struct platform_device *pdev)
> {
> int ret = 0;
> struct ocfb_dev *fbdev;
> - struct resource *res;
> int fbsize;
>
> fbdev = devm_kzalloc(&pdev->dev, sizeof(*fbdev), GFP_KERNEL);
> @@ -319,13 +318,7 @@ static int ocfb_probe(struct platform_device *pdev)
> ocfb_init_var(fbdev);
> ocfb_init_fix(fbdev);
>
> - /* Request I/O resource */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(&pdev->dev, "I/O resource request failed\n");
> - return -ENXIO;
> - }
> - fbdev->regs = devm_ioremap_resource(&pdev->dev, res);
> + fbdev->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(fbdev->regs))
> return PTR_ERR(fbdev->regs);
>
> --
> 2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: pxafb: Use devm_platform_ioremap_resource() in pxafb_probe()
On 9/19/19 5:01 PM, Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 19 Sep 2019 16:51:38 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Thanks, patch queued for v5.6 (also sorry for the delay).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/pxafb.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index f70c9f79622e..237f8f436fdb 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -2237,7 +2237,6 @@ static int pxafb_probe(struct platform_device *dev)
> {
> struct pxafb_info *fbi;
> struct pxafb_mach_info *inf, *pdata;
> - struct resource *r;
> int i, irq, ret;
>
> dev_dbg(&dev->dev, "pxafb_probe\n");
> @@ -2303,14 +2302,7 @@ static int pxafb_probe(struct platform_device *dev)
> fbi->lcd_supply = NULL;
> }
>
> - r = platform_get_resource(dev, IORESOURCE_MEM, 0);
> - if (r == NULL) {
> - dev_err(&dev->dev, "no I/O memory resource defined\n");
> - ret = -ENODEV;
> - goto failed;
> - }
> -
> - fbi->mmio_base = devm_ioremap_resource(&dev->dev, r);
> + fbi->mmio_base = devm_platform_ioremap_resource(dev, 0);
> if (IS_ERR(fbi->mmio_base)) {
> dev_err(&dev->dev, "failed to get I/O memory\n");
> ret = -EBUSY;
> --
> 2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: reduce stack usage
On 10/18/19 6:30 PM, Sudip Mukherjee wrote:
> The build of xtensa allmodconfig is giving a warning of:
> In function 'dsi_dump_dsidev_irqs':
> warning: the frame size of 1120 bytes is larger than 1024 bytes
>
> Allocate the memory for 'struct dsi_irq_stats' dynamically instead
> of assigning it in stack.
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 24 ++--
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> index d620376216e1..43402467bf40 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> @@ -1536,22 +1536,25 @@ static void dsi_dump_dsidev_irqs(struct
> platform_device *dsidev,
> {
> struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> unsigned long flags;
> - struct dsi_irq_stats stats;
> + struct dsi_irq_stats *stats;
>
> + stats = kmalloc(sizeof(*stats), GFP_KERNEL);
> + if (!stats)
> + return;
> spin_lock_irqsave(&dsi->irq_stats_lock, flags);
>
> - stats = dsi->irq_stats;
> + memcpy(stats, &dsi->irq_stats, sizeof(*stats));
"stats" copy is only needed for generating debugfs information.
We can probably reduce the stack usage and also simplify the driver
by just accessing dsi->irq_stats directly before cleaning it
(we would also need to extend coverage of spinlock but the code is
debug only so this should not be a problem).
Care to try this approach?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> memset(&dsi->irq_stats, 0, sizeof(dsi->irq_stats));
> dsi->irq_stats.last_reset = jiffies;
>
> spin_unlock_irqrestore(&dsi->irq_stats_lock, flags);
>
> seq_printf(s, "period %u ms\n",
> - jiffies_to_msecs(jiffies - stats.last_reset));
> + jiffies_to_msecs(jiffies - stats->last_reset));
>
> - seq_printf(s, "irqs %d\n", stats.irq_count);
> + seq_printf(s, "irqs %d\n", stats->irq_count);
> #define PIS(x) \
> - seq_printf(s, "%-20s %10d\n", #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]);
> + seq_printf(s, "%-20s %10d\n", #x, stats->dsi_irqs[ffs(DSI_IRQ_##x)-1]);
>
> seq_printf(s, "-- DSI%d interrupts --\n", dsi->module_id + 1);
> PIS(VC0);
> @@ -1575,10 +1578,10 @@ static void dsi_dump_dsidev_irqs(struct
> platform_device *dsidev,
>
> #define PIS(x) \
> seq_printf(s, "%-20s %10d %10d %10d %10d\n", #x, \
> - stats.vc_irqs[0][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[1][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[2][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[3][ffs(DSI_VC_IRQ_##x)-1]);
> + stats->vc_irqs[0][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[1][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[2][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[3][ffs(DSI_VC_IRQ_##x)-1]);
>
> seq_printf(s, "-- VC interrupts --\n");
> PIS(CS);
> @@ -1594,7 +1597,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device
> *dsidev,
>
> #define PIS(x) \
> seq_printf(s, "%-20s %10d\n", #x, \
> - stats.cio_irqs[ffs(DSI_CIO_IRQ_##x)-1]);
> + stats->cio_irqs[ffs(DSI_CIO_IRQ_##x)-1]);
>
> seq_printf(s, "-- CIO interrupts --\n");
> PIS(ERRSYNCESC1);
> @@ -1618,6 +1621,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device
> *dsidev,
> PIS(ULPSACTIVENOT_ALL0);
> PIS(ULPSACTIVENOT_ALL1);
> #undef PIS
> + kfree(stats);
> }
>
> static void dsi1_dump_irqs(struct seq_file *s)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: potential information leak in do_fb_ioctl()
On 10/29/19 8:02 PM, Eric W. Biederman wrote:
> Dan Carpenter writes:
>
>> The "fix" struct has a 2 byte hole after ->ywrapstep and the
>> "fix = info->fix;" assignment doesn't necessarily clear it. It depends
>> on the compiler.
>>
>> Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex held")
>> Signed-off-by: Dan Carpenter
>> ---
>> I have 13 more similar places to patch... I'm not totally sure I
>> understand all the issues involved.
>
> What I have done in a similar situation with struct siginfo, is that
> where the structure first appears I have initialized it with memset,
> and then field by field.
>
> Then when the structure is copied I copy the structure with memcpy.
>
> That ensures all of the bytes in the original structure are initialized
> and that all of the bytes are copied.
>
> The goal is to avoid memory that has values of the previous users of
> that memory region from leaking to userspace. Which depending on who
> the previous user of that memory region is could tell userspace
> information about what the kernel is doing that it should not be allowed
> to find out.
>
> I tried to trace through where "info" and thus presumably "info->fix" is
> coming from and only made it as far as register_framebuffer. Given
"info" (and thus "info->fix") comes from framebuffer_alloc() (which is
called by fbdev device drivers prior to registering "info" with
register_framebuffer()). framebuffer_alloc() does kzalloc() on "info".
Therefore shouldn't memcpy() (as suggested by Jeo Perches) be enough?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> that I suspect a local memset, and then a field by field copy right
> before copy_to_user might be a sound solution. But ick. That is a lot
> of fields to copy.
>
>
> Eric
>
>
>
>> drivers/video/fbdev/core/fbmem.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/video/fbdev/core/fbmem.c
>> b/drivers/video/fbdev/core/fbmem.c
>> index 6f6fc785b545..b4ce6a28aed9 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1109,6 +1109,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
>> int cmd,
>> ret = -EFAULT;
>> break;
>> case FBIOGET_FSCREENINFO:
>> +memset(&fix, 0, sizeof(fix));
>> lock_fb_info(info);
>> fix = info->fix;
>> if (info->flags & FBINFO_HIDE_SMEM_START)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
On 2020-01-03 12:50 a.m., Wayne Lin wrote: > [Why] > According to DP spec, it should shift left 4 digits for NO_STOP_BIT > in REMOTE_I2C_READ message. Not 5 digits. > > In current code, NO_STOP_BIT is always set to zero which means I2C > master is always generating a I2C stop at the end of each I2C write > transaction while handling REMOTE_I2C_READ sideband message. This issue > might have the generated I2C signal not meeting the requirement. Take > random read in I2C for instance, I2C master should generate a repeat > start to start to read data after writing the read address. This issue > will cause the I2C master to generate a stop-start rather than a > re-start which is not expected in I2C random read. > Thanks for elaborating on the potential consequences of this bug. Harry > [How] > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in > drm_dp_encode_sideband_req(). > > Changes since v1:(https://patchwork.kernel.org/patch/11312667/) > * Add more descriptions in commit and cc to stable > > Fixes: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper (v0.6)) > Reviewed-by: Harry Wentland > Signed-off-by: Wayne Lin > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > b/drivers/gpu/drm/drm_dp_mst_topology.c > index 1cf5f8b8bbb8..9d24c98bece1 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct > drm_dp_sideband_msg_req_body *req, > memcpy(&buf[idx], > req->u.i2c_read.transactions[i].bytes, > req->u.i2c_read.transactions[i].num_bytes); > idx += req->u.i2c_read.transactions[i].num_bytes; > > - buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit > & 0x1) << 5; > + buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit > & 0x1) << 4; > buf[idx] |= > (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf); > idx++; > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] clk: sunxi: a23/a33: Export the MIPI PLL
On Fri, Jan 3, 2020 at 11:28 PM Maxime Ripard wrote: > > The MIPI PLL is used for LVDS. Make sure it's exported in the dt bindings > headers. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] clk: sunxi: a31: Export the MIPI PLL
On Fri, Jan 3, 2020 at 11:28 PM Maxime Ripard wrote: > > The MIPI PLL is used for LVDS. Make sure it's exported in the dt bindings > headers. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] ARM: dts: sunxi: Add missing LVDS resets and clocks
On Fri, Jan 3, 2020 at 11:28 PM Maxime Ripard wrote: > > Some old SoCs, while supporting LVDS, don't list the LVDS clocks and reset > lines. Let's add them when relevant. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204849] amdgpu (RX560X) traceboot in dmesg boot output, system instability
https://bugzilla.kernel.org/show_bug.cgi?id=204849 Robert Hoffmann (rob...@servermasters.com) changed: What|Removed |Added CC||rob...@servermasters.com --- Comment #1 from Robert Hoffmann (rob...@servermasters.com) --- Hi guys, I am getting a very similar issue with a Ryzen 3400G (AMDGPU). OS Fedora 31: Linux asrock 5.3.16-300.fc31.x86_64 #1 SMP Fri Dec 13 17:59:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux The problem manifests itself every time I enter into an Xorg (LXDE) session, I guess one time per CPU core. So I am getting 10-12 errors every time I log in, as popups. Xfce also will not work at all, only LXDE (Openbox) seems to work fine. Operationally all seems relatively OK though, except if I turn off one of my 2 monitors, and turn them back on, I will get the errors again. I dont have a kernel debugger or profiler installed. here is a snippet of a backtrace: - WARNING: CPU: 1 PID: 917 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1758 write_i2c_retimer_setting.cold+0xae/0xb5 [amdgpu] Modules linked in: serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic dm_crypt xt_CHECKSUM xt_MASQUERADE nf_nat_tftp nf_conntrack_tftp xt_CT tun bridge stp llc ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc snd_hda_codec_realtek snd_hda_codec_generic edac_mce_amd ledtrig_audio snd_hda_codec_hdmi kvm_amd ccp snd_hda_intel snd_hda_codec kvm snd_hda_core snd_hwdep irqbypass snd_seq crct10dif_pclmul snd_seq_device crc32_pclmul snd_pcm joydev wmi_bmof ghash_clmulni_intel snd_timer nvme sp5100_tco nvme_core snd k10temp i2c_piix4 soundcore acpi_cpufreq ip_tables uas usb_storage amdgpu amd_iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper drm crc32c_intel r8169 wmi video pinctrl_amd fuse CPU: 1 PID: 917 Comm: Xorg Tainted: GW 5.3.16-300.fc31.x86_64 #1 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A300M-STX, BIOS P3.50 05/15/2019 RIP: 0010:write_i2c_retimer_setting.cold+0xae/0xb5 [amdgpu] Code: 6c f4 a0 c1 0f 0b e9 0e 0d fd ff 48 c7 c7 80 ee 7f c0 e8 59 f4 a0 c1 0f 0b e9 27 0b fd ff 48 c7 c7 80 ee 7f c0 e8 46 f4 a0 c1 <0f> 0b e9 fd 09 fd ff 48 c7 c7 80 ee 7f c0 e8 33 f4 a0 c1 0f 0b e9 RSP: 0018:be23c190f6a0 EFLAGS: 00010246 RAX: 0024 RBX: 0001 RCX: RDX: RSI: 99fc50657908 RDI: 99fc50657908 RBP: be23c190f71c R08: 99fc50657908 R09: 072a R10: 00024924 R11: 0003 R12: 005d R13: R14: 99fc18140648 R15: FS: 7fd0f4484f00() GS:99fc5064() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55800df036e8 CR3: 0003ef71a000 CR4: 003406e0 Call Trace: -- -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204849] amdgpu (RX560X) traceboot in dmesg boot output, system instability
https://bugzilla.kernel.org/show_bug.cgi?id=204849 --- Comment #2 from Robert Hoffmann (rob...@servermasters.com) --- (In reply to Robert Hoffmann from comment #1) > Hi guys, > > I am getting a very similar issue with a Ryzen 3400G (AMDGPU). > > OS Fedora 31: Linux asrock 5.3.16-300.fc31.x86_64 #1 SMP Fri Dec 13 17:59:04 > UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > > The problem manifests itself every time I enter into an Xorg (LXDE) session, > I guess one time per CPU core. So I am getting 10-12 errors every time I log > in, as popups. Xfce also will not work at all, only LXDE (Openbox) seems to > work fine. > > Operationally all seems relatively OK though, except if I turn off one of my > 2 monitors, and turn them back on, I will get the errors again. > > > I dont have a kernel debugger or profiler installed. > > here is a snippet of a backtrace: - > WARNING: CPU: 1 PID: 917 at > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1758 > write_i2c_retimer_setting.cold+0xae/0xb5 [amdgpu] > Modules linked in: serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 > serpent_generic dm_crypt xt_CHECKSUM xt_MASQUERADE nf_nat_tftp > nf_conntrack_tftp xt_CT tun bridge stp llc ip6t_REJECT nf_reject_ipv6 > ip6t_rpfilter ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat > ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security > iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack > nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter > ebtables ip6table_filter ip6_tables iptable_filter sunrpc > snd_hda_codec_realtek snd_hda_codec_generic edac_mce_amd ledtrig_audio > snd_hda_codec_hdmi kvm_amd ccp snd_hda_intel snd_hda_codec kvm snd_hda_core > snd_hwdep irqbypass snd_seq crct10dif_pclmul snd_seq_device crc32_pclmul > snd_pcm joydev wmi_bmof ghash_clmulni_intel snd_timer nvme sp5100_tco > nvme_core snd k10temp i2c_piix4 soundcore acpi_cpufreq ip_tables uas > usb_storage amdgpu amd_iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper drm > crc32c_intel r8169 wmi video pinctrl_amd fuse > CPU: 1 PID: 917 Comm: Xorg Tainted: GW > 5.3.16-300.fc31.x86_64 #1 > Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A300M-STX, BIOS > P3.50 05/15/2019 > RIP: 0010:write_i2c_retimer_setting.cold+0xae/0xb5 [amdgpu] > Code: 6c f4 a0 c1 0f 0b e9 0e 0d fd ff 48 c7 c7 80 ee 7f c0 e8 59 f4 a0 c1 > 0f 0b e9 27 0b fd ff 48 c7 c7 80 ee 7f c0 e8 46 f4 a0 c1 <0f> 0b e9 fd 09 fd > ff 48 c7 c7 80 ee 7f c0 e8 33 f4 a0 c1 0f 0b e9 > RSP: 0018:be23c190f6a0 EFLAGS: 00010246 > RAX: 0024 RBX: 0001 RCX: > RDX: RSI: 99fc50657908 RDI: 99fc50657908 > RBP: be23c190f71c R08: 99fc50657908 R09: 072a > R10: 00024924 R11: 0003 R12: 005d > R13: R14: 99fc18140648 R15: > FS: 7fd0f4484f00() GS:99fc5064() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 55800df036e8 CR3: 0003ef71a000 CR4: 003406e0 > Call Trace: > -- Quick update: there is also a bug in Redhat bugzilla, which is directly repated: Bug link: https://bugzilla.redhat.com/show_bug.cgi?id=1786489 BTW, this happens both on the Display Port and the HDMI port. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/19] Rename Samsung and Exynos to lowercase
Hi all, The "Samsung" and "Exynos" names are written inconsistently in Linux kernel sources. Sometimes all uppercase (as SAMSUNG), sometimes lowercase with capital letter (as Samsung). This patchset tries to unify this towards "Samsung" and "Exynos" versions because: 1. "SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked names. Therefore they should be written with lowercase letters starting with capital letter. 2. The lowercase "Exynos" name is promoted by its manufacturer Samsung Electronics Co., Ltd., in advertisement materials and on website [1]. 3. Although advertisement materials usually use uppercase "SAMSUNG", the lowercase version is used in all legal aspects (e.g. on Wikipedia [2] and in privacy/legal statements on Samsung site [3]). Patches are independent of each other so I expect they will go through each maintainer's tree. Optionally let me know - I'll take it then through samsung-soc tree. [1] https://www.samsung.com/semiconductor/minisite/exynos/ [2] https://en.wikipedia.org/wiki/Samsung [3] https://www.samsung.com/semiconductor/privacy-global/ Best regards, Krzysztof Cc: Mauro Carvalho Chehab Cc: Rob Herring Cc: Mark Rutland Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Kamil Debski Cc: Sylwester Nawrocki Cc: Kishon Vijay Abraham I Cc: Jonathan Corbet Cc: Russell King Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Lezcano Cc: Thomas Gleixner Cc: Herbert Xu Cc: "David S. Miller" Cc: MyungJoo Ham Cc: Kyungmin Park Cc: Chanwoo Choi Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: David Airlie Cc: Daniel Vetter Cc: Lee Jones Cc: Byungho An Cc: Girish K S Cc: Vipul Pandya Cc: Jingoo Han Cc: Lorenzo Pieralisi Cc: Andrew Murray Cc: Bjorn Helgaas Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Sangbeom Kim Cc: Liam Girdwood Cc: Mark Brown Cc: Zhang Rui Cc: Amit Kucheria Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Felipe Balbi Cc: Alan Stern Cc: Arnd Bergmann Cc: linux-me...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: net...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Krzysztof Kozlowski (19): arm64: dts: exynos: Rename Samsung and Exynos to lowercase ARM: dts: samsung: Rename Samsung and Exynos to lowercase ARM: samsung: Rename Samsung and Exynos to lowercase soc: samsung: Rename Samsung and Exynos to lowercase thermal: exynos: Rename Samsung and Exynos to lowercase media: samsung: Rename Samsung and Exynos to lowercase usb: exynos: Rename Samsung and Exynos to lowercase memory: samsung: Rename Exynos to lowercase phy: exynos: Rename Exynos to lowercase clocksource/drivers/exynos_mct: Rename Exynos to lowercase crypto: exynos-rng - Rename Exynos to lowercase devfreq: exynos: Rename Exynos to lowercase drm/exynos: Rename Exynos to lowercase video: exynos: Rename Exynos to lowercase pci: exynos: Rename Exynos to lowercase serial: samsung: Rename Exynos to lowercase mfd: samsung: Rename Samsung to lowercase net: ethernet: sxgbe: Rename Samsung to lowercase regulator: samsung: Rename Samsung to lowercase .../bindings/media/exynos-jpeg-codec.txt | 2 +- .../devicetree/bindings/media/exynos5-gsc.txt | 2 +- .../bindings/media/samsung-fimc.txt | 2 +- .../bindings/media/samsung-mipi-csis.txt | 2 +- .../devicetree/bindings/phy/samsung-phy.txt | 6 ++-- .../driver-api/thermal/exynos_thermal.rst | 6 ++-- Documentation/media/v4l-drivers/fimc.rst | 6 ++-- Documentation/media/v4l-drivers/tuners.rst| 2 +- arch/arm/boot/dts/exynos5250-arndale.dts | 2 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +-- arch/arm/boot/dts/exynos5250.dtsi | 8 ++--- arch/arm/boot/dts/exynos5260-xyref5260.dts| 4 +-- arch/arm/boot/dts/exynos5260.dtsi | 2 +- arch/arm/boot/dts/exynos5410-smdk5410.dts | 4 +-- arch/arm/boot/dts/exynos5410.dtsi | 6 ++-- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 +- arch/arm/boot/dts/exynos5420-cpus.dtsi| 2 +- arch/arm/boot/dts/exynos5420-smdk5420.dts | 4 +-- arch/arm/boot/dts/exynos5420.dtsi | 6 ++-- arch/arm/boot/dts/exynos5422-cpus.dtsi| 2 +- arch/arm/boot/dts/exynos5800.dtsi | 6 ++-- arch/arm/boot/dts/s3c2416-smdk2416.dts| 2 +- arch/arm/boot/dts/s3c6410-smdk6410.dts| 4 +-- arch/arm/mach-exynos/Kconfig | 36 +-- arch/arm/mach-exynos/common.h | 2 +- arch/arm/mach-exynos/exynos.c | 4 +-- arch/arm/mach-exynos/include/mach/map.h | 2 +- arch/arm/mach-exynos/pm.c | 2 +- a
[PATCH 14/19] video: exynos: Rename Exynos to lowercase
Fix up inconsistent usage of upper and lowercase letters in "Exynos" name. "EXYNOS" is not an abbreviation but a regular trademarked name. Therefore it should be written with lowercase letters starting with capital letter. The lowercase "Exynos" name is promoted by its manufacturer Samsung Electronics Co., Ltd., in advertisement materials and on website. Signed-off-by: Krzysztof Kozlowski --- include/video/samsung_fimd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index b6571c3cfa31..c4a93ce1de48 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -10,7 +10,7 @@ * * This is the register set for the fimd and new style framebuffer interface * found from the S3C2443 onwards into the S3C2416, S3C2450, the - * S3C64XX series such as the S3C6400 and S3C6410, and EXYNOS series. + * S3C64XX series such as the S3C6400 and S3C6410, and Exynos series. */ /* VIDCON0 */ -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/19] drm/exynos: Rename Exynos to lowercase
Fix up inconsistent usage of upper and lowercase letters in "Exynos"
name.
"EXYNOS" is not an abbreviation but a regular trademarked name.
Therefore it should be written with lowercase letters starting with
capital letter.
The lowercase "Exynos" name is promoted by its manufacturer Samsung
Electronics Co., Ltd., in advertisement materials and on website.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/exynos/Kconfig | 6 +++---
include/uapi/drm/exynos_drm.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 6f7d3b3b3628..6417f374b923 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,13 +1,13 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_EXYNOS
- tristate "DRM Support for Samsung SoC EXYNOS Series"
+ tristate "DRM Support for Samsung SoC Exynos Series"
depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS ||
ARCH_MULTIPLATFORM || COMPILE_TEST)
depends on MMU
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
select SND_SOC_HDMI_CODEC if SND_SOC
help
- Choose this option if you have a Samsung SoC EXYNOS chipset.
+ Choose this option if you have a Samsung SoC Exynos chipset.
If M is selected the module will be called exynosdrm.
if DRM_EXYNOS
@@ -62,7 +62,7 @@ config DRM_EXYNOS_DSI
This enables support for Exynos MIPI-DSI device.
config DRM_EXYNOS_DP
- bool "EXYNOS specific extensions for Analogix DP driver"
+ bool "Exynos specific extensions for Analogix DP driver"
depends on DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON
select DRM_ANALOGIX_DP
default DRM_EXYNOS
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index 45c6582b3df3..a51aa1c618c1 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -394,7 +394,7 @@ struct drm_exynos_ioctl_ipp_commit {
#define DRM_IOCTL_EXYNOS_IPP_COMMITDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_IPP_COMMIT, struct drm_exynos_ioctl_ipp_commit)
-/* EXYNOS specific events */
+/* Exynos specific events */
#define DRM_EXYNOS_G2D_EVENT 0x8000
#define DRM_EXYNOS_IPP_EVENT 0x8002
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204559] amdgpu: kernel oops with constant gpu resets while using mpv
https://bugzilla.kernel.org/show_bug.cgi?id=204559 --- Comment #13 from Maxim Sheviakov (shoeg...@tutanota.com) --- I'm on kernel 5.4.7 now and seems like this particular issue is fixed - I tried playing some movies with runpm enabled and things seemed to be okay. Though it looks like dGPU performance with runpm is considerably worse than without runpm, but I guess that's another issue :) Can anyone confirm if everything's fine now? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: display: panel: Add AUO B116XAK01 panel bindings
From: Rob Clark
Signed-off-by: Rob Clark
---
.../bindings/display/panel/auo,b116xa01.yaml | 32 +++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,b116xa01.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/auo,b116xa01.yaml
b/Documentation/devicetree/bindings/display/panel/auo,b116xa01.yaml
new file mode 100644
index ..6cb8ed9b2c0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,b116xa01.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,b116xa01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO B116XAK01 eDP TFT LCD Panel
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - auo,b116xa01
+ port: true
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+panel {
+compatible = "auo,b116xa01";
+port {
+panel_in: endpoint {
+remote-endpoint = <&edp_out>;
+};
+};
+};
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panel: Add support for AUO B116XAK01 panel
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5d487686d25c..895a25cfc54f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -680,6 +680,35 @@ static const struct panel_desc auo_b116xw03 = {
},
};
+static const struct drm_display_mode auo_b116xak01_mode = {
+ .clock = 69300,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 48,
+ .hsync_end = 1366 + 48 + 32,
+ .htotal = 1366 + 48 + 32 + 10,
+ .vdisplay = 768,
+ .vsync_start = 768 + 4,
+ .vsync_end = 768 + 4 + 6,
+ .vtotal = 768 + 4 + 6 + 15,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc auo_b116xak01 = {
+ .modes = &auo_b116xak01_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 256,
+ .height = 144,
+ },
+ .delay = {
+ .hpd_absent_delay = 200,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
+};
+
static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -3125,6 +3154,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "auo,b133htn01",
.data = &auo_b133htn01,
+ }, {
+ .compatible = "auo,b116xa01",
+ .data = &auo_b116xak01,
}, {
.compatible = "auo,b133xtn01",
.data = &auo_b133xtn01,
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2 2/7] iommu/arm-smmu: Add domain attribute for QCOM system cache
On Thu, Jan 2, 2020 at 3:02 AM Sharat Masetty wrote:
>
> From: Vivek Gautam
>
> Add iommu domain attribute for using system cache aka last level
> cache on QCOM SoCs by client drivers like GPU to set right
> attributes for caching the hardware pagetables into the system cache.
>
> Signed-off-by: Vivek Gautam
> Co-developed-by: Sai Prakash Ranjan
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/arm-smmu-qcom.c | 10 ++
> drivers/iommu/arm-smmu.c | 14 ++
> drivers/iommu/arm-smmu.h | 1 +
> include/linux/iommu.h | 1 +
> 4 files changed, 26 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
> index 24c071c..d1d22df 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -30,7 +30,17 @@ static int qcom_sdm845_smmu500_reset(struct
> arm_smmu_device *smmu)
> return ret;
> }
>
> +static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
> + struct io_pgtable_cfg *pgtbl_cfg)
> +{
> + if (smmu_domain->sys_cache)
> + pgtbl_cfg->coherent_walk = false;
just curious, does coherent walk not work with sys-cache, or is it
just that it is kind of pointless (given that, afaiu, the pagetables
can be cached by the system cache)?
> +
> + return 0;
> +}
> +
> static const struct arm_smmu_impl qcom_smmu_impl = {
> + .init_context = qcom_smmu_init_context,
> .reset = qcom_sdm845_smmu500_reset,
> };
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 4f7e0c0..055b548 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1466,6 +1466,9 @@ static int arm_smmu_domain_get_attr(struct iommu_domain
> *domain,
> case DOMAIN_ATTR_NESTING:
> *(int *)data = (smmu_domain->stage ==
> ARM_SMMU_DOMAIN_NESTED);
> return 0;
> + case DOMAIN_ATTR_QCOM_SYS_CACHE:
> + *((int *)data) = smmu_domain->sys_cache;
> + return 0;
> default:
> return -ENODEV;
> }
> @@ -1506,6 +1509,17 @@ static int arm_smmu_domain_set_attr(struct
> iommu_domain *domain,
> else
> smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
> break;
> + case DOMAIN_ATTR_QCOM_SYS_CACHE:
> + if (smmu_domain->smmu) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> +
> + if (*((int *)data))
> + smmu_domain->sys_cache = true;
> + else
> + smmu_domain->sys_cache = false;
> + break;
> default:
> ret = -ENODEV;
> }
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index f57cdbe..8aeaaf0 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -322,6 +322,7 @@ struct arm_smmu_domain {
> struct mutexinit_mutex; /* Protects smmu pointer
> */
> spinlock_t cb_lock; /* Serialises ATS1* ops and
> TLB syncs */
> struct iommu_domain domain;
> + boolsys_cache;
> };
>
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 0c60e75..bd61c60 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -127,6 +127,7 @@ enum iommu_attr {
> DOMAIN_ATTR_FSL_PAMUV1,
> DOMAIN_ATTR_NESTING,/* two stages of translation */
> DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
> + DOMAIN_ATTR_QCOM_SYS_CACHE,
Given that IOMMU_QCOM_SYS_CACHE was renamed to IOMMU_SYS_CACHE_ONLY, I
wonder if this domain attr should simply be DOMAIN_ATTR_SYS_CACHE?
But that said, the function of this domain attr seems to simply be to
disable coherent walk.. I wonder if naming the domain attr after what
it does would make more sense?
BR,
-R
> DOMAIN_ATTR_MAX,
> };
>
> --
> 1.9.1
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19
https://bugzilla.kernel.org/show_bug.cgi?id=201497 chrisk...@goldmail.de changed: What|Removed |Added CC||chrisk...@goldmail.de --- Comment #13 from chrisk...@goldmail.de --- Same here with Acer XB240H and AMD Vega 56: https://bugzilla.kernel.org/show_bug.cgi?id=205987 All Kernels >4.15 have this -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.5-rc5
The pull request you sent on Fri, 3 Jan 2020 16:57:38 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-01-03 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ca78fdeb00fa656f09afee977750e85da929d259 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19
https://bugzilla.kernel.org/show_bug.cgi?id=201497 --- Comment #14 from chrisk...@goldmail.de --- *** Bug 205987 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add support for AUO B116XAK01 panel
Hi Rob.
On Fri, Jan 03, 2020 at 10:30:24AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/panel/panel-simple.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 5d487686d25c..895a25cfc54f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -680,6 +680,35 @@ static const struct panel_desc auo_b116xw03 = {
> },
> };
>
> +static const struct drm_display_mode auo_b116xak01_mode = {
> + .clock = 69300,
> + .hdisplay = 1366,
> + .hsync_start = 1366 + 48,
> + .hsync_end = 1366 + 48 + 32,
> + .htotal = 1366 + 48 + 32 + 10,
> + .vdisplay = 768,
> + .vsync_start = 768 + 4,
> + .vsync_end = 768 + 4 + 6,
> + .vtotal = 768 + 4 + 6 + 15,
> + .vrefresh = 60,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> +static const struct panel_desc auo_b116xak01 = {
> + .modes = &auo_b116xak01_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 256,
> + .height = 144,
> + },
> + .delay = {
> + .hpd_absent_delay = 200,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .connector_type = DRM_MODE_CONNECTOR_eDP,
> +};
Entries in alphabetical order - check.
.connector_type specified - check.
.flags and .bus_format specified - check.
.bus_flags not specified but optional - OK.
> +
> static const struct drm_display_mode auo_b133xtn01_mode = {
> .clock = 69500,
> .hdisplay = 1366,
> @@ -3125,6 +3154,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "auo,b133htn01",
> .data = &auo_b133htn01,
> + }, {
> + .compatible = "auo,b116xa01",
> + .data = &auo_b116xak01,
This entry most also be in alphabetical order.
> }, {
> .compatible = "auo,b133xtn01",
> .data = &auo_b133xtn01,
Please fix and resend.
I am in general holding back on patches to panel-simple.
I hope we can reach a decision for the way forward with the bindings
files sometimes next week.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: panel: Add AUO B116XAK01 panel bindings
Hi Rob.
On Fri, Jan 03, 2020 at 10:30:23AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> .../bindings/display/panel/auo,b116xa01.yaml | 32 +++
> 1 file changed, 32 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/auo,b116xa01.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/auo,b116xa01.yaml
> b/Documentation/devicetree/bindings/display/panel/auo,b116xa01.yaml
> new file mode 100644
> index ..6cb8ed9b2c0a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/auo,b116xa01.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/auo,b116xa01.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AUO B116XAK01 eDP TFT LCD Panel
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - auo,b116xa01
> + port: true
Add an empty line before listing the other properties.
> +
> +required:
> + - compatible
The panel needs power - so power-supply is required too.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +panel {
> +compatible = "auo,b116xa01";
> +port {
> +panel_in: endpoint {
> +remote-endpoint = <&edp_out>;
> +};
> +};
> +};
For simple panels the example is more or less noise.
We are discusing to move all binding info to a few files for the simple
(dumb) panels.
This is a candidate for this as well.
But there is not yet a conclusion.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH resend 1/2] drm/connector: Split out orientation quirk detection (v2)
On Thu, Jan 02, 2020 at 10:35:28PM +0100, Hans de Goede wrote:
> Hi Rodrigo,
>
> Thank you for the review.
>
> On 02-01-2020 19:17, Rodrigo Vivi wrote:
> > On Mon, Dec 16, 2019 at 12:51:57PM +0100, Hans de Goede wrote:
> > > From: Derek Basehore
> > >
> > > Not every platform needs quirk detection for panel orientation, so
> > > split the drm_connector_init_panel_orientation_property into two
> > > functions. One for platforms without the need for quirks, and the
> > > other for platforms that need quirks.
> > >
> > > Hans de Goede (changes in v2):
> > >
> > > Rename the function from drm_connector_init_panel_orientation_property
> > > to drm_connector_set_panel_orientation[_with_quirk] and pass in the
> > > panel-orientation to set.
> > >
> > > Beside the rename, also make the function set the passed in value
> > > only once, if the value was set before (to a value other then
> > > DRM_MODE_PANEL_ORIENTATION_UNKNOWN) make any further set calls a no-op.
> > >
> > > This change is preparation for allowing the user to override the
> > > panel-orientation for any connector from the kernel commandline.
> > > When the panel-orientation is overridden this way, then we must ignore
> > > the panel-orientation detection done by the driver.
> > >
> > > Signed-off-by: Derek Basehore
> > > Signed-off-by: Hans de Goede
> > > ---
> > > drivers/gpu/drm/drm_connector.c | 74 ++---
> > > drivers/gpu/drm/i915/display/icl_dsi.c | 5 +-
> > > drivers/gpu/drm/i915/display/intel_dp.c | 9 ++-
> > > drivers/gpu/drm/i915/display/vlv_dsi.c | 5 +-
> > > include/drm/drm_connector.h | 9 ++-
> > > 5 files changed, 71 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > b/drivers/gpu/drm/drm_connector.c
> > > index 0965632008a9..f4fa5c59717d 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -1139,7 +1139,8 @@ static const struct drm_prop_enum_list
> > > dp_colorspaces[] = {
> > >* coordinates, so if userspace rotates the picture to adjust for
> > >* the orientation it must also apply the same transformation to
> > > the
> > >* touchscreen input coordinates. This property is initialized by
> > > calling
> > > - * drm_connector_init_panel_orientation_property().
> > > + * drm_connector_set_panel_orientation() or
> > > + * drm_connector_set_panel_orientation_with_quirk()
> >
> > do we have a better name than quirks for these dsi modes?
>
> The difference between the 2 functions is that the second one calls
> drm_get_panel_orientation_quirk() and that if that returns a valid
> orientation it overwrites the passed orientation with the return value
> from drm_get_panel_orientation_quirk(), so the name seems correct.
>
> As for drm_get_panel_orientation_quirk() itself that currently is only
> defined on x86 (it is a static inline no-op elsewhere) and it used
> DMI string matching to check for a model specific quirk. So again the
> name seems correct.
>
> > >*
> > >* scaling mode:
> > >* This property defines how a non-native mode is upscaled to the
> > > native
> > > @@ -2046,38 +2047,41 @@ void drm_connector_set_vrr_capable_property(
> > > EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> > > /**
> > > - * drm_connector_init_panel_orientation_property -
> > > - * initialize the connecters panel_orientation property
> > > - * @connector: connector for which to init the panel-orientation
> > > property.
> > > - * @width: width in pixels of the panel, used for panel quirk detection
> > > - * @height: height in pixels of the panel, used for panel quirk detection
> > > + * drm_connector_set_panel_orientation - sets the connecter's
> > > panel_orientation
> > > + * @connector: connector for which to set the panel-orientation property.
> > > + * @panel_orientation: drm_panel_orientation value to set
> > > + *
> > > + * This function sets the connector's panel_orientation and attaches
> > > + * a "panel orientation" property to the connector.
> > >*
> > > - * This function should only be called for built-in panels, after setting
> > > - * connector->display_info.panel_orientation first (if known).
> > > + * Calling this function on a connector where the panel_orientation has
> > > + * already been set is a no-op (e.g. the orientation has been overridden
> > > with
> > > + * a kernel commandline option).
> > >*
> > > - * This function will check for platform specific (e.g. DMI based) quirks
> > > - * overriding display_info.panel_orientation first, then if
> > > panel_orientation
> > > - * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
> > > - * "panel orientation" property to the connector.
> > > + * It is allowed to call this function with a panel_orientation of
> > > + * DRM_MODE_PANEL_ORIENTATION_UNKNOWN, in which case it is a no-op.
> > >*
> > >* Returns:
> > >*
Re: [Intel-gfx] [PATCH resend 2/2] drm/connector: Hookup the new drm_cmdline_mode panel_orientation member
On Mon, Dec 16, 2019 at 12:51:58PM +0100, Hans de Goede wrote:
> If the new video=... panel_orientation option is set for a connector, honor
> it and setup a matching "panel orientation" property on the connector.
>
> BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
> Acked-by: Maxime Ripard
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/drm_connector.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f4fa5c59717d..d9d7fef26275 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -140,6 +140,13 @@ static void drm_connector_get_cmdline_mode(struct
> drm_connector *connector)
> connector->force = mode->force;
> }
>
> + if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
> + DRM_INFO("setting connector %s panel_orientation to %d\n",
> + connector->name, mode->panel_orientation);
Since this overrides the standard behavior should this deserve a debug that
is a bit more clear that we are forcing the mode with the cmdline?
> + drm_connector_set_panel_orientation(connector,
> + mode->panel_orientation);
> + }
> +
> DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n",
> connector->name, mode->name,
> mode->xres, mode->yres,
> --
> 2.23.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add support for AUO B116XAK01 panel
On Fri, Jan 3, 2020 at 11:31 AM Sam Ravnborg wrote:
>
> Hi Rob.
>
> On Fri, Jan 03, 2020 at 10:30:24AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 32
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 5d487686d25c..895a25cfc54f 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -680,6 +680,35 @@ static const struct panel_desc auo_b116xw03 = {
> > },
> > };
> >
> > +static const struct drm_display_mode auo_b116xak01_mode = {
> > + .clock = 69300,
> > + .hdisplay = 1366,
> > + .hsync_start = 1366 + 48,
> > + .hsync_end = 1366 + 48 + 32,
> > + .htotal = 1366 + 48 + 32 + 10,
> > + .vdisplay = 768,
> > + .vsync_start = 768 + 4,
> > + .vsync_end = 768 + 4 + 6,
> > + .vtotal = 768 + 4 + 6 + 15,
> > + .vrefresh = 60,
> > + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> > +};
> > +
> > +static const struct panel_desc auo_b116xak01 = {
> > + .modes = &auo_b116xak01_mode,
> > + .num_modes = 1,
> > + .bpc = 6,
> > + .size = {
> > + .width = 256,
> > + .height = 144,
> > + },
> > + .delay = {
> > + .hpd_absent_delay = 200,
> > + },
> > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > + .connector_type = DRM_MODE_CONNECTOR_eDP,
> > +};
> Entries in alphabetical order - check.
> .connector_type specified - check.
> .flags and .bus_format specified - check.
> .bus_flags not specified but optional - OK.
>
> > +
> > static const struct drm_display_mode auo_b133xtn01_mode = {
> > .clock = 69500,
> > .hdisplay = 1366,
> > @@ -3125,6 +3154,9 @@ static const struct of_device_id platform_of_match[]
> > = {
> > }, {
> > .compatible = "auo,b133htn01",
> > .data = &auo_b133htn01,
> > + }, {
> > + .compatible = "auo,b116xa01",
> > + .data = &auo_b116xak01,
> This entry most also be in alphabetical order.
>
> > }, {
> > .compatible = "auo,b133xtn01",
> > .data = &auo_b133xtn01,
>
> Please fix and resend.
>
> I am in general holding back on patches to panel-simple.
> I hope we can reach a decision for the way forward with the bindings
> files sometimes next week.
I've fixed the sort-order and the couple things you've pointed out in
the bindings. Not sure if you want me to resend immediately or
hang-tight until the bindings discussion is resolved?
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add support for AUO B116XAK01 panel
Hi Rob. > > Please fix and resend. > > > > I am in general holding back on patches to panel-simple. > > I hope we can reach a decision for the way forward with the bindings > > files sometimes next week. > > I've fixed the sort-order and the couple things you've pointed out in > the bindings. Not sure if you want me to resend immediately or > hang-tight until the bindings discussion is resolved? Could we give it until Wednesday - if we do not resolve the binding discussion I will process panel patches in the weekend or maybe a day before. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add support for AUO B116XAK01 panel
On Fri, Jan 3, 2020 at 11:54 AM Sam Ravnborg wrote: > > Hi Rob. > > > > Please fix and resend. > > > > > > I am in general holding back on patches to panel-simple. > > > I hope we can reach a decision for the way forward with the bindings > > > files sometimes next week. > > > > I've fixed the sort-order and the couple things you've pointed out in > > the bindings. Not sure if you want me to resend immediately or > > hang-tight until the bindings discussion is resolved? > Could we give it until Wednesday - if we do not resolve the > binding discussion I will process panel patches in the weekend or maybe > a day before. sounds good BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: Avoid NULL pointer dereference
Back from the holidays!
Reviewed-by: Lyude Paul
Do you need me to push this to drm-misc?
On Thu, 2019-12-26 at 10:31 +0800, Wayne Lin wrote:
> [Why]
> Found kernel NULL pointer dereference under the below situation:
>
> src — HDMI_Monitor src — HDMI_Monitor
> e.g.: \=>
>MSTB — MSTB (unplug) MSTB — MSTB
>
> When display 1 HDMI and 2 DP daisy chain monitors, unplugging the dp
> cable connected to source causes kernel NULL pointer dereference at
> drm_dp_mst_atomic_check_bw_limit(). When calculating pbn_limit, if
> branch is null, accessing "&branch->ports" causes the problem.
>
> [How]
> Judge branch is null or not at the beginning. If it is null, return 0.
>
> Signed-off-by: Wayne Lin
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 7d2d31eaf003..a6473e3ab448 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4707,6 +4707,9 @@ int drm_dp_mst_atomic_check_bw_limit(struct
> drm_dp_mst_branch *branch,
> struct drm_dp_vcpi_allocation *vcpi;
> int pbn_limit = 0, pbn_used = 0;
>
> + if (!branch)
> + return 0;
> +
> list_for_each_entry(port, &branch->ports, next) {
> if (port->mstb)
> if (drm_dp_mst_atomic_check_bw_limit(port->mstb,
> mst_state))
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/19] Rename Samsung and Exynos to lowercase
On Fri, Jan 3, 2020 at 10:11 AM Krzysztof Kozlowski wrote: > > Hi all, > > The "Samsung" and "Exynos" names are written inconsistently in Linux > kernel sources. Sometimes all uppercase (as SAMSUNG), sometimes > lowercase with capital letter (as Samsung). > > This patchset tries to unify this towards "Samsung" and "Exynos" > versions because: > > 1. "SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked > names. Therefore they should be written with lowercase letters starting > with capital letter. > > 2. The lowercase "Exynos" name is promoted by its manufacturer Samsung >Electronics Co., Ltd., in advertisement materials and on website [1]. > > 3. Although advertisement materials usually use uppercase "SAMSUNG", the >lowercase version is used in all legal aspects (e.g. on Wikipedia [2] >and in privacy/legal statements on Samsung site [3]). > > Patches are independent of each other so I expect they will go through > each maintainer's tree. Optionally let me know - I'll take it then > through samsung-soc tree. > > [1] https://www.samsung.com/semiconductor/minisite/exynos/ > [2] https://en.wikipedia.org/wiki/Samsung > [3] https://www.samsung.com/semiconductor/privacy-global/ > > Best regards, > Krzysztof > > Cc: Mauro Carvalho Chehab > Cc: Rob Herring > Cc: Mark Rutland > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Kamil Debski > Cc: Sylwester Nawrocki > Cc: Kishon Vijay Abraham I > Cc: Jonathan Corbet > Cc: Russell King > Cc: Bartlomiej Zolnierkiewicz > Cc: Daniel Lezcano > Cc: Thomas Gleixner > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: MyungJoo Ham > Cc: Kyungmin Park > Cc: Chanwoo Choi > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: David Airlie > Cc: Daniel Vetter > Cc: Lee Jones > Cc: Byungho An > Cc: Girish K S > Cc: Vipul Pandya > Cc: Jingoo Han > Cc: Lorenzo Pieralisi > Cc: Andrew Murray > Cc: Bjorn Helgaas > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Sangbeom Kim > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Zhang Rui > Cc: Amit Kucheria > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: Felipe Balbi > Cc: Alan Stern > Cc: Arnd Bergmann > Cc: linux-me...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-cry...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: net...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-ser...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-fb...@vger.kernel.org > > Krzysztof Kozlowski (19): > arm64: dts: exynos: Rename Samsung and Exynos to lowercase > ARM: dts: samsung: Rename Samsung and Exynos to lowercase > ARM: samsung: Rename Samsung and Exynos to lowercase > soc: samsung: Rename Samsung and Exynos to lowercase > thermal: exynos: Rename Samsung and Exynos to lowercase > media: samsung: Rename Samsung and Exynos to lowercase > usb: exynos: Rename Samsung and Exynos to lowercase > memory: samsung: Rename Exynos to lowercase > phy: exynos: Rename Exynos to lowercase > clocksource/drivers/exynos_mct: Rename Exynos to lowercase > crypto: exynos-rng - Rename Exynos to lowercase > devfreq: exynos: Rename Exynos to lowercase > drm/exynos: Rename Exynos to lowercase > video: exynos: Rename Exynos to lowercase > pci: exynos: Rename Exynos to lowercase > serial: samsung: Rename Exynos to lowercase > mfd: samsung: Rename Samsung to lowercase > net: ethernet: sxgbe: Rename Samsung to lowercase > regulator: samsung: Rename Samsung to lowercase > > .../bindings/media/exynos-jpeg-codec.txt | 2 +- > .../devicetree/bindings/media/exynos5-gsc.txt | 2 +- > .../bindings/media/samsung-fimc.txt | 2 +- > .../bindings/media/samsung-mipi-csis.txt | 2 +- > .../devicetree/bindings/phy/samsung-phy.txt | 6 ++-- Please split bindings to a separate patch. > .../driver-api/thermal/exynos_thermal.rst | 6 ++-- > Documentation/media/v4l-drivers/fimc.rst | 6 ++-- > Documentation/media/v4l-drivers/tuners.rst| 2 +- > arch/arm/boot/dts/exynos5250-arndale.dts | 2 +- > arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +-- > arch/arm/boot/dts/exynos5250.dtsi | 8 ++--- > arch/arm/boot/dts/exynos5260-xyref5260.dts| 4 +-- > arch/arm/boot/dts/exynos5260.dtsi | 2 +- > arch/arm/boot/dts/exynos5410-smdk5410.dts | 4 +-- > arch/arm/boot/dts/exynos5410.dtsi | 6 ++-- > arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 +- > arch/arm/boot/dts/exynos5420-cpus.dtsi| 2 +- > arch/arm/boot/dts/exynos5420-smdk5420.dts | 4 +-- > arch/arm/boot/dts/exynos5420.dtsi | 6 ++-- > arch/arm/boot/dts/exynos5422-cpus.dtsi| 2 +- > arch/arm/boot/dts/exynos5800.dtsi | 6 ++-- > arch/arm/boot/dts/s3c2416-smdk2416.dts
Re: [PATCH v2] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
Reviewed-by: Lyude Paul Thanks for all of the contributions you've made as of late! I will go ahead and push this into drm-misc-fixes On Fri, 2020-01-03 at 13:50 +0800, Wayne Lin wrote: > [Why] > According to DP spec, it should shift left 4 digits for NO_STOP_BIT > in REMOTE_I2C_READ message. Not 5 digits. > > In current code, NO_STOP_BIT is always set to zero which means I2C > master is always generating a I2C stop at the end of each I2C write > transaction while handling REMOTE_I2C_READ sideband message. This issue > might have the generated I2C signal not meeting the requirement. Take > random read in I2C for instance, I2C master should generate a repeat > start to start to read data after writing the read address. This issue > will cause the I2C master to generate a stop-start rather than a > re-start which is not expected in I2C random read. > > [How] > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in > drm_dp_encode_sideband_req(). > > Changes since v1:(https://patchwork.kernel.org/patch/11312667/) > * Add more descriptions in commit and cc to stable > > Fixes: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper (v0.6)) > Reviewed-by: Harry Wentland > Signed-off-by: Wayne Lin > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > b/drivers/gpu/drm/drm_dp_mst_topology.c > index 1cf5f8b8bbb8..9d24c98bece1 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct > drm_dp_sideband_msg_req_body *req, > memcpy(&buf[idx], req- > >u.i2c_read.transactions[i].bytes, req- > >u.i2c_read.transactions[i].num_bytes); > idx += req->u.i2c_read.transactions[i].num_bytes; > > - buf[idx] = (req- > >u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5; > + buf[idx] = (req- > >u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4; > buf[idx] |= (req- > >u.i2c_read.transactions[i].i2c_transaction_delay & 0xf); > idx++; > } -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
Oh! Just a friendly tip, I fixed this before pushing your patch:
➜ drm-maint git:(drm-misc-fixes) dim push
dim: 0b1d54cedbb4 ("drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ"):
Fixes: SHA1 needs at least 12 digits:
dim: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper (v0.6))
dim: ERROR: issues in commits detected, aborting
For the future, we have a set of DRM maintainer tools (they're quite useful
for people who aren't maintainers though!) that you can use to make sure your
patch is formatted correctly ahead of time:
https://drm.pages.freedesktop.org/maintainer-tools/dim.html
Particularly useful commands:
* dim sparse # Checks for trivial code issues, like set but unused variables
* dim checkpatch # Checks for code style issues
* dim fixes $COMMIT_ID # Adds an appropriately formatted Fixes: tag
* dim cite $COMMIT_ID # Adds an appropriately formatted Reference: tag
On Fri, 2020-01-03 at 13:50 +0800, Wayne Lin wrote:
> [Why]
> According to DP spec, it should shift left 4 digits for NO_STOP_BIT
> in REMOTE_I2C_READ message. Not 5 digits.
>
> In current code, NO_STOP_BIT is always set to zero which means I2C
> master is always generating a I2C stop at the end of each I2C write
> transaction while handling REMOTE_I2C_READ sideband message. This issue
> might have the generated I2C signal not meeting the requirement. Take
> random read in I2C for instance, I2C master should generate a repeat
> start to start to read data after writing the read address. This issue
> will cause the I2C master to generate a stop-start rather than a
> re-start which is not expected in I2C random read.
>
> [How]
> Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
> drm_dp_encode_sideband_req().
>
> Changes since v1:(https://patchwork.kernel.org/patch/11312667/)
> * Add more descriptions in commit and cc to stable
>
> Fixes: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper (v0.6))
> Reviewed-by: Harry Wentland
> Signed-off-by: Wayne Lin
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 1cf5f8b8bbb8..9d24c98bece1 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct
> drm_dp_sideband_msg_req_body *req,
> memcpy(&buf[idx], req-
> >u.i2c_read.transactions[i].bytes, req-
> >u.i2c_read.transactions[i].num_bytes);
> idx += req->u.i2c_read.transactions[i].num_bytes;
>
> - buf[idx] = (req-
> >u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5;
> + buf[idx] = (req-
> >u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
> buf[idx] |= (req-
> >u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
> idx++;
> }
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v6 01/17] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display
On Fri, Jan 03, 2020 at 11:12:12AM +0800, Yongqiang Niu wrote:
> Update device tree binding documention for rdma_fifo_size
Typo. And write complete sentences.
>
> Signed-off-by: Yongqiang Niu
> ---
> .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 13
> +
> 1 file changed, 13 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index 681502e..34bef44 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -70,6 +70,10 @@ Required properties (DMA function blocks):
>argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>for details.
>
> +Required properties (DMA function blocks):
> +- mediatek,rdma_fifo_size: rdma fifo size may be different even in same SOC,
> add this
> + property to the corresponding rdma
s/_/-/
Valid values? Max value?
> +
> Examples:
>
> mmsys: clock-controller@1400 {
> @@ -211,3 +215,12 @@ od@14023000 {
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> clocks = <&mmsys CLK_MM_DISP_OD>;
> };
> +
> +rdma1: rdma@1400c000 {
> + compatible = "mediatek,mt8183-disp-rdma";
> + reg = <0 0x1400c000 0 0x1000>;
> + interrupts = ;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> + clocks = <&mmsys CLK_MM_DISP_RDMA1>;
> + mediatek,rdma_fifo_size = <2048>;
> +};
A new property doesn't really warrant a whole new example.
> \ No newline at end of file
^^^
> --
> 1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] dt-bindings: display: Document the Xylon LogiCVC display controller
On Tue, 3 Dec 2019 16:06:04 +0100, Paul Kocialkowski wrote: > The Xylon LogiCVC is a display controller implemented as programmable > logic in Xilinx FPGAs. > > Signed-off-by: Paul Kocialkowski > --- > .../display/xylon,logicvc-display.yaml| 313 ++ > 1 file changed, 313 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/nouveau: Add HD-audio component notifier support
Got shown this patch at work and realized it still needed review, so I went
ahead and did that :)
Reviewed-by: Lyude Paul
On Mon, 2019-07-22 at 16:38 +0200, Takashi Iwai wrote:
> This patch adds the support for the notification of HD-audio hotplug
> via the already existing drm_audio_component framework. This allows
> us more reliable hotplug notification and ELD transfer without
> accessing HD-audio bus; it's more efficient, and more importantly, it
> works without waking up the runtime PM.
>
> The implementation is rather simplistic: nouveau driver provides the
> get_eld ops for HD-audio, and it notifies the audio hotplug via
> pin_eld_notify callback upon each nv50_audio_enable() and _disable()
> call. As the HD-audio pin assignment seems corresponding to the CRTC,
> the crtc->index number is passed directly as the zero-based port
> number.
>
> The bind and unbind callbacks handle the device-link so that it
> assures the PM call order.
>
> Signed-off-by: Takashi Iwai
> ---
> drivers/gpu/drm/nouveau/Kconfig | 1 +
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 111
>
> drivers/gpu/drm/nouveau/nouveau_drv.h | 7 ++
> 3 files changed, 119 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/Kconfig
> b/drivers/gpu/drm/nouveau/Kconfig
> index 96b9814e6d06..33ccf11bd70d 100644
> --- a/drivers/gpu/drm/nouveau/Kconfig
> +++ b/drivers/gpu/drm/nouveau/Kconfig
> @@ -16,6 +16,7 @@ config DRM_NOUVEAU
> select INPUT if ACPI && X86
> select THERMAL if ACPI && X86
> select ACPI_VIDEO if ACPI && X86
> + select SND_HDA_COMPONENT if SND_HDA_CORE
> help
> Choose this option for open-source NVIDIA support.
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 8497768f1b41..919f3d3db161 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -466,12 +467,113 @@ nv50_dac_create(struct drm_connector *connector,
> struct dcb_output *dcbe)
> return 0;
> }
>
> +/*
> + * audio component binding for ELD notification
> + */
> +static void
> +nv50_audio_component_eld_notify(struct drm_audio_component *acomp, int
> port)
> +{
> + if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> + acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> + port, -1);
> +}
> +
> +static int
> +nv50_audio_component_get_eld(struct device *kdev, int port, int pipe,
> + bool *enabled, unsigned char *buf, int max_bytes)
> +{
> + struct drm_device *drm_dev = dev_get_drvdata(kdev);
> + struct nouveau_drm *drm = nouveau_drm(drm_dev);
> + struct drm_encoder *encoder;
> + struct nouveau_encoder *nv_encoder;
> + struct nouveau_connector *nv_connector;
> + struct nouveau_crtc *nv_crtc;
> + int ret = 0;
> +
> + *enabled = false;
> + drm_for_each_encoder(encoder, drm->dev) {
> + nv_encoder = nouveau_encoder(encoder);
> + nv_connector = nouveau_encoder_connector_get(nv_encoder);
> + nv_crtc = nouveau_crtc(encoder->crtc);
> + if (!nv_connector || !nv_crtc || nv_crtc->index != port)
> + continue;
> + *enabled = drm_detect_monitor_audio(nv_connector->edid);
> + if (*enabled) {
> + ret = drm_eld_size(nv_connector->base.eld);
> + memcpy(buf, nv_connector->base.eld,
> +min(max_bytes, ret));
> + }
> + break;
> + }
> + return ret;
> +}
> +
> +static const struct drm_audio_component_ops nv50_audio_component_ops = {
> + .get_eld = nv50_audio_component_get_eld,
> +};
> +
> +static int
> +nv50_audio_component_bind(struct device *kdev, struct device *hda_kdev,
> + void *data)
> +{
> + struct drm_device *drm_dev = dev_get_drvdata(kdev);
> + struct nouveau_drm *drm = nouveau_drm(drm_dev);
> + struct drm_audio_component *acomp = data;
> +
> + if (WARN_ON(!device_link_add(hda_kdev, kdev, DL_FLAG_STATELESS)))
> + return -ENOMEM;
> +
> + drm_modeset_lock_all(drm_dev);
> + acomp->ops = &nv50_audio_component_ops;
> + acomp->dev = kdev;
> + drm->audio.component = acomp;
> + drm_modeset_unlock_all(drm_dev);
> + return 0;
> +}
> +
> +static void
> +nv50_audio_component_unbind(struct device *kdev, struct device *hda_kdev,
> + void *data)
> +{
> + struct drm_device *drm_dev = dev_get_drvdata(kdev);
> + struct nouveau_drm *drm = nouveau_drm(drm_dev);
> + struct drm_audio_component *acomp = data;
> +
> + drm_modeset_lock_all(drm_dev);
> + drm->audio.component = NULL;
> + acomp->ops = NULL;
> + acomp->dev = NULL;
> + drm_modeset_unl
Re: [PATCH] drm/dp_mst: clear time slots for ports invalid
On Wed, 2019-12-25 at 06:45 +, Lin, Wayne wrote: > > -Original Message- > > From: Lyude Paul > > Sent: Saturday, December 21, 2019 8:12 AM > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org; > > amd-...@lists.freedesktop.org > > Cc: Kazlauskas, Nicholas ; Wentland, Harry > > ; Zuo, Jerry ; > > sta...@vger.kernel.org > > Subject: Re: [PATCH] drm/dp_mst: clear time slots for ports invalid > > > > Mhh-I think I understand the problem you're trying to solve here but I > > think this > > solution might be a bit overkill. When I did the rework of topology > > references > > for ports, I made it so that we can guarantee memory access to a port > > without > > it needing to be a valid part of the topology. As well, all parents of the > > port are > > guaranteed to be accessible for as long as the child is. Take a look at: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F01.org% > > 2Flinuxgraphics%2Fgfx-docs%2Fdrm%2Fgpu%2Fdrm-kms-helpers.html%23refco > > unt-relationships-in-a-topology&data=02%7C01%7Cwayne.lin%40amd.co > > m%7C722655b546c049dc081908d785aa6758%7C3dd8961fe4884e608e11a82d > > 994e183d%7C0%7C0%7C637124839257213115&sdata=Ctha3ja8kleeFOp > > PpA7EwDV1is81RAMsjqd1P6463ak%3D&reserved=0 > > > > It's also worth noting that because of this there's a lot of > > get_port_validated()/put_port_validated() calls in the MST helpers that > > are > > now bogus and need to be removed once I get a chance. For new code we > > should limit the use of topology references to sections of code where we > > need > > a guarantee that resources on the port/branch (such as a drm connector, dp > > aux port, etc.) won't go away for as long as we need to use them. > > > > Do you think we could change this patch so instead of removing it from the > > proposed payloads on the CONNECTION_STATUS_NOTIFY, we keep the port's > > memory allocation around until it's been removed from the proposed > > payloads > > table and clean it up there on the next payload update? > > > Really appreciate for your time and comments in detail. > > In this patch, I wanted to just set the proposed_vcpi->num_slots to 0 for > those > ports which are no longer in the topology due to there is no need to > allocate time > slots for these port. And expect those vcpi will be updated during next > update of > payload ID table by drm_dp_update_payload_part1(). > > I tried to use drm_dp_mst_topology_get_port_validated() as a helper to > decide whether a port is in the topology or not. Use this function to > iterate over > all ports that all proposed_vcpi[] drive to. If one port is not in the > topology, set the > num_slots of the proposed_vcpi for this port to 0. With num_slots as 0, > these > proposed_vcpi will be clean up in next payload table update by > drm_dp_update_payload_part1(). If a port is still in the topology, then > release > the reference count which was acquired previously from > drm_dp_mst_topology_get_port_validated() and do nothing. > > I didn't mean to kill invalid ports on receiving CONNECTION_STATUS_NOTIFY. > Sorry if I misuse or misunderstand something here? Ahh, it seems I made the mistake here then because from your explanation you're using the API exactly as intended :). All of this has me wondering if some day we should try to get rid of the payload tracking we have and move it into atomic. But, that's a problem for another day. Anyway-one small change below: > > > On Fri, 2019-12-06 at 16:39 +0800, Wayne Lin wrote: > > > [Why] > > > When change the connection status in a MST topology, mst device which > > > detect the event will send out CONNECTION_STATUS_NOTIFY messgae. > > > > > > e.g. src-mst-mst-sst => src-mst (unplug) mst-sst > > > > > > Currently, under the above case of unplugging device, ports which have > > > been allocated payloads and are no longer in the topology still occupy > > > time slots and recorded in proposed_vcpi[] of topology manager. > > > > > > If we don't clean up the proposed_vcpi[], when code flow goes to try > > > to update payload table by calling drm_dp_update_payload_part1(), we > > > will fail at checking port validation due to there are ports with > > > proposed time slots but no longer in the mst topology. As the result > > > of that, we will also stop updating the DPCD payload table of down > > > stream > > port. > > > [How] > > > While handling the CONNECTION_STATUS_NOTIFY message, add a detection > > > to see if the event indicates that a device is unplugged to an output > > > port. > > > If the detection is true, then iterrate over all proposed_vcpi[] to > > > see whether a port of the proposed_vcpi[] is still in the topology or > > > not. If the port is invalid, set its num_slots to 0. > > > > > > Thereafter, when try to update payload table by calling > > > drm_dp_update_payload_part1(), we can successfully update the DPCD > > > payload table of down stream port and clear the proposed_vcpi[] to NULL. > > > > > > Signed-off-by: Wayne Lin
Re: [PATCH v3 3/9] drm/i915/dp: Move vswing/pre-emphasis adjustment calculation
On Thu, Jan 02, 2020 at 03:56:09PM +0530, Manna, Animesh wrote:
> On 02-01-2020 14:48, Jani Nikula wrote:
> >On Mon, 30 Dec 2019, Animesh Manna wrote:
> >>vswing/pre-emphasis adjustment calculation is needed in processing
> >>of auto phy compliance request other than link training, so moved
> >>the same function in intel_dp.c.
> >I guess I'm still asking why you think this is better located in
> >intel_dp.c than intel_dp_link_training.c, as the function has been moved
> >once in the other direction already to split out stuff from intel_dp.c
> >and to make the file smaller. Even the file name suggests it should
> >really be in intel_dp_link_training.c, right?
>
> Just a thought, can we change the name to "intel_dp_link_config.c" from
> "intel_dp_link_training.c" which will provide little wider scope
> and all the function playing with link configuration can be under it and also
> exposed through header file.
>
> AFAIK, processing phy compliance request always do not need link training. I
> understood link training is very specific process consisting of clock
> recovery + channel eq.
> So I am afraid of exposing intel_get_adjust_train() from
> intel_dp_link_training.c which is not only specific to link-training. Need
> your suggestion.
>
> Regards,
> Animesh
>
I agree with Jani here and I think I had even suggested this earlier that
instead of moving this function to intel_dp.c
we should make it non static so it can be used even for PHY compliance but
since this function still deals
with adjusting training patterns IMHO it should still stay in
intel_dp_link_training.c
Manasi
> >
> >BR,
> >Jani.
> >
> >
> >>No functional change.
> >>
> >>v1: initial patch.
> >>v2:
> >>- used "intel_dp" prefix in function name. (Jani)
> >>- used array notation instead pointer for link_status. (Ville)
> >>
> >>Signed-off-by: Animesh Manna
> >>---
> >> drivers/gpu/drm/i915/display/intel_dp.c | 34 ++
> >> drivers/gpu/drm/i915/display/intel_dp.h | 4 +++
> >> .../drm/i915/display/intel_dp_link_training.c | 36 ++-
> >> 3 files changed, 40 insertions(+), 34 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >>b/drivers/gpu/drm/i915/display/intel_dp.c
> >>index 991f343579ef..2a27ee106089 100644
> >>--- a/drivers/gpu/drm/i915/display/intel_dp.c
> >>+++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >>@@ -4110,6 +4110,40 @@ ivb_cpu_edp_signal_levels(u8 train_set)
> >>}
> >> }
> >>+void
> >>+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> >>+ const u8 link_status[DP_LINK_STATUS_SIZE])
> >>+{
> >>+ u8 v = 0;
> >>+ u8 p = 0;
> >>+ int lane;
> >>+ u8 voltage_max;
> >>+ u8 preemph_max;
> >>+
> >>+ for (lane = 0; lane < intel_dp->lane_count; lane++) {
> >>+ u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
> >>+ lane);
> >>+ u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
> >>+ lane);
> >>+
> >>+ if (this_v > v)
> >>+ v = this_v;
> >>+ if (this_p > p)
> >>+ p = this_p;
> >>+ }
> >>+
> >>+ voltage_max = intel_dp_voltage_max(intel_dp);
> >>+ if (v >= voltage_max)
> >>+ v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
> >>+
> >>+ preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
> >>+ if (p >= preemph_max)
> >>+ p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
> >>+
> >>+ for (lane = 0; lane < 4; lane++)
> >>+ intel_dp->train_set[lane] = v | p;
> >>+}
> >>+
> >> void
> >> intel_dp_set_signal_levels(struct intel_dp *intel_dp)
> >> {
> >>diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> >>b/drivers/gpu/drm/i915/display/intel_dp.h
> >>index 3da166054788..83eadc87af26 100644
> >>--- a/drivers/gpu/drm/i915/display/intel_dp.h
> >>+++ b/drivers/gpu/drm/i915/display/intel_dp.h
> >>@@ -9,6 +9,7 @@
> >> #include
> >> #include
> >>+#include
> >> #include "i915_reg.h"
> >>@@ -91,6 +92,9 @@ void
> >> intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
> >> u8 dp_train_pat);
> >> void
> >>+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> >>+ const u8 link_status[DP_LINK_STATUS_SIZE]);
> >>+void
> >> intel_dp_set_signal_levels(struct intel_dp *intel_dp);
> >> void intel_dp_set_idle_link_train(struct intel_dp *intel_dp);
> >> u8
> >>diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >>b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >>index 2a1130dd1ad0..e8ff9e279800 100644
> >>--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >>+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >>@@ -34,38 +34,6 @@ intel_dp_dump_link_status(const u8
> >>link_status[DP_LINK_STATUS_SIZE])
> >> link_status[3], link_status[4], l
Re: [Intel-gfx] [PATCH v3 8/9] drm/i915/dp: Update the pattern as per request
On Thu, Jan 02, 2020 at 11:23:14AM +0200, Jani Nikula wrote:
> On Mon, 30 Dec 2019, Animesh Manna wrote:
> > As per request from DP phy compliance test few special
> > test pattern need to set by source. Added function
> > to set pattern in DP_COMP_CTL register. It will be
> > called along with other test parameters like vswing,
> > pre-emphasis programming in atomic_commit_tail path.
> >
> > Signed-off-by: Animesh Manna
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 55 +
> > 1 file changed, 55 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index cbefda9b6204..7c3f65e5d88b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5005,6 +5005,61 @@ static u8 intel_dp_prepare_phytest(struct intel_dp
> > *intel_dp)
> > return DP_TEST_ACK;
> > }
> >
> > +static inline void intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
>
> As a general rule, please only use the inline keyword for static inlines
> in headers. Sometimes, it's useful in small helpers, but usually you
> should just let the compiler decide what gets inlined.
>
> In this case, the inline probably just hides the compiler warning about
> the unused function.
>
> BR,
> Jani.
>
Yes I completely agree with Jani here, please do not use inline
other than some one line helpers in header files.
> > +{
> > + struct drm_i915_private *dev_priv =
> > + to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > + struct drm_dp_phy_test_params *data =
> > + &intel_dp->compliance.test_data.phytest;
> > + u32 temp;
> > +
> > + switch (data->phy_pattern) {
> > + case DP_PHY_TEST_PATTERN_NONE:
> > + DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
> > + I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port), 0x0);
> > + break;
> > + case DP_PHY_TEST_PATTERN_D10_2:
> > + DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
> > + I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
> > + DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
> > + break;
> > + case DP_PHY_TEST_PATTERN_ERROR_COUNT:
> > + DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
> > + I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
> > + DDI_DP_COMP_CTL_ENABLE |
> > + DDI_DP_COMP_CTL_SCRAMBLED_0);
> > + break;
> > + case DP_PHY_TEST_PATTERN_PRBS7:
> > + DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
> > + I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
> > + DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
> > + break;
> > + case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
> > + DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern\n");
> > + temp = ((data->custom80[0] << 24) | (data->custom80[1] << 16) |
> > + (data->custom80[2] << 8) | (data->custom80[3]));
> > + I915_WRITE(DDI_DP_COMP_PAT(intel_dig_port->base.port, 0), temp);
> > + temp = ((data->custom80[4] << 24) | (data->custom80[5] << 16) |
> > + (data->custom80[6] << 8) | (data->custom80[7]));
> > + I915_WRITE(DDI_DP_COMP_PAT(intel_dig_port->base.port, 1), temp);
> > + temp = ((data->custom80[8] << 8) | data->custom80[9]);
> > + I915_WRITE(DDI_DP_COMP_PAT(intel_dig_port->base.port, 2), temp);
> > + I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
> > + DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_CUSTOM80);
> > + break;
> > + case DP_PHY_TEST_PATTERN_CP2520:
> > + DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
> > + temp = ((data->hbr2_reset[1] << 8) | data->hbr2_reset[0]);
> > + I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
> > + DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
> > + temp);
> > + break;
> > + default:
> > + WARN(1, "Invalid Phy Test PAttern\n");
Small nit here, it should be PHY Pattern
Manasi
> > + }
> > +}
> > +
> > static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
> > {
> > u8 test_result = DP_TEST_NAK;
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/9] drm/amd/display: Align macro name as per DP spec
Harry, Jani - Since this also updates the AMD driver file, should this be merged through AMD tree and then backmerged to drm-misc ? Manasi On Mon, Dec 30, 2019 at 09:45:15PM +0530, Animesh Manna wrote: > [Why]: > Aligh with DP spec wanted to follow same naming convention. > > [How]: > Changed the macro name of the dpcd address used for getting requested > test-pattern. > > Cc: Harry Wentland > Cc: Alex Deucher > Reviewed-by: Harry Wentland > Signed-off-by: Animesh Manna > --- > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- > include/drm/drm_dp_helper.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > index 42aa889fd0f5..1a6109be2fce 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > @@ -2491,7 +2491,7 @@ static void dp_test_send_phy_test_pattern(struct > dc_link *link) > /* get phy test pattern and pattern parameters from DP receiver */ > core_link_read_dpcd( > link, > - DP_TEST_PHY_PATTERN, > + DP_PHY_TEST_PATTERN, > &dpcd_test_pattern.raw, > sizeof(dpcd_test_pattern)); > core_link_read_dpcd( > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 8f8f3632e697..d6e560870fb1 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -699,7 +699,7 @@ > # define DP_TEST_CRC_SUPPORTED (1 << 5) > # define DP_TEST_COUNT_MASK 0xf > > -#define DP_TEST_PHY_PATTERN 0x248 > +#define DP_PHY_TEST_PATTERN 0x248 > #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 > #define DP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 > #define DP_TEST_80BIT_CUSTOM_PATTERN_23_16 0x252 > -- > 2.24.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2 v6] drm/panel: Add driver for Sony ACX424AKP panel
On Wed, Nov 20, 2019 at 12:53 PM Stephan Gerhold wrote: > On Thu, Nov 14, 2019 at 02:15:25PM +0100, Linus Walleij wrote: > > + /* Calculate the PWM duty cycle in n/256's */ > > + pwm_ratio = max(((duty_ns * 256) / period_ns) - 1, 1); > > + pwm_div = max(1, > > + ((FOSC * period_ns) / 256) / > > + SCALE_FACTOR_NS_DIV_MHZ); > > Does this handle the case where brightness = 0 (usually display off)? Yeah for brightness = 0 it will get duty_ns = 0 and the max() clause will set the duty cycle to 1. > I have also often seen code like > > if (bl->props.power != FB_BLANK_UNBLANK || > bl->props.fb_blank != FB_BLANK_UNBLANK || > bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK)) > brightness = 0; > > to handle the blanking states. Not sure. It makes sense to wind down the brightness to minimum when blanking to save power, but that code seems a bit hairy, so not sure what is the right thing to do here :/ I guess I could just implement enable/disable for the backlight and wind it down to 0 in disable and back to whatever brightness is in enable. But I don't know if that is a good idea since I don't really enable/disable the backlight (it cannot be disable without shutting down the display). Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] dt-bindings: display: Add Satoz panel
On Tue, Dec 24, 2019 at 03:19:04PM +0100, Miquel Raynal wrote: > Satoz is a Chinese TFT manufacturer. > Website: http://www.sat-sz.com/English/index.html > > Add (simple) bindings for its SAT050AT40H12R2 5.0 inch LCD panel. > > Signed-off-by: Miquel Raynal > --- > > Changes since v2: > * None. > > Changes since v1: > * New patch > > .../display/panel/satoz,sat050at40h12r2.yaml | 27 +++ > 1 file changed, 27 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml Note that this may become obsolete if we move all simple panels to a single schema. > > diff --git > a/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml > b/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml > new file mode 100644 > index ..567b32a544f3 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml > @@ -0,0 +1,27 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/panel/satoz,sat050at40h12r2# Missing '.yaml' Run 'make dt_binding_check' which will check this and other things. > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Satoz SAT050AT40H12R2 panel > + > +maintainers: > + - Thierry Reding > + > +description: |+ > + LCD 5.0 inch 800x480 RGB panel. Any public spec for this panel? > + > + This binding is compatible with the simple-panel binding, which is > specified > + in simple-panel.txt in this directory. > + > +allOf: > + - $ref: panel-common.yaml# > + > +properties: > + compatible: > +contains: Drop 'contains'. It must be exactly the below string, not the below string and *any* other strings. > + const: satoz,sat050at40h12r2 > + > +required: > + - compatible > -- > 2.20.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7] drm/panel: Add driver for Sony ACX424AKP panel
The Sony ACX424AKP is a command/videomode DSI panel for
mobile devices. It is used on the ST-Ericsson HREF520
reference design. We support video mode by default, but
it is possible to switch the panel into command mode
by using the bool property "dsi-command-mode".
Cc: Stephan Gerhold
Signed-off-by: Linus Walleij
---
ChangeLog v6->v7:
- Add some Kconfig help text.
- Sort includes alphabetically.
- Move the struct drm_panel first in the state container
struct since we are subclassing the panel class.
- Put an explicit /* sentinel */ text in the NULL entry
for compatible.
- Move MTP ID readout to the .prepare() callback.
- Add a verbose comment about the MDDI setting so others
understand what may be going on.
- Explain why the backlight follows the display and cannot
be turned on/off
ChangeLog v5->v6:
- Move the "set MDDI" command back to this file. It is a
local pecularity, we suspect there is a Novatek controller
inside this display.
ChangeLog v4->v5:
- Bindings were iterated separately so a jump in versioning.
- Add Stephan as reviewer.
ChangeLog v3->v4:
- No changes just resending with the new binding updates.
ChangeLog v2->v3:
- No changes just resending with the new binding updates.
ChangeLog v1->v2:
- Fix up the ID read function to split into reading header,
version and ID, store the version in the struct.
- Get rid of a surplus semicolon found by the build robot
while rewriting the above code.
- Use unsigned int in probe() loop.
- Set vrefresh to 60Hz, as good as any, the measured vrefresh
in continous command mode is ~117 Hz.
- Use a different for() idiom while retrying to read ID
5 times.
- Drop the sync pulse setting, we are not using this, this
panel uses an event.
- Use the generic "enforce-video-mode" for video mode
enforcement.
---
drivers/gpu/drm/panel/Kconfig| 11 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-sony-acx424akp.c | 550 +++
3 files changed, 562 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-sony-acx424akp.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index f152bc4eeb53..7ef8d095aae6 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -316,6 +316,17 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_SONY_ACX424AKP
+ tristate "Sony ACX424AKP DSI command mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable the Sony ACX424 display
+ panel. This panel supports DSI in both command and video
+ mode.
+
config DRM_PANEL_SONY_ACX565AKM
tristate "Sony ACX565AKM panel"
depends on GPIOLIB && OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index b6cd39fe0f20..0b51793e3b43 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) +=
panel-sharp-ls037v7dw01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c
b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
new file mode 100644
index ..fe33f97cd812
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
@@ -0,0 +1,550 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * MIPI-DSI Sony ACX424AKP panel driver. This is a 480x864
+ * AMOLED panel with a command-only DSI interface.
+ *
+ * Copyright (C) Linaro Ltd. 2019
+ * Author: Linus Walleij
+ * Based on code and know-how from Marcus Lorentzon
+ * Copyright (C) ST-Ericsson SA 2010
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#define ACX424_DCS_READ_ID10xDA
+#define ACX424_DCS_READ_ID20xDB
+#define ACX424_DCS_READ_ID30xDC
+#define ACX424_DCS_SET_MDDI0xAE
+
+/*
+ * Sony seems to use vendor ID 0x81
+ */
+#define DISPLAY_SONY_ACX424AKP_ID1 0x811b
+#define DISPLAY_SONY_ACX424AKP_ID2 0x811a
+/*
+ * The third ID looks like a bug, vendor IDs begin at 0x80
+ * and panel 00 ... seems like default values.
+ */
+#define DISPLAY_SONY_ACX424AKP_ID3 0x8000
+
+struct acx424akp {
+ struct drm_panel panel;
+ struct device *dev;
+ struct backlight_device *bl;
+ s
[Bug 206017] Kernel 5.4.x unusable with GUI due to [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
https://bugzilla.kernel.org/show_bug.cgi?id=206017 --- Comment #5 from udo (udo...@xs4all.nl) --- Firefox is still the trigger. When I do not use it the system remains usable. When I use Firefox the system crashes hard within a few hours. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206017] Kernel 5.4.x unusable with GUI due to hard crashes
https://bugzilla.kernel.org/show_bug.cgi?id=206017 udo (udo...@xs4all.nl) changed: What|Removed |Added Summary|Kernel 5.4.x unusable with |Kernel 5.4.x unusable with |GUI due to |GUI due to hard crashes |[drm:amdgpu_dm_atomic_commi | |t_tail [amdgpu]] *ERROR*| |Waiting for fences timed| |out!| -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206017] Kernel 5.4.x unusable with GUI due to crashes (some hard)
https://bugzilla.kernel.org/show_bug.cgi?id=206017 udo (udo...@xs4all.nl) changed: What|Removed |Added Summary|Kernel 5.4.x unusable with |Kernel 5.4.x unusable with |GUI due to hard crashes |GUI due to crashes (some ||hard) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
