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

[Baruch Siach]

Hi Stafan,

On Mon, May 28, 2018 at 12:33:41PM +0200, Stefan Roese wrote:
> On 28.05.2018 12:29, Baruch Siach wrote:
> > 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.

What I meant to say is that moving the i2c slave disable code from Turris code 
to the mvtwsi driver would regress Turris unless Turris migrates to DM_I2C 
first. I have no access to the Turris hardware, so I can't test the DM_I2C 
migration on that platform.

If you prefer I can leave the Turris code alone. Instead, I'll add the i2c 
slave disable to mvtwsi. Once Turris migrates to DM_I2C we can remove the 
redundant code from its platform code.

What do you think?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -