> On 12.12.2018, at 10:05, Kever Yang <kever.y...@rock-chips.com> wrote: > > > > On 12/11/2018 02:20 AM, Tom Rini wrote: >> 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.y...@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.y...@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. > > OK, Got it, 'sync with upstream dts' is a good and acceptable commit > message > rather than the real reason why we need the patch. > > Philipp, > Do you need me to send out a patch with update the commit message?
If you do it, you’ll save me work and the history on the list is 1:1 identical with what I apply … If you absolutely don’t have time, I’ll change the commit message as I process this for my end-of-week pull-request. Thanks, Philipp. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
