Linux Framebuffer Layer development
 help / color / mirror / Atom feed
* Re: [Linaro-mm-sig] [RFC/PATCH] fb: Add dma-buf support
From: Jesse Barker @ 2012-06-20 15:09 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-fbdev, linaro-mm-sig, linux-media
In-Reply-To: <1340201368-20751-1-git-send-email-laurent.pinchart@ideasonboard.com>

Laurent,

Your recent documentation efforts are extremely commendable.  Just a
couple of small nits below...

On Wed, Jun 20, 2012 at 7:09 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Add support for the dma-buf exporter role to the frame buffer API. The
> importer role isn't meaningful for frame buffer devices, as the frame
> buffer device model doesn't allow using externally allocated memory.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  Documentation/fb/api.txt |   36 ++++++++++++++++++++++++++++++++++++
>  drivers/video/fbmem.c    |   36 ++++++++++++++++++++++++++++++++++++
>  include/linux/fb.h       |   12 ++++++++++++
>  3 files changed, 84 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
> index d4ff7de..f0b2173 100644
> --- a/Documentation/fb/api.txt
> +++ b/Documentation/fb/api.txt
> @@ -304,3 +304,39 @@ extensions.
>  Upon successful format configuration, drivers update the fb_fix_screeninfo
>  type, visual and line_length fields depending on the selected format. The type
>  and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.
> +
> +
> +5. DMA buffer sharing
> +---------------------
> +
> +The dma-buf kernel framework allows DMA buffers to be shared across devices
> +and applications. Sharing buffers across display devices and video capture or
> +video decoding devices allow zero-copy operation when displaying video content
> +produced by a hardware device such as a camera or a hardware codec. This is
> +crucial to achieve optimal system performances during video display.
> +
> +While dma-buf supports both exporting internally allocated memory as a dma-buf
> +object (known as the exporter role) and importing a dma-buf object to be used
> +as device memory (known as the importer role), the frame buffer API only
> +supports the exporter role, as the frame buffer device model doesn't support
> +using externally-allocated memory.
> +
> +The export a frame buffer as a dma-buf file descriptors, applications call the

s/The/To
s/descriptors/descriptor

cheers,
Jesse

> +FBIOGET_DMABUF ioctl. The ioctl takes a pointer to a fb_dmabuf_export
> +structure.
> +
> +struct fb_dmabuf_export {
> +       __u32 fd;
> +       __u32 flags;
> +};
> +
> +The flag field specifies the flags to be used when creating the dma-buf file
> +descriptor. The only supported flag is O_CLOEXEC. If the call is successful,
> +the driver will set the fd field to a file descriptor corresponding to the
> +dma-buf object.
> +
> +Applications can then pass the file descriptors to another application or
> +another device driver. The dma-buf object is automatically reference-counted,
> +applications can and should close the file descriptor as soon as they don't
> +need it anymore. The underlying dma-buf object will not be freed before the
> +last device that uses the dma-buf object releases it.
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 0dff12a..400e449 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -15,6 +15,7 @@
>
>  #include <linux/compat.h>
>  #include <linux/types.h>
> +#include <linux/dma-buf.h>
>  #include <linux/errno.h>
>  #include <linux/kernel.h>
>  #include <linux/major.h>
> @@ -1074,6 +1075,23 @@ fb_blank(struct fb_info *info, int blank)
>        return ret;
>  }
>
> +#ifdef CONFIG_DMA_SHARED_BUFFER
> +int
> +fb_get_dmabuf(struct fb_info *info, int flags)
> +{
> +       struct dma_buf *dmabuf;
> +
> +       if (info->fbops->fb_dmabuf_export = NULL)
> +               return -ENOTTY;
> +
> +       dmabuf = info->fbops->fb_dmabuf_export(info);
> +       if (IS_ERR(dmabuf))
> +               return PTR_ERR(dmabuf);
> +
> +       return dma_buf_fd(dmabuf, flags);
> +}
> +#endif
> +
>  static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>                        unsigned long arg)
>  {
> @@ -1084,6 +1102,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>        struct fb_cmap cmap_from;
>        struct fb_cmap_user cmap;
>        struct fb_event event;
> +       struct fb_dmabuf_export dmaexp;
>        void __user *argp = (void __user *)arg;
>        long ret = 0;
>
> @@ -1191,6 +1210,23 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>                console_unlock();
>                unlock_fb_info(info);
>                break;
> +#ifdef CONFIG_DMA_SHARED_BUFFER
> +       case FBIOGET_DMABUF:
> +               if (copy_from_user(&dmaexp, argp, sizeof(dmaexp)))
> +                       return -EFAULT;
> +
> +               if (!lock_fb_info(info))
> +                       return -ENODEV;
> +               dmaexp.fd = fb_get_dmabuf(info, dmaexp.flags);
> +               unlock_fb_info(info);
> +
> +               if (dmaexp.fd < 0)
> +                       return dmaexp.fd;
> +
> +               ret = copy_to_user(argp, &dmaexp, sizeof(dmaexp))
> +                   ? -EFAULT : 0;
> +               break;
> +#endif
>        default:
>                if (!lock_fb_info(info))
>                        return -ENODEV;
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index ac3f1c6..c9fee75 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -39,6 +39,7 @@
>  #define FBIOPUT_MODEINFO        0x4617
>  #define FBIOGET_DISPINFO        0x4618
>  #define FBIO_WAITFORVSYNC      _IOW('F', 0x20, __u32)
> +#define FBIOGET_DMABUF         _IOR('F', 0x21, struct fb_dmabuf_export)
>
>  #define FB_TYPE_PACKED_PIXELS          0       /* Packed Pixels        */
>  #define FB_TYPE_PLANES                 1       /* Non interleaved planes */
> @@ -403,6 +404,11 @@ struct fb_cursor {
>  #define FB_BACKLIGHT_MAX       0xFF
>  #endif
>
> +struct fb_dmabuf_export {
> +       __u32 fd;
> +       __u32 flags;
> +};
> +
>  #ifdef __KERNEL__
>
>  #include <linux/fs.h>
> @@ -418,6 +424,7 @@ struct vm_area_struct;
>  struct fb_info;
>  struct device;
>  struct file;
> +struct dma_buf;
>
>  /* Definitions below are used in the parsed monitor specs */
>  #define FB_DPMS_ACTIVE_OFF     1
> @@ -701,6 +708,11 @@ struct fb_ops {
>        /* called at KDB enter and leave time to prepare the console */
>        int (*fb_debug_enter)(struct fb_info *info);
>        int (*fb_debug_leave)(struct fb_info *info);
> +
> +#ifdef CONFIG_DMA_SHARED_BUFFER
> +       /* Export the frame buffer as a dmabuf object */
> +       struct dma_buf *(*fb_dmabuf_export)(struct fb_info *info);
> +#endif
>  };
>
>  #ifdef CONFIG_FB_TILEBLITTING
> --
> Regards,
>
> Laurent Pinchart
>
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig

^ permalink raw reply

* [RFC/PATCH] fb: Add dma-buf support
From: Laurent Pinchart @ 2012-06-20 14:09 UTC (permalink / raw)
  To: linux-fbdev; +Cc: linaro-mm-sig, linux-media

Add support for the dma-buf exporter role to the frame buffer API. The
importer role isn't meaningful for frame buffer devices, as the frame
buffer device model doesn't allow using externally allocated memory.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 Documentation/fb/api.txt |   36 ++++++++++++++++++++++++++++++++++++
 drivers/video/fbmem.c    |   36 ++++++++++++++++++++++++++++++++++++
 include/linux/fb.h       |   12 ++++++++++++
 3 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
index d4ff7de..f0b2173 100644
--- a/Documentation/fb/api.txt
+++ b/Documentation/fb/api.txt
@@ -304,3 +304,39 @@ extensions.
 Upon successful format configuration, drivers update the fb_fix_screeninfo
 type, visual and line_length fields depending on the selected format. The type
 and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.
+
+
+5. DMA buffer sharing
+---------------------
+
+The dma-buf kernel framework allows DMA buffers to be shared across devices
+and applications. Sharing buffers across display devices and video capture or
+video decoding devices allow zero-copy operation when displaying video content
+produced by a hardware device such as a camera or a hardware codec. This is
+crucial to achieve optimal system performances during video display.
+
+While dma-buf supports both exporting internally allocated memory as a dma-buf
+object (known as the exporter role) and importing a dma-buf object to be used
+as device memory (known as the importer role), the frame buffer API only
+supports the exporter role, as the frame buffer device model doesn't support
+using externally-allocated memory.
+
+The export a frame buffer as a dma-buf file descriptors, applications call the
+FBIOGET_DMABUF ioctl. The ioctl takes a pointer to a fb_dmabuf_export
+structure.
+
+struct fb_dmabuf_export {
+	__u32 fd;
+	__u32 flags;
+};
+
+The flag field specifies the flags to be used when creating the dma-buf file
+descriptor. The only supported flag is O_CLOEXEC. If the call is successful,
+the driver will set the fd field to a file descriptor corresponding to the
+dma-buf object.
+
+Applications can then pass the file descriptors to another application or
+another device driver. The dma-buf object is automatically reference-counted,
+applications can and should close the file descriptor as soon as they don't
+need it anymore. The underlying dma-buf object will not be freed before the
+last device that uses the dma-buf object releases it.
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 0dff12a..400e449 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -15,6 +15,7 @@
 
 #include <linux/compat.h>
 #include <linux/types.h>
+#include <linux/dma-buf.h>
 #include <linux/errno.h>
 #include <linux/kernel.h>
 #include <linux/major.h>
@@ -1074,6 +1075,23 @@ fb_blank(struct fb_info *info, int blank)
  	return ret;
 }
 
+#ifdef CONFIG_DMA_SHARED_BUFFER
+int
+fb_get_dmabuf(struct fb_info *info, int flags)
+{
+	struct dma_buf *dmabuf;
+
+	if (info->fbops->fb_dmabuf_export = NULL)
+		return -ENOTTY;
+
+	dmabuf = info->fbops->fb_dmabuf_export(info);
+	if (IS_ERR(dmabuf))
+		return PTR_ERR(dmabuf);
+
+	return dma_buf_fd(dmabuf, flags);
+}
+#endif
+
 static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
 			unsigned long arg)
 {
@@ -1084,6 +1102,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
 	struct fb_cmap cmap_from;
 	struct fb_cmap_user cmap;
 	struct fb_event event;
+	struct fb_dmabuf_export dmaexp;
 	void __user *argp = (void __user *)arg;
 	long ret = 0;
 
@@ -1191,6 +1210,23 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
 		console_unlock();
 		unlock_fb_info(info);
 		break;
+#ifdef CONFIG_DMA_SHARED_BUFFER
+	case FBIOGET_DMABUF:
+		if (copy_from_user(&dmaexp, argp, sizeof(dmaexp)))
+			return -EFAULT;
+
+		if (!lock_fb_info(info))
+			return -ENODEV;
+		dmaexp.fd = fb_get_dmabuf(info, dmaexp.flags);
+		unlock_fb_info(info);
+
+		if (dmaexp.fd < 0)
+			return dmaexp.fd;
+
+		ret = copy_to_user(argp, &dmaexp, sizeof(dmaexp))
+		    ? -EFAULT : 0;
+		break;
+#endif
 	default:
 		if (!lock_fb_info(info))
 			return -ENODEV;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index ac3f1c6..c9fee75 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -39,6 +39,7 @@
 #define FBIOPUT_MODEINFO        0x4617
 #define FBIOGET_DISPINFO        0x4618
 #define FBIO_WAITFORVSYNC	_IOW('F', 0x20, __u32)
+#define FBIOGET_DMABUF		_IOR('F', 0x21, struct fb_dmabuf_export)
 
 #define FB_TYPE_PACKED_PIXELS		0	/* Packed Pixels	*/
 #define FB_TYPE_PLANES			1	/* Non interleaved planes */
@@ -403,6 +404,11 @@ struct fb_cursor {
 #define FB_BACKLIGHT_MAX	0xFF
 #endif
 
+struct fb_dmabuf_export {
+	__u32 fd;
+	__u32 flags;
+};
+
 #ifdef __KERNEL__
 
 #include <linux/fs.h>
@@ -418,6 +424,7 @@ struct vm_area_struct;
 struct fb_info;
 struct device;
 struct file;
+struct dma_buf;
 
 /* Definitions below are used in the parsed monitor specs */
 #define FB_DPMS_ACTIVE_OFF	1
@@ -701,6 +708,11 @@ struct fb_ops {
 	/* called at KDB enter and leave time to prepare the console */
 	int (*fb_debug_enter)(struct fb_info *info);
 	int (*fb_debug_leave)(struct fb_info *info);
+
+#ifdef CONFIG_DMA_SHARED_BUFFER
+	/* Export the frame buffer as a dmabuf object */
+	struct dma_buf *(*fb_dmabuf_export)(struct fb_info *info);
+#endif
 };
 
 #ifdef CONFIG_FB_TILEBLITTING
-- 
Regards,

Laurent Pinchart


^ permalink raw reply related

* Re: [PATCH] video: backlight: remove unused header
From: Donghwa Lee @ 2012-06-20 10:32 UTC (permalink / raw)
  To: Florian Tobias Schandinat
  Cc: Paul Bolle, linux-fbdev, linux-kernel, Inki Dae, Kyungmin Park
In-Reply-To: <4FE1233E.9040801@gmx.de>

On 6/20/2012 10:11 AM, Florian Tobias Schandinat wrote:

> Hi Paul,
> 
> On 06/13/2012 07:47 AM, Paul Bolle wrote:
>> Commit 9befe40f6e018e508b047eb76d189ede9b4ff03d ("video: backlight:
>> support s6e8ax0 panel driver based on MIPI DSI") added s6e8ax0.h, but
>> no file includes it. That's probably a good thing, because it declares
>> an extern void function that is defined static int in s6e8ax0.c.
>> Besides, that function is also wrapped in the module_init() macro, which
>> should do everything needed to make that function available to the code
>> outside of s6e8ax0.c. This header can safely be removed.
>>
>> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> 
> it would have been a good idea to CC the authors of this file to get an
> answer to your questions and allow them to comment on the patch. (done)
> I'd like to hear their feedback before I apply your patch but it looks
> reasonable.
> 
> 
> Thanks,
> 
> Florian Tobias Schandinat
> 
>> ---
>> 0) Tested mainly by using various git tools on the (history of the)
>> tree.
>>
>> 1) Shouldn't s6e8ax0_init() and s6e8ax0_exit(), both in s6e8ax0.c, carry
>> the usual __init and __exit attributes?
>>
>> 2) But note that all the module related code in s6e8ax0.c seems moot
>> currently: EXYNOS_LCD_S6E8AX0 is a boolean Kconfig symbol, so the code
>> can only be used builtin. So, as far as I can tell, either that symbol
>> (and the symbols on which it depends) should be made tristate, or the
>> module related code can be removed from s6e8ax0.c.
>>
>>  drivers/video/exynos/s6e8ax0.h |   21 ---------------------
>>  1 files changed, 0 insertions(+), 21 deletions(-)
>>  delete mode 100644 drivers/video/exynos/s6e8ax0.h
>>
>> diff --git a/drivers/video/exynos/s6e8ax0.h b/drivers/video/exynos/s6e8ax0.h
>> deleted file mode 100644
>> index 1f1b270..0000000
>> --- a/drivers/video/exynos/s6e8ax0.h
>> +++ /dev/null
>> @@ -1,21 +0,0 @@
>> -/* linux/drivers/video/backlight/s6e8ax0.h
>> - *
>> - * MIPI-DSI based s6e8ax0 AMOLED LCD Panel definitions.
>> - *
>> - * Copyright (c) 2011 Samsung Electronics
>> - *
>> - * Inki Dae, <inki.dae@samsung.com>
>> - * Donghwa Lee <dh09.lee@samsung.com>
>> - *
>> - * This program is free software; you can redistribute it and/or modify
>> - * it under the terms of the GNU General Public License version 2 as
>> - * published by the Free Software Foundation.
>> -*/
>> -
>> -#ifndef _S6E8AX0_H
>> -#define _S6E8AX0_H
>> -
>> -extern void s6e8ax0_init(void);
>> -
>> -#endif
>> -
> 
> 


Hi,
I had looked through that code. I agree that header file will be removed.
There is no reason to maintain it.

Thank you,
Donghwa Lee


^ permalink raw reply

* Re: [PULL for v3.6] SH Mobile LCDC fixes and planes support
From: Laurent Pinchart @ 2012-06-20  8:31 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <3246665.HJN7RE5zfe@avalon>

Hi Florian,

On Wednesday 20 June 2012 01:01:31 Florian Tobias Schandinat wrote:
> On 06/16/2012 02:07 PM, Laurent Pinchart wrote:
> > Hi Florian,
> > 
> > Could you please pull the following LCDC patches ?
> 
> looks good, except...
> 
> > The following changes since commit 
b67989515defba7412acff01162e5bb1f0f5923a:
> >   video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk
> > 
> > (2012-06-13 17:34:16 +0000)
> > 
> > are available in the git repository at:
> >   git://linuxtv.org/pinchartl/fbdev.git planes
> > 
> > Guennadi Liakhovetski (1):
> >       fbdev: sh_mipi_dsi: fix a section mismatch
> > 
> > Laurent Pinchart (4):
> >       fbdev: sh_mobile_lcdc: Don't confuse line size with pitch
> 
> ...for this patch it would have been better if you based your work on a
> more recent tree of Linus that already contains it instead of asking me
> to pull it again [I now forwarded my fbdev-next to -rc3]. It's not a big
> issue as git handles such situations but pushing patches around that are
> essentially nops should be avoided I think. Well, if you decide to fix
> it I'd be happy, otherwise I'll pull this in a few days nonetheless.

Sorry about that. I've rebased the branch on top of the latest fbdev-next and 
pushed it to git://linuxtv.org/pinchartl/fbdev.git planes, that no-op patches 
isn't present anymore.

-- 
Regards,

Laurent Pinchart


^ permalink raw reply

* [PATCH v2] video: exynos_dp: fix build warning due to uninitialized value
From: Jingoo Han @ 2012-06-20  1:25 UTC (permalink / raw)
  To: 'Florian Tobias Schandinat'
  Cc: linux-fbdev, linux-kernel, 'Olof Johansson',
	'Jingoo Han'

This patch fixes build warning due to uninitialized value dereference.

drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_set_link_train':
drivers/video/exynos/exynos_dp_core.c:529:18: warning: 'reg' may be used uninitialized in this function [-Wuninitialized]
drivers/video/exynos/exynos_dp_core.c:395:6: note: 'reg' was declared here

Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/video/exynos/exynos_dp_core.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index a36b2d2..9db7b9f 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -407,6 +407,9 @@ static unsigned int exynos_dp_get_lane_link_training(
 	case 3:
 		reg = exynos_dp_get_lane3_link_training(dp);
 		break;
+	default:
+		WARN_ON(1);
+		return 0;
 	}
 
 	return reg;
-- 
1.7.1



^ permalink raw reply related

* Re: [PATCH] video: backlight: remove unused header
From: Florian Tobias Schandinat @ 2012-06-20  1:11 UTC (permalink / raw)
  To: Paul Bolle
  Cc: linux-fbdev, linux-kernel, Donghwa Lee, Inki Dae, Kyungmin Park
In-Reply-To: <1339573651.30984.130.camel@x61.thuisdomein>

Hi Paul,

On 06/13/2012 07:47 AM, Paul Bolle wrote:
> Commit 9befe40f6e018e508b047eb76d189ede9b4ff03d ("video: backlight:
> support s6e8ax0 panel driver based on MIPI DSI") added s6e8ax0.h, but
> no file includes it. That's probably a good thing, because it declares
> an extern void function that is defined static int in s6e8ax0.c.
> Besides, that function is also wrapped in the module_init() macro, which
> should do everything needed to make that function available to the code
> outside of s6e8ax0.c. This header can safely be removed.
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

it would have been a good idea to CC the authors of this file to get an
answer to your questions and allow them to comment on the patch. (done)
I'd like to hear their feedback before I apply your patch but it looks
reasonable.


Thanks,

Florian Tobias Schandinat

> ---
> 0) Tested mainly by using various git tools on the (history of the)
> tree.
> 
> 1) Shouldn't s6e8ax0_init() and s6e8ax0_exit(), both in s6e8ax0.c, carry
> the usual __init and __exit attributes?
> 
> 2) But note that all the module related code in s6e8ax0.c seems moot
> currently: EXYNOS_LCD_S6E8AX0 is a boolean Kconfig symbol, so the code
> can only be used builtin. So, as far as I can tell, either that symbol
> (and the symbols on which it depends) should be made tristate, or the
> module related code can be removed from s6e8ax0.c.
> 
>  drivers/video/exynos/s6e8ax0.h |   21 ---------------------
>  1 files changed, 0 insertions(+), 21 deletions(-)
>  delete mode 100644 drivers/video/exynos/s6e8ax0.h
> 
> diff --git a/drivers/video/exynos/s6e8ax0.h b/drivers/video/exynos/s6e8ax0.h
> deleted file mode 100644
> index 1f1b270..0000000
> --- a/drivers/video/exynos/s6e8ax0.h
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -/* linux/drivers/video/backlight/s6e8ax0.h
> - *
> - * MIPI-DSI based s6e8ax0 AMOLED LCD Panel definitions.
> - *
> - * Copyright (c) 2011 Samsung Electronics
> - *
> - * Inki Dae, <inki.dae@samsung.com>
> - * Donghwa Lee <dh09.lee@samsung.com>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> -*/
> -
> -#ifndef _S6E8AX0_H
> -#define _S6E8AX0_H
> -
> -extern void s6e8ax0_init(void);
> -
> -#endif
> -


^ permalink raw reply

* Re: [PULL for v3.6] SH Mobile LCDC fixes and planes support
From: Florian Tobias Schandinat @ 2012-06-20  1:01 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <3246665.HJN7RE5zfe@avalon>

Hi Laurent,

On 06/16/2012 02:07 PM, Laurent Pinchart wrote:
> Hi Florian,
> 
> Could you please pull the following LCDC patches ?

looks good, except...

> 
> The following changes since commit b67989515defba7412acff01162e5bb1f0f5923a:
> 
>   video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk 
> (2012-06-13 17:34:16 +0000)
> 
> are available in the git repository at:
>   git://linuxtv.org/pinchartl/fbdev.git planes
> 
> Guennadi Liakhovetski (1):
>       fbdev: sh_mipi_dsi: fix a section mismatch
> 
> Laurent Pinchart (4):
>       fbdev: sh_mobile_lcdc: Don't confuse line size with pitch

...for this patch it would have been better if you based your work on a
more recent tree of Linus that already contains it instead of asking me
to pull it again [I now forwarded my fbdev-next to -rc3]. It's not a big
issue as git handles such situations but pushing patches around that are
essentially nops should be avoided I think. Well, if you decide to fix
it I'd be happy, otherwise I'll pull this in a few days nonetheless.


Best regards,

Florian Tobias Schandinat

>       fbdev: sh_mobile_lcdc: Constify sh_mobile_lcdc_fix structure
>       fbdev: sh_mobile_lcdc: Rename fb operation handlers with a common prefix
>       fbdev: sh_mobile_lcdc: Implement overlays support
> 
>  .../sysfs-devices-platform-sh_mobile_lcdc_fb       |   44 +
>  drivers/video/sh_mipi_dsi.c                        |    7 +-
>  drivers/video/sh_mobile_lcdcfb.c                   |  987 +++++++++++++++++--
>  drivers/video/sh_mobile_lcdcfb.h                   |    1 +
>  include/video/sh_mobile_lcdc.h                     |    7 +
>  5 files changed, 944 insertions(+), 102 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-
> sh_mobile_lcdc_fb
> 

^ permalink raw reply

* Re: [PATCH] video: exynos_dp: fix build warning due to uninitialized value
From: Jingoo Han @ 2012-06-20  0:54 UTC (permalink / raw)
  To: 'Florian Tobias Schandinat'
  Cc: linux-fbdev, linux-kernel, 'Olof Johansson',
	'Jingoo Han'
In-Reply-To: <4FE11D60.9040109@gmx.de>


On Wed, June 20, 2012 at 9:46 AM, Florian Tobias Schandinat wrote:

> Hi Jingoo,
> 
> On 06/19/2012 06:36 AM, Jingoo Han wrote:
> > This patch fixes build warning due to uninitialized value dereference.
> > @@ -407,6 +407,8 @@ static unsigned int exynos_dp_get_lane_link_training(
> >  	case 3:
> >  		reg = exynos_dp_get_lane3_link_training(dp);
> >  		break;
> > +	default:
> > +		return -EINVAL;
> 
> Why do you consider returning -EINVAL here a good idea? As far as I can
> see the caller does not check the return value for an error condition
> and I doubt that the hardware understands what -EINVAL means. If you
> want to fix the warning, make sure that you don't hide actual errors,
> add an WARN or BUG or make sure the error code makes it to userspace.
> 

OK, I will fix it and send the v2 patch.
Thank you.

Best regards,
Jingoo Han



^ permalink raw reply

* Re: [PATCH] video: exynos_dp: fix build warning due to uninitialized value
From: Florian Tobias Schandinat @ 2012-06-20  0:46 UTC (permalink / raw)
  To: Jingoo Han; +Cc: linux-fbdev, linux-kernel, 'Olof Johansson'
In-Reply-To: <001501cd4de5$d955a290$8c00e7b0$%han@samsung.com>

Hi Jingoo,

On 06/19/2012 06:36 AM, Jingoo Han wrote:
> This patch fixes build warning due to uninitialized value dereference.
> 
> drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_set_link_train':
> drivers/video/exynos/exynos_dp_core.c:529:18: warning: 'reg' may be used uninitialized in this function [-Wuninitialized]
> drivers/video/exynos/exynos_dp_core.c:395:6: note: 'reg' was declared here
> 
> Signed-off-by: Olof Johansson <olof@lixom.net>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
>  drivers/video/exynos/exynos_dp_core.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index a36b2d2..9b2cdff 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -407,6 +407,8 @@ static unsigned int exynos_dp_get_lane_link_training(
>  	case 3:
>  		reg = exynos_dp_get_lane3_link_training(dp);
>  		break;
> +	default:
> +		return -EINVAL;

Why do you consider returning -EINVAL here a good idea? As far as I can
see the caller does not check the return value for an error condition
and I doubt that the hardware understands what -EINVAL means. If you
want to fix the warning, make sure that you don't hide actual errors,
add an WARN or BUG or make sure the error code makes it to userspace.

>  	}
>  
>  	return reg;


Best regards,

Florian Tobias Schandinat

^ permalink raw reply

* Re: [PATCH 1/2] video: s3c-fb: clear SHADOWCON register when clearing hardware window registers
From: Florian Tobias Schandinat @ 2012-06-20  0:26 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <001801cd4779$a2c2c220$e8484660$%han@samsung.com>

On 06/11/2012 02:26 AM, Jingoo Han wrote:
> All bits of SHADOWCON register should be cleared when clearing
> hardware window registers; however, some bits of SHADOWCON register
> are not cleared previously.

A bit more detailed description of what this might cause would be good.
I assume you are fixing this because it is more correct but there are no
known bugs related to this? Anyway, please try to give more information
next time.

> 
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>

Applied both patches.


Thanks,

Florian Tobias Schandinat

> ---
>  drivers/video/s3c-fb.c |   10 ++++++++--
>  1 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 5f9d8e6..b5c2939 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1348,8 +1348,14 @@ static void s3c_fb_clear_win(struct s3c_fb *sfb, int win)
>  	writel(0, regs + VIDOSD_A(win, sfb->variant));
>  	writel(0, regs + VIDOSD_B(win, sfb->variant));
>  	writel(0, regs + VIDOSD_C(win, sfb->variant));
> -	reg = readl(regs + SHADOWCON);
> -	writel(reg & ~SHADOWCON_WINx_PROTECT(win), regs + SHADOWCON);
> +
> +	if (sfb->variant.has_shadowcon) {
> +		reg = readl(sfb->regs + SHADOWCON);
> +		reg &= ~(SHADOWCON_WINx_PROTECT(win) |
> +			SHADOWCON_CHx_ENABLE(win) |
> +			SHADOWCON_CHx_LOCAL_ENABLE(win));
> +		writel(reg, sfb->regs + SHADOWCON);
> +	}
>  }
>  
>  static int __devinit s3c_fb_probe(struct platform_device *pdev)


^ permalink raw reply

* [PATCH] video: exynos_dp: fix build warning due to uninitialized value
From: Jingoo Han @ 2012-06-19  6:36 UTC (permalink / raw)
  To: 'Florian Tobias Schandinat'
  Cc: linux-fbdev, linux-kernel, 'Olof Johansson',
	'Jingoo Han'

This patch fixes build warning due to uninitialized value dereference.

drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_set_link_train':
drivers/video/exynos/exynos_dp_core.c:529:18: warning: 'reg' may be used uninitialized in this function [-Wuninitialized]
drivers/video/exynos/exynos_dp_core.c:395:6: note: 'reg' was declared here

Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/video/exynos/exynos_dp_core.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index a36b2d2..9b2cdff 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -407,6 +407,8 @@ static unsigned int exynos_dp_get_lane_link_training(
 	case 3:
 		reg = exynos_dp_get_lane3_link_training(dp);
 		break;
+	default:
+		return -EINVAL;
 	}
 
 	return reg;
-- 
1.7.1



^ permalink raw reply related

* Re: [RFC 00/10] fblog: framebuffer kernel log driver
From: David Herrmann @ 2012-06-18 19:06 UTC (permalink / raw)
  To: linux-serial
  Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
	Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>

Hi

On Sun, Jun 17, 2012 at 12:04 AM, David Herrmann
<dh.herrmann@googlemail.com> wrote:
> Hi
>
> As some might know I am working on making CONFIG_VT obsolete. But as a developer
> it is often useful to have a kernel-log on the screen during boot to debug many
> common kernel(-config) errors. However, without CONFIG_VT we cannot use the
> VGA/framebbufer consoles either. Therefore, I am working on a small driver
> called "fblog".
>
> This driver simply writes the kernel log to all connected framebuffers. It works
> similar to fbcon but removes all the complexity of the virtual terminals. There
> is a sysfs attribute called "active" that allows to enable/disable fblog so
> user-space can start an xserver or similar.
>
> The main purpose is debugging kernel boot problems. Therefore, it is not
> optimized for speed and I tried keeping it simple. I splitted the patches
> into 10 small chunks to make review easier.
>
> I would be glad if someone could review this and tell me whether this is
> something we could include in mainline or not.
>
>
> There are still some issues but apart from them it works fine on my
> machine (x86):
>  - I register the fblog device during module_init and need to call
>    module_get(). However, this means it is impossible to call "rmmod fblog" as
>    fblog has a reference to itself. Using "rmmod -f fblog" works fine but is a
>    bit ugly. Is there a nice way to fix this? Otherwise I would need to call
>    device_get() in module_exit() if there is a pending user of the fblog-device
>    even though I unregistered it.
>  - I redraw all framebuffers while holding the console-lock. This may slow down
>    machines with more than 2 framebuffers (like 10 or 20). However, as this is
>    supposed to be a debug driver, I think I can ignore this? If someone wants
>    to improve the redraw logic to avoid redrawing the whole screen all the
>    time, I would be glad to include it in this patchset :)
>  - I am really no expert regarding the framebuffer subsystem. So I would
>    appreciate it if someone could comment whether I need to handle the events
>    in a different way or whether it is ok the way it is now.

One additional issue:
With udlfb.c we have hotplug capable framebuffers. However, fbcon and
fblog currently never close a framebuffer if not explicitely requested
by user-space. Therefore, if a framebuffer device is removed, the
FB_EVENT_FB_UNREGISTER event will never be sent because fbcon/fblog
still have a reference to the framebuffer(-driver). Therefore, the
number of available fbs will grow until there are no more free
indices.

See dlfb_usb_disconnect() in udlfb.c for an example. It does not
invoke unregister_framebuffer() unless the last user closed the FB.
udlfb disables the console on its framebuffer devices to avoid this,
but this doesn't seem to be a good solution.
How about sending an FB_EVENT_FB_DISCONNECT event during unlink_framebuffer()?

This still doesn't force user-space to close /dev/fbX but it at least
will make it possible to fblog/fbcon to close the framebuffer. fbmem.c
can then still be modified to mark the open file as dead so user-space
will also close the device hopefully.

Regards
David

^ permalink raw reply

* Re: [PATCH 05/10] fblog: add framebuffer helpers
From: David Herrmann @ 2012-06-18 18:50 UTC (permalink / raw)
  To: Bruno Prémont
  Cc: linux-serial, Florian Tobias Schandinat, linux-fbdev,
	linux-kernel, Greg Kroah-Hartman
In-Reply-To: <20120617003334.765f6226@neptune.home>

Hi Bruno

On Sun, Jun 17, 2012 at 12:33 AM, Bruno Prémont
<bonbons@linux-vserver.org> wrote:
> On Sun, 17 June 2012 David Herrmann <dh.herrmann@googlemail.com> wrote:
>> These helpers scan the system for all available framebuffers and register
>> or unregister them. This is needed during startup and stopping fblog so we
>> are aware of all connected displays.
>>
>> The third helper handles mode changes by rescanning the mode and adjusting
>> the buffer size.
>>
>> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
>> ---
>>  drivers/video/console/fblog.c |   29 +++++++++++++++++++++++++++++
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
>> index e790971..7d4032e 100644
>> --- a/drivers/video/console/fblog.c
>> +++ b/drivers/video/console/fblog.c
>> @@ -399,6 +399,35 @@ static void fblog_unregister(struct fblog_fb *fb)
>>       kfree(fb);
>>  }
>>
>> +static void fblog_register_all(void)
>> +{
>> +     int i;
>> +
>> +     for (i = 0; i < FB_MAX; ++i)
>> +             fblog_register(registered_fb[i]);
>
> You should take registration_lock mutex for accessing registered_fb[],
> even better would be to make use of get_fb_info() and put_fb_info()

Indeed, I will change it to use get_fb_info()/put_fb_info().

Btw., is it safe to call console_lock() during
FB_EVENT_FB_(UN)REGISTERED? I definitely need the console lock when
calling fblog_register() but I am not sure whether all fb-drivers lock
the console during "(un)register_framebuffer()". Otherwise, I would
have to avoid redrawing the console inside of fblog_register().

>> +}
>> +
>> +static void fblog_unregister_all(void)
>> +{
>> +     int i;
>> +
>> +     for (i = 0; i < FB_MAX; ++i)
>> +             fblog_unregister(fblog_info2fb(registered_fb[i]));
>
> Same here.
>
> Though for unregistering I'm wondering why you still scan through
> registered_fb[], you should just scan your fblog_fbs[] array!

Oops, you're right. I will change it.

> But here again, make sure to have proper locking to not get races with
> registration of new framebuffers or removal of existing ones via
> notifications.
>
>> +}
>> +
>> +static void fblog_refresh(struct fblog_fb *fb)
>> +{
>> +     unsigned int width, height;
>> +
>> +     if (!fb || !fb->font)
>> +             return;
>> +
>> +     width = fb->info->var.xres / fb->font->width;
>> +     height = fb->info->var.yres / fb->font->height;
>> +     fblog_buf_resize(&fb->buf, width, height);
>> +     fblog_redraw(fb);
>> +}
>> +
>
> All these new functions are still unused, for easier following of your
> patch series it would be nice to have them connected when they are
> introduced as otherwise on has to search all following patches for
> finding possible users.

I have to admit the split was crap. I am sorry. I will recreate the
patchset with a proper split. Thanks!

>>  static int __init fblog_init(void)
>>  {
>>       return 0;
>
> Bruno

Thanks for reviewing, regards
David

^ permalink raw reply

* Re: [PATCH 04/10] fblog: implement fblog_redraw()
From: David Herrmann @ 2012-06-18 18:36 UTC (permalink / raw)
  To: Alan Cox
  Cc: linux-serial, Florian Tobias Schandinat, linux-fbdev,
	linux-kernel, Greg Kroah-Hartman
In-Reply-To: <20120616233526.7f830890@pyramind.ukuu.org.uk>

Hi Alan

On Sun, Jun 17, 2012 at 12:35 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sun, 17 Jun 2012 00:04:20 +0200
> David Herrmann <dh.herrmann@googlemail.com> wrote:
>
>> This mostly copies the functionality from drivers/video/console/bitblit.c
>> so we can draw the console content on all available framebuffers.
>>
>> All speed optimizations have been removed for simplicity. The original
>> code depends heavily on CONFIG_VT so we cannot share the codebase here.
>
> No. That means we've got two sets of code to maintain not one. Fix the
> dependancy.
>
> Pull the relevant subset of struct vc_data into another struct
> Make struct vc_data be
>
> struct vc_data {
>        struct vc_whatever
>        rest
> }

It's a bit more complex as we cannot call scr_read() either. Hence, I
need to assemble the array of printed characters before calling the
redraw functions. But that should be feasible, too. I just need to
figure out how to avoid heavy allocations during redraw to avoid
slowdowns.

If there are no objections I will send these patches as a separate
patchset as we can apply it without fblog.

> Alan

Thanks for reviewing
David

^ permalink raw reply

* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar @ 2012-06-18 13:36 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1340025071.4012.27.camel@deskari>

On 18 June 2012 18:41, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote:
>> On 18 June 2012 17:54, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
>>
>> >> So preferably I would move request_threaded_irq() to after
>> >> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable()  and convert the
>> >
>> > No, you can't move the check. If you move it, the HPD state could change
>> > between the check and the request_irq, and we'd miss it.
>> >
>> Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that?
>
> No, if we haven't requested the irq yet. So what could happen:
>
> - initially the cable is unplugged
> - ti_hdmi_4xxx_phy_enable() calls hdmi_check_hpd_state(), nothing is
> done as cable is unplugged
> - cable plugged in
> - ti_hdmi_4xxx_phy_enable() calls request_irq. No irq raised, as the
> cable's state doesn't change.
>
> We wouldn't know that cable is actually plugged in at that point.
>
I see, you mean physically (un)plugging the cable could race with phy_enable.

OK, I'll revise the changelog for this patch and submit another patch
converting the spinlock to mutex.

Thanks.

^ permalink raw reply

* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar @ 2012-06-18 13:19 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1340022276.4012.23.camel@deskari>

On 18 June 2012 17:54, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:

>> So preferably I would move request_threaded_irq() to after
>> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable()  and convert the
>
> No, you can't move the check. If you move it, the HPD state could change
> between the check and the request_irq, and we'd miss it.
>
Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that?

^ permalink raw reply

* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Tomi Valkeinen @ 2012-06-18 13:11 UTC (permalink / raw)
  To: Jassi Brar; +Cc: linux-omap, linux-fbdev
In-Reply-To: <CAJe_ZhdoEjyf0ejjsJJpznt83bTJTR0UW3aqaYAZdcm01GBp_A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote:
> On 18 June 2012 17:54, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
> 
> >> So preferably I would move request_threaded_irq() to after
> >> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable()  and convert the
> >
> > No, you can't move the check. If you move it, the HPD state could change
> > between the check and the request_irq, and we'd miss it.
> >
> Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that?

No, if we haven't requested the irq yet. So what could happen:

- initially the cable is unplugged
- ti_hdmi_4xxx_phy_enable() calls hdmi_check_hpd_state(), nothing is
done as cable is unplugged
- cable plugged in
- ti_hdmi_4xxx_phy_enable() calls request_irq. No irq raised, as the
cable's state doesn't change.

We wouldn't know that cable is actually plugged in at that point.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Tomi Valkeinen @ 2012-06-18 12:24 UTC (permalink / raw)
  To: Jassi Brar; +Cc: linux-omap, linux-fbdev
In-Reply-To: <CAJe_ZhfJV6kYvSkU+4RGywv80A47=CxnoCy2rr-x=c2LFDGb7A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
> On 18 June 2012 16:24, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
> 
> >> BTW, coming to think about it, I am not sure what we need the
> >> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ?  It
> >> can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
> >> expensive and is already unprotected elsewhere.
> >
> > It's needed when enabling the hdmi output. In phy_enable() the irq is
> > requested first, and then the phy_enable() runs hdmi_check_hpd_state().
> > So there's a chance to run hdmi_check_hpd_state() from both
> > hpd-interrupt and phy_enable() at the same time.
> >
> > The hdmi_set_phy_pwr() is not called in many places, but I think there's
> > indeed a problem there. It is called after free_irq(), but I think
> > (guess) the irq handler could still be running after free_irq. So those
> > should be protected by the same spinlock too.
> >
> You know TI HDMI better than I do, so I assume your concerns are valid.
> So preferably I would move request_threaded_irq() to after
> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable()  and convert the

No, you can't move the check. If you move it, the HPD state could change
between the check and the request_irq, and we'd miss it.

> spin_lock_irqsave() in hdmi_check_hpd_state() to some mutex (we don't
> want irqs disabled so long as it takes for phy to power on/off).

Yes, I guess a mutex is better.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar @ 2012-06-18 11:58 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1340016865.4012.10.camel@deskari>

On 18 June 2012 16:24, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:

>> BTW, coming to think about it, I am not sure what we need the
>> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ?  It
>> can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
>> expensive and is already unprotected elsewhere.
>
> It's needed when enabling the hdmi output. In phy_enable() the irq is
> requested first, and then the phy_enable() runs hdmi_check_hpd_state().
> So there's a chance to run hdmi_check_hpd_state() from both
> hpd-interrupt and phy_enable() at the same time.
>
> The hdmi_set_phy_pwr() is not called in many places, but I think there's
> indeed a problem there. It is called after free_irq(), but I think
> (guess) the irq handler could still be running after free_irq. So those
> should be protected by the same spinlock too.
>
You know TI HDMI better than I do, so I assume your concerns are valid.
So preferably I would move request_threaded_irq() to after
hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable()  and convert the
spin_lock_irqsave() in hdmi_check_hpd_state() to some mutex (we don't
want irqs disabled so long as it takes for phy to power on/off).

^ permalink raw reply

* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Tomi Valkeinen @ 2012-06-18 10:54 UTC (permalink / raw)
  To: Jassi Brar; +Cc: linux-omap, linux-fbdev
In-Reply-To: <CAJe_ZhdhBre8DUVNpawF6X5P+QSiMarkt3WUvbJ=RPcmpX3TPA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
> On 18 June 2012 13:41, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >>
> >> Explicitly maintaining HDMI phy power state using a flag is prone to
> >> race and un-necessary when we have a zero-cost alternative of checking
> >> the state before trying to set it.
> >
> > Why would reading the value from the register be any less racy than
> > keeping it in memory?
> >
> Racy in the sense that h/w doesn't always hop states according to what
> a "state" variable would expect it to.

But I don't think the status register is any better. If I'm not
mistaken, when you set the phy pwr to, say, TXON, the status register
will still show the old value. The status register will be right only
after the HW is actually at TXON state.

In this case the hdmi_set_phy_pwr() function will anyway wait until the
HW has changed states, so both approaches should work just fine.

> Also in this case, phy_tx_enabled modification is unprotected in
> ti_hdmi_4xxx_phy_disable().

So is hdmi_set_phy_pwr(). Note that I'm not saying the current approach
is not racy, but your patch doesn't make it any less racy.

> BTW, coming to think about it, I am not sure what we need the
> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ?  It
> can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
> expensive and is already unprotected elsewhere.

It's needed when enabling the hdmi output. In phy_enable() the irq is
requested first, and then the phy_enable() runs hdmi_check_hpd_state().
So there's a chance to run hdmi_check_hpd_state() from both
hpd-interrupt and phy_enable() at the same time.

The hdmi_set_phy_pwr() is not called in many places, but I think there's
indeed a problem there. It is called after free_irq(), but I think
(guess) the irq handler could still be running after free_irq. So those
should be protected by the same spinlock too.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar @ 2012-06-18 10:24 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1340007094.1859.3.camel@lappyti>

On 18 June 2012 13:41, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>> Explicitly maintaining HDMI phy power state using a flag is prone to
>> race and un-necessary when we have a zero-cost alternative of checking
>> the state before trying to set it.
>
> Why would reading the value from the register be any less racy than
> keeping it in memory?
>
Racy in the sense that h/w doesn't always hop states according to what
a "state" variable would expect it to.
Also in this case, phy_tx_enabled modification is unprotected in
ti_hdmi_4xxx_phy_disable().

BTW, coming to think about it, I am not sure what we need the
spin_lock_irqsave() protection for in hdmi_check_hpd_state() ?  It
can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
expensive and is already unprotected elsewhere.

> And reading from memory is probably much faster
> than reading from an HDMI register, so I'm not sure what you mean with
> zero-cost.
>
Zero-cost in terms of space and bother :)

> But I guess it is simpler, so in that sense the patch is ok. But please
> revise the description.
>
OK, will do.

Thanks.

^ permalink raw reply

* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Tomi Valkeinen @ 2012-06-18  8:11 UTC (permalink / raw)
  Cc: linux-omap, linux-fbdev, Jassi Brar
In-Reply-To: <1339797701-11540-1-git-send-email-jaswinder.singh@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On Sat, 2012-06-16 at 03:31 +0530, jaswinder.singh@linaro.org wrote:
> From: Jassi Brar <jaswinder.singh@linaro.org>
> 
> Explicitly maintaining HDMI phy power state using a flag is prone to
> race and un-necessary when we have a zero-cost alternative of checking
> the state before trying to set it.

Why would reading the value from the register be any less racy than
keeping it in memory? And reading from memory is probably much faster
than reading from an HDMI register, so I'm not sure what you mean with
zero-cost.

But I guess it is simpler, so in that sense the patch is ok. But please
revise the description.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* RE: [PATCH 1/1] video: exynos_dp: Fix compilation warning
From: Jingoo Han @ 2012-06-18  5:22 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1339995317-17788-1-git-send-email-sachin.kamat@linaro.org>


On Mon, June 18, 2012 at 1:55 PM, Sachin Kamat wrote:

> Fixes the following warning:
> drivers/video/exynos/exynos_dp_core.c: In function ‘exynos_dp_set_link_train’:
> drivers/video/exynos/exynos_dp_core.c:529:18: warning: ‘reg’ may be used uninitialized in this function
> [-Wuninitialized]
> drivers/video/exynos/exynos_dp_core.c:395:6: note: ‘reg’ was declared here

This warning was already reported and patch was submitted by Olof Johansson.
I will check and fix it later.

Thank you.

> 
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
>  drivers/video/exynos/exynos_dp_core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index a36b2d2..017c727 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -392,7 +392,7 @@ static unsigned int exynos_dp_get_lane_link_training(
>  				struct exynos_dp_device *dp,
>  				int lane)
>  {
> -	u32 reg;
> +	u32 reg = 0;
> 
>  	switch (lane) {
>  	case 0:
> --
> 1.7.4.1


^ permalink raw reply

* [PATCH 1/1] video: exynos_dp: Fix compilation warning
From: Sachin Kamat @ 2012-06-18  5:07 UTC (permalink / raw)
  To: linux-fbdev

Fixes the following warning:
drivers/video/exynos/exynos_dp_core.c: In function ‘exynos_dp_set_link_train’:
drivers/video/exynos/exynos_dp_core.c:529:18: warning: ‘reg’ may be used uninitialized in this function [-Wuninitialized]
drivers/video/exynos/exynos_dp_core.c:395:6: note: ‘reg’ was declared here

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
 drivers/video/exynos/exynos_dp_core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index a36b2d2..017c727 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -392,7 +392,7 @@ static unsigned int exynos_dp_get_lane_link_training(
 				struct exynos_dp_device *dp,
 				int lane)
 {
-	u32 reg;
+	u32 reg = 0;
 
 	switch (lane) {
 	case 0:
-- 
1.7.4.1


^ permalink raw reply related

* Re: [PATCH 4/6] pwm_backlight: Add deferred probe support
From: Simon Horman @ 2012-06-18  2:14 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1339773427-29508-5-git-send-email-laurent.pinchart@ideasonboard.com>

On Fri, Jun 15, 2012 at 05:17:05PM +0200, Laurent Pinchart wrote:
> If the PWM instance is not available yet at probe time, request a
> deferred probe.
> 
> A better way to fix might be to create a PWM subsystem (possible
> integrated into the GPIO subsystem) to support generic PWM objects, and
> make sure the subsystem gets initialized first.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: linux-fbdev@vger.kernel.org

Tested-by: Simon Horman <horms@verge.net.au>


^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox