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

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

[Dirk Behme]

Hi,

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/recipes-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/renesas/salvator-x/salvator-x.c#L116


3. Linux kernel

https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/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)?


Any opinions?


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.

Best regards

Dirk

[1] 
https://github.com/renesas-rcar/u-boot/blob/v2015.04/rcar-3.2.x/board/renesas/salvator-x/salvator-x.c#L152

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

[Geert Uytterhoeven]

Hi Dirk,

On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme <dirk.behme@de.bosch.com> 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/recipes-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/renesas/salvator-x/salvator-x.c#L116
>
>
> 3. Linux kernel
>
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/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. This is the same stance as
for module clocks.

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).

> 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?
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).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Dirk Behme]

Hi Geert,

On 09.06.2016 10:22, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme <dirk.behme@de.bosch.com> 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/recipes-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/renesas/salvator-x/salvator-x.c#L116
>>
>>
>> 3. Linux kernel
>>
>> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/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.

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.


> 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?


>> 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?


Best regards

Dirk

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

[Laurent Pinchart]

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

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

[Geert Uytterhoeven]

Hi Dirk,

On Thu, Jun 9, 2016 at 10:58 AM, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> On 09.06.2016 10:22, Geert Uytterhoeven wrote:
>> On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme <dirk.behme@de.bosch.com>
>> 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/recipes-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/renesas/salvator-x/salvator-x.c#L116
>>>
>>> 3. Linux kernel
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/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.
>
> 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.
>
>> 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?

Pinctrl for devices is described in the board's DTS (e.g.
r8a7795-salvator-x.dts).

Or in a DT overlay, if you use the EXIO connectors.

>>> 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?

No, you need more steps.

1. Add non-GPIO drive strength support to pfc-r8a7795,
2. Describe correct RAVB pinctrl config in r8a7795-salvator-x.dts.
3. Profit!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Dirk Behme]

Hi Geert,

On 09.06.2016 11:20, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Thu, Jun 9, 2016 at 10:58 AM, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> On 09.06.2016 10:22, Geert Uytterhoeven wrote:
>>> On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme <dirk.behme@de.bosch.com>
>>> 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/recipes-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/renesas/salvator-x/salvator-x.c#L116
>>>>
>>>> 3. Linux kernel
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/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.
>>
>> 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.
>>
>>> 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?
>
> Pinctrl for devices is described in the board's DTS (e.g.
> r8a7795-salvator-x.dts).
>
> Or in a DT overlay, if you use the EXIO connectors.
>
>>>> 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?
>
> No, you need more steps.
>
> 1. Add non-GPIO drive strength support to pfc-r8a7795,
> 2. Describe correct RAVB pinctrl config in r8a7795-salvator-x.dts.
> 3. Profit!


I think we will go with fixing the boot loader, then :)


Best regards

Dirk