On Tue, Apr 02, 2019 at 06:02:46PM +0200, Marek Vasut wrote: > On 4/2/19 5:40 PM, Eugeniu Rosca wrote: > > On Tue, Apr 02, 2019 at 05:28:43PM +0200, Marek Vasut wrote: > >> On 4/2/19 5:17 PM, Dirk Behme wrote: > >>> On 02.04.19 15:34, Marek Vasut wrote: > >>>> On 4/2/19 3:18 PM, Eugeniu Rosca wrote: > >>>>> With CONFIG_PINCTRL_PFC=n, aarch64-linux-gnu-ld reports: > >>>>> > >>>>> -----8<----- > >>>>> LD u-boot > >>>>> drivers/gpio/built-in.o: In function `rcar_gpio_request': > >>>>> drivers/gpio/gpio-rcar.c:128: undefined reference to > >>>>> `sh_pfc_config_mux_for_gpio' > >>>>> -----8<----- [..] > >>>> Does CONFIG_PINCTRL_PFC=n produce a bootable binary ? > >>> > >>> Why not? Main memory, boot device and UART are configured before U-Boot, > >>> no? > >> > >> It depends on what is running before U-Boot, so not necessarily. > >> > >> And speaking of boot device, consider the case where the system runs > >> from eMMC and uses the HS200/HS400 modes, which need to switch bus mode > >> using the pinmux driver. > >> > >> Is there a real-world use case where you would want to disable the > >> pinmux driver ? And what is the benefit of that, except that it would > >> cause all kinds of weird problems. > > > > My H3ULCB-KF boots just fine [1] with CONFIG_PINCTRL_PFC=n, but I > > personally don't have any use-case which I need to fulfill on a > > Renesas reference design by disabling PFC. > > And the eMMC and SDHI both work fine too in HS400/SDR104 modes ? > They cannot, since you cannot switch the pinmux properties of the bus. > What about the errors in the log below, they don't look quite fine. > > > Rather, the motivation here is to ensure U-Boot builds fine with as > > many randconfig results as possible, which is a standard practice in > > Linux. I personally favor my solution, but I am also open minded if > > the linker error is avoided by introducing a direct/reverse dependency > > between PFC and another relevant R-Car3 Kconfig symbol. > > I am fine with fixing randconfig build errors. My question here is > whether it makes sense to allow U-Boot build without PFC support, > since that would cause all kinds of problems. I am banking toward > playing it safe and not allowing such an option at all. Thoughts ?
It looks like in Linux, PINCTRL is a fundamental feature selected (i.e. *cannot* be disabled by users) by ARCH_RENESAS since v4.5 commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26a7e06dfee9 ("arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support"). So, demanding a PFC-free U-Boot doesn't look reasonable to me. Should PINCTRL be selected by CONFIG_RCAR_GEN3 as it is done in Linux? One caveat is that PINCTRL currently depends on DM, so R-Car3 U-Boot would become dependent on DM too, i.e. users won't have the option of a legacy U-Boot anymore. > > [1] U-Boot 2019.04-rc4-00100-g03ece61db8 (Apr 02 2019 - 17:23:57 +0200) [..] Best regards, Eugeniu. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
