[U-Boot] [PATCH v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform

[Hans de Goede]

Hi,

On 07-04-15 09:51, Paul Kocialkowski wrote:
> Le dimanche 05 avril 2015 à 22:59 +0200, Paul Kocialkowski a écrit :
>> Hi Hans,
>>
>> Le dimanche 05 avril 2015 à 10:44 +0200, Hans de Goede a écrit :
>>> Hi,
>
> [snip]
>
>>> Thanks for your work on this, may I request one more change ? For sunxi I would
>>> like to also see a CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / sun8i
>>> we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic there.
>>>
>>> This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp.
>>> PH2/3 (sun8i) which may be used in some other fashion.
>>>
>>> This also means making a small change to the first patch to also make registering
>>> of twsi0 #ifdef CONFIG_I2C_MVTWSI_BASE0 .
>>>
>>> Can you please make the default for CONFIG_I2C0_ENABLE y on sun4i / sun5i / sun7i and n
>>> on others?
>>
>> Ack that, it makes sense to me.
>
> Implementing this leads to build errors:
> drivers/i2c/mvtwsi.c:319:13: attention : ‘twsi_i2c_init’ defined but not
> used [-Wunused-function]
> drivers/i2c/mvtwsi.c:362:12: attention : ‘twsi_i2c_probe’ defined but
> not used [-Wunused-function]
> drivers/i2c/mvtwsi.c:388:12: attention : ‘twsi_i2c_read’ defined but not
> used [-Wunused-function]
> drivers/i2c/mvtwsi.c:424:12: attention : ‘twsi_i2c_write’ defined but
> not used [-Wunused-function]
>
> Ways to get rid of those include:
> * not building the driver at all when no controller 0 base is defined,
> which involves moving moving SYS_I2C_MVTWSI to Kconfig and selecting it
> when at least one i2c controller is selected in the sunxi Kconfig
> * having twsi0 enabled on all sunxi devices, as it was before
>
> What do you prefer?

I would prefer for the driver to not be build at all then, thank you for
working on this.

Regards,

Hans


>
>>> Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex boards
>>> which have a i2c eeprom enabling the attached i2c controller makes sense, but on the
>>> other boards the i2c pins are really just gpio pins, any daughter board can be connected
>>> including one which uses them differently. I believe that in the defconfig the i2c
>>> controllers should thus be left off. It is after all a default config, users with
>>> a daughter board which they want to use in u-boot can easily change the config after
>>> running make foo_defconfig.
>>
>> I think the right bargain here would be to enable i2c lines that already
>> have something useful for U-Boot attached (e.g. not an accelerometer
>> sensor). I concur to your point otherwise.