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