Hi Michal, On Tue, 5 Feb 2019 at 00:58, Michal Simek <michal.si...@xilinx.com> wrote: > > 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. > > > 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.
Yes that function seems useful to me. > 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. Well maybe, but of course the problem you are fixing applies to other subsystems too, doesn't it? > > 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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
