[PATCH 1/3] FB: Add some members for CPU Interface.

[PATCH 1/3] FB: Add some members for CPU Interface.

[InKi Dae]

[-- Attachment #1.1: Type: text/plain, Size: 2369 bytes --]

 CPU interface needs cs, wr setup, wr act and hold delay.
I added some members for them to common framework.

Signed-off-by: InKi Dae <inki.dae@samsung.com <mailto:p.osciak@samsung.com>>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com
<mailto:kyungmin.park@samsung.com>>
---

diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c

index 0a4dbdc..74122d1 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
 }
 
 /**
+ * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
+ * @var: pointer to struct fb_var_screeninfo
+ * @mode: pointer to struct fb_cpumode
+ */
+void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
+			 const struct fb_cmdmode *mode)
+{
+	var->xres = mode->xres;
+	var->yres = mode->yres;
+	var->xres_virtual = mode->xres;
+	var->yres_virtual = mode->yres;
+	var->xoffset = 0;
+	var->yoffset = 0;
+	var->pixclock = mode->pixclock;
+	var->cs_setup = mode->cs_setup;
+	var->wr_setup = mode->wr_setup;
+	var->wr_act = mode->wr_act;
+	var->wr_hold = mode->wr_hold;
+}
+
+/**
  * fb_mode_is_equal - compare 2 videomodes
  * @mode1: first videomode
  * @mode2: second videomode
@@ -1048,6 +1069,7 @@ finished:
 EXPORT_SYMBOL(fb_find_best_display);
 
 EXPORT_SYMBOL(fb_videomode_to_var);
+EXPORT_SYMBOL(fb_cmdmode_to_var);
 EXPORT_SYMBOL(fb_var_to_videomode);
 EXPORT_SYMBOL(fb_mode_is_equal);
 EXPORT_SYMBOL(fb_add_videomode);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 907ace3..73381c3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -269,6 +269,12 @@ struct fb_var_screeninfo {
 	__u32 vmode;			/* see FB_VMODE_*		*/
 	__u32 rotate;			/* angle we rotate counter clockwise */
 	__u32 reserved[5];		/* Reserved for future compatibility */
+
+	/* For cpu interface timing. */
+	__u32 cs_setup;
+	__u32 wr_setup;
+	__u32 wr_act;
+	__u32 wr_hold;
 };
 
 struct fb_cmap {
@@ -1117,11 +1123,24 @@ struct fb_videomode {
 	u32 lower_margin;
 	u32 hsync_len;
 	u32 vsync_len;
+	u32 cmd_allow_len;
 	u32 sync;
 	u32 vmode;
 	u32 flag;
 };
 
+struct fb_cmdmode {
+	const char *name;	/* optional */
+	u32 refresh;		/* optional */
+	u32 xres;
+	u32 yres;
+	u32 pixclock;
+	u32 cs_setup;
+	u32 wr_setup;
+	u32 wr_act;
+	u32 wr_hold;
+};
+
 extern const char *fb_mode_option;
 extern const struct fb_videomode vesa_modes[];
 



[-- Attachment #1.2: Type: text/html, Size: 2813 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/3] FB: Add some members for CPU Interface.

[InKi Dae]

 CPU interface needs cs, wr setup, wr act and hold delay.
I added some members for them to common framework.

Signed-off-by: InKi Dae <inki.dae at samsung.com <mailto:p.osciak@samsung.com>>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com
<mailto:kyungmin.park@samsung.com>>
---

diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c

index 0a4dbdc..74122d1 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
 }
 
 /**
+ * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
+ * @var: pointer to struct fb_var_screeninfo
+ * @mode: pointer to struct fb_cpumode
+ */
+void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
+			 const struct fb_cmdmode *mode)
+{
+	var->xres = mode->xres;
+	var->yres = mode->yres;
+	var->xres_virtual = mode->xres;
+	var->yres_virtual = mode->yres;
+	var->xoffset = 0;
+	var->yoffset = 0;
+	var->pixclock = mode->pixclock;
+	var->cs_setup = mode->cs_setup;
+	var->wr_setup = mode->wr_setup;
+	var->wr_act = mode->wr_act;
+	var->wr_hold = mode->wr_hold;
+}
+
+/**
  * fb_mode_is_equal - compare 2 videomodes
  * @mode1: first videomode
  * @mode2: second videomode
@@ -1048,6 +1069,7 @@ finished:
 EXPORT_SYMBOL(fb_find_best_display);
 
 EXPORT_SYMBOL(fb_videomode_to_var);
+EXPORT_SYMBOL(fb_cmdmode_to_var);
 EXPORT_SYMBOL(fb_var_to_videomode);
 EXPORT_SYMBOL(fb_mode_is_equal);
 EXPORT_SYMBOL(fb_add_videomode);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 907ace3..73381c3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -269,6 +269,12 @@ struct fb_var_screeninfo {
 	__u32 vmode;			/* see FB_VMODE_*		*/
 	__u32 rotate;			/* angle we rotate counter clockwise */
 	__u32 reserved[5];		/* Reserved for future compatibility */
+
+	/* For cpu interface timing. */
+	__u32 cs_setup;
+	__u32 wr_setup;
+	__u32 wr_act;
+	__u32 wr_hold;
 };
 
 struct fb_cmap {
@@ -1117,11 +1123,24 @@ struct fb_videomode {
 	u32 lower_margin;
 	u32 hsync_len;
 	u32 vsync_len;
+	u32 cmd_allow_len;
 	u32 sync;
 	u32 vmode;
 	u32 flag;
 };
 
+struct fb_cmdmode {
+	const char *name;	/* optional */
+	u32 refresh;		/* optional */
+	u32 xres;
+	u32 yres;
+	u32 pixclock;
+	u32 cs_setup;
+	u32 wr_setup;
+	u32 wr_act;
+	u32 wr_hold;
+};
+
 extern const char *fb_mode_option;
 extern const struct fb_videomode vesa_modes[];
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100629/17de1d8e/attachment-0001.html>

Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[Jaya Kumar]

2010/6/29 InKi Dae <inki.dae@samsung.com>:
> CPU interface needs cs, wr setup, wr act and hold delay.
> I added some members for them to common framework.

Hi InKi Dae,

The patch looks interesting. Could you help us understand more about
it from a big picture perspective? ie: how is this "cpu interface"
used? I think fb_var_screeninfo is intended to be a very generic data
structure and since it is exposed to userspace we should be cautious
about what we add to it. I didn't understand the purpose of exposing
cs, wr setup, wr act and hold delay to userspace. Are the MIPI display
parameters being specified from userspace? I also didn't understand
the fb_cmdmode_to_var export. I looked through the other 2 patches
(3/3 and 2/3) and didn't see it used so I might have missed something.
Also, I wanted to ask, since there are now multiple MIPI-DSI host
controller drivers in fbdev (omap and also mobile-sh), is there any
work that could be done to make these implementations share more code?

Thanks,
jaya

>
> Signed-off-by: InKi Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>
> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
>
> index 0a4dbdc..74122d1 100644
> --- a/drivers/video/modedb.c
> +++ b/drivers/video/modedb.c
> @@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
>  }
>
>  /**
> + * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
> + * @var: pointer to struct fb_var_screeninfo
> + * @mode: pointer to struct fb_cpumode
> + */
> +void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
> +			 const struct fb_cmdmode *mode)
> +{
> +	var->xres = mode->xres;
> +	var->yres = mode->yres;
> +	var->xres_virtual = mode->xres;
> +	var->yres_virtual = mode->yres;
> +	var->xoffset = 0;
> +	var->yoffset = 0;
> +	var->pixclock = mode->pixclock;
> +	var->cs_setup = mode->cs_setup;
> +	var->wr_setup = mode->wr_setup;
> +	var->wr_act = mode->wr_act;
> +	var->wr_hold = mode->wr_hold;
> +}
> +
> +/**
>   * fb_mode_is_equal - compare 2 videomodes
>   * @mode1: first videomode
>   * @mode2: second videomode
> @@ -1048,6 +1069,7 @@ finished:
>  EXPORT_SYMBOL(fb_find_best_display);
>
>  EXPORT_SYMBOL(fb_videomode_to_var);
> +EXPORT_SYMBOL(fb_cmdmode_to_var);
>  EXPORT_SYMBOL(fb_var_to_videomode);
>  EXPORT_SYMBOL(fb_mode_is_equal);
>  EXPORT_SYMBOL(fb_add_videomode);
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 907ace3..73381c3 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -269,6 +269,12 @@ struct fb_var_screeninfo {
>  	__u32 vmode;			/* see FB_VMODE_*		*/
>  	__u32 rotate;			/* angle we rotate counter clockwise */
>  	__u32 reserved[5];		/* Reserved for future compatibility */
> +
> +	/* For cpu interface timing. */
> +	__u32 cs_setup;
> +	__u32 wr_setup;
> +	__u32 wr_act;
> +	__u32 wr_hold;
>  };
>
>  struct fb_cmap {
> @@ -1117,11 +1123,24 @@ struct fb_videomode {
>  	u32 lower_margin;
>  	u32 hsync_len;
>  	u32 vsync_len;
> +	u32 cmd_allow_len;
>  	u32 sync;
>  	u32 vmode;
>  	u32 flag;
>  };
>
> +struct fb_cmdmode {
> +	const char *name;	/* optional */
> +	u32 refresh;		/* optional */
> +	u32 xres;
> +	u32 yres;
> +	u32 pixclock;
> +	u32 cs_setup;
> +	u32 wr_setup;
> +	u32 wr_act;
> +	u32 wr_hold;
> +};
> +
>  extern const char *fb_mode_option;
>  extern const struct fb_videomode vesa_modes[];
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>

[PATCH 1/3] FB: Add some members for CPU Interface.

[Jaya Kumar]

2010/6/29 InKi Dae <inki.dae@samsung.com>:
> CPU interface needs cs, wr setup, wr act and hold delay.
> I added some members for them to common framework.

Hi InKi Dae,

The patch looks interesting. Could you help us understand more about
it from a big picture perspective? ie: how is this "cpu interface"
used? I think fb_var_screeninfo is intended to be a very generic data
structure and since it is exposed to userspace we should be cautious
about what we add to it. I didn't understand the purpose of exposing
cs, wr setup, wr act and hold delay to userspace. Are the MIPI display
parameters being specified from userspace? I also didn't understand
the fb_cmdmode_to_var export. I looked through the other 2 patches
(3/3 and 2/3) and didn't see it used so I might have missed something.
Also, I wanted to ask, since there are now multiple MIPI-DSI host
controller drivers in fbdev (omap and also mobile-sh), is there any
work that could be done to make these implementations share more code?

Thanks,
jaya

>
> Signed-off-by: InKi Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>
> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
>
> index 0a4dbdc..74122d1 100644
> --- a/drivers/video/modedb.c
> +++ b/drivers/video/modedb.c
> @@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
>  }
>
>  /**
> + * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
> + * @var: pointer to struct fb_var_screeninfo
> + * @mode: pointer to struct fb_cpumode
> + */
> +void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
> +			 const struct fb_cmdmode *mode)
> +{
> +	var->xres = mode->xres;
> +	var->yres = mode->yres;
> +	var->xres_virtual = mode->xres;
> +	var->yres_virtual = mode->yres;
> +	var->xoffset = 0;
> +	var->yoffset = 0;
> +	var->pixclock = mode->pixclock;
> +	var->cs_setup = mode->cs_setup;
> +	var->wr_setup = mode->wr_setup;
> +	var->wr_act = mode->wr_act;
> +	var->wr_hold = mode->wr_hold;
> +}
> +
> +/**
>   * fb_mode_is_equal - compare 2 videomodes
>   * @mode1: first videomode
>   * @mode2: second videomode
> @@ -1048,6 +1069,7 @@ finished:
>  EXPORT_SYMBOL(fb_find_best_display);
>
>  EXPORT_SYMBOL(fb_videomode_to_var);
> +EXPORT_SYMBOL(fb_cmdmode_to_var);
>  EXPORT_SYMBOL(fb_var_to_videomode);
>  EXPORT_SYMBOL(fb_mode_is_equal);
>  EXPORT_SYMBOL(fb_add_videomode);
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 907ace3..73381c3 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -269,6 +269,12 @@ struct fb_var_screeninfo {
>  	__u32 vmode;			/* see FB_VMODE_*		*/
>  	__u32 rotate;			/* angle we rotate counter clockwise */
>  	__u32 reserved[5];		/* Reserved for future compatibility */
> +
> +	/* For cpu interface timing. */
> +	__u32 cs_setup;
> +	__u32 wr_setup;
> +	__u32 wr_act;
> +	__u32 wr_hold;
>  };
>
>  struct fb_cmap {
> @@ -1117,11 +1123,24 @@ struct fb_videomode {
>  	u32 lower_margin;
>  	u32 hsync_len;
>  	u32 vsync_len;
> +	u32 cmd_allow_len;
>  	u32 sync;
>  	u32 vmode;
>  	u32 flag;
>  };
>
> +struct fb_cmdmode {
> +	const char *name;	/* optional */
> +	u32 refresh;		/* optional */
> +	u32 xres;
> +	u32 yres;
> +	u32 pixclock;
> +	u32 cs_setup;
> +	u32 wr_setup;
> +	u32 wr_act;
> +	u32 wr_hold;
> +};
> +
>  extern const char *fb_mode_option;
>  extern const struct fb_videomode vesa_modes[];
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>

Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[InKi Dae]

Hi Jaya,

2010/6/30 Jaya Kumar <jayakumar.lkml@gmail.com>:
> 2010/6/29 InKi Dae <inki.dae@samsung.com>:
>> CPU interface needs cs, wr setup, wr act and hold delay.
>> I added some members for them to common framework.
>
> Hi InKi Dae,
>
> The patch looks interesting. Could you help us understand more about
> it from a big picture perspective? ie: how is this "cpu interface"
> used? I think fb_var_screeninfo is intended to be a very generic data
> structure and since it is exposed to userspace we should be cautious
> about what we add to it. I didn't understand the purpose of exposing
> cs, wr setup, wr act and hold delay to userspace.

in case of lcd panel with cpu interface, it could get screen data
through arm core
or display controller supporting cpu interface mode.
display controller of s5pv210 chip can create cpu interface signal according to
cs, wr setup, wr act and hold time setting.
the reason I added cpu timing variables to fb_var_screeninfo is for using common
framework when setting them to the display controller as cpu timing info.
please, see [PATCH 2/3], s3c_fb_set_timing function part.

and cpu timing could be adjusted by user through fb_var_screeninfo,
for this, suitable checking should be considered at machine specific
fb_check_var func.
also you can see that through [PATCH 2/3], s3c_fb_check_var.

> Are the MIPI display
> parameters being specified from userspace? I also didn't understand
> the fb_cmdmode_to_var export. I looked through the other 2 patches
> (3/3 and 2/3) and didn't see it used so I might have missed something.

I just exported fb_cmdmode_to_var for future use. it doesn't use this func yet.
now, modedb.c and fb.h have no variables for cpu interface. perhaps, more codes
for cpu interface should be added to them.

> Also, I wanted to ask, since there are now multiple MIPI-DSI host
> controller drivers in fbdev (omap and also mobile-sh), is there any
> work that could be done to make these implementations share more code?

can MIPI-DSI host controller drivers you said use commonly?
I think these drivers are machine specific. so driver for MIPI-DSI
controller of S5PV210
should be implemented.

this patch code is MIPI Master driver and it can registered multiple
MIPI client driver
(mipi based lcd panel driver).
to use master driver, mipi client driver have to define some callbacks to struct
mipi_lcd_driver, and register them through s5p_dsim_register_lcd_driver func.
after this, client driver would be registered to master driver, and
client driver registered
would be probed when master driver was probed scaning client driver name.

please, see [PATCH 3/3], s5p_dsim_probe func part.

thank you for your interesting.

Best Regards,
InKi Dae.

[PATCH 1/3] FB: Add some members for CPU Interface.

[InKi Dae]

Hi Jaya,

2010/6/30 Jaya Kumar <jayakumar.lkml@gmail.com>:
> 2010/6/29 InKi Dae <inki.dae@samsung.com>:
>> CPU interface needs cs, wr setup, wr act and hold delay.
>> I added some members for them to common framework.
>
> Hi InKi Dae,
>
> The patch looks interesting. Could you help us understand more about
> it from a big picture perspective? ie: how is this "cpu interface"
> used? I think fb_var_screeninfo is intended to be a very generic data
> structure and since it is exposed to userspace we should be cautious
> about what we add to it. I didn't understand the purpose of exposing
> cs, wr setup, wr act and hold delay to userspace.

in case of lcd panel with cpu interface, it could get screen data
through arm core
or display controller supporting cpu interface mode.
display controller of s5pv210 chip can create cpu interface signal according to
cs, wr setup, wr act and hold time setting.
the reason I added cpu timing variables to fb_var_screeninfo is for using common
framework when setting them to the display controller as cpu timing info.
please, see [PATCH 2/3], s3c_fb_set_timing function part.

and cpu timing could be adjusted by user through fb_var_screeninfo,
for this, suitable checking should be considered at machine specific
fb_check_var func.
also you can see that through [PATCH 2/3], s3c_fb_check_var.

> Are the MIPI display
> parameters being specified from userspace? I also didn't understand
> the fb_cmdmode_to_var export. I looked through the other 2 patches
> (3/3 and 2/3) and didn't see it used so I might have missed something.

I just exported fb_cmdmode_to_var for future use. it doesn't use this func yet.
now, modedb.c and fb.h have no variables for cpu interface. perhaps, more codes
for cpu interface should be added to them.

> Also, I wanted to ask, since there are now multiple MIPI-DSI host
> controller drivers in fbdev (omap and also mobile-sh), is there any
> work that could be done to make these implementations share more code?

can MIPI-DSI host controller drivers you said use commonly?
I think these drivers are machine specific. so driver for MIPI-DSI
controller of S5PV210
should be implemented.

this patch code is MIPI Master driver and it can registered multiple
MIPI client driver
(mipi based lcd panel driver).
to use master driver, mipi client driver have to define some callbacks to struct
mipi_lcd_driver, and register them through s5p_dsim_register_lcd_driver func.
after this, client driver would be registered to master driver, and
client driver registered
would be probed when master driver was probed scaning client driver name.

please, see [PATCH 3/3], s5p_dsim_probe func part.

thank you for your interesting.

Best Regards,
InKi Dae.

Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[Jaya Kumar]

Hi InKi,

Thanks for your reply.

On Wed, Jun 30, 2010 at 12:36 PM, InKi Dae <daeinki@gmail.com> wrote:
> Hi Jaya,
>
> 2010/6/30 Jaya Kumar <jayakumar.lkml@gmail.com>:
>> 2010/6/29 InKi Dae <inki.dae@samsung.com>:
>>> CPU interface needs cs, wr setup, wr act and hold delay.
>>> I added some members for them to common framework.
>>
>> Hi InKi Dae,
>>
>> The patch looks interesting. Could you help us understand more about
>> it from a big picture perspective? ie: how is this "cpu interface"
>> used? I think fb_var_screeninfo is intended to be a very generic data
>> structure and since it is exposed to userspace we should be cautious
>> about what we add to it. I didn't understand the purpose of exposing
>> cs, wr setup, wr act and hold delay to userspace.
>
> in case of lcd panel with cpu interface, it could get screen data
> through arm core
> or display controller supporting cpu interface mode.
> display controller of s5pv210 chip can create cpu interface signal according to
> cs, wr setup, wr act and hold time setting.
> the reason I added cpu timing variables to fb_var_screeninfo is for using common
> framework when setting them to the display controller as cpu timing info.
> please, see [PATCH 2/3], s3c_fb_set_timing function part.
>
> and cpu timing could be adjusted by user through fb_var_screeninfo,
> for this, suitable checking should be considered at machine specific
> fb_check_var func.
> also you can see that through [PATCH 2/3], s3c_fb_check_var.

I'm still having difficulty understanding this. I guess what I am
asking is why do these new variables "cs, wr setup, wr act and hold
time setting", have to be in fb_var_screeninfo which is a generic
platform/implementation independent structure exposed to userspace? If
I've understood things correctly, the variables themselves, eg: wr
setup seem to be specific to this implementation rather than being
generic like the other members of fb_var_sreeninfo. Have you
considered an alternative way by which you can achieve the desired
functionality. Also, I'm confused when you say "cpu timing" could be
adjusted by user through fb_var_screeninfo. Could you elaborate on
that?

I haven't read through the remaining part of the message about
mipi-dsi issues, I'm hoping developers who have implemented the other
MIPI-DSI implementations in fbdev could chime in.

Thanks,
jaya

[PATCH 1/3] FB: Add some members for CPU Interface.

[Jaya Kumar]

Hi InKi,

Thanks for your reply.

On Wed, Jun 30, 2010 at 12:36 PM, InKi Dae <daeinki@gmail.com> wrote:
> Hi Jaya,
>
> 2010/6/30 Jaya Kumar <jayakumar.lkml@gmail.com>:
>> 2010/6/29 InKi Dae <inki.dae@samsung.com>:
>>> CPU interface needs cs, wr setup, wr act and hold delay.
>>> I added some members for them to common framework.
>>
>> Hi InKi Dae,
>>
>> The patch looks interesting. Could you help us understand more about
>> it from a big picture perspective? ie: how is this "cpu interface"
>> used? I think fb_var_screeninfo is intended to be a very generic data
>> structure and since it is exposed to userspace we should be cautious
>> about what we add to it. I didn't understand the purpose of exposing
>> cs, wr setup, wr act and hold delay to userspace.
>
> in case of lcd panel with cpu interface, it could get screen data
> through arm core
> or display controller supporting cpu interface mode.
> display controller of s5pv210 chip can create cpu interface signal according to
> cs, wr setup, wr act and hold time setting.
> the reason I added cpu timing variables to fb_var_screeninfo is for using common
> framework when setting them to the display controller as cpu timing info.
> please, see [PATCH 2/3], s3c_fb_set_timing function part.
>
> and cpu timing could be adjusted by user through fb_var_screeninfo,
> for this, suitable checking should be considered at machine specific
> fb_check_var func.
> also you can see that through [PATCH 2/3], s3c_fb_check_var.

I'm still having difficulty understanding this. I guess what I am
asking is why do these new variables "cs, wr setup, wr act and hold
time setting", have to be in fb_var_screeninfo which is a generic
platform/implementation independent structure exposed to userspace? If
I've understood things correctly, the variables themselves, eg: wr
setup seem to be specific to this implementation rather than being
generic like the other members of fb_var_sreeninfo. Have you
considered an alternative way by which you can achieve the desired
functionality. Also, I'm confused when you say "cpu timing" could be
adjusted by user through fb_var_screeninfo. Could you elaborate on
that?

I haven't read through the remaining part of the message about
mipi-dsi issues, I'm hoping developers who have implemented the other
MIPI-DSI implementations in fbdev could chime in.

Thanks,
jaya

Re: Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[In-Ki Dae]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 3742 bytes --]

Hi, Jaya,

>I'm confused when you say "cpu timing" could be
>adjusted by user through fb_var_screeninfo. Could you elaborate on
>that?

my saying is the case that display controller creates cpu timing.
display controller with cpu mode would create cpu timing signals
according to cpu timing variables.

the reason, using cpu interface, is because it could reduce power consumption.
in case of rgb interface, screen data with 60fps are transferred to lcd panel automatically
according to rgb signals.
but cpu interface is transferred only when triggerred, of course the way of triggering could
be different according to platform. (also adjusting cpu timing delay)
ex) if there is stop screen, it doesn't need to trigger and
      if slow moving, it could increase cpu timing delay.

as I said to Andraw before, cpu timing variables could be used gernerically.
because lcd panel includes cpu mode also.
but linux framebuffer framework didn't consider cpu mode.

if there is some part I don't know, please give me some advices.
I could modify my patchs anytime.

thank you.

------- Original Message -------
Sender : Jaya Kumar<jayakumar.lkml@gmail.com> 
Date   : 2010-07-02 08:47 (GMT+09:00)
Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.

Hi InKi,

Thanks for your reply.

On Wed, Jun 30, 2010 at 12:36 PM, InKi Dae <daeinki@gmail.com> wrote:
> Hi Jaya,
>
> 2010/6/30 Jaya Kumar <jayakumar.lkml@gmail.com>:
>> 2010/6/29 InKi Dae <inki.dae@samsung.com>:
>>> CPU interface needs cs, wr setup, wr act and hold delay.
>>> I added some members for them to common framework.
>>
>> Hi InKi Dae,
>>
>> The patch looks interesting. Could you help us understand more about
>> it from a big picture perspective? ie: how is this "cpu interface"
>> used? I think fb_var_screeninfo is intended to be a very generic data
>> structure and since it is exposed to userspace we should be cautious
>> about what we add to it. I didn't understand the purpose of exposing
>> cs, wr setup, wr act and hold delay to userspace.
>
> in case of lcd panel with cpu interface, it could get screen data
> through arm core
> or display controller supporting cpu interface mode.
> display controller of s5pv210 chip can create cpu interface signal according to
> cs, wr setup, wr act and hold time setting.
> the reason I added cpu timing variables to fb_var_screeninfo is for using common
> framework when setting them to the display controller as cpu timing info.
> please, see [PATCH 2/3], s3c_fb_set_timing function part.
>
> and cpu timing could be adjusted by user through fb_var_screeninfo,
> for this, suitable checking should be considered at machine specific
> fb_check_var func.
> also you can see that through [PATCH 2/3], s3c_fb_check_var.

I'm still having difficulty understanding this. I guess what I am
asking is why do these new variables "cs, wr setup, wr act and hold
time setting", have to be in fb_var_screeninfo which is a generic
platform/implementation independent structure exposed to userspace? If
I've understood things correctly, the variables themselves, eg: wr
setup seem to be specific to this implementation rather than being
generic like the other members of fb_var_sreeninfo. Have you
considered an alternative way by which you can achieve the desired
functionality. Also, I'm confused when you say "cpu timing" could be
adjusted by user through fb_var_screeninfo. Could you elaborate on
that?

I haven't read through the remaining part of the message about
mipi-dsi issues, I'm hoping developers who have implemented the other
MIPI-DSI implementations in fbdev could chime in.

Thanks,
jaya



ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

[PATCH 1/3] FB: Add some members for CPU Interface.

[In-Ki Dae]

Hi, Jaya,

>I'm confused when you say "cpu timing" could be
>adjusted by user through fb_var_screeninfo. Could you elaborate on
>that?

my saying is the case that display controller creates cpu timing.
display controller with cpu mode would create cpu timing signals
according to cpu timing variables.

the reason, using cpu interface, is because it could reduce power consumption.
in case of rgb interface, screen data with 60fps are transferred to lcd panel automatically
according to rgb signals.
but cpu interface is transferred only when triggerred, of course the way of triggering could
be different according to platform. (also adjusting cpu timing delay)
ex) if there is stop screen, it doesn't need to trigger and
      if slow moving, it could increase cpu timing delay.

as I said to Andraw before, cpu timing variables could be used gernerically.
because lcd panel includes cpu mode also.
but linux framebuffer framework didn't consider cpu mode.

if there is some part I don't know, please give me some advices.
I could modify my patchs anytime.

thank you.

------- Original Message -------
Sender : Jaya Kumar<jayakumar.lkml@gmail.com> 
Date   : 2010-07-02 08:47 (GMT+09:00)
Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.

Hi InKi,

Thanks for your reply.

On Wed, Jun 30, 2010 at 12:36 PM, InKi Dae <daeinki@gmail.com> wrote:
> Hi Jaya,
>
> 2010/6/30 Jaya Kumar <jayakumar.lkml@gmail.com>:
>> 2010/6/29 InKi Dae <inki.dae@samsung.com>:
>>> CPU interface needs cs, wr setup, wr act and hold delay.
>>> I added some members for them to common framework.
>>
>> Hi InKi Dae,
>>
>> The patch looks interesting. Could you help us understand more about
>> it from a big picture perspective? ie: how is this "cpu interface"
>> used? I think fb_var_screeninfo is intended to be a very generic data
>> structure and since it is exposed to userspace we should be cautious
>> about what we add to it. I didn't understand the purpose of exposing
>> cs, wr setup, wr act and hold delay to userspace.
>
> in case of lcd panel with cpu interface, it could get screen data
> through arm core
> or display controller supporting cpu interface mode.
> display controller of s5pv210 chip can create cpu interface signal according to
> cs, wr setup, wr act and hold time setting.
> the reason I added cpu timing variables to fb_var_screeninfo is for using common
> framework when setting them to the display controller as cpu timing info.
> please, see [PATCH 2/3], s3c_fb_set_timing function part.
>
> and cpu timing could be adjusted by user through fb_var_screeninfo,
> for this, suitable checking should be considered at machine specific
> fb_check_var func.
> also you can see that through [PATCH 2/3], s3c_fb_check_var.

I'm still having difficulty understanding this. I guess what I am
asking is why do these new variables "cs, wr setup, wr act and hold
time setting", have to be in fb_var_screeninfo which is a generic
platform/implementation independent structure exposed to userspace? If
I've understood things correctly, the variables themselves, eg: wr
setup seem to be specific to this implementation rather than being
generic like the other members of fb_var_sreeninfo. Have you
considered an alternative way by which you can achieve the desired
functionality. Also, I'm confused when you say "cpu timing" could be
adjusted by user through fb_var_screeninfo. Could you elaborate on
that?

I haven't read through the remaining part of the message about
mipi-dsi issues, I'm hoping developers who have implemented the other
MIPI-DSI implementations in fbdev could chime in.

Thanks,
jaya

Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[Russell King - ARM Linux]

On Wed, Jun 30, 2010 at 08:02:31AM +0800, Jaya Kumar wrote:
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 907ace3..73381c3 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -269,6 +269,12 @@ struct fb_var_screeninfo {
> >  	__u32 vmode;			/* see FB_VMODE_*		*/
> >  	__u32 rotate;			/* angle we rotate counter clockwise */
> >  	__u32 reserved[5];		/* Reserved for future compatibility */
> > +
> > +	/* For cpu interface timing. */
> > +	__u32 cs_setup;
> > +	__u32 wr_setup;
> > +	__u32 wr_act;
> > +	__u32 wr_hold;

This changes the framebuffer userspace API, making it incompatible with
existing users.  What this means is that stuff using the framebuffer API
in userspace has to be upgraded/downgraded in lock-step with this change
- which is not a good idea.

[PATCH 1/3] FB: Add some members for CPU Interface.

[Russell King - ARM Linux]

On Wed, Jun 30, 2010 at 08:02:31AM +0800, Jaya Kumar wrote:
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 907ace3..73381c3 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -269,6 +269,12 @@ struct fb_var_screeninfo {
> >  	__u32 vmode;			/* see FB_VMODE_*		*/
> >  	__u32 rotate;			/* angle we rotate counter clockwise */
> >  	__u32 reserved[5];		/* Reserved for future compatibility */
> > +
> > +	/* For cpu interface timing. */
> > +	__u32 cs_setup;
> > +	__u32 wr_setup;
> > +	__u32 wr_act;
> > +	__u32 wr_hold;

This changes the framebuffer userspace API, making it incompatible with
existing users.  What this means is that stuff using the framebuffer API
in userspace has to be upgraded/downgraded in lock-step with this change
- which is not a good idea.

Re: Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[In-Ki Dae]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1602 bytes --]

Ok, I understood.

I think this issue incompatible with existing users is because userspace API didn't consider cpu mode before.
anyway, I will correct my patch as your comments and send it again.
Perhaps, cpu timing variables would be moved to platform file.

thank you.

------- Original Message -------
Sender : Russell King - ARM Linux<linux@arm.linux.org.uk> 
Date   : 2010-07-02 16:30 (GMT+09:00)
Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.

On Wed, Jun 30, 2010 at 08:02:31AM +0800, Jaya Kumar wrote:
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 907ace3..73381c3 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -269,6 +269,12 @@ struct fb_var_screeninfo {
> >  	__u32 vmode;			/* see FB_VMODE_*		*/
> >  	__u32 rotate;			/* angle we rotate counter clockwise */
> >  	__u32 reserved[5];		/* Reserved for future compatibility */
> > +
> > +	/* For cpu interface timing. */
> > +	__u32 cs_setup;
> > +	__u32 wr_setup;
> > +	__u32 wr_act;
> > +	__u32 wr_hold;

This changes the framebuffer userspace API, making it incompatible with
existing users.  What this means is that stuff using the framebuffer API
in userspace has to be upgraded/downgraded in lock-step with this change
- which is not a good idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

[PATCH 1/3] FB: Add some members for CPU Interface.

[In-Ki Dae]

Ok, I understood.

I think this issue incompatible with existing users is because userspace API didn't consider cpu mode before.
anyway, I will correct my patch as your comments and send it again.
Perhaps, cpu timing variables would be moved to platform file.

thank you.

------- Original Message -------
Sender : Russell King - ARM Linux<linux@arm.linux.org.uk> 
Date   : 2010-07-02 16:30 (GMT+09:00)
Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.

On Wed, Jun 30, 2010 at 08:02:31AM +0800, Jaya Kumar wrote:
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 907ace3..73381c3 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -269,6 +269,12 @@ struct fb_var_screeninfo {
> >  	__u32 vmode;			/* see FB_VMODE_*		*/
> >  	__u32 rotate;			/* angle we rotate counter clockwise */
> >  	__u32 reserved[5];		/* Reserved for future compatibility */
> > +
> > +	/* For cpu interface timing. */
> > +	__u32 cs_setup;
> > +	__u32 wr_setup;
> > +	__u32 wr_act;
> > +	__u32 wr_hold;

This changes the framebuffer userspace API, making it incompatible with
existing users.  What this means is that stuff using the framebuffer API
in userspace has to be upgraded/downgraded in lock-step with this change
- which is not a good idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1755 bytes --]


> 
> I think this issue incompatible with existing users is because userspace API didn't consider cpu mode before.
> anyway, I will correct my patch as your comments and send it again.
> Perhaps, cpu timing variables would be moved to platform file.

I would suggest using sysfs for those extra variables.

> thank you.
> 
> ------- Original Message -------
> Sender : Russell King - ARM Linux<linux@arm.linux.org.uk> 
> Date   : 2010-07-02 16:30 (GMT+09:00)
> Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.
> 
> On Wed, Jun 30, 2010 at 08:02:31AM +0800, Jaya Kumar wrote:
> > > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > > index 907ace3..73381c3 100644
> > > --- a/include/linux/fb.h
> > > +++ b/include/linux/fb.h
> > > @@ -269,6 +269,12 @@ struct fb_var_screeninfo {
> > >  	__u32 vmode;			/* see FB_VMODE_*		*/
> > >  	__u32 rotate;			/* angle we rotate counter clockwise */
> > >  	__u32 reserved[5];		/* Reserved for future compatibility */
> > > +
> > > +	/* For cpu interface timing. */
> > > +	__u32 cs_setup;
> > > +	__u32 wr_setup;
> > > +	__u32 wr_act;
> > > +	__u32 wr_hold;
> 
> This changes the framebuffer userspace API, making it incompatible with
> existing users.  What this means is that stuff using the framebuffer API
> in userspace has to be upgraded/downgraded in lock-step with this change
> - which is not a good idea.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±}·^¾)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j/???êäz¹Þ–Šà2ŠÞ™¨è­Ú&¢)ß¡«a¶Ú\x7fþø\x1e®G«???éh®\x0fæj:+v‰¨Šwè†Ù¥

[PATCH 1/3] FB: Add some members for CPU Interface.

[James Simmons]

> 
> I think this issue incompatible with existing users is because userspace API didn't consider cpu mode before.
> anyway, I will correct my patch as your comments and send it again.
> Perhaps, cpu timing variables would be moved to platform file.

I would suggest using sysfs for those extra variables.

> thank you.
> 
> ------- Original Message -------
> Sender : Russell King - ARM Linux<linux@arm.linux.org.uk> 
> Date   : 2010-07-02 16:30 (GMT+09:00)
> Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.
> 
> On Wed, Jun 30, 2010 at 08:02:31AM +0800, Jaya Kumar wrote:
> > > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > > index 907ace3..73381c3 100644
> > > --- a/include/linux/fb.h
> > > +++ b/include/linux/fb.h
> > > @@ -269,6 +269,12 @@ struct fb_var_screeninfo {
> > >  	__u32 vmode;			/* see FB_VMODE_*		*/
> > >  	__u32 rotate;			/* angle we rotate counter clockwise */
> > >  	__u32 reserved[5];		/* Reserved for future compatibility */
> > > +
> > > +	/* For cpu interface timing. */
> > > +	__u32 cs_setup;
> > > +	__u32 wr_setup;
> > > +	__u32 wr_act;
> > > +	__u32 wr_hold;
> 
> This changes the framebuffer userspace API, making it incompatible with
> existing users.  What this means is that stuff using the framebuffer API
> in userspace has to be upgraded/downgraded in lock-step with this change
> - which is not a good idea.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> N?????r??y????b?X????v?^?)??{.n?+????{?}?^?)????w*\x1fjg???
???????j/?????z?????2???????&?)???a??\x7f??
?G?????h?\x0f?j:+v???w????

[PATCH 1/3] FB: Add some members for CPU Interface.

[James Simmons]

CPU interface needs cs, wr setup, wr act and hold delay.
I added some members for them to common framework.

Signed-off-by: InKi Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---

diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c

index 0a4dbdc..74122d1 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
 }
 
 /**
+ * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
+ * @var: pointer to struct fb_var_screeninfo
+ * @mode: pointer to struct fb_cpumode
+ */
+void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
+			 const struct fb_cmdmode *mode)
+{
+	var->xres = mode->xres;
+	var->yres = mode->yres;
+	var->xres_virtual = mode->xres;
+	var->yres_virtual = mode->yres;
+	var->xoffset = 0;
+	var->yoffset = 0;
+	var->pixclock = mode->pixclock;
+	var->cs_setup = mode->cs_setup;
+	var->wr_setup = mode->wr_setup;
+	var->wr_act = mode->wr_act;
+	var->wr_hold = mode->wr_hold;
+}
+
+/**
  * fb_mode_is_equal - compare 2 videomodes
  * @mode1: first videomode
  * @mode2: second videomode
@@ -1048,6 +1069,7 @@ finished:
 EXPORT_SYMBOL(fb_find_best_display);
 
 EXPORT_SYMBOL(fb_videomode_to_var);
+EXPORT_SYMBOL(fb_cmdmode_to_var);
 EXPORT_SYMBOL(fb_var_to_videomode);
 EXPORT_SYMBOL(fb_mode_is_equal);
 EXPORT_SYMBOL(fb_add_videomode);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 907ace3..73381c3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -269,6 +269,12 @@ struct fb_var_screeninfo {
 	__u32 vmode;			/* see FB_VMODE_*		*/
 	__u32 rotate;			/* angle we rotate counter clockwise */
 	__u32 reserved[5];		/* Reserved for future compatibility */
+
+	/* For cpu interface timing. */
+	__u32 cs_setup;
+	__u32 wr_setup;
+	__u32 wr_act;
+	__u32 wr_hold;
 };
 
 struct fb_cmap {
@@ -1117,11 +1123,24 @@ struct fb_videomode {
 	u32 lower_margin;
 	u32 hsync_len;
 	u32 vsync_len;
+	u32 cmd_allow_len;
 	u32 sync;
 	u32 vmode;
 	u32 flag;
 };
 
+struct fb_cmdmode {
+	const char *name;	/* optional */
+	u32 refresh;		/* optional */
+	u32 xres;
+	u32 yres;
+	u32 pixclock;
+	u32 cs_setup;
+	u32 wr_setup;
+	u32 wr_act;
+	u32 wr_hold;
+};
+
 extern const char *fb_mode_option;
 extern const struct fb_videomode vesa_modes[];
 

[PATCH 1/3] FB: Add some members for CPU Interface.

[James Simmons]

CPU interface needs cs, wr setup, wr act and hold delay.
I added some members for them to common framework.

Signed-off-by: InKi Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---

diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c

index 0a4dbdc..74122d1 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
 }
 
 /**
+ * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
+ * @var: pointer to struct fb_var_screeninfo
+ * @mode: pointer to struct fb_cpumode
+ */
+void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
+			 const struct fb_cmdmode *mode)
+{
+	var->xres = mode->xres;
+	var->yres = mode->yres;
+	var->xres_virtual = mode->xres;
+	var->yres_virtual = mode->yres;
+	var->xoffset = 0;
+	var->yoffset = 0;
+	var->pixclock = mode->pixclock;
+	var->cs_setup = mode->cs_setup;
+	var->wr_setup = mode->wr_setup;
+	var->wr_act = mode->wr_act;
+	var->wr_hold = mode->wr_hold;
+}
+
+/**
  * fb_mode_is_equal - compare 2 videomodes
  * @mode1: first videomode
  * @mode2: second videomode
@@ -1048,6 +1069,7 @@ finished:
 EXPORT_SYMBOL(fb_find_best_display);
 
 EXPORT_SYMBOL(fb_videomode_to_var);
+EXPORT_SYMBOL(fb_cmdmode_to_var);
 EXPORT_SYMBOL(fb_var_to_videomode);
 EXPORT_SYMBOL(fb_mode_is_equal);
 EXPORT_SYMBOL(fb_add_videomode);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 907ace3..73381c3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -269,6 +269,12 @@ struct fb_var_screeninfo {
 	__u32 vmode;			/* see FB_VMODE_*		*/
 	__u32 rotate;			/* angle we rotate counter clockwise */
 	__u32 reserved[5];		/* Reserved for future compatibility */
+
+	/* For cpu interface timing. */
+	__u32 cs_setup;
+	__u32 wr_setup;
+	__u32 wr_act;
+	__u32 wr_hold;
 };
 
 struct fb_cmap {
@@ -1117,11 +1123,24 @@ struct fb_videomode {
 	u32 lower_margin;
 	u32 hsync_len;
 	u32 vsync_len;
+	u32 cmd_allow_len;
 	u32 sync;
 	u32 vmode;
 	u32 flag;
 };
 
+struct fb_cmdmode {
+	const char *name;	/* optional */
+	u32 refresh;		/* optional */
+	u32 xres;
+	u32 yres;
+	u32 pixclock;
+	u32 cs_setup;
+	u32 wr_setup;
+	u32 wr_act;
+	u32 wr_hold;
+};
+
 extern const char *fb_mode_option;
 extern const struct fb_videomode vesa_modes[];
 

[PATCH 1/3] FB: Add some members for CPU Interface.

[James Simmons]

CPU interface needs cs, wr setup, wr act and hold delay.
I added some members for them to common framework.

Signed-off-by: InKi Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---

diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c

index 0a4dbdc..74122d1 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
 }
 
 /**
+ * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
+ * @var: pointer to struct fb_var_screeninfo
+ * @mode: pointer to struct fb_cpumode
+ */
+void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
+			 const struct fb_cmdmode *mode)
+{
+	var->xres = mode->xres;
+	var->yres = mode->yres;
+	var->xres_virtual = mode->xres;
+	var->yres_virtual = mode->yres;
+	var->xoffset = 0;
+	var->yoffset = 0;
+	var->pixclock = mode->pixclock;
+	var->cs_setup = mode->cs_setup;
+	var->wr_setup = mode->wr_setup;
+	var->wr_act = mode->wr_act;
+	var->wr_hold = mode->wr_hold;
+}
+
+/**
  * fb_mode_is_equal - compare 2 videomodes
  * @mode1: first videomode
  * @mode2: second videomode
@@ -1048,6 +1069,7 @@ finished:
 EXPORT_SYMBOL(fb_find_best_display);
 
 EXPORT_SYMBOL(fb_videomode_to_var);
+EXPORT_SYMBOL(fb_cmdmode_to_var);
 EXPORT_SYMBOL(fb_var_to_videomode);
 EXPORT_SYMBOL(fb_mode_is_equal);
 EXPORT_SYMBOL(fb_add_videomode);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 907ace3..73381c3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -269,6 +269,12 @@ struct fb_var_screeninfo {
 	__u32 vmode;			/* see FB_VMODE_*		*/
 	__u32 rotate;			/* angle we rotate counter clockwise */
 	__u32 reserved[5];		/* Reserved for future compatibility */
+
+	/* For cpu interface timing. */
+	__u32 cs_setup;
+	__u32 wr_setup;
+	__u32 wr_act;
+	__u32 wr_hold;
 };
 
 struct fb_cmap {
@@ -1117,11 +1123,24 @@ struct fb_videomode {
 	u32 lower_margin;
 	u32 hsync_len;
 	u32 vsync_len;
+	u32 cmd_allow_len;
 	u32 sync;
 	u32 vmode;
 	u32 flag;
 };
 
+struct fb_cmdmode {
+	const char *name;	/* optional */
+	u32 refresh;		/* optional */
+	u32 xres;
+	u32 yres;
+	u32 pixclock;
+	u32 cs_setup;
+	u32 wr_setup;
+	u32 wr_act;
+	u32 wr_hold;
+};
+
 extern const char *fb_mode_option;
 extern const struct fb_videomode vesa_modes[];
 

Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[Geert Uytterhoeven]

On Tue, Jul 6, 2010 at 17:30, James Simmons <jsimmons@infradead.org> wrote:
>
> CPU interface needs cs, wr setup, wr act and hold delay.
> I added some members for them to common framework.
>
> Signed-off-by: InKi Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>
> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
>
> index 0a4dbdc..74122d1 100644
> --- a/drivers/video/modedb.c
> +++ b/drivers/video/modedb.c
> @@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
>  }
>
>  /**
> + * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
         ^^^
> + * @var: pointer to struct fb_var_screeninfo
> + * @mode: pointer to struct fb_cpumode
> + */
> +void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
           ^^^

cpu vs cmd?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 964 bytes --]


On Tue, 6 Jul 2010, Geert Uytterhoeven wrote:

> On Tue, Jul 6, 2010 at 17:30, James Simmons <jsimmons@infradead.org> wrote:
> >
> > CPU interface needs cs, wr setup, wr act and hold delay.
> > I added some members for them to common framework.
> >
> > Signed-off-by: InKi Dae <inki.dae@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> >
> > diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
> >
> > index 0a4dbdc..74122d1 100644
> > --- a/drivers/video/modedb.c
> > +++ b/drivers/video/modedb.c
> > @@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
> >  }
> >
> >  /**
> > + * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
>          ^^^
> > + * @var: pointer to struct fb_var_screeninfo
> > + * @mode: pointer to struct fb_cpumode
> > + */
> > +void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
>            ^^^
> 
> cpu vs cmd?
> 

Forward comment to original author.

Re: Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[In-Ki Dae]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1788 bytes --]

Hi, Geert

cpu and command mode are same mean.
and fb_cmdmode_to_var func had been removed from my previous patch.
please, see patch v2.

thank you.

------- Original Message -------
Sender : Geert Uytterhoeven<geert@linux-m68k.org> 
Date   : 2010-07-07 05:23 (GMT+09:00)
Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.

On Tue, Jul 6, 2010 at 17:30, James Simmons <jsimmons@infradead.org> wrote:
>
> CPU interface needs cs, wr setup, wr act and hold delay.
> I added some members for them to common framework.
>
> Signed-off-by: InKi Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>
> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
>
> index 0a4dbdc..74122d1 100644
> --- a/drivers/video/modedb.c
> +++ b/drivers/video/modedb.c
> @@ -759,6 +759,27 @@ void fb_videomode_to_var(struct fb_var_screeninfo *var,
>  }
>
>  /**
> + * fb_cpumode_to_var - convert fb_cpumode to fb_var_screeninfo
         ^^^
> + * @var: pointer to struct fb_var_screeninfo
> + * @mode: pointer to struct fb_cpumode
> + */
> +void fb_cmdmode_to_var(struct fb_var_screeninfo *var,
           ^^^

cpu vs cmd?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

RE: [PATCH 1/3] FB: Add some members for CPU Interface.

[Pawel Osciak]

InKi Dae wrote:
>Signed-off-by: InKi Dae &lt;<a href="mailto:p.osciak@samsung.com">inki.dae@samsung.com</a>&gt;<br>
>Signed-off-by: Kyungmin Park &lt;<a
>href="mailto:kyungmin.park@samsung.com">kyungmin.park@samsung.com</a>&gt;<br>

Hi InKi,

please do not include my e-mail address like this. I had absolutely nothing to do with this patch series whatsoever.

Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center

[PATCH 1/3] FB: Add some members for CPU Interface.

[Pawel Osciak]

InKi Dae wrote:
>Signed-off-by: InKi Dae &lt;<a href="mailto:p.osciak@samsung.com">inki.dae at samsung.com</a>&gt;<br>
>Signed-off-by: Kyungmin Park &lt;<a
>href="mailto:kyungmin.park at samsung.com">kyungmin.park at samsung.com</a>&gt;<br>

Hi InKi,

please do not include my e-mail address like this. I had absolutely nothing to do with this patch series whatsoever.

Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center

Re: Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[In-Ki Dae]

Hi, Andrew,

cpu timing variables could be used generically.
now fb.h and modedb.c file have been considered only for video mode.
but the way of transfering screen data includes also command mode(cpu mode or i80 mode)
so I thought it should be added things for it to fb_varscreeninfo struct.

Could you please tell me why cpu timing variables are specific to s3c-fb?
------- Original Message -------
Sender : Andrew Morton<akpm@linux-foundation.org> 
Date   : 2010-07-02 07:26 (GMT+09:00)
Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.

On Tue, 29 Jun 2010 19:28:14 +0900
InKi Dae <inki.dae@samsung.com> wrote:

> 
> CPU interface needs cs, wr setup, wr act and hold delay.
> I added some members for them to common framework.
> 
> Signed-off-by: InKi Dae <inki.dae@samsung.com <mailto:p.osciak@samsung.com>>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com
> <mailto:kyungmin.park@samsung.com>>

These email addresses are mangled.

> --- a/drivers/video/modedb.c
> +++ b/drivers/video/modedb.c
> ...
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h

The patch seems pretty specific to s3c-fb.  Is it possible and sensible
to somhow avoid adding code to generic files?  Can we push more (or
all) of these changes into s3c-fb.c or into the arch/arm support code?

Re: Re: [PATCH 1/3] FB: Add some members for CPU Interface.

[In-Ki Dae]

Ok, andrew

I will add descriptions to these variables also apply commends of other developers.

Thank you.
------- Original Message -------
Sender : Andrew Morton<akpm@linux-foundation.org> 
Date   : 2010-07-02 10:46 (GMT+09:00)
Title  : Re: [PATCH 1/3] FB: Add some members for CPU Interface.

On Fri, 02 Jul 2010 01:21:12 +0000 (GMT) In-Ki Dae <inki.dae@samsung.com> wrote:

> Hi, Andrew,
> 
> cpu timing variables could be used generically.
> now fb.h and modedb.c file have been considered only for video mode.
> but the way of transfering screen data includes also command mode(cpu mode or i80 mode)
> so I thought it should be added things for it to fb_varscreeninfo struct.
> 
> Could you please tell me why cpu timing variables are specific to s3c-fb?

I dunno - I was just looking at the code.

I don't even know what "cpu timing variables" _are_, in the context of
video drivers.  Look at this:

> > CPU interface needs cs, wr setup, wr act and hold delay.
> > I added some members for them to common framework.

It's gobbledigook!  Please, write patch descriptions which help poor
dumb people who don't have detailed knowledge of the particular
hardware understand your patch?