[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 at 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>