On Thu, Jul 12 2018 at 10:31 -0600, Evan Green wrote:
On Tue, Jul 10, 2018 at 1:38 PM Lina Iyer <ilina@xxxxxxxxxxxxxx> wrote:
On Tue, Jul 10 2018 at 12:53 -0600, Evan Green wrote:
>On Mon, Jul 9, 2018 at 10:27 AM Bjorn Andersson
><bjorn.andersson@xxxxxxxxxx> wrote:
>Our understanding is the downstream kernel had an interrupt hierarchy
>of GIC > PDC > TLMM & everybody else. In the downstream world PDC
>acted transparently, forwarding most requests directly onto the GIC,
>but quietly handling wake interrupts as well. With the upstream PDC
>driver, the #interrupt-cells got changed to 2, and it seemed like
>folks didn't like the idea that PDC was acting transparently. Correct
>me if I'm wrong there. So now we're sort of unsure about how to wire
>in PDC. If we make everybody an interrupt child of PDC, then we lose
>the ability to specify the third GIC parameter, and we're stuck
>expressing interrupts with respect to PDC pins, which is an awkward
>mental translation.
Its an unfortunate side effect of the design. Drivers will have to
request the PDC pin for wakeup IRQs.
Would they use the PDC pin to request their regular interrupt, and the
PDC would turn around and ask the GIC for them, and also enable the
wakeup interrupt?>
Yes, drivers would need to request a PDC pin since using the
interrupts-extended format and then enable that interrupt was a wakeup
interrupt.
Or would devices have some sort of separate entry for wakeup
interrupts?
Not sure how you mean. If it's the DT you are asking, then yes, they
would need to have a separate entry in DT.
wake-device {
interrupts-extended = <&pdc 2 IRQ_TYPE_LEVEL_HIGH>;
};
See Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
Thanks,
Lina
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
