On 24.01.19 12:07, Andre Przywara wrote: > On Thu, 24 Jan 2019 11:59:32 +0100 > Alexander Graf <ag...@suse.de> wrote: > >> On 24.01.19 11:57, Andre Przywara wrote: >>> On Thu, 24 Jan 2019 11:17:03 +0100 >>> Alexander Graf <ag...@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 <osk...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
