[U-Boot] Question regarding early pinctrl and driver model in u-boot

[U-Boot] Question regarding early pinctrl and driver model in u-boot

[Lukasz Majewski]

Dear All,

I've stumbled upon a following issue:

- I do have a vybrid SoC which is not using SPL. It only uses U-boot
  proper (u-boot.vyb).

- In the board_early_init_f() (when we are still in SRAM) I do perform
  pinctrl (pinmux) setup for UART1 (this is the console device).

- I also do use ucalss-serial.c for this device and have proper pinmux
  definition for it in the *.dts file - but this is done latter. 

The problem is that, when I try to remove pinmux setup code
(imx_iomux_v3_setup_multiple_pads()) from board_early_init_f(), then I
do see uart output late (no U-boot early output - U-Boot
2018.11-00052-g6552299a40-dirty (Nov 23 2018 - 16:13:51 +0100)).

The reason for this is the lack of pinctrl UART pins setup.


Do you see any idea how to move to full dts support for uart? The uart
driver and pinmux have defined DM_FLAG_PRE_RELOC.


The same kind of problem I do have with DDR memory controller pin
setup. It would be nice to have it all in DTS, not in a board file.




[ My idea would be to manually extract relevant data from fdt blob and
configure pins in board_early_init_f(), but this looks like a hack -
maybe there is another, better solution? ]



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181203/2d8af1b4/attachment.sig>

[U-Boot] Question regarding early pinctrl and driver model in u-boot

[Simon Glass]

Hi Lukasz,

On Mon, 3 Dec 2018 at 15:13, Lukasz Majewski <lukma@denx.de> wrote:
>
> Dear All,
>
> I've stumbled upon a following issue:
>
> - I do have a vybrid SoC which is not using SPL. It only uses U-boot
>   proper (u-boot.vyb).
>
> - In the board_early_init_f() (when we are still in SRAM) I do perform
>   pinctrl (pinmux) setup for UART1 (this is the console device).
>
> - I also do use ucalss-serial.c for this device and have proper pinmux
>   definition for it in the *.dts file - but this is done latter.
>
> The problem is that, when I try to remove pinmux setup code
> (imx_iomux_v3_setup_multiple_pads()) from board_early_init_f(), then I
> do see uart output late (no U-boot early output - U-Boot
> 2018.11-00052-g6552299a40-dirty (Nov 23 2018 - 16:13:51 +0100)).
>
> The reason for this is the lack of pinctrl UART pins setup.
>
>
> Do you see any idea how to move to full dts support for uart? The uart
> driver and pinmux have defined DM_FLAG_PRE_RELOC.

Is this due to pinconfig_post_bind() only operating after relocation?

>
>
> The same kind of problem I do have with DDR memory controller pin
> setup. It would be nice to have it all in DTS, not in a board file.
>
>
>
>
> [ My idea would be to manually extract relevant data from fdt blob and
> configure pins in board_early_init_f(), but this looks like a hack -
> maybe there is another, better solution? ]

Hopefully :-)

Regards,
Simon

[U-Boot] Question regarding early pinctrl and driver model in u-boot

[Lukasz Majewski]

Hi Simon,

> Hi Lukasz,
> 
> On Mon, 3 Dec 2018 at 15:13, Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Dear All,
> >
> > I've stumbled upon a following issue:
> >
> > - I do have a vybrid SoC which is not using SPL. It only uses U-boot
> >   proper (u-boot.vyb).
> >
> > - In the board_early_init_f() (when we are still in SRAM) I do
> > perform pinctrl (pinmux) setup for UART1 (this is the console
> > device).
> >
> > - I also do use ucalss-serial.c for this device and have proper
> > pinmux definition for it in the *.dts file - but this is done
> > latter.
> >
> > The problem is that, when I try to remove pinmux setup code
> > (imx_iomux_v3_setup_multiple_pads()) from board_early_init_f(),
> > then I do see uart output late (no U-boot early output - U-Boot
> > 2018.11-00052-g6552299a40-dirty (Nov 23 2018 - 16:13:51 +0100)).
> >
> > The reason for this is the lack of pinctrl UART pins setup.
> >
> >
> > Do you see any idea how to move to full dts support for uart? The
> > uart driver and pinmux have defined DM_FLAG_PRE_RELOC.  
> 
> Is this due to pinconfig_post_bind() only operating after relocation?

Please correct me if I'm wrong, but post_bind() callback is called with
device_bind_* family of functions?

Those functions - e.g. device_bind() are used in an interesting way
- e.g.: drivers/gpio/s5p_gpio.c -> gpio_exynos_bind().

The problem seems to be with the time pinctrl device itself is probed
(way after board_early_init_f()).

IMHO it would be enough to "probe" pinctrl itself very early (before
relocation - DDR setup) to just configure pins from iomux's pictrl_hog
group (and put there DDR and uart pins) - not waiting for other devices
to be "discovered" (like uart).

> 
> >
> >
> > The same kind of problem I do have with DDR memory controller pin
> > setup. It would be nice to have it all in DTS, not in a board file.
> >
> >
> >
> >
> > [ My idea would be to manually extract relevant data from fdt blob
> > and configure pins in board_early_init_f(), but this looks like a
> > hack - maybe there is another, better solution? ]  
> 
> Hopefully :-)
> 
> Regards,
> Simon




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181206/3bf9e520/attachment.sig>

[U-Boot] Question regarding early pinctrl and driver model in u-boot

[Simon Glass]

Hi Lukasz,

On Thu, 6 Dec 2018 at 01:50, Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Simon,
>
> > Hi Lukasz,
> >
> > On Mon, 3 Dec 2018 at 15:13, Lukasz Majewski <lukma@denx.de> wrote:
> > >
> > > Dear All,
> > >
> > > I've stumbled upon a following issue:
> > >
> > > - I do have a vybrid SoC which is not using SPL. It only uses U-boot
> > >   proper (u-boot.vyb).
> > >
> > > - In the board_early_init_f() (when we are still in SRAM) I do
> > > perform pinctrl (pinmux) setup for UART1 (this is the console
> > > device).
> > >
> > > - I also do use ucalss-serial.c for this device and have proper
> > > pinmux definition for it in the *.dts file - but this is done
> > > latter.
> > >
> > > The problem is that, when I try to remove pinmux setup code
> > > (imx_iomux_v3_setup_multiple_pads()) from board_early_init_f(),
> > > then I do see uart output late (no U-boot early output - U-Boot
> > > 2018.11-00052-g6552299a40-dirty (Nov 23 2018 - 16:13:51 +0100)).
> > >
> > > The reason for this is the lack of pinctrl UART pins setup.
> > >
> > >
> > > Do you see any idea how to move to full dts support for uart? The
> > > uart driver and pinmux have defined DM_FLAG_PRE_RELOC.
> >
> > Is this due to pinconfig_post_bind() only operating after relocation?
>
> Please correct me if I'm wrong, but post_bind() callback is called with
> device_bind_* family of functions?

Yes

>
> Those functions - e.g. device_bind() are used in an interesting way
> - e.g.: drivers/gpio/s5p_gpio.c -> gpio_exynos_bind().

Yes, they create child devices.

>
> The problem seems to be with the time pinctrl device itself is probed
> (way after board_early_init_f()).
>
> IMHO it would be enough to "probe" pinctrl itself very early (before
> relocation - DDR setup) to just configure pins from iomux's pictrl_hog
> group (and put there DDR and uart pins) - not waiting for other devices
> to be "discovered" (like uart).

Well, even probing a single device will cause pinctrlt to be probed,
so shouldn't this happen automatically?

Regards,
Simon