Document the Top Level Mode Multiplexer on the Milos Platform.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
.../bindings/pinctrl/qcom,milos-tlmm.yaml | 133 +++++++++++++++++++++
1 file changed, 133 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..0091204df20a0eca7d0d0e766afcb8d08042b015
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,milos-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. Milos TLMM block
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm Milos SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,milos-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 84
+
+ gpio-line-names:
+ maxItems: 167
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-milos-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-milos-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-milos-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-5][0-9]|16[0-7])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, aoss_cti, atest_char, atest_usb, audio_ext_mclk0,
+ audio_ext_mclk1, audio_ref_clk, cam_mclk, cci_async_in0,
+ cci_i2c_scl, cci_i2c_sda, cci_timer, coex_uart1_rx,
+ coex_uart1_tx, dbg_out_clk, ddr_bist_complete, ddr_bist_fail,
+ ddr_bist_start, ddr_bist_stop, ddr_pxi0, ddr_pxi1, dp0_hot,
+ egpio, gcc_gp1, gcc_gp2, gcc_gp3, host2wlan_sol, i2s0_data0,
+ i2s0_data1, i2s0_sck, i2s0_ws, ibi_i3c, jitter_bist, mdp_vsync,
+ mdp_vsync0_out, mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out,
+ mdp_vsync_e, nav_gpio0, nav_gpio1, nav_gpio2, pcie0_clk_req_n,
+ pcie1_clk_req_n, phase_flag, pll_bist_sync, pll_clk_aux,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti,
+ qdss_gpio, qlink0_enable, qlink0_request, qlink0_wmss,
+ qlink1_enable, qlink1_request, qlink1_wmss, qspi0, qup0_se0,
+ qup0_se1, qup0_se2, qup0_se3, qup0_se4, qup0_se5, qup0_se6,
+ qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4, qup1_se5,
+ qup1_se6, resout_gpio_n, sd_write_protect, sdc1_clk, sdc1_cmd,
+ sdc1_data, sdc1_rclk, sdc2_clk, sdc2_cmd, sdc2_data,
+ sdc2_fb_clk, tb_trig_sdc1, tb_trig_sdc2, tgu_ch0_trigout,
+ tgu_ch1_trigout, tmess_prng0, tmess_prng1, tmess_prng2,
+ tmess_prng3, tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data,
+ uim0_present, uim0_reset, uim1_clk_mira, uim1_clk_mirb,
+ uim1_data_mira, uim1_data_mirb, uim1_present_mira,
+ uim1_present_mirb, uim1_reset_mira, uim1_reset_mirb, usb0_hs,
+ usb0_phy_ps, vfr_0, vfr_1, vsense_trigger_mirnat, wcn_sw,
+ wcn_sw_ctrl ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,milos-tlmm";
+ reg = <0x0f100000 0x300000>;
+
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio-ranges = <&tlmm 0 0 168>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ qup-uart5-default-state {
+ pins = "gpio25", "gpio26";
+ function = "qup0_se5";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+...
--
2.50.0On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote:
> Document the Top Level Mode Multiplexer on the Milos Platform.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> .../bindings/pinctrl/qcom,milos-tlmm.yaml | 133 +++++++++++++++++++++
> 1 file changed, 133 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..0091204df20a0eca7d0d0e766afcb8d08042b015
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/qcom,milos-tlmm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies, Inc. Milos TLMM block
> +
> +maintainers:
> + - Luca Weiss <luca.weiss@fairphone.com>
> +
> +description:
> + Top Level Mode Multiplexer pin controller in Qualcomm Milos SoC.
> +
> +allOf:
> + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
> +
> +properties:
> + compatible:
> + const: qcom,milos-tlmm
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + gpio-reserved-ranges:
> + minItems: 1
> + maxItems: 84
> +
> + gpio-line-names:
> + maxItems: 167
> +
> +patternProperties:
> + "-state$":
type: object
Because a boolean "foo-state;" would actually pass without.
With that,
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> + oneOf:
> + - $ref: "#/$defs/qcom-milos-tlmm-state"
> + - patternProperties:
> + "-pins$":
> + $ref: "#/$defs/qcom-milos-tlmm-state"
> + additionalProperties: false
Hi Rob,
On Fri Jul 11, 2025 at 8:22 PM CEST, Rob Herring wrote:
> On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote:
>> Document the Top Level Mode Multiplexer on the Milos Platform.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> .../bindings/pinctrl/qcom,milos-tlmm.yaml | 133 +++++++++++++++++++++
>> 1 file changed, 133 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..0091204df20a0eca7d0d0e766afcb8d08042b015
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
>> @@ -0,0 +1,133 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pinctrl/qcom,milos-tlmm.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm Technologies, Inc. Milos TLMM block
>> +
>> +maintainers:
>> + - Luca Weiss <luca.weiss@fairphone.com>
>> +
>> +description:
>> + Top Level Mode Multiplexer pin controller in Qualcomm Milos SoC.
>> +
>> +allOf:
>> + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: qcom,milos-tlmm
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + gpio-reserved-ranges:
>> + minItems: 1
>> + maxItems: 84
>> +
>> + gpio-line-names:
>> + maxItems: 167
>> +
>> +patternProperties:
>> + "-state$":
>
> type: object
>
> Because a boolean "foo-state;" would actually pass without.
While the patch has been applied already, I'm happy to fix this for all
Qualcomm pinctrl schemas, since pretty much all have this issue.
Are you looking for a change like the following for all
60+ pinctrl/qcom,* schemas?
If that's fine, I will prepare the changes and send them soon. Different
sorting of properties, or moving "type: object" just below "-state$":
would also work, not sure what you prefer.
++++++++++++++
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.yaml
index 38877d8b97ff..1d17abde246b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.yaml
@@ -34,6 +34,7 @@ patternProperties:
- patternProperties:
"-pins$":
$ref: "#/$defs/qcom-apq8084-tlmm-state"
+ type: object
additionalProperties: false
$defs:
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
index 0091204df20a..e277b884bf5c 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
@@ -39,6 +39,7 @@ patternProperties:
- patternProperties:
"-pins$":
$ref: "#/$defs/qcom-milos-tlmm-state"
+ type: object
additionalProperties: false
$defs:
++++++++++++++
Regards
Luca
>
> With that,
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
>
>> + oneOf:
>> + - $ref: "#/$defs/qcom-milos-tlmm-state"
>> + - patternProperties:
>> + "-pins$":
>> + $ref: "#/$defs/qcom-milos-tlmm-state"
>> + additionalProperties: false
On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote: > Document the Top Level Mode Multiplexer on the Milos Platform. What is Milos platform? Does it have some sort of model number how we usually expect? Wasn't this SM7325 or similar? The problem with such new naming that it awfully sounds like family names, so just expand the name and explain it. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > .../bindings/pinctrl/qcom,milos-tlmm.yaml | 133 +++++++++++++++++++++ > 1 file changed, 133 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml > new file mode 100644 > index 0000000000000000000000000000000000000000..0091204df20a0eca7d0d0e766afcb8d08042b015 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml > @@ -0,0 +1,133 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/pinctrl/qcom,milos-tlmm.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm Technologies, Inc. Milos TLMM block > + > +maintainers: > + - Luca Weiss <luca.weiss@fairphone.com> > + > +description: > + Top Level Mode Multiplexer pin controller in Qualcomm Milos SoC. > + > +allOf: > + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# > + > +properties: > + compatible: > + const: qcom,milos-tlmm Before you start adding such 'milos' all over the code, you need to update the rule for compatible naming. I don't know how thus I would not recomment the switch from obvious model number to non-obvious cryptic alias. Best regards, Krzysztof
On Thu Jul 3, 2025 at 9:41 AM CEST, Krzysztof Kozlowski wrote: > On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote: >> Document the Top Level Mode Multiplexer on the Milos Platform. > > What is Milos platform? Does it have some sort of model number how we > usually expect? Wasn't this SM7325 or similar? > > The problem with such new naming that it awfully sounds like family > names, so just expand the name and explain it. Please go argue with Bjorn/Konrad about this, wasn't my idea. https://lore.kernel.org/linux-arm-msm/aGMI1Zv6D+K+vWZL@hu-bjorande-lv.qualcomm.com/ https://lore.kernel.org/linux-arm-msm/b98d305b-247f-415b-8675-50d073452feb@oss.qualcomm.com/ Regards Luca > >> >> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> >> --- >> .../bindings/pinctrl/qcom,milos-tlmm.yaml | 133 +++++++++++++++++++++ >> 1 file changed, 133 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml >> new file mode 100644 >> index 0000000000000000000000000000000000000000..0091204df20a0eca7d0d0e766afcb8d08042b015 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml >> @@ -0,0 +1,133 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/pinctrl/qcom,milos-tlmm.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Qualcomm Technologies, Inc. Milos TLMM block >> + >> +maintainers: >> + - Luca Weiss <luca.weiss@fairphone.com> >> + >> +description: >> + Top Level Mode Multiplexer pin controller in Qualcomm Milos SoC. >> + >> +allOf: >> + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# >> + >> +properties: >> + compatible: >> + const: qcom,milos-tlmm > > Before you start adding such 'milos' all over the code, you need to > update the rule for compatible naming. I don't know how thus I would not > recomment the switch from obvious model number to non-obvious cryptic > alias. > > Best regards, > Krzysztof
On 03/07/2025 09:44, Luca Weiss wrote: > On Thu Jul 3, 2025 at 9:41 AM CEST, Krzysztof Kozlowski wrote: >> On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote: >>> Document the Top Level Mode Multiplexer on the Milos Platform. >> >> What is Milos platform? Does it have some sort of model number how we >> usually expect? Wasn't this SM7325 or similar? >> >> The problem with such new naming that it awfully sounds like family >> names, so just expand the name and explain it. > > Please go argue with Bjorn/Konrad about this, wasn't my idea. > > https://lore.kernel.org/linux-arm-msm/aGMI1Zv6D+K+vWZL@hu-bjorande-lv.qualcomm.com/ > https://lore.kernel.org/linux-arm-msm/b98d305b-247f-415b-8675-50d073452feb@oss.qualcomm.com/ I don't think you got my point. I want it to be explicit in commit msg. Best regards, Krzysztof
On 03-Jul-25 09:44, Luca Weiss wrote: > On Thu Jul 3, 2025 at 9:41 AM CEST, Krzysztof Kozlowski wrote: >> On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote: >>> Document the Top Level Mode Multiplexer on the Milos Platform. >> >> What is Milos platform? Does it have some sort of model number how we >> usually expect? Wasn't this SM7325 or similar? >> >> The problem with such new naming that it awfully sounds like family >> names, so just expand the name and explain it. > > Please go argue with Bjorn/Konrad about this, wasn't my idea. > > https://lore.kernel.org/linux-arm-msm/aGMI1Zv6D+K+vWZL@hu-bjorande-lv.qualcomm.com/ > https://lore.kernel.org/linux-arm-msm/b98d305b-247f-415b-8675-50d073452feb@oss.qualcomm.com/ Milos is the "real-est" name of this silicon. All the associated S[AM]|QC[MS]s are just variations of it, with different fusing. You'll stumble upon it across e.g. firmware build strings, as well as in any documentation pieces. There are various internal reasons for the switch, but the most obvious external-facing one is not to have the user buy a devkit and wonder whether they should use QCS9100 or QCS9075 DTB, and why there's zero drivers code for these magic numbers (they include SA8775P). We can simply point them to "codename" and all C code will refer to it as well. As for external reviewers not knowing what the platform name refers to, this is nothing new - AMD submits colorful fish names and it's broadly accepted practice Konrad
On 03/07/2025 12:04, Konrad Dybcio wrote: > > > On 03-Jul-25 09:44, Luca Weiss wrote: >> On Thu Jul 3, 2025 at 9:41 AM CEST, Krzysztof Kozlowski wrote: >>> On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote: >>>> Document the Top Level Mode Multiplexer on the Milos Platform. >>> >>> What is Milos platform? Does it have some sort of model number how we >>> usually expect? Wasn't this SM7325 or similar? >>> >>> The problem with such new naming that it awfully sounds like family >>> names, so just expand the name and explain it. >> >> Please go argue with Bjorn/Konrad about this, wasn't my idea. >> >> https://lore.kernel.org/linux-arm-msm/aGMI1Zv6D+K+vWZL@hu-bjorande-lv.qualcomm.com/ >> https://lore.kernel.org/linux-arm-msm/b98d305b-247f-415b-8675-50d073452feb@oss.qualcomm.com/ > > Milos is the "real-est" name of this silicon. All the associated > S[AM]|QC[MS]s are just variations of it, with different fusing. > > You'll stumble upon it across e.g. firmware build strings, as > well as in any documentation pieces. > > There are various internal reasons for the switch, but the most > obvious external-facing one is not to have the user buy a devkit > and wonder whether they should use QCS9100 or QCS9075 DTB, and > why there's zero drivers code for these magic numbers (they > include SA8775P). We can simply point them to "codename" and > all C code will refer to it as well. These are different SoCs, optionally with different firmware, so they cannot use the same top-level compatible chain. I hope you did not propose that. For me list like "qcs9100, sa8775p" is clear enough, but if you want "qcs9100, koala-bear" or "brown-bear, koala-bear" it is fine as well. You just cannot use koala-bear for all of them. Best regards, Krzysztof
On Thu, Jul 03, 2025 at 01:26:11PM +0200, Krzysztof Kozlowski wrote: > On 03/07/2025 12:04, Konrad Dybcio wrote: > > > > > > On 03-Jul-25 09:44, Luca Weiss wrote: > >> On Thu Jul 3, 2025 at 9:41 AM CEST, Krzysztof Kozlowski wrote: > >>> On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote: > >>>> Document the Top Level Mode Multiplexer on the Milos Platform. > >>> > >>> What is Milos platform? Does it have some sort of model number how we > >>> usually expect? Wasn't this SM7325 or similar? > >>> Milos is the actual name of the SoC. > >>> The problem with such new naming that it awfully sounds like family > >>> names, so just expand the name and explain it. > >> > >> Please go argue with Bjorn/Konrad about this, wasn't my idea. > >> > >> https://lore.kernel.org/linux-arm-msm/aGMI1Zv6D+K+vWZL@hu-bjorande-lv.qualcomm.com/ > >> https://lore.kernel.org/linux-arm-msm/b98d305b-247f-415b-8675-50d073452feb@oss.qualcomm.com/ > > > > Milos is the "real-est" name of this silicon. All the associated > > S[AM]|QC[MS]s are just variations of it, with different fusing. > > > > You'll stumble upon it across e.g. firmware build strings, as > > well as in any documentation pieces. > > > > There are various internal reasons for the switch, but the most > > obvious external-facing one is not to have the user buy a devkit > > and wonder whether they should use QCS9100 or QCS9075 DTB, and > > why there's zero drivers code for these magic numbers (they > > include SA8775P). We can simply point them to "codename" and > > all C code will refer to it as well. > > These are different SoCs, optionally with different firmware, so they > cannot use the same top-level compatible chain. I hope you did not > propose that. > No they are not different SoCs, and that's the problem with the current naming scheme. > For me list like "qcs9100, sa8775p" is clear enough, but if you want > "qcs9100, koala-bear" or "brown-bear, koala-bear" it is fine as well. > You just cannot use koala-bear for all of them. > It looks "clear enough", but it's wrong. The problem is that sa8775p, qca9100, and qcs9075 are the "same" hardware and firmware. The difference between sa8775p and qcs9100 is the reserved-memory map, the difference between qcs9100 and qcs9075 is one IP block being status = "okay" vs "disabled", due to fuses. It's exactly the same problem we first saw in QRB5165, but we let the problem explode. Now we use the names sc7280, sm7325, qcm6490, and qcs6490 for the same SoC. Using the SoC's actual name here will remove the need for playing games with DT includes etc to try to map things to the current naming scheme. The one case that isn't being taking care of such naming is when there are differences in the firmware. But as can be seen in the "sc7280" familiy, those software differences doesn't align with the chosen names. And even within a given SoC, with a (overall) given firmware, the reserved-memory map ends up differing. So, the name of the SoC in this patch is "Milos". We already have ways of dealing with firmware and/or hardware variations within one SoC, we should use them (and refine them as necessary), rather than pretending that something like SM7325 will define those properties. I don't have any concerns with your request of mentioning SM7325 in the commit messages, for now... Regards, Bjorn > > Best regards, > Krzysztof
On Thu, Jul 03, 2025 at 12:31:46PM -0500, Bjorn Andersson wrote: > On Thu, Jul 03, 2025 at 01:26:11PM +0200, Krzysztof Kozlowski wrote: > > On 03/07/2025 12:04, Konrad Dybcio wrote: > > > > > > > > > On 03-Jul-25 09:44, Luca Weiss wrote: > > >> On Thu Jul 3, 2025 at 9:41 AM CEST, Krzysztof Kozlowski wrote: > > >>> On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote: > > >>>> Document the Top Level Mode Multiplexer on the Milos Platform. > > >>> > > >>> What is Milos platform? Does it have some sort of model number how we > > >>> usually expect? Wasn't this SM7325 or similar? > > >>> > > Milos is the actual name of the SoC. > > > >>> The problem with such new naming that it awfully sounds like family > > >>> names, so just expand the name and explain it. > > >> > > >> Please go argue with Bjorn/Konrad about this, wasn't my idea. > > >> > > >> https://lore.kernel.org/linux-arm-msm/aGMI1Zv6D+K+vWZL@hu-bjorande-lv.qualcomm.com/ > > >> https://lore.kernel.org/linux-arm-msm/b98d305b-247f-415b-8675-50d073452feb@oss.qualcomm.com/ > > > > > > Milos is the "real-est" name of this silicon. All the associated > > > S[AM]|QC[MS]s are just variations of it, with different fusing. > > > > > > You'll stumble upon it across e.g. firmware build strings, as > > > well as in any documentation pieces. > > > > > > There are various internal reasons for the switch, but the most > > > obvious external-facing one is not to have the user buy a devkit > > > and wonder whether they should use QCS9100 or QCS9075 DTB, and > > > why there's zero drivers code for these magic numbers (they > > > include SA8775P). We can simply point them to "codename" and > > > all C code will refer to it as well. > > > > These are different SoCs, optionally with different firmware, so they > > cannot use the same top-level compatible chain. I hope you did not > > propose that. > > > > No they are not different SoCs, and that's the problem with the current > naming scheme. > > > For me list like "qcs9100, sa8775p" is clear enough, but if you want > > "qcs9100, koala-bear" or "brown-bear, koala-bear" it is fine as well. > > You just cannot use koala-bear for all of them. > > > > It looks "clear enough", but it's wrong. The problem is that sa8775p, > qca9100, and qcs9075 are the "same" hardware and firmware. > > The difference between sa8775p and qcs9100 is the reserved-memory map, > the difference between qcs9100 and qcs9075 is one IP block being status > = "okay" vs "disabled", due to fuses. > > It's exactly the same problem we first saw in QRB5165, but we let the > problem explode. Now we use the names sc7280, sm7325, qcm6490, and > qcs6490 for the same SoC. > > Using the SoC's actual name here will remove the need for playing games > with DT includes etc to try to map things to the current naming scheme. > > > The one case that isn't being taking care of such naming is when there > are differences in the firmware. But as can be seen in the "sc7280" > familiy, those software differences doesn't align with the chosen names. > And even within a given SoC, with a (overall) given firmware, the > reserved-memory map ends up differing. > > > So, the name of the SoC in this patch is "Milos". We already have ways > of dealing with firmware and/or hardware variations within one SoC, we > should use them (and refine them as necessary), rather than pretending > that something like SM7325 will define those properties. I for one prefer 1 compatible per die. We often don't know if that's the case, but in this case we do so let's take advantage of it. Rob
On Tue, Jul 08, 2025 at 12:15:15PM -0500, Rob Herring wrote: > On Thu, Jul 03, 2025 at 12:31:46PM -0500, Bjorn Andersson wrote: > > On Thu, Jul 03, 2025 at 01:26:11PM +0200, Krzysztof Kozlowski wrote: > > > On 03/07/2025 12:04, Konrad Dybcio wrote: > > > > > > > > > > > > On 03-Jul-25 09:44, Luca Weiss wrote: > > > >> On Thu Jul 3, 2025 at 9:41 AM CEST, Krzysztof Kozlowski wrote: > > > >>> On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote: > > > >>>> Document the Top Level Mode Multiplexer on the Milos Platform. > > > >>> > > > >>> What is Milos platform? Does it have some sort of model number how we > > > >>> usually expect? Wasn't this SM7325 or similar? > > > >>> > > > > Milos is the actual name of the SoC. > > > > > >>> The problem with such new naming that it awfully sounds like family > > > >>> names, so just expand the name and explain it. > > > >> > > > >> Please go argue with Bjorn/Konrad about this, wasn't my idea. > > > >> > > > >> https://lore.kernel.org/linux-arm-msm/aGMI1Zv6D+K+vWZL@hu-bjorande-lv.qualcomm.com/ > > > >> https://lore.kernel.org/linux-arm-msm/b98d305b-247f-415b-8675-50d073452feb@oss.qualcomm.com/ > > > > > > > > Milos is the "real-est" name of this silicon. All the associated > > > > S[AM]|QC[MS]s are just variations of it, with different fusing. > > > > > > > > You'll stumble upon it across e.g. firmware build strings, as > > > > well as in any documentation pieces. > > > > > > > > There are various internal reasons for the switch, but the most > > > > obvious external-facing one is not to have the user buy a devkit > > > > and wonder whether they should use QCS9100 or QCS9075 DTB, and > > > > why there's zero drivers code for these magic numbers (they > > > > include SA8775P). We can simply point them to "codename" and > > > > all C code will refer to it as well. > > > > > > These are different SoCs, optionally with different firmware, so they > > > cannot use the same top-level compatible chain. I hope you did not > > > propose that. > > > > > > > No they are not different SoCs, and that's the problem with the current > > naming scheme. > > > > > For me list like "qcs9100, sa8775p" is clear enough, but if you want > > > "qcs9100, koala-bear" or "brown-bear, koala-bear" it is fine as well. > > > You just cannot use koala-bear for all of them. > > > > > > > It looks "clear enough", but it's wrong. The problem is that sa8775p, > > qca9100, and qcs9075 are the "same" hardware and firmware. > > > > The difference between sa8775p and qcs9100 is the reserved-memory map, > > the difference between qcs9100 and qcs9075 is one IP block being status > > = "okay" vs "disabled", due to fuses. > > > > It's exactly the same problem we first saw in QRB5165, but we let the > > problem explode. Now we use the names sc7280, sm7325, qcm6490, and > > qcs6490 for the same SoC. > > > > Using the SoC's actual name here will remove the need for playing games > > with DT includes etc to try to map things to the current naming scheme. > > > > > > The one case that isn't being taking care of such naming is when there > > are differences in the firmware. But as can be seen in the "sc7280" > > familiy, those software differences doesn't align with the chosen names. > > And even within a given SoC, with a (overall) given firmware, the > > reserved-memory map ends up differing. > > > > > > So, the name of the SoC in this patch is "Milos". We already have ways > > of dealing with firmware and/or hardware variations within one SoC, we > > should use them (and refine them as necessary), rather than pretending > > that something like SM7325 will define those properties. > > I for one prefer 1 compatible per die. We often don't know if that's > the case, but in this case we do so let's take advantage of it. > I like this definition, and to the best of my knowledge these are all examples of "it's the same die". Regards, Bjorn
© 2016 - 2025 Red Hat, Inc.