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 When I that start initializing the eMMC module, SPI flash fails When I then unplug the eMMC module, SPI flash works again So this is not pinmux related. The eMMC module really just drives the line. Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
