diff mbox series

[3/4] dt-bindings: arm: qcom,ids: Add a bunch of older SoCs

Message ID 20230104115348.25046-4-stephan@gerhold.net (mailing list archive)
State Not Applicable
Headers show
Series soc: qcom: socinfo: Add a bunch of older SoCs | expand

Commit Message

Stephan Gerhold Jan. 4, 2023, 11:53 a.m. UTC
Sync the SoC IDs in qcom,ids.h with relevant entries from Qualcomm's LK
bootloader [1] that is used for almost all older Qualcomm SoCs.

Several of these are already supported, e.g.:
  - MSM8960 -> APQ8060, MSM8260, ...
  - MSM8976 -> APQ8076
  - MSM8956 -> APQ8056
Others are currently being worked on, e.g.:
  - MSM8909(W) -> APQ8009(W), MSM8905, MSM8209, ...
  - MSM8939 -> MSM8239, ...

And even all remaining ones added are close enough to what is already
supported so that future support is realistic (if someone steps up to
do the work).

Add all of them at once to avoid having to add them one by one in the
future. This will also benefit other projects making use of the same
dt-bindings, e.g. bootloaders where adding support for all these SoCs
is a bit easier than on Linux.

[1]: https://git.codelinaro.org/clo/la/kernel/lk/-/blob/9d563e4a1d38c5a662bf94215ffc828db57c9e19/platform/msm_shared/smem.h#L286

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
---
 include/dt-bindings/arm/qcom,ids.h | 74 ++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

Comments

Rob Herring Jan. 8, 2023, 9:40 p.m. UTC | #1
On Wed, Jan 04, 2023 at 12:53:47PM +0100, Stephan Gerhold wrote:
> Sync the SoC IDs in qcom,ids.h with relevant entries from Qualcomm's LK
> bootloader [1] that is used for almost all older Qualcomm SoCs.
> 
> Several of these are already supported, e.g.:
>   - MSM8960 -> APQ8060, MSM8260, ...
>   - MSM8976 -> APQ8076
>   - MSM8956 -> APQ8056
> Others are currently being worked on, e.g.:
>   - MSM8909(W) -> APQ8009(W), MSM8905, MSM8209, ...
>   - MSM8939 -> MSM8239, ...
> 
> And even all remaining ones added are close enough to what is already
> supported so that future support is realistic (if someone steps up to
> do the work).
> 
> Add all of them at once to avoid having to add them one by one in the
> future. This will also benefit other projects making use of the same
> dt-bindings, e.g. bootloaders where adding support for all these SoCs
> is a bit easier than on Linux.

The promise was in accepting the properties upstream is we'd only be 
adding these for bootloaders with dtbs that we can't otherwise update or 
change. Do all of those meet this criteria? Seems unlikely.

Rob
Dmitry Baryshkov Jan. 8, 2023, 10:20 p.m. UTC | #2
On 08/01/2023 23:40, Rob Herring wrote:
> On Wed, Jan 04, 2023 at 12:53:47PM +0100, Stephan Gerhold wrote:
>> Sync the SoC IDs in qcom,ids.h with relevant entries from Qualcomm's LK
>> bootloader [1] that is used for almost all older Qualcomm SoCs.
>>
>> Several of these are already supported, e.g.:
>>    - MSM8960 -> APQ8060, MSM8260, ...
>>    - MSM8976 -> APQ8076
>>    - MSM8956 -> APQ8056
>> Others are currently being worked on, e.g.:
>>    - MSM8909(W) -> APQ8009(W), MSM8905, MSM8209, ...
>>    - MSM8939 -> MSM8239, ...
>>
>> And even all remaining ones added are close enough to what is already
>> supported so that future support is realistic (if someone steps up to
>> do the work).
>>
>> Add all of them at once to avoid having to add them one by one in the
>> future. This will also benefit other projects making use of the same
>> dt-bindings, e.g. bootloaders where adding support for all these SoCs
>> is a bit easier than on Linux.
> 
> The promise was in accepting the properties upstream is we'd only be
> adding these for bootloaders with dtbs that we can't otherwise update or
> change. Do all of those meet this criteria? Seems unlikely.


Most of Qualcomm platforms come with the signed bootloader, so it is 
impossible to change it without vendor keys. This might sound bad for 
you, but I fear that this list would include most of the platforms until 
Qualcomm agrees to rework kernel-bootloader-dtb interaction.
Stephan Gerhold Jan. 9, 2023, 8:43 a.m. UTC | #3
On Sun, Jan 08, 2023 at 03:40:52PM -0600, Rob Herring wrote:
> On Wed, Jan 04, 2023 at 12:53:47PM +0100, Stephan Gerhold wrote:
> > Sync the SoC IDs in qcom,ids.h with relevant entries from Qualcomm's LK
> > bootloader [1] that is used for almost all older Qualcomm SoCs.
> > 
> > Several of these are already supported, e.g.:
> >   - MSM8960 -> APQ8060, MSM8260, ...
> >   - MSM8976 -> APQ8076
> >   - MSM8956 -> APQ8056
> > Others are currently being worked on, e.g.:
> >   - MSM8909(W) -> APQ8009(W), MSM8905, MSM8209, ...
> >   - MSM8939 -> MSM8239, ...
> > 
> > And even all remaining ones added are close enough to what is already
> > supported so that future support is realistic (if someone steps up to
> > do the work).
> > 
> > Add all of them at once to avoid having to add them one by one in the
> > future. This will also benefit other projects making use of the same
> > dt-bindings, e.g. bootloaders where adding support for all these SoCs
> > is a bit easier than on Linux.
> 
> The promise was in accepting the properties upstream is we'd only be 
> adding these for bootloaders with dtbs that we can't otherwise update or 
> change.

qcom,ids.h contains all the SoC IDs, even ones not meant to be used in
the deprecated "qcom,msm-id" property. This is because it is also used
in the socinfo driver for example (that I'm also editing in this
series).

The actual allowlist for the "qcom,msm-id"/"qcom,board-id" is in
Documentation/devicetree/bindings/arm/qcom.yaml and is unchanged by this
patch series.

Still:

>
> Do all of those meet this criteria? Seems unlikely.
> 

All platforms added in this patch are older ones that do indeed require
the "qcom,msm-id"/"qcom,board-id" properties - except for the really
ancient ones that are still using ATAGS for booting.

However, there is no need to extend the allowlist to all these
platforms. We're circumventing the limitations of the Qualcomm
bootloader by "chainloading" another bootloader without those quirks
(right now mainly a modified version of Qualcomm's original bootloader,
but U-Boot also works on some of these platforms). That is why the
deprecated properties do not need to be present in the Linux DT.

Thanks,
Stephan
Stephan Gerhold Jan. 9, 2023, 9:39 a.m. UTC | #4
On Mon, Jan 09, 2023 at 12:20:55AM +0200, Dmitry Baryshkov wrote:
> On 08/01/2023 23:40, Rob Herring wrote:
> > On Wed, Jan 04, 2023 at 12:53:47PM +0100, Stephan Gerhold wrote:
> > > Sync the SoC IDs in qcom,ids.h with relevant entries from Qualcomm's LK
> > > bootloader [1] that is used for almost all older Qualcomm SoCs.
> > > 
> > > Several of these are already supported, e.g.:
> > >    - MSM8960 -> APQ8060, MSM8260, ...
> > >    - MSM8976 -> APQ8076
> > >    - MSM8956 -> APQ8056
> > > Others are currently being worked on, e.g.:
> > >    - MSM8909(W) -> APQ8009(W), MSM8905, MSM8209, ...
> > >    - MSM8939 -> MSM8239, ...
> > > 
> > > And even all remaining ones added are close enough to what is already
> > > supported so that future support is realistic (if someone steps up to
> > > do the work).
> > > 
> > > Add all of them at once to avoid having to add them one by one in the
> > > future. This will also benefit other projects making use of the same
> > > dt-bindings, e.g. bootloaders where adding support for all these SoCs
> > > is a bit easier than on Linux.
> > 
> > The promise was in accepting the properties upstream is we'd only be
> > adding these for bootloaders with dtbs that we can't otherwise update or
> > change. Do all of those meet this criteria? Seems unlikely.
> 
> 
> Most of Qualcomm platforms come with the signed bootloader, so it is
> impossible to change it without vendor keys. This might sound bad for you,
> but I fear that this list would include most of the platforms until Qualcomm
> agrees to rework kernel-bootloader-dtb interaction.
> 

There is no need to replace the signed bootloader to avoid these quirks.
The bootloader does not care if it is booting Linux directly or another
OS, so you can just package a less broken bootloader into an Android
boot image and "chainload" it before booting Linux.

This is fairly simple to do for the older platforms that are still using
LK as bootloader, but more complicated for the UEFI platforms since a
fully open-source bootloader is not available there.

For the older platforms I'm working on (mainly MSM8916 and similar) this
approach has proven to be extremely beneficial. I have seen all sorts of
vendor-specific bootloader quirks that go way beyond just requiring a
non-standard property in the DT. Some of them require almost the entire
downstream DT because they use information from it to initialize the
display shortly before booting Linux. Others make random modifications
to the DT that would cause trouble for mainline Linux.

lk2nd [1] covers all relevant LK platforms. IMO investing the time to
get e.g. U-Boot running for newer platforms would be well worth the
effort, especially because it can cut many discussions short.

For example, lk2nd has working display panel selection (by setting the
correct panel compatible in the Linux DT). AFAIU this is still unsolved
for all newer platforms because Qualcomm still passes this in some weird
cmdline format to the kernel (mdss_mdp.panel=, msm_drm.dsi_display0=, ...)

Thanks,
Stephan

[1]: https://github.com/msm8916-mainline/lk2nd
Bjorn Andersson Jan. 11, 2023, 7:42 p.m. UTC | #5
On Sun, Jan 08, 2023 at 03:40:52PM -0600, Rob Herring wrote:
> On Wed, Jan 04, 2023 at 12:53:47PM +0100, Stephan Gerhold wrote:
> > Sync the SoC IDs in qcom,ids.h with relevant entries from Qualcomm's LK
> > bootloader [1] that is used for almost all older Qualcomm SoCs.
> > 
> > Several of these are already supported, e.g.:
> >   - MSM8960 -> APQ8060, MSM8260, ...
> >   - MSM8976 -> APQ8076
> >   - MSM8956 -> APQ8056
> > Others are currently being worked on, e.g.:
> >   - MSM8909(W) -> APQ8009(W), MSM8905, MSM8209, ...
> >   - MSM8939 -> MSM8239, ...
> > 
> > And even all remaining ones added are close enough to what is already
> > supported so that future support is realistic (if someone steps up to
> > do the work).
> > 
> > Add all of them at once to avoid having to add them one by one in the
> > future. This will also benefit other projects making use of the same
> > dt-bindings, e.g. bootloaders where adding support for all these SoCs
> > is a bit easier than on Linux.
> 
> The promise was in accepting the properties upstream is we'd only be 
> adding these for bootloaders with dtbs that we can't otherwise update or 
> change. Do all of those meet this criteria? Seems unlikely.
> 

Independent of the question about qcom,msm-id and qcom,board-id, I would
like these constants for the socinfo driver (as shown in patch 4).

Would you prefer that we keep a separate list in Linux?

Thanks,
Bjorn
Rob Herring Jan. 12, 2023, 9:08 p.m. UTC | #6
On Wed, Jan 11, 2023 at 01:42:15PM -0600, Bjorn Andersson wrote:
> On Sun, Jan 08, 2023 at 03:40:52PM -0600, Rob Herring wrote:
> > On Wed, Jan 04, 2023 at 12:53:47PM +0100, Stephan Gerhold wrote:
> > > Sync the SoC IDs in qcom,ids.h with relevant entries from Qualcomm's LK
> > > bootloader [1] that is used for almost all older Qualcomm SoCs.
> > > 
> > > Several of these are already supported, e.g.:
> > >   - MSM8960 -> APQ8060, MSM8260, ...
> > >   - MSM8976 -> APQ8076
> > >   - MSM8956 -> APQ8056
> > > Others are currently being worked on, e.g.:
> > >   - MSM8909(W) -> APQ8009(W), MSM8905, MSM8209, ...
> > >   - MSM8939 -> MSM8239, ...
> > > 
> > > And even all remaining ones added are close enough to what is already
> > > supported so that future support is realistic (if someone steps up to
> > > do the work).
> > > 
> > > Add all of them at once to avoid having to add them one by one in the
> > > future. This will also benefit other projects making use of the same
> > > dt-bindings, e.g. bootloaders where adding support for all these SoCs
> > > is a bit easier than on Linux.
> > 
> > The promise was in accepting the properties upstream is we'd only be 
> > adding these for bootloaders with dtbs that we can't otherwise update or 
> > change. Do all of those meet this criteria? Seems unlikely.
> > 
> 
> Independent of the question about qcom,msm-id and qcom,board-id, I would
> like these constants for the socinfo driver (as shown in patch 4).
> 
> Would you prefer that we keep a separate list in Linux?

No, its fine given there's more than one use and the schema only allows 
the properties on certain SoCs already.

Acked-by: Rob Herring <robh@kernel.org>
diff mbox series

Patch

diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h
index 18746bd3e595..22d7ba17804b 100644
--- a/include/dt-bindings/arm/qcom,ids.h
+++ b/include/dt-bindings/arm/qcom,ids.h
@@ -11,36 +11,62 @@ 
  * The MSM chipset and hardware revision used by Qualcomm bootloaders, DTS for
  * older chipsets (qcom,msm-id) and in socinfo driver:
  */
+#define QCOM_ID_MSM8260			70
+#define QCOM_ID_MSM8660			71
+#define QCOM_ID_APQ8060			86
 #define QCOM_ID_MSM8960			87
 #define QCOM_ID_APQ8064			109
+#define QCOM_ID_MSM8930			116
+#define QCOM_ID_MSM8630			117
+#define QCOM_ID_MSM8230			118
+#define QCOM_ID_APQ8030			119
+#define QCOM_ID_MSM8627			120
+#define QCOM_ID_MSM8227			121
 #define QCOM_ID_MSM8660A		122
 #define QCOM_ID_MSM8260A		123
 #define QCOM_ID_APQ8060A		124
 #define QCOM_ID_MSM8974			126
+#define QCOM_ID_MSM8225			127
+#define QCOM_ID_MSM8625			129
 #define QCOM_ID_MPQ8064			130
 #define QCOM_ID_MSM8960AB		138
 #define QCOM_ID_APQ8060AB		139
 #define QCOM_ID_MSM8260AB		140
 #define QCOM_ID_MSM8660AB		141
+#define QCOM_ID_MSM8930AA		142
+#define QCOM_ID_MSM8630AA		143
+#define QCOM_ID_MSM8230AA		144
 #define QCOM_ID_MSM8626			145
 #define QCOM_ID_MSM8610			147
 #define QCOM_ID_APQ8064AB		153
+#define QCOM_ID_MSM8930AB		154
+#define QCOM_ID_MSM8630AB		155
+#define QCOM_ID_MSM8230AB		156
+#define QCOM_ID_APQ8030AB		157
 #define QCOM_ID_MSM8226			158
 #define QCOM_ID_MSM8526			159
+#define QCOM_ID_APQ8030AA		160
 #define QCOM_ID_MSM8110			161
 #define QCOM_ID_MSM8210			162
 #define QCOM_ID_MSM8810			163
 #define QCOM_ID_MSM8212			164
 #define QCOM_ID_MSM8612			165
 #define QCOM_ID_MSM8112			166
+#define QCOM_ID_MSM8125			167
 #define QCOM_ID_MSM8225Q		168
 #define QCOM_ID_MSM8625Q		169
 #define QCOM_ID_MSM8125Q		170
 #define QCOM_ID_APQ8064AA		172
 #define QCOM_ID_APQ8084			178
+#define QCOM_ID_MSM8130			179
+#define QCOM_ID_MSM8130AA		180
+#define QCOM_ID_MSM8130AB		181
+#define QCOM_ID_MSM8627AA		182
+#define QCOM_ID_MSM8227AA		183
 #define QCOM_ID_APQ8074			184
 #define QCOM_ID_MSM8274			185
 #define QCOM_ID_MSM8674			186
+#define QCOM_ID_MDM9635			187
 #define QCOM_ID_MSM8974PRO_AC		194
 #define QCOM_ID_MSM8126			198
 #define QCOM_ID_APQ8026			199
@@ -68,34 +94,72 @@ 
 #define QCOM_ID_MSM8510			225
 #define QCOM_ID_MSM8512			226
 #define QCOM_ID_MSM8936			233
+#define QCOM_ID_MDM9640			234
 #define QCOM_ID_MSM8939			239
 #define QCOM_ID_APQ8036			240
 #define QCOM_ID_APQ8039			241
+#define QCOM_ID_MSM8236			242
+#define QCOM_ID_MSM8636			243
+#define QCOM_ID_MSM8909			245
 #define QCOM_ID_MSM8996			246
 #define QCOM_ID_APQ8016			247
 #define QCOM_ID_MSM8216			248
 #define QCOM_ID_MSM8116			249
 #define QCOM_ID_MSM8616			250
 #define QCOM_ID_MSM8992			251
+#define QCOM_ID_APQ8092			252
 #define QCOM_ID_APQ8094			253
+#define QCOM_ID_MSM8209			258
+#define QCOM_ID_MSM8208			259
+#define QCOM_ID_MDM9209			260
+#define QCOM_ID_MDM9309			261
+#define QCOM_ID_MDM9609			262
+#define QCOM_ID_MSM8239			263
+#define QCOM_ID_MSM8952			264
+#define QCOM_ID_APQ8009			265
 #define QCOM_ID_MSM8956			266
+#define QCOM_ID_MSM8929			268
+#define QCOM_ID_MSM8629			269
+#define QCOM_ID_MSM8229			270
+#define QCOM_ID_APQ8029			271
+#define QCOM_ID_APQ8056			274
+#define QCOM_ID_MSM8609			275
+#define QCOM_ID_APQ8076			277
 #define QCOM_ID_MSM8976			278
+#define QCOM_ID_MDM9650			279
+#define QCOM_ID_MDM9655			283
+#define QCOM_ID_MDM9250			284
+#define QCOM_ID_MDM9255			285
+#define QCOM_ID_MDM9350			286
+#define QCOM_ID_APQ8052			289
 #define QCOM_ID_MDM9607			290
 #define QCOM_ID_APQ8096			291
 #define QCOM_ID_MSM8998			292
 #define QCOM_ID_MSM8953			293
+#define QCOM_ID_MSM8937			294
+#define QCOM_ID_APQ8037			295
 #define QCOM_ID_MDM8207			296
 #define QCOM_ID_MDM9207			297
 #define QCOM_ID_MDM9307			298
 #define QCOM_ID_MDM9628			299
+#define QCOM_ID_MSM8909W		300
+#define QCOM_ID_APQ8009W		301
+#define QCOM_ID_MSM8996L		302
+#define QCOM_ID_MSM8917			303
 #define QCOM_ID_APQ8053			304
 #define QCOM_ID_MSM8996SG		305
+#define QCOM_ID_APQ8017			307
+#define QCOM_ID_MSM8217			308
+#define QCOM_ID_MSM8617			309
 #define QCOM_ID_MSM8996AU		310
 #define QCOM_ID_APQ8096AU		311
 #define QCOM_ID_APQ8096SG		312
+#define QCOM_ID_MSM8940			313
+#define QCOM_ID_SDX201			314
 #define QCOM_ID_SDM660			317
 #define QCOM_ID_SDM630			318
 #define QCOM_ID_APQ8098			319
+#define QCOM_ID_MSM8920			320
 #define QCOM_ID_SDM845			321
 #define QCOM_ID_MDM9206			322
 #define QCOM_ID_IPQ8074			323
@@ -103,6 +167,8 @@ 
 #define QCOM_ID_SDM658			325
 #define QCOM_ID_SDA658			326
 #define QCOM_ID_SDA630			327
+#define QCOM_ID_MSM8905			331
+#define QCOM_ID_SDX202			333
 #define QCOM_ID_SDM450			338
 #define QCOM_ID_SM8150			339
 #define QCOM_ID_SDA845			341
@@ -114,10 +180,15 @@ 
 #define QCOM_ID_SDM632			349
 #define QCOM_ID_SDA632			350
 #define QCOM_ID_SDA450			351
+#define QCOM_ID_SDM439			353
+#define QCOM_ID_SDM429			354
 #define QCOM_ID_SM8250			356
 #define QCOM_ID_SA8155			362
+#define QCOM_ID_SDA439			363
+#define QCOM_ID_SDA429			364
 #define QCOM_ID_IPQ8070			375
 #define QCOM_ID_IPQ8071			376
+#define QCOM_ID_QM215			386
 #define QCOM_ID_IPQ8072A		389
 #define QCOM_ID_IPQ8074A		390
 #define QCOM_ID_IPQ8076A		391
@@ -127,11 +198,14 @@ 
 #define QCOM_ID_IPQ8071A		396
 #define QCOM_ID_IPQ6018			402
 #define QCOM_ID_IPQ6028			403
+#define QCOM_ID_SDM429W			416
 #define QCOM_ID_SM4250			417
 #define QCOM_ID_IPQ6000			421
 #define QCOM_ID_IPQ6010			422
 #define QCOM_ID_SC7180			425
 #define QCOM_ID_SM6350			434
+#define QCOM_ID_QCM2150			436
+#define QCOM_ID_SDA429W			437
 #define QCOM_ID_SM8350			439
 #define QCOM_ID_SM6115			444
 #define QCOM_ID_SC8280XP		449