new kernel ... / meaning of stable-tracking
werner at openmoko.org
Fri Sep 26 08:25:57 CEST 2008
Sorry for the delay. I had network problems for the last few days.
Seems that my ISP's having a really bad year :-(
Balaji Rao wrote:
> What are the other parts that we need to seperate out ?
The more, the better :-) There is actually very little in this device
that is shared - only I2C communication, interrupts, and global state.
The worst that could happen if you're too enthustiastic about
separating subsystems is that you might realize that some subsystems
are too tightly connected for separation. That in turn may reveal
unnecessary connections (I've listed a few below), so it's a good
way to spot potential problems.
> Do we need to
> provide sysfs interfaces for , say led control and charger ?
If you mean to use the device class APIs which in turn provide the
sysfs interfaces, then yes.
You'll notice that we have a few ugly spots in the driver, where it
makes assumptions about how the chip is used, e.g.,
- that the LED driver drives a backlight (with a lot of suspend/resume
- that ADCIN1 is connected to USB ID pin
- that we can also output USB power
- generate various responses depending on how long the power button
The backlight handling is a bit of a trouble spot, because user space
and kernel sometimes have divergent ideas about what the state should
be. At least moving all the backlight code into a separate file would
help to make it clearer, and maybe we can pare it down later.
ADC access is currently messy. I think it would be a lot clearer if
each request included a callback function. E.g., charger detection
could then live somewhere in platform-specific code and use the ADC
without the PMU driver having to know anything else about it.
Also interpret_charger_type_from_adc would be in the platform-specific
code. configure_pmu_for_charger should go into platform-specific code
as well - it gets the modes right, but has way too much platform
knowledge about the 1A charger.
I wouldn't mind seeing the fancy POWER/ONKEY button handling go
entirely. A question for our user space folks: do you really need
that, or could a little daemon or library do the job as well ?
These are quite drastic changes. The PCF50633 driver has grown into
being the "GTA02 schematics sheet 3" driver over time, so there's now
quite a bit to untangle.
Since this will affect various interfaces visible to user space,
please make sure to document when sysfs files change name, when their
semantics change, etc., so that our user space developers have plenty
of time to prepare for a smooth migration.
More information about the openmoko-kernel