[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0d6f8f95-01be-4fa3-9fde-bc00cbb894f6@oss.qualcomm.com>
Date: Wed, 7 Jan 2026 11:30:04 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>
Cc: Gopikrishna Garmidi <gopikrishna.garmidi@....qualcomm.com>,
Linus Walleij <linusw@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley
<conor+dt@...nel.org>,
Rajendra Nayak <rajendra.nayak@....qualcomm.com>,
Pankaj Patil <pankaj.patil@....qualcomm.com>,
Sibi Sankar <sibi.sankar@....qualcomm.com>,
Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
linux-arm-msm@...r.kernel.org, linux-gpio@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] pinctrl: qcom: glymur: Add Mahua TLMM support
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@....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
Powered by blists - more mailing lists