[U-Boot] [PATCH 1/2] arm: sunxi: allwinner spi driver sun6i support

[Andre Przywara]

On Thu, 24 Jan 2019 11:59:32 +0100
Alexander Graf <agraf at suse.de> wrote:

> On 24.01.19 11:57, Andre Przywara wrote:
> > On Thu, 24 Jan 2019 11:17:03 +0100
> > Alexander Graf <agraf at suse.de> wrote:
> >   
> >> On 22.01.19 17:37, Alexander Graf wrote:  
> >>>
> >>>
> >>> On 22.01.19 17:28, Alexander Graf wrote:    
> >>>>
> >>>>
> >>>> On 22.01.19 17:17, Oskari Lemmelä wrote:    
> >>>>> Hi,
> >>>>>
> >>>>> On 22.1.2019 16.54, Alexander Graf wrote:    
> >>>>>>
> >>>>>> On 05.01.19 18:52, Oskari Lemmela wrote:    
> >>>>>>> Minimal changes to support sun6i based Allwinner SOCs
> >>>>>>> Changes are based to SPL driver
> >>>>>>> arch/arm/mach-sunxi/spl_spi_sunxi.c
> >>>>>>>
> >>>>>>> Signed-off-by: Oskari Lemmela <oskari at lemmela.net>    
> >>>>>> I just tried to see if this patch gives me "sf" access on a
> >>>>>> SoPine system. Unfortunately, it seems as if the sun4i_spi
> >>>>>> driver doesn't even get probed?
> >>>>>>
> >>>>>> How did you manage to actually make use of this driver?
> >>>>>>
> >>>>>>
> >>>>>> Alex    
> >>>>>
> >>>>> You need to add spi0 alias to dts and enable needed drivers to
> >>>>> defconfig. You can take look from Jagan's patch [1].
> >>>>>
> >>>>> I didn't include those changes as Maxime already commented [2]
> >>>>> that Kconfig depends/defaults should be modified first.    
> >>>>
> >>>> I don't see any relation between the dts change and the Kconfig
> >>>> dependency issues?
> >>>>
> >>>> But thanks for the pointer, I'll give this patch a try.    
> >>>
> >>> Ok, so I now get the SPI controller initialized, but it seems to
> >>> only returns zeros when trying to access the SPI flash device.
> >>>
> >>> In other words, it doesn't work for me :). But maybe I'm missing
> >>> all the other clk patches to actually get it working?    
> >>
> >> Ok, so turns out the problem is that you can't have eMMC and SPI
> >> both working. I don't quite know yet whether this is just a pinmux
> >> problem (so potentially software workaroundable) or if it's a
> >> hardware limitation (eMMC pulling a line required for SPI).  
> > 
> > The line that is shared is "DS", which is only needed for higher
> > (e)MMC modes (HS-400). At the moment neither Linux nor U-Boot
> > implement this mode, and probably U-Boot will never need it: it
> > adds software complexity for a questionable performance benefit,
> > especially if the flash chips can't keep up with the high interface
> > speed anyway.
> > 
> > We addressed this in the DTs (kernel commit fa59dd2ef755).
> > 
> > I am a bit puzzled here as why this happens: I can't find where
> > U-Boot would configure PC1 to use the MMC2 function: the hard-coded
> > mmc_pinmux_setup() doesn't touch PC1 at all. Maybe it's the BootROM
> > configuring this line? So we would need to reset it?
> > 
> > As I don't have an eMMC module here at hand right now, this has to
> > wait till tonight for further insights.  
> 
> A few more data points:
> 
> When I boot w/o eMMC module attached, SPI flash works
> When I then plug in the eMMC module, SPI flash still works

Plug in with power off (which you should always do)? So it goes through
the BootROM?

> When I that start initializing the eMMC module, SPI flash fails

What do you mean by that, exactly? Accessing eMMC from U-Boot?
Because that is the interesting data point, somehow this makes the
eMMC module drive the pin.

> When I then unplug the eMMC module, SPI flash works again

Again, at runtime?

> So this is not pinmux related. The eMMC module really just drives the
> line.

Thanks for that.

Cheers,
Andre.