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

[Maulik Shah (mkshah)]

On 3/13/2026 7:52 AM, Dmitry Baryshkov wrote:
> On Thu, Mar 12, 2026 at 09:26:37PM +0530, Maulik Shah wrote:
>> There are two modes PDC irqchip supports pass through mode and secondary
>> controller mode.
> 
> Can't parse this, excuse me.

Ok, I can drop this in v2.

> 
>>
>> All PDC irqchip supports pass through mode in which both Direct SPIs and
>> GPIO IRQs (as SPIs) are sent to GIC without latching at PDC.
>>
>> Newer PDCs (v3.0 onwards) also support additional secondary controller mode
> 
> It would help to mention the platforms, not everybody has the core docs.

Sure, i can update the platforms which are v3.0 or higher.

> 
>> where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs
>> still works same as pass through mode without latching at PDC even in
>> secondary controller mode.
>>
>> 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.

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

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

> 
..
..

>>  
>> -	pdc_base = ioremap(res.start, res_size);
>> -	if (!pdc_base) {
>> -		pr_err("%pOF: unable to map PDC registers\n", node);
>> -		ret = -ENXIO;
>> -		goto fail;
>> +		/*
>> +		 * There are two modes PDC irqchip can work in
>> +		 *	- pass through mode
>> +		 *	- secondary controller mode
>> +		 *
>> +		 * All PDC irqchip supports pass through mode in which both
>> +		 * Direct SPIs and GPIO IRQs (as SPIs) are sent to GIC
>> +		 * without latching at PDC.
>> +		 *
>> +		 * Newer PDCs (v3.0 onwards) also support additional
>> +		 * secondary controller mode where PDC latches GPIO IRQs
>> +		 * and sends to GIC as level type IRQ. Direct SPIs still
>> +		 * works same as pass through mode without latching at PDC
>> +		 * even in secondary controller mode.
> 
> I'd say, there is no need to duplicate the commit message.

Sure, i can remove from comments.

> 
>> +		 *
>> +		 * All the SoCs so far default uses pass through mode with
>> +		 * the exception of x1e.
>> +		 *
>> +		 * x1e modes:
>> +		 *
>> +		 * 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 boards.
>> +		 *
>> +		 * 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.
>> +		 *
>> +		 * Configure PDC mode to pass through mode for all x1e based
>> +		 * boards.
>> +		 *
>> +		 * For successful write:
>> +		 *	- Nothing more to be done
>> +		 *
>> +		 * For unsuccessful write:
> 
> Why would it fail?

It can fail if the write is denied by firmware.
As i understand the older firmware had neither read/write as such firmware
was meant to be used for non-linux (windows only and not for the dual boot).

> 
>> +		 *	- 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().

In summary,

Below is what x1e users get today if they boot up Linux:
 - All the GPIO interrupts works fine for them as they don't get forwarded to PDC
   due to commit 602cb14e310a ("pinctrl: qcom: x1e80100: Bypass PDC wakeup parent for now")
 - SS3 idle state (CPU level deepest low power mode) not added in device tree due to
   above commit.
 - This prevents CXPC (SoC level low power mode) as the CPU subsystem cannot hit deepest low power mode.

Below is what would x1e users would get from this series,
 - GPIO interrupts continue to work fine after reverting commit 602cb14e310a
   ("pinctrl: qcom: x1e80100: Bypass PDC wakeup parent for now"), PATCH 5/5 of this series.
 - SS3 idle state (CPU level deepest idle state) is added, PATCH 4/4 of this series.
   Adding the SS3 idle states opens up the path for the SoC to achieve CXPC (SoC level low power mode)
   (This again depends on drivers removing all the global resources vote)

   While all global resources votes can get removed, if the PDC still could not wake the SoC from GPIO
   interrupts, the CX is kept at MoL (minimum operating level) and TLMM (which is on Cx rail) would then
   wake up the CPUs from SS3 CPUidle / suspend (s2idle) state with GPIO interrupts.

Thanks,
Maulik