[U-Boot] [RFC] POWER framework v3 - wish list

[Simon Glass]

Hi Przemyslaw,

On 20 May 2014 03:16, Przemyslaw Marczak <p.marczak at 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 at 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