From: Heiko Stuebner <heiko@sntech.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node
Date: Tue, 04 Dec 2018 15:49:26 +0100 [thread overview]
Message-ID: <1890683.7l19v6Bhrs@phil> (raw)
In-Reply-To: <A2AD3229-EC88-4C36-9912-E354530708DD@theobroma-systems.com>
Am Dienstag, 4. Dezember 2018, 10:35:48 CET schrieb Philipp Tomsich:
> Kever,
>
> > On 04.12.2018, at 08:06, Kever Yang <kever.yang@rock-chips.com> wrote:
> >
> > Hi Fabio,
> >
> >
> > On 12/03/2018 07:27 PM, Fabio Estevam wrote:
> >> Hi Kever,
> >>
> >> On Mon, Dec 3, 2018 at 2:00 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >>> The U-Boot eMMC does not need to care about the power for Rockchip
> >>> SoC, because if the board is using eMMC, the power will default on
> >>> (for bootrom), and we do not do power management for it like kernel,
> >>> so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot.
> >> Devicetree should represent the hardware and should not rely on
> >> details of BootROM / kernel / U-Boot.
> >>
> >> If these supplies are present in the hardware, they should be
> >> represented in the devicetree.
> >>
> >> What is the exact issue you are trying to solve?
> >
> > The U-Boot will fail to boot if eMMC driver try to enable the regulator
> > with error return.
> > These two nodes makes the eMMC driver need depends on pmic/regulator driver
> > works good.
> > My case is I have two similar boards, but have different pmic or pmic
> > config,
> > then only the one with correct config can boot successful.
> > I know you would ask me to commit a new dts with correct pmic config,
> > but please
> > note that there are much much more boards then what the upstream already
> > have.
> > We are not possible to add every board, and I don't think we have to.
>
> These boards should have their own DTS, as that’s the main function of
> the DTS (i.e. to describe the actual hardware).
>
> Why is it not possible to add these boards?
I'd also like to have each board represented correctly.
I think the main issue for Kever is, that each marketed device (hundreds?)
is largely following a reference design for the soc with smallish per-
board changes for their relevant features. So I guess the hope is that
it will save effort if there is common devicetree/board.
While these largely similar dts are somewhat of a concern, on the kernel-
side I try to only allow shared files for boards of the same vendor ... aka
when it really is safe to assume that everybody knows what really is shared
like the Vamrs Ficus+Rock960 or of course the Google-Gru series of devices.
Heiko
next prev parent reply other threads:[~2018-12-04 14:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 3:59 [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node Kever Yang
2018-12-03 11:27 ` Fabio Estevam
2018-12-04 7:06 ` Kever Yang
2018-12-04 9:35 ` Philipp Tomsich
2018-12-04 14:49 ` Heiko Stuebner [this message]
2018-12-05 2:13 ` Kever Yang
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=1890683.7l19v6Bhrs@phil \
--to=heiko@sntech.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox