[U-Boot] [PATCH v2] rockchip: rk3288-evb: dts: remove 'vmmc' from emmc node

[Tom Rini]

On Sat, Dec 08, 2018 at 12:27:42PM +0800, Kever Yang wrote:
> Hi Tom,
> 
> 
> On 12/07/2018 10:13 PM, Tom Rini wrote:
> > On Fri, Dec 07, 2018 at 02:24:22PM +0100, Philipp Tomsich wrote:
> >> Kever,
> >>
> >>> On 07.12.2018, at 02:39, Kever Yang <kever.yang at rock-chips.com> wrote:
> >>>
> >>> Hi Philipp,
> >>>
> >>> On 12/06/2018 09:50 PM, Philipp Tomsich wrote:
> >>>> +Tom
> >>>>
> >>>>> On 05.12.2018, at 03:25, Kever Yang <kever.yang at 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.
> >>>>>
> >>>>> This make U-Boot can boot into kernel even if the pmic driver is
> >>>>> broken.
> >>>> If the PMIC driver is broken, we should fix the PMIC driver.
> >>>> I would feel more comfortable w/o this statement.
> >>>>
> >>>>> The rk3288-evb dts may be used in many boards using rockchip reference
> >>>>> schematic but with little change, so we hope it can be more robust to
> >>>>> boot into next stage.
> >>>> Again, this is not how the DTS should be used.  I believe that Heiko, Fabio and
> >>>> I had already highlighted this in comments to the earlier thread.
> >>>     Not sure if you have read my previous mail for answer all your comments,
> >>>
> >>> I do agree DTS should represent the hardware, but please note that the DTS
> >>> is no kind of standard, and people always choose what they need and add
> >>> those part in there dts, but not always add all the property and
> >>> everyone use the same model. I would say there are many boards does not have this
> >>> 'vmmc-supply’ in there emmc node.
> >> That is exactly the reason why I bumped the decision up the stairs (to Tom and/or
> >> Simon): what you are saying makes sense to me (viewed through your eyes and 
> >> from your specific usecase), but it directly contradicts how the DTS usage is intended.
> >>
> >> In other words: Tom (as the top-level decision maker) or Simon (who owns the 
> >> device-model and therefore will also have an opinion on DTS usage) should make
> >> the final call.
> > My answer is that I would strongly suspect that over in linux "we have N
> > different close-enough boards using this one DTS" isn't acceptable.  You
> > make a dtsi and include it from the board and things that aren't common
> > don't go into the dtsi.  And yes, when starting off everyone (myself
> > included) copies the reference platform dts and then changes it as
> > needed, and sometimes misses a thing or two.  But no, I don't think we
> > want a wrong dts and I'm pretty sure the kernel really wouldn't want
> > wrong dts files and the general goal is that excluding the -u-boot.dtsi
> > files, ours are copies of the kernel.
> I don't think this is a "wrong dts" after my patch, these two nodes are
> not mark
> as required property in kernel, so many dts emmc node does not have it.
> I check the latest kernel dtsi in arch/arm/boot/dts/rk3288-evb.dtsi [1],
> the emmc node do not have 'vmmc' and 'vqmmc' while the SD node have, which
> just like description in my commit message.

OK.  So this would fall into the category of "sync with upstream dts"
then, right?  That is what we want.

> Well, I don't know why U-Boot project is so difficult to accept a
> reasonable patch now, I don't
> want to make you unhappy, but make 'every board must have its own dts'
> in U-Boot to make
> every developer to join U-Boot does not make sense to me. The kernel
> need different
> dts for different board because they need to use/control those different
> feature, but U-Boot
> is not the case, U-Boot should work if the storage driver works.

Well, here's the thing.  If you want U-Boot to then load and pass the
correct DTB to the kernel, we need per-board tweaks to the code anyhow
to find and load that DTB (see the various "findfdt" environment scripts
for example).  If you want to rework things so that you have a "generic"
type board under U-Boot that's more clearly not tied to any specific
board but instead runs on many, that might help clear things up too.
Hope this helps!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181210/83abc5fe/attachment.sig>