My Zaurus SL-C3200 PDA needs a driver that needs to call another driver
from another part of the device tree:
MAX1111 (4 channel A/D) is connected to several other pieces of hardware
(audio player remote keyboard, battery voltage, battery temperature,
external power voltage).
Battery power and charging management needs to read values from MAX1111
during. Also Remote Keyboard input device needs to read MAX1111.
But both drivers also need dedicated GPIO that are allocated on Scoop
chip (different part of the platform device tree).
What is the best way to implement it?
Now it is implemented by a hardcoded static reference. This does not
work well and breaks on suspend. MAX1111 goes to sleep first and attempt
to set-up offline charging fails (see below).
I need to make sure, that MAX1111 is going to suspend after the
battery management and after the audio remote driver (not yet in
vanilla) and resumes before them.
What is the best way to implement it?
Well, in fact, the problem is even worse: Spitz has a dumb charging
management. CPU has to wake-up each few minutes, check the battery,
adjust charging parameters and continue in sleeping.
That is why I either need to disable sleeping of SPI and MAX1111 or
temporarily wake up SPI and MAX111 without going to resume completely.
Is something like this possible?
It was working in past (linux-2.6.26) - MAX1111+SPI driver was hardcoded
into power management and when SPI was probably never suspended. Now it
obviously cannot work.
Thanks.
PM: suspend of devices complete after 549.298 msecs
PM: late suspend of devices complete after 0.359 msecs
max1111 spi2.2: spi_sync failed with -108
max1111 spi2.2: spi_sync failed with -108
max1111 spi2.2: spi_sync failed with -108
max1111 spi2.2: spi_sync failed with -108
max1111 spi2.2: spi_sync failed with -108
sharpsl-pm sharpsl-pm: Error: AC check failed: voltage -108.
sharpsl-pm sharpsl-pm: Offline Charger: Error occurred.
sharpsl-pm sharpsl-pm: Charging Error!
PM: early resume of devices complete after 0.255 msecs
________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx
Stanislav> My Zaurus SL-C3200 PDA needs a driver that needs to call
Stanislav> another driver from another part of the device tree:
Stanislav> MAX1111 (4 channel A/D) is connected to several other
Stanislav> pieces of hardware (audio player remote keyboard, battery
Stanislav> voltage, battery temperature, external power voltage).
Stanislav> Battery power and charging management needs to read values
Stanislav> from MAX1111 during. Also Remote Keyboard input device
Stanislav> needs to read MAX1111.
Stanislav> But both drivers also need dedicated GPIO that are
Stanislav> allocated on Scoop chip (different part of the platform
Stanislav> device tree).
Stanislav> What is the best way to implement it?
By no means am I a driver expert or writer, but from what I recall in
the past when such questions came up is for you to write a low level
core driver, which binds to the device, and then exposes that various
interfaces you want to bind to for other devices to talk to.
This gets the ref counting right, and lets you know when something is
accessing the MAX1111, so that suspend and such happen in the correct
order.
Look through the lkml archives for previous answers. I'm sure Greg
will have a better answer and a pointer to an example driver to look
at.
Cheers,
John
Hi,
dito here: I've got a nice ELV USB2I2C adapter which has a cp210x USB2serial
chip (i.e., drivers/usb/serial/cp210x.c) and is a definite I2C stack
driver candidate (i.e., drivers/i2c/xxx).
So???
Although I suspect that our two cases might be unrelated since yours
seems like lots of platform data magic and mine might perhaps be
solvable via some tty layer magic.
Sorry for the disruption ;)
Andreas Mohr
Stanislav Brabec <utx <at> penguin.cz> writes:
>
> My Zaurus SL-C3200 PDA needs a driver that needs to call another driver
> from another part of the device tree:
>
> MAX1111 (4 channel A/D) is connected to several other pieces of hardware
> (audio player remote keyboard, battery voltage, battery temperature,
> external power voltage).
>
> Battery power and charging management needs to read values from MAX1111
> during. Also Remote Keyboard input device needs to read MAX1111.
>
> But both drivers also need dedicated GPIO that are allocated on Scoop
> chip (different part of the platform device tree).
>
GPIO already has a generic API that can be used. I've had similar problems with
I2C devices. I've always implemented as adding in .command support to the I2C
driver in question, using i2c_use_client and then try_module_get. I'm not sure
if it is the proper way of doing things, it's always bugged me that there
doesn't seem to programatically access things like I2C eeproms and HW monitoring
devices. They seem to only be exposed though sysfs.