new kernel ... / meaning of stable-tracking
andy at openmoko.com
Mon Sep 22 20:29:59 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
|> What I think I would suggest is to go through the steps we talked about
|> already to form a clean add-pcf50633-support-to-mainline.patch, and then
|> approach upstream with it explaining the situation as an RFC about what
|> absolutely has to be changed. Maybe they have mercy about regulator API
|> because we are nice guys, we dunno. Then discuss the results of it on
|> this list and we figure out what to do.
| Hmmmm.. I feel that it's better to fix the driver to use the new
| API to increase the possibility of upstream acceptance. I think I'll
| if it wouldn't involve too much work. or would it ?
| What else do we need to change if we need to make it "new" ?
Mark Brown's mfd idea sounds right too. Have a look in ./drivers/mfd,
you can see the various units of "multi function devices" are broken out
there because they don't really belong properly in any other category.
At the moment pcf50633 is stuck in i2c category but really that is not
the defining characteristic of the device, it works even without an i2c
connection if you like.
I worry we are making this path so abstract for you, but actually, this
is good for us. We will be relying on pcf50633 on GTA03 and let's face
it the driver should be better for all this. One thing though if I were
you I would resist suggestion to do pcf50606 at the same time. This was
the PMU on GTA01, it's the same amount of work again but we don't plan
to use that chip again. So I would "leave it for later".
The one advantage you got is that existing pcf50633 is basically
working, it means you can test change by change.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel