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?
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.
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
