[PATCH 0/2] pinctrl: qcom: Add Mahua TLMM support

[PATCH 0/2] pinctrl: qcom: Add Mahua TLMM support

[Gopikrishna Garmidi]

Introduce Top Level Mode Multiplexer support for Mahua, a 12-core
variant of Qualcomm's Glymur compute SoC.

Mahua shares the same pin configuration and GPIO layout as Glymur 
but requires different PDC (Power Domain Controller) wake IRQ
mappings for proper wake-up functionality.

Changes:
- Add DeviceTree bindings for Mahua SoC TLMM block
- Add mahua_pdc_map[] with Mahua-specific GPIO to PDC IRQ mappings
- Add mahua tlmm soc data
- Enable probe time config selection based on the compatible string

Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
Gopikrishna Garmidi (2):
      dt-bindings: pinctrl: Add Mahua TLMM support
      pinctrl: qcom: glymur: Add Mahua TLMM support

 .../bindings/pinctrl/qcom,glymur-tlmm.yaml         |  6 ++-
 drivers/pinctrl/qcom/pinctrl-glymur.c              | 43 ++++++++++++++++++++--
 2 files changed, 44 insertions(+), 5 deletions(-)
---
base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8
change-id: 20260102-pinctrl-qcom-mahua-tlmm-433644bae64c

Best regards,
-- 
Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>

[PATCH 1/2] dt-bindings: pinctrl: Add Mahua TLMM support

[Gopikrishna Garmidi]

Update the compatible property to accept both "qcom,glymur-tlmm" and
"qcom,mahua-tlmm" using enum to allow proper device tree validation
for both SoCs.

Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml
index d2b0cfeffb50..2836a1a10579 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml
@@ -10,14 +10,16 @@ maintainers:
   - Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
 
 description:
-  Top Level Mode Multiplexer pin controller in Qualcomm Glymur SoC.
+  Top Level Mode Multiplexer pin controller in Qualcomm Glymur and Mahua SoC.
 
 allOf:
   - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
 
 properties:
   compatible:
-    const: qcom,glymur-tlmm
+    enum:
+      - qcom,glymur-tlmm
+      - qcom,mahua-tlmm
 
   reg:
     maxItems: 1

-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: pinctrl: Add Mahua TLMM support

[Krzysztof Kozlowski]

On 02/01/2026 12:07, Gopikrishna Garmidi wrote:
> Update the compatible property to accept both "qcom,glymur-tlmm" and
> "qcom,mahua-tlmm" using enum to allow proper device tree validation
> for both SoCs.

1. Why? You explained what, with a lot of redundant words. I do not find
"paid by commit line" useful. Drop all the redundancies, do not explain
what is "device tree validation". Look at other commits to learn how
this is supposed to be written.

2. Why they are not compatible? You have entire commit msg to say
something useful instead stating obvious and repeating the diff.

3. Subject: You cannot add "support" in the binding. Again, look at
other commits.


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: pinctrl: Add Mahua TLMM support

[Krzysztof Kozlowski]

On 02/01/2026 12:10, Krzysztof Kozlowski wrote:
> On 02/01/2026 12:07, Gopikrishna Garmidi wrote:
>> Update the compatible property to accept both "qcom,glymur-tlmm" and
>> "qcom,mahua-tlmm" using enum to allow proper device tree validation
>> for both SoCs.
> 
> 1. Why? You explained what, with a lot of redundant words. I do not find
> "paid by commit line" useful. Drop all the redundancies, do not explain
> what is "device tree validation". Look at other commits to learn how
> this is supposed to be written.
> 
> 2. Why they are not compatible? You have entire commit msg to say
> something useful instead stating obvious and repeating the diff.
> 
> 3. Subject: You cannot add "support" in the binding. Again, look at
> other commits.


AND I give you this feedback 4 minutes AFTER you sent your patches, so
you can stop now and fix the same issues for all your future and your
team's future Mahua patches.

Best regards,
Krzysztof

[PATCH 2/2] pinctrl: qcom: glymur: Add Mahua TLMM support

[Gopikrishna Garmidi]

Introduce support for the Mahua TLMM (Top Level Mode Multiplexer)
in the pinctrl-glymur driver. Mahua shares the same pin configuration
as Glymur but requires a different PDC wake IRQ mapping.

Changes include:
- Add mahua_pdc_map[] with Mahua-specific GPIO to PDC IRQ mappings
- Define mahua_tlmm msm_pinctrl_soc_data structure
- Update device match table to include "qcom,mahua-tlmm" compatible
- Modify probe function to use of_device_get_match_data() for dynamic
  SoC-specific data selection

Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
 drivers/pinctrl/qcom/pinctrl-glymur.c | 43 ++++++++++++++++++++++++++++++++---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-glymur.c b/drivers/pinctrl/qcom/pinctrl-glymur.c
index 335005084b6b..bf56a064d09c 100644
--- a/drivers/pinctrl/qcom/pinctrl-glymur.c
+++ b/drivers/pinctrl/qcom/pinctrl-glymur.c
@@ -1729,6 +1729,25 @@ static const struct msm_gpio_wakeirq_map glymur_pdc_map[] = {
 	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
 };
 
+static const struct msm_gpio_wakeirq_map mahua_pdc_map[] = {
+	{ 0, 116 },   { 2, 114 },   { 3, 115 },	  { 4, 175 },	{ 5, 176 },
+	{ 7, 111 },   { 11, 129 },  { 13, 130 },  { 15, 112 },	{ 19, 113 },
+	{ 23, 187 },  { 27, 188 },  { 28, 121 },  { 29, 122 },	{ 30, 136 },
+	{ 31, 203 },  { 32, 189 },  { 34, 174 },  { 35, 190 },	{ 36, 191 },
+	{ 39, 124 },  { 43, 192 },  { 47, 193 },  { 51, 123 },	{ 53, 133 },
+	{ 55, 125 },  { 59, 131 },  { 64, 134 },  { 65, 150 },	{ 66, 186 },
+	{ 67, 132 },  { 68, 195 },  { 71, 135 },  { 75, 196 },	{ 79, 197 },
+	{ 83, 198 },  { 84, 181 },  { 85, 199 },  { 87, 200 },	{ 91, 201 },
+	{ 92, 182 },  { 93, 183 },  { 94, 184 },  { 95, 185 },	{ 98, 202 },
+	{ 105, 157 }, { 113, 128 }, { 121, 117 }, { 123, 118 }, { 125, 119 },
+	{ 129, 120 }, { 131, 126 }, { 132, 160 }, { 133, 194 }, { 134, 127 },
+	{ 141, 137 }, { 144, 138 }, { 145, 139 }, { 147, 140 }, { 148, 141 },
+	{ 150, 146 }, { 151, 147 }, { 153, 148 }, { 154, 144 }, { 155, 159 },
+	{ 156, 149 }, { 157, 151 }, { 163, 142 }, { 172, 143 }, { 181, 145 },
+	{ 193, 161 }, { 196, 152 }, { 203, 177 }, { 208, 178 }, { 215, 162 },
+	{ 217, 153 }, { 220, 154 }, { 221, 155 }, { 228, 179 }, { 230, 180 },
+	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
+};
 static const struct msm_pinctrl_soc_data glymur_tlmm = {
 	.pins = glymur_pins,
 	.npins = ARRAY_SIZE(glymur_pins),
@@ -1742,14 +1761,32 @@ static const struct msm_pinctrl_soc_data glymur_tlmm = {
 	.egpio_func = 11,
 };
 
+static const struct msm_pinctrl_soc_data mahua_tlmm = {
+	.pins = glymur_pins,
+	.npins = ARRAY_SIZE(glymur_pins),
+	.functions = glymur_functions,
+	.nfunctions = ARRAY_SIZE(glymur_functions),
+	.groups = glymur_groups,
+	.ngroups = ARRAY_SIZE(glymur_groups),
+	.ngpios = 251,
+	.wakeirq_map = mahua_pdc_map,
+	.nwakeirq_map = ARRAY_SIZE(mahua_pdc_map),
+	.egpio_func = 11,
+};
 static const struct of_device_id glymur_tlmm_of_match[] = {
-	{ .compatible = "qcom,glymur-tlmm", },
-	{ }
+	{ .compatible = "qcom,glymur-tlmm", .data = &glymur_tlmm },
+	{ .compatible = "qcom,mahua-tlmm", .data = &mahua_tlmm },
+	{ },
 };
 
 static int glymur_tlmm_probe(struct platform_device *pdev)
 {
-	return msm_pinctrl_probe(pdev, &glymur_tlmm);
+	const struct msm_pinctrl_soc_data *data;
+
+	data = of_device_get_match_data(&pdev->dev);
+	if (!data)
+		return -ENODEV;
+	return msm_pinctrl_probe(pdev, data);
 }
 
 static struct platform_driver glymur_tlmm_driver = {

-- 
2.34.1

Re: [PATCH 2/2] pinctrl: qcom: glymur: Add Mahua TLMM support

[Konrad Dybcio]

On 1/2/26 12:07 PM, Gopikrishna Garmidi wrote:
> Introduce support for the Mahua TLMM (Top Level Mode Multiplexer)
> in the pinctrl-glymur driver. Mahua shares the same pin configuration
> as Glymur but requires a different PDC wake IRQ mapping.
> 
> Changes include:
> - Add mahua_pdc_map[] with Mahua-specific GPIO to PDC IRQ mappings
> - Define mahua_tlmm msm_pinctrl_soc_data structure
> - Update device match table to include "qcom,mahua-tlmm" compatible
> - Modify probe function to use of_device_get_match_data() for dynamic
>   SoC-specific data selection
> 
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
>  drivers/pinctrl/qcom/pinctrl-glymur.c | 43 ++++++++++++++++++++++++++++++++---
>  1 file changed, 40 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-glymur.c b/drivers/pinctrl/qcom/pinctrl-glymur.c
> index 335005084b6b..bf56a064d09c 100644
> --- a/drivers/pinctrl/qcom/pinctrl-glymur.c
> +++ b/drivers/pinctrl/qcom/pinctrl-glymur.c
> @@ -1729,6 +1729,25 @@ static const struct msm_gpio_wakeirq_map glymur_pdc_map[] = {
>  	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
>  };
>  
> +static const struct msm_gpio_wakeirq_map mahua_pdc_map[] = {
> +	{ 0, 116 },   { 2, 114 },   { 3, 115 },	  { 4, 175 },	{ 5, 176 },
> +	{ 7, 111 },   { 11, 129 },  { 13, 130 },  { 15, 112 },	{ 19, 113 },
> +	{ 23, 187 },  { 27, 188 },  { 28, 121 },  { 29, 122 },	{ 30, 136 },
> +	{ 31, 203 },  { 32, 189 },  { 34, 174 },  { 35, 190 },	{ 36, 191 },
> +	{ 39, 124 },  { 43, 192 },  { 47, 193 },  { 51, 123 },	{ 53, 133 },
> +	{ 55, 125 },  { 59, 131 },  { 64, 134 },  { 65, 150 },	{ 66, 186 },
> +	{ 67, 132 },  { 68, 195 },  { 71, 135 },  { 75, 196 },	{ 79, 197 },
> +	{ 83, 198 },  { 84, 181 },  { 85, 199 },  { 87, 200 },	{ 91, 201 },
> +	{ 92, 182 },  { 93, 183 },  { 94, 184 },  { 95, 185 },	{ 98, 202 },
> +	{ 105, 157 }, { 113, 128 }, { 121, 117 }, { 123, 118 }, { 125, 119 },
> +	{ 129, 120 }, { 131, 126 }, { 132, 160 }, { 133, 194 }, { 134, 127 },
> +	{ 141, 137 }, { 144, 138 }, { 145, 139 }, { 147, 140 }, { 148, 141 },
> +	{ 150, 146 }, { 151, 147 }, { 153, 148 }, { 154, 144 }, { 155, 159 },
> +	{ 156, 149 }, { 157, 151 }, { 163, 142 }, { 172, 143 }, { 181, 145 },
> +	{ 193, 161 }, { 196, 152 }, { 203, 177 }, { 208, 178 }, { 215, 162 },
> +	{ 217, 153 }, { 220, 154 }, { 221, 155 }, { 228, 179 }, { 230, 180 },
> +	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },

Over the "common" base, Glymur has GPIO143 (PCIE3a_RST) and Mahua has GPIO155
(PCIE3b_RST). Both SoCs GPIO maps seem to contain both, but Mahua has a _unused
suffix for the missing 143, which makes sense given the bus isn't bifurcated
there.

The _RST (PERST#) pin is driven by the SoC so I don't think it's useful to
have it as a wakeup source, unless someone decides to connect something that's
not PCIe to it (+Mani)

Perhaps we could unify these maps?

Konrad

Re: [PATCH 2/2] pinctrl: qcom: glymur: Add Mahua TLMM support

[Manivannan Sadhasivam]

On Fri, Jan 02, 2026 at 01:40:22PM +0100, Konrad Dybcio wrote:
> On 1/2/26 12:07 PM, Gopikrishna Garmidi wrote:
> > Introduce support for the Mahua TLMM (Top Level Mode Multiplexer)
> > in the pinctrl-glymur driver. Mahua shares the same pin configuration
> > as Glymur but requires a different PDC wake IRQ mapping.
> > 
> > Changes include:
> > - Add mahua_pdc_map[] with Mahua-specific GPIO to PDC IRQ mappings
> > - Define mahua_tlmm msm_pinctrl_soc_data structure
> > - Update device match table to include "qcom,mahua-tlmm" compatible
> > - Modify probe function to use of_device_get_match_data() for dynamic
> >   SoC-specific data selection
> > 
> > Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> > ---
> >  drivers/pinctrl/qcom/pinctrl-glymur.c | 43 ++++++++++++++++++++++++++++++++---
> >  1 file changed, 40 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/qcom/pinctrl-glymur.c b/drivers/pinctrl/qcom/pinctrl-glymur.c
> > index 335005084b6b..bf56a064d09c 100644
> > --- a/drivers/pinctrl/qcom/pinctrl-glymur.c
> > +++ b/drivers/pinctrl/qcom/pinctrl-glymur.c
> > @@ -1729,6 +1729,25 @@ static const struct msm_gpio_wakeirq_map glymur_pdc_map[] = {
> >  	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
> >  };
> >  
> > +static const struct msm_gpio_wakeirq_map mahua_pdc_map[] = {
> > +	{ 0, 116 },   { 2, 114 },   { 3, 115 },	  { 4, 175 },	{ 5, 176 },
> > +	{ 7, 111 },   { 11, 129 },  { 13, 130 },  { 15, 112 },	{ 19, 113 },
> > +	{ 23, 187 },  { 27, 188 },  { 28, 121 },  { 29, 122 },	{ 30, 136 },
> > +	{ 31, 203 },  { 32, 189 },  { 34, 174 },  { 35, 190 },	{ 36, 191 },
> > +	{ 39, 124 },  { 43, 192 },  { 47, 193 },  { 51, 123 },	{ 53, 133 },
> > +	{ 55, 125 },  { 59, 131 },  { 64, 134 },  { 65, 150 },	{ 66, 186 },
> > +	{ 67, 132 },  { 68, 195 },  { 71, 135 },  { 75, 196 },	{ 79, 197 },
> > +	{ 83, 198 },  { 84, 181 },  { 85, 199 },  { 87, 200 },	{ 91, 201 },
> > +	{ 92, 182 },  { 93, 183 },  { 94, 184 },  { 95, 185 },	{ 98, 202 },
> > +	{ 105, 157 }, { 113, 128 }, { 121, 117 }, { 123, 118 }, { 125, 119 },
> > +	{ 129, 120 }, { 131, 126 }, { 132, 160 }, { 133, 194 }, { 134, 127 },
> > +	{ 141, 137 }, { 144, 138 }, { 145, 139 }, { 147, 140 }, { 148, 141 },
> > +	{ 150, 146 }, { 151, 147 }, { 153, 148 }, { 154, 144 }, { 155, 159 },
> > +	{ 156, 149 }, { 157, 151 }, { 163, 142 }, { 172, 143 }, { 181, 145 },
> > +	{ 193, 161 }, { 196, 152 }, { 203, 177 }, { 208, 178 }, { 215, 162 },
> > +	{ 217, 153 }, { 220, 154 }, { 221, 155 }, { 228, 179 }, { 230, 180 },
> > +	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
> 
> Over the "common" base, Glymur has GPIO143 (PCIE3a_RST) and Mahua has GPIO155
> (PCIE3b_RST). Both SoCs GPIO maps seem to contain both, but Mahua has a _unused
> suffix for the missing 143, which makes sense given the bus isn't bifurcated
> there.
> 
> The _RST (PERST#) pin is driven by the SoC so I don't think it's useful to
> have it as a wakeup source, unless someone decides to connect something that's
> not PCIe to it (+Mani)
> 

PERST# by definition is an optional reset line, but on most of the *recent*
designs, OEMs always connect it to PERST# line. So practically, I don't think it
make sense to mark this GPIO as a wakeup source.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH 2/2] pinctrl: qcom: glymur: Add Mahua TLMM support

[Bjorn Andersson]

On Mon, Jan 05, 2026 at 11:04:44AM +0530, Manivannan Sadhasivam wrote:
> On Fri, Jan 02, 2026 at 01:40:22PM +0100, Konrad Dybcio wrote:
> > On 1/2/26 12:07 PM, Gopikrishna Garmidi wrote:
> > > Introduce support for the Mahua TLMM (Top Level Mode Multiplexer)
> > > in the pinctrl-glymur driver. Mahua shares the same pin configuration
> > > as Glymur but requires a different PDC wake IRQ mapping.
> > > 
> > > Changes include:
> > > - Add mahua_pdc_map[] with Mahua-specific GPIO to PDC IRQ mappings
> > > - Define mahua_tlmm msm_pinctrl_soc_data structure
> > > - Update device match table to include "qcom,mahua-tlmm" compatible
> > > - Modify probe function to use of_device_get_match_data() for dynamic
> > >   SoC-specific data selection
> > > 
> > > Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> > > ---
> > >  drivers/pinctrl/qcom/pinctrl-glymur.c | 43 ++++++++++++++++++++++++++++++++---
> > >  1 file changed, 40 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/pinctrl/qcom/pinctrl-glymur.c b/drivers/pinctrl/qcom/pinctrl-glymur.c
> > > index 335005084b6b..bf56a064d09c 100644
> > > --- a/drivers/pinctrl/qcom/pinctrl-glymur.c
> > > +++ b/drivers/pinctrl/qcom/pinctrl-glymur.c
> > > @@ -1729,6 +1729,25 @@ static const struct msm_gpio_wakeirq_map glymur_pdc_map[] = {
> > >  	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
> > >  };
> > >  
> > > +static const struct msm_gpio_wakeirq_map mahua_pdc_map[] = {
> > > +	{ 0, 116 },   { 2, 114 },   { 3, 115 },	  { 4, 175 },	{ 5, 176 },
> > > +	{ 7, 111 },   { 11, 129 },  { 13, 130 },  { 15, 112 },	{ 19, 113 },
> > > +	{ 23, 187 },  { 27, 188 },  { 28, 121 },  { 29, 122 },	{ 30, 136 },
> > > +	{ 31, 203 },  { 32, 189 },  { 34, 174 },  { 35, 190 },	{ 36, 191 },
> > > +	{ 39, 124 },  { 43, 192 },  { 47, 193 },  { 51, 123 },	{ 53, 133 },
> > > +	{ 55, 125 },  { 59, 131 },  { 64, 134 },  { 65, 150 },	{ 66, 186 },
> > > +	{ 67, 132 },  { 68, 195 },  { 71, 135 },  { 75, 196 },	{ 79, 197 },
> > > +	{ 83, 198 },  { 84, 181 },  { 85, 199 },  { 87, 200 },	{ 91, 201 },
> > > +	{ 92, 182 },  { 93, 183 },  { 94, 184 },  { 95, 185 },	{ 98, 202 },
> > > +	{ 105, 157 }, { 113, 128 }, { 121, 117 }, { 123, 118 }, { 125, 119 },
> > > +	{ 129, 120 }, { 131, 126 }, { 132, 160 }, { 133, 194 }, { 134, 127 },
> > > +	{ 141, 137 }, { 144, 138 }, { 145, 139 }, { 147, 140 }, { 148, 141 },
> > > +	{ 150, 146 }, { 151, 147 }, { 153, 148 }, { 154, 144 }, { 155, 159 },
> > > +	{ 156, 149 }, { 157, 151 }, { 163, 142 }, { 172, 143 }, { 181, 145 },
> > > +	{ 193, 161 }, { 196, 152 }, { 203, 177 }, { 208, 178 }, { 215, 162 },
> > > +	{ 217, 153 }, { 220, 154 }, { 221, 155 }, { 228, 179 }, { 230, 180 },
> > > +	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
> > 
> > Over the "common" base, Glymur has GPIO143 (PCIE3a_RST) and Mahua has GPIO155
> > (PCIE3b_RST). Both SoCs GPIO maps seem to contain both, but Mahua has a _unused
> > suffix for the missing 143, which makes sense given the bus isn't bifurcated
> > there.
> > 
> > The _RST (PERST#) pin is driven by the SoC so I don't think it's useful to
> > have it as a wakeup source, unless someone decides to connect something that's
> > not PCIe to it (+Mani)
> > 
> 
> PERST# by definition is an optional reset line, but on most of the *recent*
> designs, OEMs always connect it to PERST# line. So practically, I don't think it
> make sense to mark this GPIO as a wakeup source.
> 

This assumes that all the OEMs uses the particular PCI instance. If they
choose to route this GPIO to some other use case, they would have to
figure out that we omitted one entry in this table and patch it with
the appropriate data in order to have their GPIO wakeup capable.

Wouldn't it be better to put the correct information in this table at
this time? If we have a concrete reason not to, I think we should
include something useful in the commit message to help the poor engineer
faced with this task...

But perhaps I'm misunderstanding what the two of you are saying.

Regards,
Bjorn

> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்

Re: [PATCH 2/2] pinctrl: qcom: glymur: Add Mahua TLMM support

[Manivannan Sadhasivam]

On Mon, Jan 05, 2026 at 09:31:03AM -0600, Bjorn Andersson wrote:
> On Mon, Jan 05, 2026 at 11:04:44AM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Jan 02, 2026 at 01:40:22PM +0100, Konrad Dybcio wrote:
> > > On 1/2/26 12:07 PM, Gopikrishna Garmidi wrote:
> > > > Introduce support for the Mahua TLMM (Top Level Mode Multiplexer)
> > > > in the pinctrl-glymur driver. Mahua shares the same pin configuration
> > > > as Glymur but requires a different PDC wake IRQ mapping.
> > > > 
> > > > Changes include:
> > > > - Add mahua_pdc_map[] with Mahua-specific GPIO to PDC IRQ mappings
> > > > - Define mahua_tlmm msm_pinctrl_soc_data structure
> > > > - Update device match table to include "qcom,mahua-tlmm" compatible
> > > > - Modify probe function to use of_device_get_match_data() for dynamic
> > > >   SoC-specific data selection
> > > > 
> > > > Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> > > > ---
> > > >  drivers/pinctrl/qcom/pinctrl-glymur.c | 43 ++++++++++++++++++++++++++++++++---
> > > >  1 file changed, 40 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/pinctrl/qcom/pinctrl-glymur.c b/drivers/pinctrl/qcom/pinctrl-glymur.c
> > > > index 335005084b6b..bf56a064d09c 100644
> > > > --- a/drivers/pinctrl/qcom/pinctrl-glymur.c
> > > > +++ b/drivers/pinctrl/qcom/pinctrl-glymur.c
> > > > @@ -1729,6 +1729,25 @@ static const struct msm_gpio_wakeirq_map glymur_pdc_map[] = {
> > > >  	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
> > > >  };
> > > >  
> > > > +static const struct msm_gpio_wakeirq_map mahua_pdc_map[] = {
> > > > +	{ 0, 116 },   { 2, 114 },   { 3, 115 },	  { 4, 175 },	{ 5, 176 },
> > > > +	{ 7, 111 },   { 11, 129 },  { 13, 130 },  { 15, 112 },	{ 19, 113 },
> > > > +	{ 23, 187 },  { 27, 188 },  { 28, 121 },  { 29, 122 },	{ 30, 136 },
> > > > +	{ 31, 203 },  { 32, 189 },  { 34, 174 },  { 35, 190 },	{ 36, 191 },
> > > > +	{ 39, 124 },  { 43, 192 },  { 47, 193 },  { 51, 123 },	{ 53, 133 },
> > > > +	{ 55, 125 },  { 59, 131 },  { 64, 134 },  { 65, 150 },	{ 66, 186 },
> > > > +	{ 67, 132 },  { 68, 195 },  { 71, 135 },  { 75, 196 },	{ 79, 197 },
> > > > +	{ 83, 198 },  { 84, 181 },  { 85, 199 },  { 87, 200 },	{ 91, 201 },
> > > > +	{ 92, 182 },  { 93, 183 },  { 94, 184 },  { 95, 185 },	{ 98, 202 },
> > > > +	{ 105, 157 }, { 113, 128 }, { 121, 117 }, { 123, 118 }, { 125, 119 },
> > > > +	{ 129, 120 }, { 131, 126 }, { 132, 160 }, { 133, 194 }, { 134, 127 },
> > > > +	{ 141, 137 }, { 144, 138 }, { 145, 139 }, { 147, 140 }, { 148, 141 },
> > > > +	{ 150, 146 }, { 151, 147 }, { 153, 148 }, { 154, 144 }, { 155, 159 },
> > > > +	{ 156, 149 }, { 157, 151 }, { 163, 142 }, { 172, 143 }, { 181, 145 },
> > > > +	{ 193, 161 }, { 196, 152 }, { 203, 177 }, { 208, 178 }, { 215, 162 },
> > > > +	{ 217, 153 }, { 220, 154 }, { 221, 155 }, { 228, 179 }, { 230, 180 },
> > > > +	{ 232, 206 }, { 234, 172 }, { 235, 173 }, { 242, 158 }, { 244, 156 },
> > > 
> > > Over the "common" base, Glymur has GPIO143 (PCIE3a_RST) and Mahua has GPIO155
> > > (PCIE3b_RST). Both SoCs GPIO maps seem to contain both, but Mahua has a _unused
> > > suffix for the missing 143, which makes sense given the bus isn't bifurcated
> > > there.
> > > 
> > > The _RST (PERST#) pin is driven by the SoC so I don't think it's useful to
> > > have it as a wakeup source, unless someone decides to connect something that's
> > > not PCIe to it (+Mani)
> > > 
> > 
> > PERST# by definition is an optional reset line, but on most of the *recent*
> > designs, OEMs always connect it to PERST# line. So practically, I don't think it
> > make sense to mark this GPIO as a wakeup source.
> > 
> 
> This assumes that all the OEMs uses the particular PCI instance. If they
> choose to route this GPIO to some other use case, they would have to
> figure out that we omitted one entry in this table and patch it with
> the appropriate data in order to have their GPIO wakeup capable.
> 
> Wouldn't it be better to put the correct information in this table at
> this time? If we have a concrete reason not to, I think we should
> include something useful in the commit message to help the poor engineer
> faced with this task...
> 

There is no concrete reason actually. I just mentioned that in practical
usecase, I never saw an OEM routing the PERST# signal to other wakeup capable
functionality. But the possibility still exists, so I'm not completely against
it.

- Mani

-- 
மணிவண்ணன் சதாசிவம்