Skip to contentSkip to conversation

FB: Add some members for CPU Interface.

PATCH New InKi Dae 7 participants 12 messages Jun 29, 2010 – Jul 8, 2010 Framebuffer layer

lore
Share & tools
lore

InKi Dae

author
#0 lore raw

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

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:[email protected]>>
Signed-off-by Kyungmin Park <kyungmin.park at samsung.com

<mailto:[email protected]>>
---

drivers/video/modedb.c +0 -0

index 0a4dbdc..74122d1 100644

drivers/video/modedb.c +22 -0
@@ -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);
include/linux/fb.h +19 -0
index 907ace3..73381c3 100644
@@ -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>

#1 lore raw

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

2010/6/29 InKi Dae <[email protected]>:

Quoted 2 lines

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

Quoted 96 lines

---

drivers/video/modedb.c +0 -0

index 0a4dbdc..74122d1 100644

drivers/video/modedb.c +22 -0
@@ -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);
include/linux/fb.h +19 -0
index 907ace3..73381c3 100644
@@ -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

#2 lore raw

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

Hi Jaya,

2010/6/30 Jaya Kumar <[email protected]>:

Quoted 4 lines

2010/6/29 InKi Dae <[email protected]>:

Quoted 2 lines

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

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

#3 lore raw

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

Hi InKi,

Thanks for your reply.

Quoted 25 lines · InKi Dae

Hi Jaya,

2010/6/30 Jaya Kumar <[email protected]>:

Quoted 4 lines

2010/6/29 InKi Dae <[email protected]>:

Quoted 2 lines

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

Quoted 8 lines

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.

Quoted 4 lines

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

#4 lore raw

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

In reply to Jaya Kumar
Quoted 6 lines · Jaya Kumar
Quoted 6 lines
include/linux/fb.h +0 -0
index 907ace3..73381c3 100644
@@ -269,6 +269,12 @@ struct fb_var_screeninfo {
 	__u32 vmode;			/* see FB_VMODE_*		*/
Quoted 8 lines

include/linux/fb.h struct fb_var_screeninfo { · line 277

Quoted 8 lines
include/linux/fb.h +6 -0
 	__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.

#5 lore raw

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

In reply to Jaya Kumar

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

---

drivers/video/modedb.c +0 -0

index 0a4dbdc..74122d1 100644

drivers/video/modedb.c +22 -0
@@ -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);
include/linux/fb.h +19 -0
index 907ace3..73381c3 100644
@@ -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[];
 
#6 lore raw

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

In reply to Jaya Kumar

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

---

drivers/video/modedb.c +0 -0

index 0a4dbdc..74122d1 100644

drivers/video/modedb.c +22 -0
@@ -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);
include/linux/fb.h +19 -0
index 907ace3..73381c3 100644
@@ -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[];
 
#7 lore raw

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

In reply to Jaya Kumar

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

---

drivers/video/modedb.c +0 -0

index 0a4dbdc..74122d1 100644

drivers/video/modedb.c +22 -0
@@ -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);
include/linux/fb.h +19 -0
index 907ace3..73381c3 100644
@@ -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[];
 
#8 lore raw
In reply to Jaya Kumar
Quoted 14 lines · James Simmons

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

---

drivers/video/modedb.c +0 -0

index 0a4dbdc..74122d1 100644

drivers/video/modedb.c void fb_videomode_to_var(struct fb_var_screeninfo *var, · line 762

Quoted 4 lines
drivers/video/modedb.c +1 -0
@@ -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
         ^^^

drivers/video/modedb.c void fb_videomode_to_var(struct fb_var_screeninfo *var, · line 766

Quoted 4 lines
drivers/video/modedb.c +4 -0
+ * @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 -- [email protected]

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

#9 lore raw
In reply to Jaya Kumar
Quoted 20 lines · Geert Uytterhoeven
Quoted 14 lines · James Simmons

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

---

drivers/video/modedb.c +0 -0

index 0a4dbdc..74122d1 100644

drivers/video/modedb.c void fb_videomode_to_var(struct fb_var_screeninfo *var, · line 762

Quoted 4 lines
drivers/video/modedb.c +1 -0
@@ -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
         ^^^
Quoted 8 lines

drivers/video/modedb.c void fb_videomode_to_var(struct fb_var_screeninfo *var, · line 766

Quoted 4 lines
drivers/video/modedb.c +4 -0
+ * @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.

author
#10 lore raw
In reply to Jaya Kumar

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<[email protected]>
Date : 2010-07-07 05:23 (GMT+09:00)
Title : Re: [PATCH 1/3] FB: Add some members for CPU Interface.

Quoted 14 lines · James Simmons

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

---

drivers/video/modedb.c +0 -0

index 0a4dbdc..74122d1 100644

drivers/video/modedb.c void fb_videomode_to_var(struct fb_var_screeninfo *var, · line 762

Quoted 4 lines
drivers/video/modedb.c +1 -0
@@ -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
         ^^^

drivers/video/modedb.c void fb_videomode_to_var(struct fb_var_screeninfo *var, · line 766

Quoted 4 lines
drivers/video/modedb.c +4 -0
+ * @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 -- [email protected]

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

#11 lore raw

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

In reply to InKi Dae
Quoted 3 lines · InKi Dae
Signed-off-by InKi Dae &lt;<a href="mailto:[email protected]">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