[U-Boot] [PATCH 2/6] power: Explicitly select pmic device's bus

[Heiko Schocher <hs@denx.de>]

Hello Lukasz,

Am 04.10.2013 10:58, schrieb Lukasz Majewski:
> Hi Heiko,
>
>> Hello Lukasz,
>>
>> Am 03.10.2013 18:15, schrieb Lukasz Majewski:
>>> Hi Heiko,
>>>
>>> Sorry for a late reply.
>>>
>>>> Hello Lukasz,
>>>>
>>>> Am 02.10.2013 17:11, schrieb Lukasz Majewski:
>>>>> Hi Leela,
[...]
>>>> but exactly I want to get rid of this code as it is in
>>>> pmic_select() someday, when all i2c drivers converted to the new
>>>> i2c framework.
>>>
>>> My 2 cents. I understand that pmic_select() preserves old i2c bus
>>> number, when PMIC performs transmission. This is probably done to
>>> not break the legacy code (where one driver assumed, that it is
>>> alone).
>>>
>>> If this is necessary, then I'm OK with this. However I personally
>>> think, that drivers shall call API functions from i2c core (like
>>> i2c_bus_num()) only with bus number to switch and do not store and
>>> preserve the i2c value. This is my personal comment.
>>
>> Full Ack. I am just thinking, that we can get rid of such constructs,
>> independent of the new i2c framework switch. We just need to introduce
>> a "current_i2c_cmd_bus" in common/cmd_i2c.c. This var stores the
>> current i2c bus where i2c commands are executed ...
>
> I think that "last used bus" variable shall be stored/managed at
> i2c_core.c. I can use i2c without cmd_i2c.c compiled (as it is with

Thats the case for the new framework! It stores the current bus, and
so i2c_set_bus_num() can decide, if it is necessary to switch to
a new bus ...

Additionally to get rid of such "store oldbus, switch to new, restore
old bus" constructs, the i2c commands needs to store somewhere, which
i2c bus the i2c commands currently use, because you can do a "i2c md ..."
then a "date" (maybe on antoher i2c bus) and then again a "i2c md ..."
I think, thats the real historical reason for doing all over the code
such "save oldbus" code ...

That var (saying i2c_cur_cmd_bus) can easily stored in common/cmd_i2c.c,
as commands are only useable after relocation. So, we must just add a
i2c_set_bus_num(i2c_cur_cmd_bus) call before a command is executed ...
That can be done in common/cmd_i2c.c also ...

So, in the end, before every i2c access we call i2c_set_bus_num()
and have no longer to store an "old bus" ... and if we have reached
this point, we can make i2c_set_bus_num() static, and add to the
i2c api a new first "int bus" parameter .... and can delete all
i2c_set_bus_num() calls ... so every i2c device must know, on which
i2c bus it works ... and as a bonus, we can get rid of all i2c_init()
calls all over around the code, as i2c_set_bus_num() checks, if the
drivers is initialized or not, if not initialize it, look if i2c
muxes are involved on this bus, and so on ...

> pmic and fuel gauge, which use different buses).

Yep, and its enough to call i2c_set_bus_num() before you want to access
a device ... i2c_set_bus_num() do all necessary steps for you.

>> and all other
>> subsystems, which use the i2c_api can call i2c_set_bus_num() without
>> a previous "save old bus" and after the i2c bus usage a "restore i2c
>> bus" ...
>
>
>> I try to look into this, maybe we can do this before all
>> i2c drivers are ported to the new framework ...
>
> Ok, lets wait for a patch.

I have such a patch in my queue, but it works only for drivers, which use
the new framework I think ... so I must think about it, if this works
for old style drivers too ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany