QVGA for Neo

andrzej zaborowski balrogg at gmail.com
Fri Sep 28 13:30:35 CEST 2007

On 28/09/2007, john cass <johnpcass at yahoo.com> wrote:
> >>2) What's the best way to send a command from the framebuffer driver to
> the LCM
> >>    (spi) module - so that we can have a full change of mode using e.g.
> fbset?
> >>    The way the code is currently structured, a call to the mode change
> function
> >>    in the LCM module needs a data structure which the framebuffer doesnt
> know
> >>    about. (e.g. should we store a reference to the jbt_info structure
> >>    statically in jbt6k74.c so that external callers dont need to specify
> it?
> >>    or should we try to arrange a call through the sysfs user interface?)
> > I think the jbt6k74 should export these properties through sysfs as it
> > is a separate device from the LCDC.
> Andrej - jbt6k74 does already export these to sysfs.  The question is
> whether that
> is the best way for the kernel to access its functions internally :
> (How) can one access the sysfs from within the kernel?  Is there a kernel
> interface?
> Do we have to pass a message out to a user application which can access
> sysfs?
> This last sounds like a nasty way of doing things..
> It would be easy (and reasonable for the gta01) to assume there is only one
> jbt6k74
> device and keep a data structure statically in jbt6k74.c.  This would allow
> jbt6k74.c
> to EXPORT a kernel function for changing mode which would be fast and easy.

I don't know, I think the userspace should take care to poke both
drivers separately (maybe in the neod or somewhere), linux is about
choices. If you want to automate that then I think "notifier chains"
are the way to go (see include/linux/notifier.h), or add a resolution
change callback in struct s3c2410fb_mach_info. But yes, you can access
sysfs from within the kernel too (I think
had an example of this but I can't open it now).

More information about the neo1973-hardware mailing list