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

[Oskari Lemmelä]

Hi,

On 24.1.2019 12.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.
>
>> But either way, without the eMMC module, things seem to work:
>>
>>   Tested-by: Alexander Graf <agraf at suse.de>
> Does anyone care to clean up the Kconfig dependency mess, since we seem
> to know all the options we need now? Ideally we would just need one or
> two symbols in the *_defconfig files, the rest being automatically
> selected by Kconfig magic.
> It's on my list, but there are other things higher on that one.
I can try contribute and take a look this one.
> Cheers,
> Andre.

Thanks,
Oskari