All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation
Date: Sat, 12 Jan 2019 22:45:46 +0100	[thread overview]
Message-ID: <20190112224546.2df1d0ee@jawa> (raw)
In-Reply-To: <CAO5Uq5Ty7TUsdJt9ZBeAJyxT7DUPC68vyvA0c3QPXdfNHmtN8A@mail.gmail.com>

Hi Alex,

> On Tue, Jan 8, 2019 at 11:24 PM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Hi Alex,
> >  
> > > On Tue, Jan 8, 2019 at 10:52 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > > >
> > > > Hi Alex,
> > > >  
> > > > > On Thu, Dec 27, 2018 at 3:49 PM Tom Rini <trini@konsulko.com>
> > > > > 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 <lukma@denx.de>  
> > > > > >
> > > > > > 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?
> > > >  
> > >
> > > Yeah, well "u-boot,dm-spl", though now I re-read the docs I guess
> > > that's equivalent to "u-boot,dm-pre-reloc" as I've no TPL.  
> >
> > I do need to check this -> as in my case I do have
> > "u-boot,dm-pre-reloc" property. And yes, in my case I do not have
> > TPL too (just SPL).
> >  
> > >  
> > > > 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. 
> > >
> > > Yes, that's a much clearer description...  
> >
> > Frankly, your mail opened my eyes to a use case which was handled (I
> > assume on purpose) with the old code - the "cross" boot with pinmux
> > and devices.
> >
> > For example boot from UART (MLO/SPL) and then continue with eMMC
> > (which require pinmux).
> >  
> 
> So I guess this needs something like a bloblist to communicate the
> initialisation state between MLO/SPL and u-boot,

Yes. IMHO this is one way to do it. There is already a
DM_FLAG_ACTIVATED, which indicates if the device was probed. However,
it is not "dragged" from MLO / SPL to u-boot.img

However, I think that we shall introduce a new flag -
DM_FLAG_CONFIGURE_ONCE [*], which would indicate that the device need
single configuration. 

This flag could be used with DM_PINMUX driver, to avoid
re-configuration.

The idea would be to use bloblist (only when [*] is set) to pass tuples:
(driver_name, config_status) 

and in the core of DM just check if we shall re-configure the driver or
not.

> which I've not the
> faintest idea where to start on.
> 
> Horrible as they are, is a CONFIG symbol a possibility whilst we
> figure out how to solve this properly?

The bloblist can be activated with CONFIG_BLOBLIST

> 
> I guess another option would be an additional two properties that give
> the two behaviours, but that feels like something we don't want long
> term.

As we strive to use as little "u-boot,XXXXXX" extra properties to avoid
problems with Linux re-sync, I think that we shall use bloblist.

> 
> 
> --
> Alex Kiernan




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/20190112/109e8157/attachment.sig>

  reply	other threads:[~2019-01-12 21:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18 11:30 [U-Boot] [PATCH] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation Lukasz Majewski
2018-12-27 15:47 ` [U-Boot] " Tom Rini
2019-01-08 17:49   ` Alex Kiernan
2019-01-08 22:52     ` Lukasz Majewski
2019-01-08 23:13       ` Alex Kiernan
2019-01-08 23:24         ` Lukasz Majewski
2019-01-12  9:30           ` Alex Kiernan
2019-01-12 21:45             ` Lukasz Majewski [this message]
2019-01-16 21:35               ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190112224546.2df1d0ee@jawa \
    --to=lukma@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.