Re: R-Car3: PFC: Where to do the pinmux/drvctrl?

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Dirk,

On Thursday 09 Jun 2016 10:58:30 Dirk Behme wrote:
> On 09.06.2016 10:22, Geert Uytterhoeven wrote:
> > On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme wrote:
> >> with the R-Car3, the pinmux/drvctrl is done at 3 places:
> >> 
> >> 1. ARM trusted firmware / IPL:
> >> 
> >> https://github.com/renesas-rcar/meta-renesas/blob/jethro/meta-rcar-gen3/r
> >> ecipes-bsp/arm-trusted-firmware/arm-trusted-firmware/0001-add-bl2-bl31-R-
> >> Car-support.patch#L8428
> >> 
> >> 
> >> 2. U-Boot:
> >> 
> >> https://github.com/renesas-rcar/u-boot/blob/v2015.04/rcar-3.2.x/board/ren
> >> esas/salvator-x/salvator-x.c#L116
> >> 
> >> 
> >> 3. Linux kernel
> >> 
> >> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tr
> >> ee/drivers/pinctrl/sh-pfc/pfc-r8a7795.c?h=topic/gen3-latest
> >> 
> >> 
> >> Now, the issue we see is that (of course?) this is not necessarily
> >> consistent.
> >> 
> >> Therefore: What's supposed to be the correct place to do this (once)?
> > 
> > IMHO the kernel should take care of making sure pinctrl is configured
> > correctly, independent of earlier stages in the boot process.
> 
>  From previous discussions with kernel people I expected this answer ;)
> 
> In my opinion, to be able to keep the pinctrl consistent, you have to do
> it in one place. To avoid issues like discussed below. And to be able to
> maintain it. The consequence of this "one place" would be that the main
> place is the boot loader, then. In case of the Salvator-X this would be
> the ARM trusted firmware (IPL), then.

Anything with "trusted" in its name can't be trusted.

> Yes, I know, kernel people see this differently, as the kernel is the
> only place they have under control. From that point of view only the
> kernel can "fix" broken or not updated boot loaders.
> 
> So it depends whether you have only the kernel or everything under your
> control, including the boot loader.

It's a nice dream, but in practice I'm afraid boot loaders get it wrong, and 
the kernel has to handle the mess.

> > Note that if the kernel takes care of it, doing it once is not an option,
> > as earlier stages may need pinctrl configuration depending on boot method
> > (e.g. TFTP over Ethernet needs RAVB setup).
> 
> How will the kernel handle different boards needing different pinctrl
> configuration?
> 
> I.e. how is pfc-r8a7795 supposed to cover different boards?

pfc-r8a7795 isn't. That driver needs to implement all needed configuration 
options for the R8A7795 pins. Pinmux/pinctrl configuration is then selected by 
device drivers (the ethernet driver in this case) based on the information 
supplied in the board's device tree.

> >> The example is the RAVB ethernet: We found that on the Salvator-X the
> >> kernel's ethernet doesn't work without being initialized by U-Boot. I.e.
> >> without running U-Boot doing the drvctrl [1] ethernet fails in the Linux
> >> kernel.
> > 
> > This is a missing/incorrect drive strength configuration?
> 
> Yes, I think so.
> 
> > The pfc-r8a7795 does have support for drive strength, but only for pins
> > that also have GPIO capabilities. (At least some of) the RAVB pins don't
> > seem to be handled (e.g. DRVCTRL2).
> 
> So your proposal would be to fix/correct/extend Linux kernel's
> pfc-r8a7795 to correctly support the drive strength needed for the RAVB
> on the Salvator-X?

If the R8A7795 supports configuring the drive strength of RAVB pins, and that 
feature is needed by systems using that SoC, then the pfc-r8a7795 driver 
should implement it, yes. That's no different that any other hardware feature.

-- 
Regards,

Laurent Pinchart