From mboxrd@z Thu Jan 1 00:00:00 1970 From: jmcnicol@redhat.com (Jeremy McNicoll) Date: Fri, 23 Sep 2016 16:27:35 -0700 Subject: [RFC 1/4] arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support In-Reply-To: <147456957514.9057.12155171248212777735@sboyd-linaro> References: <1467938467-21607-1-git-send-email-jmcnicol@redhat.com> <1467938467-21607-2-git-send-email-jmcnicol@redhat.com> <20160708174125.GC7896@hector.attlocal.net> <6cf4c215-e8a3-a9db-fcf1-8b56b5c1fab9@redhat.com> <147456957514.9057.12155171248212777735@sboyd-linaro> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2016-09-22 11:39 AM, Stephen Boyd wrote: > Quoting Jeremy McNicoll (2016-09-20 17:42:02) >> On 2016-07-08 10:41 AM, Andy Gross wrote: >>> On Thu, Jul 07, 2016 at 05:41:04PM -0700, Jeremy McNicoll wrote: >>>> + >>>> +#include "../qcom/msm8992.dtsi" >>>> + >>>> +/ { >>>> + model = "LGE MSM8992 BULLHEAD rev-1.01"; >>>> + compatible = "qcom,msm8992"; >>>> + qcom,board-id = <0xb64 0>; >>> >>> Please work with sboyd to add the board-id to the dtbTool. We don't put >>> board-ids in the dts file. We post-process the dtb file and add them then. >>> >> >> sboyd has all the info he needs for this, I believe its just with legal >> now. Will remove for V2. > > I've pushed out an update for dtbtool to have these msm ids. > >> >>>> + >>>> +#include >>>> +#include >>>> + >>>> +/ { >>>> + model = "Qualcomm Technologies, Inc. MSM 8992"; >>>> + compatible = "qcom,msm8992"; >>>> + qcom,msm-id = <251 0>, <252 0>; >> >> This is needed or else the LK provides the following error >> >> [5380] qcom,msm-id entry not found >> >> and refuses to boot. >> >> >>>> + qcom,pmic-id = <0x10009 0x1000A 0x0 0x0>; >>> >>> See above comment on ids. >> >> removal of this (pmic-id) seems to be ok. >> > > Having the msm ids (and the pmic ids) in dtbtool isn't going to help > here though. I believe the bootloader on these devices uses a design of > appended dtbs where each dtb has the qcom,{msm-id,board-id,pmic-id} > properties in them. The QCDT "header" that dtbtool generates is not > used. > > To fix that problem we'll need to update dtbtool to inject these > properties into the dtbs based on the compatible strings. Or get > maintainers to accept that these ids are now necessary for proper > functionality. I will try modifying the tool to inject these values to understand how easy and/or complicated it will be. This topic will be raised during plumbers as most people will be there. > > Furthermore, the value of board-id (0xb64) is concerning. qcom only > supports a certain set of values there for their boards, but vendors are > free to do whatever they want with that value. This means they can reuse > existing values that would map to qcom's concept of the "mtp" or "cdp" > boards, or they can numbers that would alias with other vendors. > Thankfully, msm-id and pmic-id are values that are under qcom's control, > so those are always going to be unique and sane. Really all that could > alias is board-id. > > What does this all mean? We can't support non-qcom boards in the same > boot.img because of the possibility for the board-id property to alias > between different dtbs. Or at least dtbtool will have to do some alias > analysis and eject one aliasing dtbs from the blob. It also means that > we have a lot of work to do in dtbtool to inject these properties based > on strings, and to have custom parsers for different vendor prefixes so > that we know what values to inject (the nightmare is growing). > This provides a reasonably compelling argument that can be discussed with the device tree maintainers during Plumbers. > I've asked the bootloader folks to fix this in future platforms so that > we match based on the compatible string, instead of having to do any > post processing. Basically, put dtbtool logic into the bootloader. The > discussion is still on-going, but I'm hopeful that we don't need to keep > doing things here with post-processing and the headache will be reduced. > That could totally backfire though if vendors decide to leave the > bootloader unchanged and boot the "qcom,msm8992-mtp" dtb that's been > slightly tweaked for their design. Let's hope that doesn't happen. > Thank you for pushing this internally as it will definitely aid in the mainline support going forward. -jeremy