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.1On 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
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
--
மணிவண்ணன் சதாசிவம்
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
>
> --
> மணிவண்ணன் சதாசிவம்
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
--
மணிவண்ணன் சதாசிவம்
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
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
On Mon, Jan 12, 2026 at 01:16:37PM +0530, 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
>
For the GPIOs with an entry in the pdc_map we delegate the interrupt
handling to the PDC.
So with the union, I believe that when you on a Glymur device request
GPIO 155, you will start getting interrupts from GPIO 143, and on Mahua
the other way around.
Perhaps I'm missing something, but I think we make the two GPIOs
unusable by this "optimization".
Regards,
Bjorn
> Happy to update v3 in whichever direction you prefer.
>
> Best regards,
> Gopikrishna Garmidi
>
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
© 2016 - 2026 Red Hat, Inc.