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

[Alexander Graf]

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 :).


Alex