[PATCH 2/2] ARM i.MX23/28: Add framebuffer device support

Shawn Guo shawn.guo at freescale.com
Tue Feb 22 22:28:57 EST 2011


Hi Sascha,

On Mon, Feb 21, 2011 at 03:18:42PM +0100, Sascha Hauer wrote:
> On Fri, Feb 18, 2011 at 05:36:23PM +0800, Shawn Guo wrote:
> > On Fri, Feb 18, 2011 at 10:26:50AM +0100, Sascha Hauer wrote:
> > > On Fri, Feb 18, 2011 at 05:17:18PM +0800, Shawn Guo wrote:
> > > > > > I understand that "mxsfb" was picked up for the device name to
> > > > > > reflect the driver name.  But since this is the device under mach- mxs
> > > > > > folder, can we simply call it "fb" just like the way you name fb.h?
> > > > > > 
> > > > > > In this way, we have all mxs platform device naming schema aligned,
> > > > > > auart, duart, dma, fb, fec, flexcan, mmc ...
> > > > > 
> > > > > I see it the other way round. mach/fb.h is too generic, I would prefer
> > > > > mach/mxsfb.h to be able to add support for a different framebuffer
> > > > > later. So I better change fb.h to mxsfb.h.
> > > > > 
> > > > I'm fine with either way, but just wondering what kind of fb later
> > > > it is and its naming, relatively to mxsfs.
> > > 
> > > IPU...?
> > > 
> > AFAICT, this is something that never going to happen.
> 
> Just the first thing that came to my mind. It could also be the lcd
> controller known from i.MX1/2
> 
What about only having one pair fb.h/platform-fb.c to accommodate all
possible framebuffer driver stuff there with appropriate name-space 
added for definitions inside the files?  Less files, and some common
definitions and functions can be consolidated inside the file.

-- 
Regards,
Shawn




More information about the linux-arm-kernel mailing list