From: Tom Rini Date: Mon, 10 Dec 2018 13:20:22 -0500 Subject: [U-Boot] [PATCH v2] rockchip: rk3288-evb: dts: remove 'vmmc' from emmc node In-Reply-To: References: <20181205022500.5878-1-kever.yang@rock-chips.com> <515C6EEE-DAEC-4398-BBF2-82380DCC7ECC@theobroma-systems.com> <67828730-3052-488A-ADF5-35EC5D7F4482@theobroma-systems.com> <20181207141300.GD14374@bill-the-cat> Message-ID: <20181210182022.GX8702@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de On Sat, Dec 08, 2018 at 12:27:42PM +0800, Kever Yang wrote: > Hi Tom, >=20 >=20 > 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 wrote: > >>> > >>> Hi Philipp, > >>> > >>> On 12/06/2018 09:50 PM, Philipp Tomsich wrote: > >>>> +Tom > >>>> > >>>>> On 05.12.2018, at 03:25, Kever Yang wro= te: > >>>>> > >>>>> 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 refere= nce > >>>>> 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 co= mments, > >>> > >>> I do agree DTS should represent the hardware, but please note that th= e DTS > >>> is no kind of standard, and people always choose what they need and a= dd > >>> 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 n= ot have this > >>> 'vmmc-supply=E2=80=99 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 eye= s and=20 > >> from your specific usecase), but it directly contradicts how the DTS u= sage is intended. > >> > >> In other words: Tom (as the top-level decision maker) or Simon (who ow= ns the=20 > >> device-model and therefore will also have an opinion on DTS usage) sho= uld 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! --=20 Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: