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

[Michal Simek <monstr@monstr.eu>]

On 08. 02. 19 12:14, Michal Simek wrote:
> On 08. 02. 19 10:57, Heiko Schocher wrote:
>> Hello Michael,
>>
>> Am 31.01.2019 um 16:30 schrieb Michal Simek:
>>> 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
>>>
>>> Michal Simek (7):
>>>    dm: core: Add of_alias_get_highest_id()
>>>    fdt: Introduce fdtdec_get_alias_highest_id()
>>>    dm: core: Introduce dev_read_alias_highest_id()
>>>    dm: core: Add tests for dev_read_alias_highest_id()
>>>    i2c: dm: Record maximum id of devices before probing devices
>>>    i2c: Fill req_seq in i2c_post_bind()
>>>    i2c: mux: Generate longer i2c mux name
>>>
>>>   drivers/core/of_access.c           | 18 ++++++++++++++
>>>   drivers/core/read.c                |  8 ++++++
>>>   drivers/i2c/i2c-uclass.c           | 50
>>> +++++++++++++++++++++++++++++++++++---
>>>   drivers/i2c/muxes/i2c-mux-uclass.c | 29 +++++++++++++++++++---
>>>   include/dm/of_access.h             | 10 ++++++++
>>>   include/dm/read.h                  | 16 ++++++++++++
>>>   include/fdtdec.h                   | 13 ++++++++++
>>>   lib/fdtdec.c                       | 33 +++++++++++++++++++++++++
>>>   test/dm/test-fdt.c                 | 23 ++++++++++++++++++
>>>   9 files changed, 194 insertions(+), 6 deletions(-)
>>>
>>
>> I just applied your patches and triggered a build on travis:
>>
>> It shows error for omap boards:
>>
>> https://travis-ci.org/hsdenx/u-boot-i2c/jobs/490393822
>>
>> I try to find time to look into it, but may you have time too?
>>
> 
> This should be the fix.  (I tried that on omap35_logic_somlv_defconfig)
> 
> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
> index 6f3fca2d2326..391fb1289983 100644
> --- a/drivers/i2c/i2c-uclass.c
> +++ b/drivers/i2c/i2c-uclass.c
> @@ -655,8 +655,12 @@ int i2c_uclass_init(struct uclass *class)
>         if (!priv)
>                 return -ENOMEM;
> 
> +#if CONFIG_IS_ENABLED(OF_CONTROL)
>         /* Get the last allocated alias. */
>         priv->max_id = dev_read_alias_highest_id("i2c");
> +#else
> +       priv->max_id = -1;
> +#endif
> 
>         debug("%s: highest alias id is %d\n", __func__, priv->max_id);
> 
> 
> SPL has no OF_CONTROL and also no LIBFDT that's why it is trying to call
> it.

:-) that sentence doesn't make sense. Correction:
...that's why it shouldn't be called.

Maybe it should be enough to have dependency on OF_LIBFDT but Kconfig is
saying that OF_LIBFDT is bool setup to y when OF_CONTROL is enabled.
And in Makefile fdtdec is enabled

obj-$(CONFIG_$(SPL_TPL_)OF_CONTROL) += fdtdec.o
or just
obj-$(CONFIG_OF_LIBFDT) += fdtdec.o

Anyway it should be likely enough to have dependency just on OF_LIBFDT.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190208/5933a337/attachment.sig>