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

Thu Jan 24 12:21:51 UTC 2019

On Thu, 24 Jan 2019 13:07:54 +0100
Alexander Graf <agraf at suse.de> wrote:

> On 24.01.19 12:31, Andre Przywara wrote:
> > On Thu, 24 Jan 2019 12:21:17 +0100
> > Alexander Graf <agraf at suse.de> wrote:
> >   
> >> On 24.01.19 12:07, Andre Przywara wrote:  
> >>> 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?    
> >>
> >> Yes, "mmc part" to be precise.
> >>  
> >>> 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?    
> >>
> >> Yup, all of it at runtime. I felt darey and ignored the fact that
> >> you should really only plug the eMMC module at boot time ;).
> >>
> >> The last step definitely did not change pinmux. Hence the
> >> conclusion that this is line drive collision, not pinmux.
> >>
> >> So I guess you're saying that forcing the eMMC into 4-DAT mode
> >> would make things work?  
> > 
> > Technically DS is for HS-400, which is a step beyond 8-bit bus
> > width. So just enabling 8 bit should not affect the DS line. There
> > is a bit in the MMC controller to enable HS-400, but I don't see
> > that we would set it (we actually don't even define the register).
> > You could try to force eMMC to 4 bit to check this theory, by
> > hack-removing the MMC_MODE_8BIT line in sunxi_mmc_init() in
> > drivers/mmc/sunxi-mmc.c (we don't use DM_MMC yet, so it's in the
> > hacky part and ignores the DT property)  
> 
> Ok, that did not help. I guess the next best useful thing to do now
> would be to measure what the MISO line shows in each situation.
> Unfortunately I don't have my oscilloscope handy :).

Can't you configure PC1 as a gpio, and read that? Not sure the "gpio"
command works with PC1 being a "function pin", but you could always hack
it to GPIO-in by clearing bits[7:4] in 0x01C20848, with md.l/mw.l.

Cheers,
Andre.