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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 1/12/26 8:46 AM, Gopikrishna Garmidi wrote:
> 
> 
> 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.

Glad to hear this idea works too

Up to you, @Bjorn

Konrad