[U-Boot] [PATCH] arm: mvebu: move i2c slave disable to generic SPL code

[Stefan Roese]

On 28.05.2018 12:29, Baruch Siach wrote:
> Hi Stefan,
> 
> On Mon, May 28, 2018 at 12:24:37PM +0200, Stefan Roese wrote:
>> On 28.05.2018 12:08, Baruch Siach wrote:
>>> On Mon, May 28, 2018 at 12:05:43PM +0200, Stefan Roese wrote:
>>>> On 28.05.2018 11:56, Baruch Siach wrote:
>>>>> On Mon, May 28, 2018 at 10:20:01AM +0200, Stefan Roese wrote:
>>>>>> On 28.05.2018 10:11, Chris Packham wrote:
>>>>>>> On Mon, May 28, 2018 at 3:27 AM Baruch Siach <baruch at tkos.co.il> wrote:
>>>>>>>
>>>>>>>> The hidden i2c slave that interferes the i2c bus is not board specific.
>>>>>>>> All Armada 38x SoCs are affected. Move the code disabling this slave to
>>>>>>>> generic code to make it work on all affected hardware.
>>>>>>>
>>>>>>> I can't find a definition of this but the register seems to work for
>>>>>>> kirkwood as well (not surprising since it's probably a common IP block). Is
>>>>>>> there any chance we can find a home for this that's available to boards
>>>>>>> that don't use SPL?
>>>>>>
>>>>>> Yes, please. Can't we move this into the I2C driver instead (mvtwsi.c)?
>>>>>> No need to use MVEBU_TWSI_BASE then.
>>>>>
>>>>> The trouble is that the Turris Omnia board needs the i2c in SPL to read the
>>>>> RAM configuration from EEPROM. But I could not get the __twsi_i2c_init()
>>>>> routine (runs in both DM and non-DM) to be called from SPL.
>>>>
>>>> Are you sure? How can you use the I2C functions of this driver, if the
>>>> init / probe function is not called?
>>>
>>> __twsi_i2c_init() is called from the main U-Boot image, but not from SPL as
>>> far as my testing shows. Clearfog doesn't use i2c from SPL, but the Turris
>>> board does.
>>
>> Can't you switch to DM_I2C then? This should make sure, that the probe
>> function is always called before the xfer functions are used.
> 
> I plan to do so for Clearfog. But the turris_omnia_defconfig does not enable
> DM_I2C. So that would regress Turris.

Regress? Definitely not. We plan to remove all non-DM parts at some
time. So a move from the ancient driver parts to DM is definitely
preferred (especially if the platform and the driver already support
DM) - better sooner than later.

Thanks,
Stefan