video: SuperH Mobile LCDC Driver
Subsystems (2)
PATCH 1/1 video: SuperH Mobile LCDC Driver
This patch adds frame buffer support for the LCDC block found in SuperH Mobile processors. The hardware supports up to two LCD panels per LCDC block, and both RGB and SYS interfaces can be used to hook up LCD panels/modules.
The device driver is a regular platform driver, so LCD configuration and board specific hooks are passed to the driver using platform data. LCD modules using SYS interface often require special configuration using the SYS bus, and to solve this cleanly the driver provides SYS interface operations to the board code.
Tested on sh7723 and sh7722 processors with a SYS16A QVGA panel and WVGA panels using RGB16 and RGB18 interfaces.
---
drivers/video/Kconfig | 10 drivers/video/Makefile | 2 drivers/video/sh_mobile_lcdcfb.c | 742 ++++++++++++++++++++++++++++++++++++++ include/asm-sh/sh_mobile_lcdc.h | 66 +++ 4 files changed, 820 insertions(+)
drivers/video/Kconfig +10 -0
@@ -1839,6 +1839,16 @@ config FB_W100 If unsure, say N. +config FB_SH_MOBILE_LCDC + tristate "SuperH Mobile LCDC framebuffer support" + depends on FB && SUPERH + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default m + ---help--- + Frame buffer driver for the on-chip SH-Mobile LCD controller. + config FB_S3C2410 tristate "S3C2410 LCD framebuffer support" depends on FB && ARCH_S3C2410
drivers/video/Makefile +2 -0
@@ -115,6 +115,8 @@ obj-$(CONFIG_FB_IBM_GXT4500) += gxt450 obj-$(CONFIG_FB_PS3) += ps3fb.o obj-$(CONFIG_FB_SM501) += sm501fb.o obj-$(CONFIG_FB_XILINX) += xilinxfb.o +obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o +obj-$(CONFIG_FB_SH7343VOU) += sh7343_voufb.o obj-$(CONFIG_FB_OMAP) += omap/ obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o
drivers/video/sh_mobile_lcdcfb.c new file +742 -0
742 lines not on this page · raw message
include/asm-sh/sh_mobile_lcdc.h new file +66 -0
66 lines not on this page · raw message
Quoted 16 lines · On Thu, 29 May 2008 18:24:51 +0900 Magnus Damm <[email protected]> wrote:
This patch adds frame buffer support for the LCDC block found in SuperH Mobile processors. The hardware supports up to two LCD panels per LCDC block, and both RGB and SYS interfaces can be used to hook up LCD panels/modules.
The device driver is a regular platform driver, so LCD configuration and board specific hooks are passed to the driver using platform data. LCD modules using SYS interface often require special configuration using the SYS bus, and to solve this cleanly the driver provides SYS interface operations to the board code.
Tested on sh7723 and sh7722 processors with a SYS16A QVGA panel and WVGA panels using RGB16 and RGB18 interfaces.
...
Review
Quoted 2 lines
(quoted diff) +2
-0+ while (lcdc_read(ch->lcdc, _LDSR) & 2) + ;
Indenting is odd and inconsistent with most of the other zillions of busywait loops here (multiple instances)
It might make sense to write a single function to do this busywaiting. That function can implement a timeout and can avoid lockups and provide useful diagnostics.
Is sh's cpu_relax() a no-op? Or are we assuming that ioread is a suitable substitute?
Quoted 21 lines · Andrew Morton
Quoted 16 lines · On Thu, 29 May 2008 18:24:51 +0900 Magnus Damm <[email protected]> wrote:
This patch adds frame buffer support for the LCDC block found in SuperH Mobile processors. The hardware supports up to two LCD panels per LCDC block, and both RGB and SYS interfaces can be used to hook up LCD panels/modules.
The device driver is a regular platform driver, so LCD configuration and board specific hooks are passed to the driver using platform data. LCD modules using SYS interface often require special configuration using the SYS bus, and to solve this cleanly the driver provides SYS interface operations to the board code.
Tested on sh7723 and sh7722 processors with a SYS16A QVGA panel and WVGA panels using RGB16 and RGB18 interfaces.
...
Review
Quoted 2 lines
(quoted diff) +2
-0+ while (lcdc_read(ch->lcdc, _LDSR) & 2) + ;
Quoted 6 lines
Indenting is odd and inconsistent with most of the other zillions of busywait loops here (multiple instances)
It might make sense to write a single function to do this busywaiting. That function can implement a timeout and can avoid lockups and provide useful diagnostics.
Breaking out to a single function and implementing timeout makes sense. I'll see what I can do.
Quoted 2 lines
Is sh's
cpu_relax()a no-op? Or are we assuming that ioread is a suitable substitute?
I simply forgot to use cpu_relax(). =)
I'll fix up the code and post a V2. Thank you for your review!
/ magnus
Hi Magnus,
Thank you for a new driver. I have reviewed your driver. It is quite clean. Please resolve issues below and I will ACK it.
drivers/video/sh_mobile_lcdcfb.c line 9
Quoted 12 lines · On Thu, 29 May 2008 18:24:51 +0900 Magnus Damm <[email protected]> wrote:
drivers/video/sh_mobile_lcdcfb.c new file +9
-0@@ -0,0 +1,742 @@ +/* +* SuperH Mobile LCDC Framebuffer +* +* Copyright (c) 2008 Magnus Damm +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License +*
English is not my native language but the last line sounds suspicious (either what?)
(...)
Quoted 10 lines
drivers/video/sh_mobile_lcdcfb.c new file +10
-0+ +struct sh_mobile_lcdc_priv ; +struct sh_mobile_lcdc_chan { +struct sh_mobile_lcdc_priv *lcdc; +unsigned long *reg_offs; +unsigned long ldmt1r_value; +unsigned long enabled;/* ME and SE in LDCNT2R */ +struct sh_mobile_lcdc_chan_cfg cfg; +u32 pseudo_palette[PALETTE_NR ]; +struct fb_info info;
drivers/video/sh_mobile_lcdcfb.c line 50
Quoted 10 lines
drivers/video/sh_mobile_lcdcfb.c new file +10
-0+dma_addr_t dma_handle; +}; + +struct sh_mobile_lcdc_priv { +void __iomem *base; +struct clk *clk; +unsigned long lddckr; +struct sh_mobile_lcdc_chan ch[2 ]; +}; +
You have created a circular link herelcdc_priv -> lcdc_chan -> lcdc_priv
you can easily break it by removing the lcdc
field from the lcdc_chan structure.
drivers/video/sh_mobile_lcdcfb.c line 120
Quoted 13 lines
drivers/video/sh_mobile_lcdcfb.c new file +13
-0+ +static void lcdc_write_chan (struct sh_mobile_lcdc_chan *chan, +int reg_nr,unsigned long data) +{ +iowrite32 (data, chan->lcdc->base + chan->reg_offs[reg_nr]); +} + +static unsigned long lcdc_read_chan (struct sh_mobile_lcdc_chan *chan, +int reg_nr) +{ +return ioread32 (chan->lcdc->base + chan->reg_offs[reg_nr]); +} +
put lcdc_priv and channel number (or base address and and channel pointer) as arguments to break the circular link.
You can make these functions inline as well.
drivers/video/sh_mobile_lcdcfb.c line 132
Quoted 12 lines
drivers/video/sh_mobile_lcdcfb.c new file +12
-0+static void lcdc_write (struct sh_mobile_lcdc_priv *priv, +int reg_offs,unsigned long data) +{ +iowrite32 (data, priv->base + reg_offs); +} + +static unsigned long lcdc_read (struct sh_mobile_lcdc_priv *priv, +unsigned long reg_offs) +{ +return ioread32 (priv->base + reg_offs); +} +
These two functions can be inline.
drivers/video/sh_mobile_lcdcfb.c line 141
Quoted 9 lines
drivers/video/sh_mobile_lcdcfb.c new file +9
-0+static void lcdc_sys_write_index (void *handle,unsigned long data) +{ +struct sh_mobile_lcdc_chan *ch = handle; + +lcdc_write (ch->lcdc, _LDDWD0R, data |0x10000000 ); + +while (lcdc_read (ch->lcdc, _LDSR) &2 ) + ; +
As Andrew Morton put it it would be better to putcpu_relax() inside this loop (or do some other
cpu releasing). There are more busy loops
in the driver's code.
That's it. A few things for a whole new driver.
Regards,
Krzysztof
----------------------------------------------------------------------
Tanie rozmowy!
Sprawdz >>> http://link.interia.pl/f1e13
Quoted 6 lines · Krzysztof Helt
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +3
-0@@ -0,0 +1,742 @@ +/* +* SuperH Mobile LCDC Framebuffer +*
Quoted 9 lines
drivers/video/sh_mobile_lcdcfb.c line 9
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +6
-0+* Copyright (c) 2008 Magnus Damm +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License +* English is not my native language but the last line sounds suspicious (either what?)
Yes, there's overzealous trimming here. This should be amended to refer to GPLv2 only, though as the MODULE_LICENSE() its already get this right, it's mostly a cosmetic change.
Quoted 4 lines
put
lcdc_privand channel number (or base address and and channel pointer) as arguments to break the circular link.
You can make these functions inline as well.
As the 'circular' link is being used in a pre-defined way, it's not clear that there's a problem with it existing in the first place. It's obviously a matter of convenience.
Quoted 6 lines
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +6
-0+static void lcdc_write (struct sh_mobile_lcdc_priv *priv, +int reg_offs,unsigned long data) +{ +iowrite32 (data, priv->base + reg_offs); +} +
Quoted 9 lines
drivers/video/sh_mobile_lcdcfb.c line 132
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +6
-0+static unsigned long lcdc_read (struct sh_mobile_lcdc_priv *priv, +unsigned long reg_offs) +{ +return ioread32 (priv->base + reg_offs); +} +These two functions can be inline.
The compiler will do this automatically, there's no need to mark it explicity.
Quoted 6 lines
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +6
-0+static void lcdc_sys_write_index (void *handle,unsigned long data) +{ +struct sh_mobile_lcdc_chan *ch = handle; + +lcdc_write (ch->lcdc, _LDDWD0R, data |0x10000000 ); +
Quoted 9 lines
drivers/video/sh_mobile_lcdcfb.c line 141
Quoted 3 lines
drivers/video/sh_mobile_lcdcfb.c new file +3
-0+while (lcdc_read (ch->lcdc, _LDSR) &2 ) + ; +As Andrew Morton put it it would be better to put
cpu_relax()inside this loop (or do some other
cpu releasing). There are more busy loops
in the driver's code.
cpu_relax() doesn't really matter here. It's good to include for general coherency, since we don't have the same barriers in the ioread() path, but it's hardly critical.
Quoted 16 lines · On Fri, 30 May 2008 06:07:36 +0900 Paul Mundt <[email protected]> wrote:
Quoted 6 lines · Krzysztof Helt
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +3
-0@@ -0,0 +1,742 @@ +/* +* SuperH Mobile LCDC Framebuffer +* Quoted 9 lines
drivers/video/sh_mobile_lcdcfb.c line 9
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +6
-0+* Copyright (c) 2008 Magnus Damm +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License +* English is not my native language but the last line sounds suspicious (either what?)
Quoted 4 lines
Yes, there's overzealous trimming here. This should be amended to refer to GPLv2 only, though as the
MODULE_LICENSE()its already get this right, it's mostly a cosmetic change.
I am not a lawyer and I simply afraid errors in the legal statements. I just pointed a mistake here.
Quoted 8 lines
Quoted 4 lines
put
lcdc_privand channel number (or base address and and channel pointer) as arguments to break the circular link.
You can make these functions inline as well.As the 'circular' link is being used in a pre-defined way, it's not clear that there's a problem with it existing in the first place. It's obviously a matter of convenience.
It is not that big problem so if it is required to simplify the driver it is fine. It seems it is access to only the lcdc_priv->base field is needed from the channel structure. Just take a second look at it if it can be done differently without adding to much complexity to the driver.
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +6
-0+static void lcdc_write (struct sh_mobile_lcdc_priv *priv, +int reg_offs,unsigned long data) +{ +iowrite32 (data, priv->base + reg_offs); +} +Quoted 9 lines
drivers/video/sh_mobile_lcdcfb.c line 132
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +6
-0+static unsigned long lcdc_read (struct sh_mobile_lcdc_priv *priv, +unsigned long reg_offs) +{ +return ioread32 (priv->base + reg_offs); +} +These two functions can be inline.
Quoted 3 lines
The compiler will do this automatically, there's no need to mark it explicity.
I don't know the SuperH compiler but I saw things like not inlined functions like this on PC (checked by disassembling the module object):
static void t_outb(struct tridentfb_par *p, u8 val, u16 reg)
{
fb_writeb(val, p->io_virt + reg);
}I didn't know why, so safer was just to mark it inline then
the function was inlined. That was x86 gcc 3.4.6 compiler. Before the check I believed that compiler did the right thing all the time. You can check the objdump of the compiled module.
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
drivers/video/sh_mobile_lcdcfb.c new file +6
-0+static void lcdc_sys_write_index (void *handle,unsigned long data) +{ +struct sh_mobile_lcdc_chan *ch = handle; + +lcdc_write (ch->lcdc, _LDDWD0R, data |0x10000000 ); +Quoted 9 lines
drivers/video/sh_mobile_lcdcfb.c line 141
Quoted 3 lines
drivers/video/sh_mobile_lcdcfb.c new file +3
-0+while (lcdc_read (ch->lcdc, _LDSR) &2 ) + ; +As Andrew Morton put it it would be better to put
cpu_relax()inside this loop (or do some other
cpu releasing). There are more busy loops
in the driver's code.
Quoted 4 lines
cpu_relax()doesn't really matter here. It's good to include for general coherency, since we don't have the same barriers in theioread()path, but it's hardly critical.
No, it is not critical. It is improvement.
The driver code is very clean. All above are just hints for possible improvements.
Regards,
Krzysztof
----------------------------------------------------------------------
Mucha powraca!
Sprawdz >>> http://link.interia.pl/f1e0d
Hi Krzysztof,
Quoted 8 lines · Krzysztof Helt
Hi Magnus,
Thank you for a new driver. I have reviewed your driver. It is quite clean. Please resolve issues below and I will ACK it.
On Thu, 29 May 2008 18:24:51 +0900
Magnus Damm <[email protected]> wrote:
Quoted 14 lines
drivers/video/sh_mobile_lcdcfb.c 2008-05-29 17:21:48.000000000 +0900 line 9
Quoted 12 lines
drivers/video/sh_mobile_lcdcfb.c 2008-05-29 17:21:48.000000000 +0900 new file +9
-0@@ -0,0 +1,742 @@ +/* + * SuperH Mobile LCDC Framebuffer + * + * Copyright (c) 2008 Magnus Damm + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + *English is not my native language but the last line sounds suspicious (either what?)
Yep, same here and I agree.
Quoted 5 lines
You have created a circular link here
lcdc_priv->lcdc_chan->lcdc_privyou can easily break it by removing the lcdc
field from thelcdc_chanstructure.
Sure, but the field is there for convenience.
Quoted 7 lines
Quoted 7 lines
drivers/video/sh_mobile_lcdcfb.c 2008-05-29 17:21:48.000000000 +0900 new file +7
-0+static void lcdc_write_chan(struct sh_mobile_lcdc_chan *chan, + int reg_nr, unsigned long data) +{ + iowrite32(data, chan->lcdc->base + chan->reg_offs[reg_nr]); +} + +static unsigned long lcdc_read_chan(struct sh_mobile_lcdc_chan *chan,
Quoted 8 lines
drivers/video/sh_mobile_lcdcfb.c 2008-05-29 17:21:48.000000000 +0900 line 21
Quoted 5 lines
drivers/video/sh_mobile_lcdcfb.c 2008-05-29 17:21:48.000000000 +0900 new file +5
-0+ int reg_nr) +{ + return ioread32(chan->lcdc->base + chan->reg_offs[reg_nr]); +} +put
lcdc_privand channel number (or base address and and channel pointer) as arguments to break the circular link.
That's possible, and maybe it makes sense. It didn't when I originally wrote the code - quite some time ago - abstracting the LCDs into channels and passing around a single pointer just seemed more natural to me.
I'll have a second look at the code though. Maybe it makes sense to shuffle things around a bit.
Quoted 1 line
That's it. A few things for a whole new driver.
Excellent. Thanks for your review!
/ magnus
Hi, Magnus.
Quoted 14 lines · On Thu, 29 May 2008 18:24:51 +0900 Magnus Damm <[email protected]> wrote:
This patch adds frame buffer support for the LCDC block found in SuperH Mobile processors. The hardware supports up to two LCD panels per LCDC block, and both RGB and SYS interfaces can be used to hook up LCD panels/modules.
The device driver is a regular platform driver, so LCD configuration and board specific hooks are passed to the driver using platform data. LCD modules using SYS interface often require special configuration using the SYS bus, and to solve this cleanly the driver provides SYS interface operations to the board code.
Tested on sh7723 and sh7722 processors with a SYS16A QVGA panel and WVGA panels using RGB16 and RGB18 interfaces.
Quoted 7 lines
Signed-off-by Magnus Damm <[email protected]>---
drivers/video/Kconfig | 10 drivers/video/Makefile | 2 drivers/video/sh_mobile_lcdcfb.c | 742 ++++++++++++++++++++++++++++++++++++++ include/asm-sh/sh_mobile_lcdc.h | 66 +++
This is a proposal.
I am coding sh7763's frame buffer driver.
I think that the number of FB drivers of SH will increase in the future. I think that I want to make the driver/video/sh directory, and to bring SH together in this directory for the future.
Do you think about it?
Best regards,
Nobuhiro
Signature · 1 line
Nobuhiro Iwamatsu
Hi Folks,
Quoted 22 lines · Nobuhiro Iwamatsu
Hi, Magnus.
Quoted 17 lines · On Thu, 29 May 2008 18:24:51 +0900 Magnus Damm <[email protected]> wrote:
This patch adds frame buffer support for the LCDC block found in SuperH Mobile processors. The hardware supports up to two LCD panels per LCDC block, and both RGB and SYS interfaces can be used to hook up LCD panels/modules.
The device driver is a regular platform driver, so LCD configuration and board specific hooks are passed to the driver using platform data. LCD modules using SYS interface often require special configuration using the SYS bus, and to solve this cleanly the driver provides SYS interface operations to the board code.
Tested on sh7723 and sh7722 processors with a SYS16A QVGA panel and WVGA panels using RGB16 and RGB18 interfaces.
Signed-off-by Magnus Damm <[email protected]>---
Quoted 7 lines
Quoted 4 lines
drivers/video/Kconfig | 10 drivers/video/Makefile | 2 drivers/video/sh_mobile_lcdcfb.c | 742 ++++++++++++++++++++++++++++++++++++++ include/asm-sh/sh_mobile_lcdc.h | 66 +++This is a proposal.
I am coding sh7763's frame buffer driver.
I wrote a driver for the SH7760 LCDC 2 years ago. From a quick glance at
the respective datasheets it seems both 7760 and 7763 have identical register layout. Looking at Magnus' driver, the 7722/7723 LCDC seems to be an extended version of the 7760/63 LCDC. Maybe we can unify them somehow?
Manuel Lauss
Hi Manuel,
Thanks for your email.
Quoted 21 lines · Manuel Lauss
Quoted 19 lines · Nobuhiro Iwamatsu
Quoted 16 lines · On Thu, 29 May 2008 18:24:51 +0900 Magnus Damm <[email protected]> wrote:
This patch adds frame buffer support for the LCDC block found in SuperH Mobile processors. The hardware supports up to two LCD panels per LCDC block, and both RGB and SYS interfaces can be used to hook up LCD panels/modules.
The device driver is a regular platform driver, so LCD configuration and board specific hooks are passed to the driver using platform data. LCD modules using SYS interface often require special configuration using the SYS bus, and to solve this cleanly the driver provides SYS interface operations to the board code.
Tested on sh7723 and sh7722 processors with a SYS16A QVGA panel and WVGA panels using RGB16 and RGB18 interfaces.
Signed-off-by Magnus Damm <[email protected]>---
Quoted 6 lines
Quoted 1 line
I am coding sh7763's frame buffer driver.
I wrote a driver for the SH7760 LCDC 2 years ago. From a quick glance at
the respective datasheets it seems both 7760 and 7763 have identical register layout. Looking at Magnus' driver, the 7722/7723 LCDC seems to be an extended version of the 7760/63 LCDC. Maybe we can unify them somehow?
As for the SuperH Mobile LCDC block, the sh7723 is register compatible with sh7722, but it only supports a single channel. I suspect that sh7343 is register compatible with sh7722 as well, but I have no docs. Both SYS and RGB interfaces are supported. Up to 24bpp. Both RGB and YUV pixel formats are supported by the hardware. Clock configuration and SYS bus stuff is shared between the channels.
The sh7760 LCDC supports a single channel using RGB interface up to 16bpp. No YUV. Just a handful of registers seem to have the same layout as the SuperH Mobile LCDC block.
My gut feeling is that the complexity of a driver for one type of LCDC block is enough. Think about the number of combinations of board type, processor type, LCD panel, bus type, bus configuration and potentially external LCD controller chip. And now we're talking about an extra dimension on top of that... =)
If we can unify drivers and keep the complexity relatively low then that's great, but before that can happen we sort of need something to unify. So please write simple framebuffer drivers for now, and work on getting them merged upstream. And when that's done _then_ we can unify drivers and/or break out common code. In my mind, that's the right order to do things.
/ magnus
Hi, Manuel.
Quoted 7 lines · On Fri, 30 May 2008 07:15:54 +0200 Manuel Lauss <[email protected]>…
Quoted 2 lines
This is a proposal.
I am coding sh7763's frame buffer driver.I wrote a driver for the SH7760 LCDC 2 years ago. From a quick glance at
the respective datasheets it seems both 7760 and 7763 have identical register layout. Looking at Magnus' driver, the 7722/7723 LCDC seems to be an extended version of the 7760/63 LCDC. Maybe we can unify them somehow?
Thank you for your comments.
I comment on SH7760 and SH7763 because Magnus is writing for SH7722 and SH7723.
I checked these data sheets. Most registers are the same. I think that I can merge it.
Can I check the driver of SH7760 that you wrote where?
And I need found SH7760 LCDC suport board .....
Best regards,
Nobuhiro
Signature · 1 line
Nobuhiro Iwamatsu
Hi Iwamatsu-san!
Quoted 22 lines · Nobuhiro Iwamatsu
Hi, Magnus.
Quoted 17 lines · On Thu, 29 May 2008 18:24:51 +0900 Magnus Damm <[email protected]> wrote:
This patch adds frame buffer support for the LCDC block found in SuperH Mobile processors. The hardware supports up to two LCD panels per LCDC block, and both RGB and SYS interfaces can be used to hook up LCD panels/modules.
The device driver is a regular platform driver, so LCD configuration and board specific hooks are passed to the driver using platform data. LCD modules using SYS interface often require special configuration using the SYS bus, and to solve this cleanly the driver provides SYS interface operations to the board code.
Tested on sh7723 and sh7722 processors with a SYS16A QVGA panel and WVGA panels using RGB16 and RGB18 interfaces.
Signed-off-by Magnus Damm <[email protected]>---
Quoted 7 lines
Quoted 4 lines
drivers/video/Kconfig | 10 drivers/video/Makefile | 2 drivers/video/sh_mobile_lcdcfb.c | 742 ++++++++++++++++++++++++++++++++++++++ include/asm-sh/sh_mobile_lcdc.h | 66 +++This is a proposal.
I am coding sh7763's frame buffer driver.
That's great news!
Quoted 4 lines
I think that the number of FB drivers of SH will increase in the future. I think that I want to make the driver/video/sh directory, and to bring SH together in this directory for the future.
Do you think about it?
I think grouping drivers together by architecture is a good suggestion, but I personally prefer a step by step approach. So I think we should deal with it later when we actually have more drivers upstream.
I'm aiming for having this driver included in 2.6.27. Your driver is targeted for some release later on, right?
Thanks!
/ magnus
Hi, Magnus.
Quoted 5 lines · On Fri, 30 May 2008 14:24:26 +0900 "Magnus Damm" <[email protected]> wrote:
I think grouping drivers together by architecture is a good suggestion, but I personally prefer a step by step approach. So I think we should deal with it later when we actually have more drivers upstream.
OK.
I also have the driver first released.
Quoted 2 lines
I'm aiming for having this driver included in 2.6.27. Your driver is targeted for some release later on, right?
I also am working aiming at 2.6.27.
Best regards,
Nobuhiro
Signature · 1 line
Nobuhiro Iwamatsu