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

On Feb 20, 2008 12:01 PM, Paul Sokolovsky <pmiscml_at_gmail.com> wrote:
> Hello,
>
>
> On Wed, 20 Feb 2008 09:50:26 +0100
> "pHilipp Zabel" <philipp.zabel_at_gmail.com> wrote:
>
> > 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?!).
>
> Since I sent mail, I thought just about the same - serial hooks are not
> in mainline, so that's very good argument for going "extra device" route.
> It can exactly abstract away PM, so it can:
> 1. Install these serial hooks.
> 2. Or add entries to /sys like one hacky patch for h1940 which I saw on
> LAKML
> 3. Or whatever
>
> Another argument is that we already have rs232_serial written in the
> same vein, to control rs232 transceiver on a serial port.
>
> > 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.
>
> It's so convenient to not patch userspace with all that
> machine-specific ways to control power otherwise!

Yes, and that.

> Well, it's relative
> of course - we already have blueprobe, it looks for ports/protocols, so
> could look for power switches too. But blueprobe itself a hack - what
> about pluggable cards? So, it should be replaced with udev-based stuff.
> And to have any sanity with PM-from-userspace approach, we'd need to
> introduce BT classdev, so we at least know where to look for power
> controls without maintaining awful list of device-specificity.

The most common cases here seem to be GPS, BT and GSM chips, currently.

> Oh, and those pluggable cards - they wouldn't have external power
> controls, right? ;-) They would work on just port open, expectably
> making PM internally, right? So, we just emulate that approach with
> internal devices, and find it very elegant actually, not wrong or a
> hack.

But don't those just have the power management on another level (USB,
PCMCIA) and are to be considered always-on otherwise?

> But I understand that mainline will be making faces on trying to
> merge that.

Hm. Did anybody actually try?

> > 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.
>
> I already guessed ;-). In what way it will fail? With playing
> siren? ;-) Is there return code to distinguish it? Is there call to
> check if gpio is owned? I guess request_gpio() could be bent for that
> purpose, but that would be indeed bending and dirty hack.

The gpio_desc will not be marked as requested and gpio_request will
return -EINVAL instead of 0. If the gpio is already requested by
something else, -EBUSY is returned.

regards
Philipp
Received on Wed Feb 20 2008 - 08:09:27 EST