Hi Przemyslaw,
On 20 May 2014 03:16, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 05/19/2014 08:37 PM, Simon Glass wrote:
Hi,
On 9 May 2014 03:25, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello,
Some time ago I had a pleasure to work on some kind of a simple charger manager for u-boot. For checking battery charge level, cable state, and some more info I made a common calls which were implemented in board files, so actually it didn't base directly on PMIC framework. This allowed making charger abstraction but it was a second power related framework next to the PMIC. From my side I would like to introduce its next version according to the doc/README.power-framework documents "TO DO" list and some more...
In this RFC any comments about next version of power management framework are welcome. What new PMIC framework should provide? How to extend it? What can be fixed?
So, what should be done (in my opinion):
Can I suggest we try to build this with driver model if possible? It seems like you will otherwise end up duplicating much of the plumbing of that. For example, see 'struct device'.
Regards, Simon
Yes, I also would like to take it into account - but I am not sure that driver model is not too redundant for it? If I well understand the current driver model - each driver can have only one uclass, right? If yes, then for each previous listed ops we need to register separate driver - isn't it too much for read one register or turn on the led in the same physically device?
So maybe better is to register one "power" driver in driver model? And the power uclass driver could init more then one class specific ops.
I just would like to keep it simply.
Well the intent is for all drivers to fit within the driver model framework somehow. To answer your questions:
Each device can only have one uclass, but it is possible to create multiple child devices associated with a driver, and each of those can be associated with a different uclass. For example a PMIC chip might have a GPIO driver, a battery driver and a regulator driver. You can have a top-level mfd device perhaps, which provides access to the rest. Note there is no mfd uclass as yet, but it would be pretty easy to add something that supports basic enumeration of its children. This is how it works in linux and that model works well enough in practice.
On the other hand it doesn't make sense to conflate one function with another. Clearly the interface you need to access GPIOs is quite different from that used for setting up power supply voltages. It actually makes more sense to split up these functions into separate devices than to try to invent a new semi-merged API for this strange new franken-device.
Also, I'm not sure what the top level 'power' device would actually do? Wouldn't you need to grub around inside it and find out its capabilities (regulators, GPIO, ADC, etc.)? If so, that grubbing-around layer might as well just be driver model IMO.
A bigger challenge is that almost no drivers support driver model yet, so definitely there will be a bit of trail-blazing. I'm in there looking at GPIOs at the moment so can help if questions come up.
Regards, Simon