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.si...@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@ff020000 >>>> 20: gpio@20, offset len 1, flags 0 >>>> 21: gpio@21, offset len 1, flags 0 >>>> 75: i2c-mux@75, offset len 1, flags 0 >>>> Bus 1: i2c@ff020000->i2c-mux@75->i2c@0 >>>> Bus 2: i2c@ff020000->i2c-mux@75->i2c@1 >>>> Bus 3: i2c@ff020000->i2c-mux@75->i2c@2 >>>> Bus 4: i2c@ff030000 (active 4) >>>> 74: i2c-mux@74, offset len 1, flags 0 >>>> 75: i2c-mux@75, offset len 1, flags 0 >>>> Bus 5: i2c@ff030000->i2c-mux@74->i2c@0 (active 5) >>>> 54: eeprom@54, offset len 1, flags 0 >>>> Bus 6: i2c@ff030000->i2c-mux@74->i2c@1 >>>> Bus 7: i2c@ff030000->i2c-mux@74->i2c@2 >>>> Bus 8: i2c@ff030000->i2c-mux@74->i2c@3 >>>> Bus 9: i2c@ff030000->i2c-mux@74->i2c@4 >>>> Bus 10: i2c@ff030000->i2c-mux@75->i2c@0 >>>> Bus 11: i2c@ff030000->i2c-mux@75->i2c@1 >>>> Bus 12: i2c@ff030000->i2c-mux@75->i2c@2 >>>> Bus 13: i2c@ff030000->i2c-mux@75->i2c@3 >>>> Bus 14: i2c@ff030000->i2c-mux@75->i2c@4 >>>> Bus 15: i2c@ff030000->i2c-mux@75->i2c@5 >>>> Bus 16: i2c@ff030000->i2c-mux@75->i2c@6 >>>> Bus 17: i2c@ff030000->i2c-mux@75->i2c@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
