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
> > > > > > > > <bar...@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------------{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
