Re: [PATCH 3/5] irqchip/qcom-pdc: Configure PDC to pass through mode

[Konrad Dybcio]

On 3/13/26 7:40 AM, Maulik Shah (mkshah) wrote:
> 
> 
> On 3/13/2026 7:52 AM, Dmitry Baryshkov wrote:
>> On Thu, Mar 12, 2026 at 09:26:37PM +0530, Maulik Shah wrote:

[...]

>>> All the SoCs so far default uses pass through mode with the exception of
>>
>> Is it something that must be configured by the bootloaders?
> 
> yes, currently changing the the mode can be done from secure world either at boot
> or after boot via scm write.

..which won't work on almost any X1E devices, except CRD and IOT..

>>> x1e. x1e PDC may be set to secondary controller mode for builds on CRD
>>> boards whereas it may be set to pass through mode for IoT-EVK.
>>>
>>> There is no way to read which current mode it is set to and make PDC work
>>> in respective mode as the read access is not opened up for non secure
>>> world. There is though write access opened up via SCM write API to set the
>>> mode.
>>
>> What are going to loose? The ability to latch the wakeup sources on the
>> CRD?
> 
> CXPC (SoC level low power mode) would be lost if the device can not wake up from GPIO wakeup sources.

To the best of my understanding, that's only because your approach chooses
to ignore supporting the secondary controller mode and force-reconfigure,
since GPIO wakeup functionality is otherwise available regardless of the
mode.

>>> Configure PDC mode to pass through mode for all x1e based boards via SCM
>>> write.
>>
>> Would it make sense to always use the secondary mode instead?
> 
> No, it would not make sense to support the secondary mode in Linux.

Why?

[...]

>>> +		 *	- Inform TLMM to monitor GPIO IRQs (same as MPM)
>>> +		 *	- Prevent SoC low power mode (CxPC) as PDC is not
>>> +		 *	  monitoring GPIO IRQs which may be needed to wake
>>> +		 *	  the SoC from low power mode.
>>
>> This doesn't quite match the description of "latches the GPIO IRQs".
> 
> It does, PDC would continue to still latch the GPIO IRQs (as the mode change failed)
> but PDC won't forward them to parent GIC as they are masked at PDC with __pdc_mask_intr().

Can you not refrain from masking them then, and clear them upon reception,
with a write to IRQ_i_CFG[IRQ_STATUS]?

The HPG states that this mechanism is only engaged for GPIO IRQs and that
the forwarded interrupt will be of LEVEL_HIGH type (which is what TLMM
accepts anyway)

FWIW, some related work:
c7984dc0a2b9 ("pinctrl: qcom: Add test case for TLMM interrupt handling")

Konrad