Re: h5000 - some help needed with LCD and BL merge to main file.

On Feb 20, 2008 12:45 AM, Paul Sokolovsky <pmiscml_at_gmail.com> wrote:
> Hello,
>
>
> On Wed, 20 Feb 2008 00:53:40 +0200
> Paul Sokolovsky <pmiscml_at_gmail.com> wrote:
>
> > Hello,
> >
> > On Tue, 19 Feb 2008 00:33:45 +0100
> > "Michal Panczyk" <mpanczyk_at_gmail.com> wrote:
> >
> > > Hello all...
> > >
> > > I am working on merging LCD and backlight functions to h5400.c file.
> > > The code so far existed in h5400_lcd.c and h5400_bl.c and worked
> > > like charm.... I am not experienced kernel developer and I have some
> > > problems with this task...
> > > After some chats on IRC with Milan Plizk we decided that BL depends
> > > on LCD code, so LCD has to be initized first. Also because of this
> > > LCD and BL are treated as one issue. Most of the code is just
> > > copy&paste (for now...) - as I don't want to mess it up, before I
> > > am sure is is working.
> > > LCD is initized by the h5400_init function, after the samcop
> > > intization. This calls for other function of LCD
> > > code getting to the h5400_mq_set_power where it gets stuck at
> > > samcop_set_gpio_b. As far as I get the error it has empty (NULL)
> > > &h5400_samcop.dev. At least this is how I understand it. Could
> > > somebody point me to the direction of correcting this problem ? Why
> > > does it work outside h5000.c and not as build in ?
> >
> > Yes, this is very well by now case of device initialization order. We
> > also discussed and agreed on consistent pattern to resolve such
> > issues: if a device A uses resources (e.g. GPIOs) of device B, then A
> > should be made a child device of B.
>
> Or maybe no. Alas, it's not that easy. For example, h5000 BT merge-id=n
> just violated that ;-\. That's why Anton moved it to separate file - to
> comply with the convention we set, per above. ;-I
>
> Well, nothing's easy. Philipp, Anton, are you there? What should we do
> about all this? Scheme above is of course the right way, but it
> requires complete adherence to that idea. So, BT methods should not be
> attached directly to UART devices, but instead there should be separate
> BT device and on/off methods attached to. And there should be generic
> (on PXA level) driver for that device.

Yes, no, maybe :/
I think the pxa_serial_funcs are a hack and semantically wrong (device
power management via tty open/close?!).
On the other hand it is so very much convenient to have the device
shut down automatically when the corresponding daemon dies for
whatever reason. But maybe we should really split the two and use a
watchdog to power off devices when their users go away unexpectedly
(or save_debugging_info; cat warning_screen > /dev/fb0; aplay
dissonant_siren.wav; reboot)

> Or, boring "check it for NULL on every breath" alternative... Philipp,
> what's the behavior of gpiolib recently merged to mainline in case
> gpio request is made against not yet registered gpio_chip? Is there a
> way to check beforehand if a given gpio would be serviced?

If there is no gpio chip serving a given gpio, the request will fail.

regards
Philipp
Received on Wed Feb 20 2008 - 09:15:50 EST