Re: [PATCH 2/2] pinctrl: qcom: glymur: Add Mahua TLMM support
From: Gopikrishna Garmidi
Date: Mon Jan 12 2026 - 02:46:46 EST
On 1/7/2026 4:00 PM, Konrad Dybcio wrote:
On 1/5/26 6:20 PM, Manivannan Sadhasivam wrote:
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@xxxxxxxxxxxxxxxx>
---
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.
I'm curious whether we can just describe the union of these sets as a
common config, because as I've mentioned, IPCat says both of these platforms
seem to have these interrupts wired up
Konrad
Hi Konrad Dybcio,
Thanks for the suggestion!
I tested using a single combined wake map (i.e., the union of both Mahua and Glymur sets) on actual Glymur and Mahua hardware, and both platforms work correctly without any errors.
Although both GPIOs are present in the wiring, only one of them is actually wake-capable on each platform.
Glymur:
- GPIO 143: Supports wakeup
- GPIO 155: Does not support wakeup
Mahua:
- GPIO 143: Does not support wakeup
- GPIO 155: Supports wakeup
The combined map works functionally, but includes entries that don't match hardware capabilities.
Could you please advise which approach I should follow for v3?
1. Use a single combined map (union of both sets) with comments about wakeup capability difference, or
2. Keep separate maps for each SoC
Happy to update v3 in whichever direction you prefer.
Best regards,
Gopikrishna Garmidi