From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Tue, 8 Jan 2019 23:52:36 +0100 Subject: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation In-Reply-To: References: <20181218113050.6115-1-lukma@denx.de> <20181227154733.GI16433@bill-the-cat> Message-ID: <20190108235236.41aa25f5@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Alex, > On Thu, Dec 27, 2018 at 3:49 PM Tom Rini wrote: > > > > On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski wrote: > > > > > This commit prevents from re-configuring pins if those were > > > configured before relocation. > > > > > > Some pins - like UART or DDR must be setup before relocation > > > (as they have 'u-boot,dm-pre-reloc' property set in DTS). Without > > > this change, those pins are re-configured after relocation > > > (pre_reloc_only = 0, so we do not "continue"). > > > Such behavior may be a problem for DDR PAD configuration, as they > > > might be already leveled/tuned with original setup). > > > > > > Signed-off-by: Lukasz Majewski > > > > Applied to u-boot/master, thanks! > > > > I've bisected out to this commit and it's slightly broken things for > me on an AM3352. It all works fine so long as I boot MLO from MMC (so > the MMC is probed, pinctrl setup), but if I boot from UART then I get > to full U-Boot, MMC hasn't been probed and the pinmuxing isn't set up > for the MMC. I suppose that the pinmux node have set "u-boot,dm-pre-reloc" property? The problem is not with lack of eMMC probing - it is with pinctrl nodes having "u-boot,dm-pre-reloc" set in DTS and the eMMC is probed after MLO/SPL. It looks like your use case implicitly depends on pinmux being reconfigured no matter if we are pre-relocated (MLO) or afterwards. As stated in the commit message above - for DDR pads it is dangerous to re-configure them. I'm wondering as in the device_probe() @ drivers/core/device.c the DM_FLAG_ACTIVATED is checked. This should be enough to prevent re-checking (of the DDR pins). Anyway, this will not fix the issue you mentioned. I've put Simon to CC, maybe he would have some input? 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: