All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: Soeren Moch <smoch@web.de>
Cc: Tom Rini <trini@konsulko.com>, Stefano Babic <sbabic@denx.de>,
	 Fabio Estevam <festevam@gmail.com>,
	U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH 2/2] board: tbs2910: Convert to DM_SERIAL
Date: Mon, 14 Mar 2022 13:37:04 -0600	[thread overview]
Message-ID: <CAPnjgZ2u-w2A0TUZ_cJs_t0MKoK7cLS1KpFtM_r3DAe3=mh2WQ@mail.gmail.com> (raw)
In-Reply-To: <cc7e3951-5152-d463-7be0-f1ea17b4f886@web.de>

Hi Soeren,

On Mon, 14 Mar 2022 at 13:22, Soeren Moch <smoch@web.de> wrote:
>
>
> On 14.03.22 19:28, Tom Rini wrote:
> > On Mon, Mar 14, 2022 at 12:24:36PM -0600, Simon Glass wrote:
> >> Hi Soeren,
> >>
> >> On Mon, 14 Mar 2022 at 02:26, Soeren Moch <smoch@web.de> wrote:
> >>> ... to get rid of the build warning.
> >>> Unfortunately we still need the board specific serial pin init code.
> >>> Otherwise the first boot messages over the serial console are lost.
> >>>
> >>> Signed-off-by: Soeren Moch <smoch@web.de>
> >>> ---
> >>> Cc: Stefano Babic <sbabic@denx.de>
> >>> Cc: Fabio Estevam <festevam@gmail.com>
> >>> Cc: Tom Rini <trini@konsulko.com>
> >>> Cc: Simon Glass <sjg@chromium.org>
> >>> Cc: u-boot@lists.denx.de
> >>>
> >>> The whole purpose of DM is somewhat defeated when we still need board
> >>> specific initializations. Any ideas how we can get all boot messages
> >>> without board specific inits? 'u-boot,dm-pre-reloc;' in the uart device
> >>> tree node did not help.
> >> You can put that in your serial driver, perhaps? Or in the initial SoC
> >> init code?
> Why should I do so? The whole point of DM is initializing devices from
> DT. And when I wish to do so pre-relocation, it is advertised in DM to
> add 'u-boot,dm-pre-reloc;' for this purpose. I tried, it did not work.
> And this is nothing closely related to the serial driver itself, I just
> want the pin setup running pre-relocation and not as late as it is
> running now under DM_SERIAL.

If you have a pinctrl driver it will be used. I don't really
understand your problem.

>
> I also do not want to run this pin setup twice (first in board or SoC
> code and again by DM_SERIAL later). Maybe I miss something obvious, but
> duplication of the setup code cannot be a proper solution.

Well the pinctrl will be triggered before relocation and after, if
enabled. We could solve that but have not tried.

> >>
> >> Another recent way (in -next) is to use events to monitor the
> >> EVT_DM_PRE_PROBE event for the serial driver.
> I can monitor the probe event, OK. But how can this solve my problem?
> Again, maybe I miss something obvious, please tell me when I do so.
> > It's just the same thing every single imx platform is doing.
> >
> Sorry, I don't understand what you mean here. The reference platform for
> my board is mx6sabresd. This is not converted to DM_SERIAL yet. Most (?)
> imx boards use SPL, pin setup is different there.
> I looked into imx boards with DM_SERIAL. They either removed the
> board-specific setup code (which results in missing early boot messages:
> u-boot version, board name, DDR size, ...) or they are playing tricks in
> SPL (not the clean and easy solution that DM promises). Maybe I missed a
> better reference for the DM_SERIAL conversion without SPL. Can you point
> me to such board?

If you want to use pinctrl in SPL, you can do all of this cleanly. If
you have code-size constraints, then you may want to do something like
rockchip, where only specific peripherals are supported in pinctrl in
SPL.

You could look at firefly-rk3288 (or bob/coral/jerry) which I believe
is done fully with driver model.

Perhaps Tom has a better handle on the problem.

Regards,
Simon

  parent reply	other threads:[~2022-03-14 19:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14  8:26 [PATCH 1/2] board: tbs2910: Enable Link Time Optimizations in defconfig Soeren Moch
2022-03-14  8:26 ` [PATCH 2/2] board: tbs2910: Convert to DM_SERIAL Soeren Moch
2022-03-14 18:24   ` Simon Glass
2022-03-14 18:28     ` Tom Rini
2022-03-14 19:22       ` Soeren Moch
2022-03-14 19:34         ` Tom Rini
2022-03-14 19:37         ` Simon Glass [this message]
2022-03-14 21:51           ` Sören Moch
2022-03-14 22:20             ` Simon Glass
2022-03-14 22:38               ` Tom Rini
2022-03-14 22:46                 ` Simon Glass
2022-03-14 23:16                 ` Fabio Estevam
2022-03-15 20:56                   ` Soeren Moch
2022-03-19 11:34                     ` Soeren Moch
2022-03-14 18:14 ` [PATCH 1/2] board: tbs2910: Enable Link Time Optimizations in defconfig Tom Rini
2022-03-14 18:24 ` 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='CAPnjgZ2u-w2A0TUZ_cJs_t0MKoK7cLS1KpFtM_r3DAe3=mh2WQ@mail.gmail.com' \
    --to=sjg@chromium.org \
    --cc=festevam@gmail.com \
    --cc=sbabic@denx.de \
    --cc=smoch@web.de \
    --cc=trini@konsulko.com \
    --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.