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

[Alexander Graf]

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?


Alex