[U-Boot] [PATCH v2 0/7] Align U-Boot I2C DM bus ID handling with Linux

[Michal Simek]

On 05. 02. 19 9:20, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 05.02.2019 um 08:57 schrieb Michal Simek:
>> Hi Simon,
>>
>> On 02. 02. 19 15:10, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Thu, 31 Jan 2019 at 08:31, Michal Simek <michal.simek at xilinx.com>
>>> wrote:
>>>>
>>>> U-Boot with I2C_DM enabled is not capable to list i2c busses connected
>>>> to i2c mux. For getting this work there is a need to find out highest
>>>> alias ID and use this uniq number for new buses connected to I2C mux.
>>>> This series is making this happen.
>>>>
>>>> There is only one missing piece which is that also i2c controllers
>>>> which
>>>> are not listed in DT are not using this feature.
>>>>
>>>> Removing setting up aliases from i2c mux code and unifying it in the
>>>> same code ensures that numbering schema is proper if no alias is
>>>> specified.
>>>>
>>>> ZynqMP> i2c bus
>>>> Bus 0:  i2c at ff020000
>>>>     20: gpio at 20, offset len 1, flags 0
>>>>     21: gpio at 21, offset len 1, flags 0
>>>>     75: i2c-mux at 75, offset len 1, flags 0
>>>> Bus 1:  i2c at ff020000->i2c-mux at 75->i2c at 0
>>>> Bus 2:  i2c at ff020000->i2c-mux at 75->i2c at 1
>>>> Bus 3:  i2c at ff020000->i2c-mux at 75->i2c at 2
>>>> Bus 4:  i2c at ff030000  (active 4)
>>>>     74: i2c-mux at 74, offset len 1, flags 0
>>>>     75: i2c-mux at 75, offset len 1, flags 0
>>>> Bus 5:  i2c at ff030000->i2c-mux at 74->i2c at 0  (active 5)
>>>>     54: eeprom at 54, offset len 1, flags 0
>>>> Bus 6:  i2c at ff030000->i2c-mux at 74->i2c at 1
>>>> Bus 7:  i2c at ff030000->i2c-mux at 74->i2c at 2
>>>> Bus 8:  i2c at ff030000->i2c-mux at 74->i2c at 3
>>>> Bus 9:  i2c at ff030000->i2c-mux at 74->i2c at 4
>>>> Bus 10: i2c at ff030000->i2c-mux at 75->i2c at 0
>>>> Bus 11: i2c at ff030000->i2c-mux at 75->i2c at 1
>>>> Bus 12: i2c at ff030000->i2c-mux at 75->i2c at 2
>>>> Bus 13: i2c at ff030000->i2c-mux at 75->i2c at 3
>>>> Bus 14: i2c at ff030000->i2c-mux at 75->i2c at 4
>>>> Bus 15: i2c at ff030000->i2c-mux at 75->i2c at 5
>>>> Bus 16: i2c at ff030000->i2c-mux at 75->i2c at 6
>>>> Bus 17: i2c at ff030000->i2c-mux at 75->i2c at 7
>>>>
>>>> Thanks,
>>>> Michal
>>>>
>>>> Changes in v2:
>>>> - Update kernel-doc binding
>>>> - Return -1 in case of error. -1 means that the next free alias is 0.
>>>> - New patch
>>>> - New patch
>>>> - Use dev_read_alias_highest_id()
>>>> - Use uclass private data
>>>> - Use private uclass data
>>>> - Fix headers
>>>> - Change patch description to focus only on bus name
>>>
>>> I don't have strong objections to this series, but I'd still like to
>>> try a bit harder on the existing req_seq/seq stuff.
>>>
>>> I don't think we necessarily need to set the 'seq' before probe,
>>> although I suppose we could.
>>>
>>> But is there anything to stop us moving some of the logic which sets
>>> seq to setting req_seq? We could check the aliases and then set
>>> req_seq during bind(), perhaps?
>>
>> Let me put this to my TODO list. But it is not a task which you know
>> will be done in some hours. It requires to study the whole logic if this
>> works for all cases.
> 
> For me it is okay to do this in a second step.
> 
> @Simon: Can you give the patcheseries a formal Reviewed-by?

Thanks for this I wanted Simon to ask about it too.

>>> This would be better for code size since it would help all subsystems.
>>
>> This approach is used in the linux kernel that's why there is no way to
>> get rid of dev_read_alias_highest_id() as function.
>> It means only i2c_uclass_init() and little code in i2c_post_bind() could
>> be removed. That's why I don't think we will improve size a lot.
>> If this is copied to other subsystems then yes it will be more useful.
>> If we have just one now we can't save a lot.
>>
>> Heiko: Can you please take a look at this series? I have another 7
>> patches on the top of this series which depends on it which cleanup all
>> zynq/zynqmp platforms and I would like to close this to be able to move.
> 
> ASAP as I was ill the last 2 weeks ... sorry, give me some time.

Sure.

Thanks,
Michal