| Message ID | 20230104115348.25046-4-stephan@gerhold.net |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | soc: qcom: socinfo: Add a bunch of older SoCs | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | warning | total: 0 errors, 1 warnings, 171 lines checked |
| robh/patch-applied | success |
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
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.
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
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
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
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 --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
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(+)