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

[Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>]

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@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.
> 
> 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