| Message ID | 20181121000648.29262-3-ilina@codeaurora.org |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | qcom: GPIO IRQ wakeup using PDC irqchip | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success |
Quoting Lina Iyer (2018-11-20 16:06:47) > SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO > routed to the PDC as interrupts that can be used to wake the system up > from deep low power modes and suspend. > > Signed-off-by: Lina Iyer <ilina@codeaurora.org> > --- > .../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 31 ++++++++++++++++++- > 1 file changed, 30 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt > index 665aadb5ea28..bedfa0b57fa6 100644 > --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt > @@ -29,6 +29,17 @@ SDM845 platform. > Definition: must be 2. Specifying the pin number and flags, as defined > in <dt-bindings/interrupt-controller/irq.h> > > +- wakeup-parent: > + Usage: optional > + Value type: <phandle> > + Definition: A phandle to the wakeup interrupt controller for the SoC. > + > +- wakeup-irq: This shouldn't be needed. TLMM driver can probe for the possibility of wakeup capable irqs from irq allocation step. The only place we should need to know what TLMM pins map to what PDC lines is in the PDC driver.
On Wed, Nov 21 2018 at 14:36 -0700, Stephen Boyd wrote: >Quoting Lina Iyer (2018-11-20 16:06:47) >> SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO >> routed to the PDC as interrupts that can be used to wake the system up >> from deep low power modes and suspend. >> >> Signed-off-by: Lina Iyer <ilina@codeaurora.org> >> --- >> .../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 31 ++++++++++++++++++- >> 1 file changed, 30 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt >> index 665aadb5ea28..bedfa0b57fa6 100644 >> --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt >> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt >> @@ -29,6 +29,17 @@ SDM845 platform. >> Definition: must be 2. Specifying the pin number and flags, as defined >> in <dt-bindings/interrupt-controller/irq.h> >> >> +- wakeup-parent: >> + Usage: optional >> + Value type: <phandle> >> + Definition: A phandle to the wakeup interrupt controller for the SoC. >> + >> +- wakeup-irq: > >This shouldn't be needed. TLMM driver can probe for the possibility of >wakeup capable irqs from irq allocation step. The only place we should >need to know what TLMM pins map to what PDC lines is in the PDC driver. > Why? Every driver seems to translate the hardware IRQ and pass it to it's parent. Why should this be any different ? The PDC is an interrupt controller that just knows an interrupt port and maps it to the GIC. Not sure, I understand the reasoning for this. It seems to add more confusing relationship with the PDC interrupt controller, that way. -- Lina
On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: >Quoting Lina Iyer (2018-11-26 08:14:55) >> On Wed, Nov 21 2018 at 14:36 -0700, Stephen Boyd wrote: >> >Quoting Lina Iyer (2018-11-20 16:06:47) >> >> SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO >> >> routed to the PDC as interrupts that can be used to wake the system up >> >> from deep low power modes and suspend. >> >> >> >> Signed-off-by: Lina Iyer <ilina@codeaurora.org> >> >> --- >> >> .../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 31 ++++++++++++++++++- >> >> 1 file changed, 30 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt >> >> index 665aadb5ea28..bedfa0b57fa6 100644 >> >> --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt >> >> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt >> >> @@ -29,6 +29,17 @@ SDM845 platform. >> >> Definition: must be 2. Specifying the pin number and flags, as defined >> >> in <dt-bindings/interrupt-controller/irq.h> >> >> >> >> +- wakeup-parent: >> >> + Usage: optional >> >> + Value type: <phandle> >> >> + Definition: A phandle to the wakeup interrupt controller for the SoC. >> >> + >> >> +- wakeup-irq: >> > >> >This shouldn't be needed. TLMM driver can probe for the possibility of >> >wakeup capable irqs from irq allocation step. The only place we should >> >need to know what TLMM pins map to what PDC lines is in the PDC driver. >> > >> Why? Every driver seems to translate the hardware IRQ and pass it to >> it's parent. Why should this be any different ? The PDC is an interrupt >> controller that just knows an interrupt port and maps it to the GIC. Not >> sure, I understand the reasoning for this. It seems to add more >> confusing relationship with the PDC interrupt controller, that way. >> > >Two reasons. First, simplicity. The TLMM driver just needs to pass the >gpio number up to the PDC gpio domain and then that domain can figure >out what hwirq it maps to within the PDC hw irq space. I don't see any >reason why we have to know the hwirq of PDC within the TLMM driver >besides "let's not be different". > >And second, it makes it easier for us to implement the MPM case in the >TLMM driver by letting the TLMM code just ask "should I mask the irq >here or not?" by passing that with a wrapper struct around the fwspec >and a dedicated domain in the PDC/MPM driver. Keeping less things in the >TLMM driver and not driving the decision from DT but from tables in the >PDC driver also keeps things simple and reduces DT parsing code/time. > Couldn't this be simply achieved by matching the compatible flags for PDC/MPM bindings for the wakeup-parent in the TLMM driver? Thanks, Lina
Quoting Lina Iyer (2018-11-27 10:21:23) > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: > > > >Two reasons. First, simplicity. The TLMM driver just needs to pass the > >gpio number up to the PDC gpio domain and then that domain can figure > >out what hwirq it maps to within the PDC hw irq space. I don't see any > >reason why we have to know the hwirq of PDC within the TLMM driver > >besides "let's not be different". > > > >And second, it makes it easier for us to implement the MPM case in the > >TLMM driver by letting the TLMM code just ask "should I mask the irq > >here or not?" by passing that with a wrapper struct around the fwspec > >and a dedicated domain in the PDC/MPM driver. Keeping less things in the > >TLMM driver and not driving the decision from DT but from tables in the > >PDC driver also keeps things simple and reduces DT parsing code/time. > > > Couldn't this be simply achieved by matching the compatible flags for > PDC/MPM bindings for the wakeup-parent in the TLMM driver? > It could be, but then we would be making TLMM highly aware of the wakeup parent and have to do compatible string matching in two places, instead of making TLMM more abstractly aware that it needs to keep things masked while irq parent deals with the interrupts.
On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote: >Quoting Lina Iyer (2018-11-27 10:21:23) >> On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: >> > >> >Two reasons. First, simplicity. The TLMM driver just needs to pass the >> >gpio number up to the PDC gpio domain and then that domain can figure >> >out what hwirq it maps to within the PDC hw irq space. I don't see any >> >reason why we have to know the hwirq of PDC within the TLMM driver >> >besides "let's not be different". >> > >> >And second, it makes it easier for us to implement the MPM case in the >> >TLMM driver by letting the TLMM code just ask "should I mask the irq >> >here or not?" by passing that with a wrapper struct around the fwspec >> >and a dedicated domain in the PDC/MPM driver. Keeping less things in the >> >TLMM driver and not driving the decision from DT but from tables in the >> >PDC driver also keeps things simple and reduces DT parsing code/time. >> > >> Couldn't this be simply achieved by matching the compatible flags for >> PDC/MPM bindings for the wakeup-parent in the TLMM driver? >> > >It could be, but then we would be making TLMM highly aware of the wakeup >parent It is is not aware of anything about the wakeup parent, just the compatible that indicates whether it needs to be mask locally or not. >and have to do compatible string matching in two places, instead >of making TLMM more abstractly aware that it needs to keep things masked >while irq parent deals with the interrupts. > Your approach seems too complex just to circumvent a simple match node. I think we are stretching too much to support something that is not a priority. -- Lina
On Wed 28 Nov 09:39 PST 2018, Lina Iyer wrote: > On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote: > > Quoting Lina Iyer (2018-11-27 10:21:23) > > > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: > > > > > > > >Two reasons. First, simplicity. The TLMM driver just needs to pass the > > > >gpio number up to the PDC gpio domain and then that domain can figure > > > >out what hwirq it maps to within the PDC hw irq space. I don't see any > > > >reason why we have to know the hwirq of PDC within the TLMM driver > > > >besides "let's not be different". > > > > > > > >And second, it makes it easier for us to implement the MPM case in the > > > >TLMM driver by letting the TLMM code just ask "should I mask the irq > > > >here or not?" by passing that with a wrapper struct around the fwspec > > > >and a dedicated domain in the PDC/MPM driver. Keeping less things in the > > > >TLMM driver and not driving the decision from DT but from tables in the > > > >PDC driver also keeps things simple and reduces DT parsing code/time. > > > > > > > Couldn't this be simply achieved by matching the compatible flags for > > > PDC/MPM bindings for the wakeup-parent in the TLMM driver? > > > > > > > It could be, but then we would be making TLMM highly aware of the wakeup > > parent > It is is not aware of anything about the wakeup parent, just the > compatible that indicates whether it needs to be mask locally or not. > But the information related to how the PDC is wired to GPIO pins is a property related to the PDC not of the TLMM, so it does make sense to represent this information there. And iiuc it also makes sense to not encode it in DT because it's physical wiring, not configuration. > > and have to do compatible string matching in two places, instead > > of making TLMM more abstractly aware that it needs to keep things masked > > while irq parent deals with the interrupts. > > > Your approach seems too complex just to circumvent a simple match node. > I think we are stretching too much to support something that is not a > priority. > What "something" are you referring to here? Regards, Bjorn
On Wed, Nov 28 2018 at 17:25 -0700, Bjorn Andersson wrote: >On Wed 28 Nov 09:39 PST 2018, Lina Iyer wrote: > >> On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote: >> > Quoting Lina Iyer (2018-11-27 10:21:23) >> > > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: >> > > > >> > > >Two reasons. First, simplicity. The TLMM driver just needs to pass the >> > > >gpio number up to the PDC gpio domain and then that domain can figure >> > > >out what hwirq it maps to within the PDC hw irq space. I don't see any >> > > >reason why we have to know the hwirq of PDC within the TLMM driver >> > > >besides "let's not be different". >> > > > >> > > >And second, it makes it easier for us to implement the MPM case in the >> > > >TLMM driver by letting the TLMM code just ask "should I mask the irq >> > > >here or not?" by passing that with a wrapper struct around the fwspec >> > > >and a dedicated domain in the PDC/MPM driver. Keeping less things in the >> > > >TLMM driver and not driving the decision from DT but from tables in the >> > > >PDC driver also keeps things simple and reduces DT parsing code/time. >> > > > >> > > Couldn't this be simply achieved by matching the compatible flags for >> > > PDC/MPM bindings for the wakeup-parent in the TLMM driver? >> > > >> > >> > It could be, but then we would be making TLMM highly aware of the wakeup >> > parent >> It is is not aware of anything about the wakeup parent, just the >> compatible that indicates whether it needs to be mask locally or not. >> > >But the information related to how the PDC is wired to GPIO pins is a >property related to the PDC not of the TLMM, so it does make sense to >represent this information there. > Hmm.. But we are inconsistent in what we provide as input into the PDC driver. >From the PDC driver perspective, it gets a hwirq number either when driver requests a wakeup interrupt specified in DT as <&pdc 5 IRQ_TYPE_LEVEL_HIGH> or from GPIO, which translates the GPIO to the PDC hwirq and requests that. >And iiuc it also makes sense to not encode it in DT because it's >physical wiring, not configuration. > I would agree. >> > and have to do compatible string matching in two places, instead >> > of making TLMM more abstractly aware that it needs to keep things masked >> > while irq parent deals with the interrupts. >> > >> Your approach seems too complex just to circumvent a simple match node. >> I think we are stretching too much to support something that is not a >> priority. >> > >What "something" are you referring to here? > MPM :) BTW, I am discussing with the internal folks here on if we need to mask TLMM when the wakeup-parent is MPM. If we don't have to, we should be able to follow the same model as we done in this patch and don't even have to check the compatible or use the approach suggested by Stephen. -- Lina
On Thu 29 Nov 13:45 PST 2018, Lina Iyer wrote: > On Wed, Nov 28 2018 at 17:25 -0700, Bjorn Andersson wrote: > > On Wed 28 Nov 09:39 PST 2018, Lina Iyer wrote: > > > > > On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote: > > > > Quoting Lina Iyer (2018-11-27 10:21:23) > > > > > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: > > > > > > > > > > > >Two reasons. First, simplicity. The TLMM driver just needs to pass the > > > > > >gpio number up to the PDC gpio domain and then that domain can figure > > > > > >out what hwirq it maps to within the PDC hw irq space. I don't see any > > > > > >reason why we have to know the hwirq of PDC within the TLMM driver > > > > > >besides "let's not be different". > > > > > > > > > > > >And second, it makes it easier for us to implement the MPM case in the > > > > > >TLMM driver by letting the TLMM code just ask "should I mask the irq > > > > > >here or not?" by passing that with a wrapper struct around the fwspec > > > > > >and a dedicated domain in the PDC/MPM driver. Keeping less things in the > > > > > >TLMM driver and not driving the decision from DT but from tables in the > > > > > >PDC driver also keeps things simple and reduces DT parsing code/time. > > > > > > > > > > > Couldn't this be simply achieved by matching the compatible flags for > > > > > PDC/MPM bindings for the wakeup-parent in the TLMM driver? > > > > > > > > > > > > > It could be, but then we would be making TLMM highly aware of the wakeup > > > > parent > > > It is is not aware of anything about the wakeup parent, just the > > > compatible that indicates whether it needs to be mask locally or not. > > > > > > > But the information related to how the PDC is wired to GPIO pins is a > > property related to the PDC not of the TLMM, so it does make sense to > > represent this information there. > > > Hmm.. But we are inconsistent in what we provide as input into the PDC > driver. > From the PDC driver perspective, it gets a hwirq number either when > driver requests a wakeup interrupt specified in DT as > <&pdc 5 IRQ_TYPE_LEVEL_HIGH> > or from GPIO, which translates the GPIO to the PDC hwirq and requests > that. > I see what you're saying, but need to think some more about this... > > And iiuc it also makes sense to not encode it in DT because it's > > physical wiring, not configuration. > > > I would agree. > > > > > and have to do compatible string matching in two places, instead > > > > of making TLMM more abstractly aware that it needs to keep things masked > > > > while irq parent deals with the interrupts. > > > > > > > Your approach seems too complex just to circumvent a simple match node. > > > I think we are stretching too much to support something that is not a > > > priority. > > > > > > > What "something" are you referring to here? > > > MPM :) > There are still new platforms coming out with MPM, so there's even a business case to care about it. > BTW, I am discussing with the internal folks here on if we need to mask > TLMM when the wakeup-parent is MPM. If we don't have to, we should be > able to follow the same model as we done in this patch and don't even > have to check the compatible or use the approach suggested by Stephen. > Looking forward to the result of that discussion. Regards, Bjorn
On Thu, Nov 29 2018 at 14:45 -0700, Lina Iyer wrote: >On Wed, Nov 28 2018 at 17:25 -0700, Bjorn Andersson wrote: >>On Wed 28 Nov 09:39 PST 2018, Lina Iyer wrote: >> >>>On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote: >>>> Quoting Lina Iyer (2018-11-27 10:21:23) >>>> > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: [...] >BTW, I am discussing with the internal folks here on if we need to mask >TLMM when the wakeup-parent is MPM. If we don't have to, we should be >able to follow the same model as we done in this patch and don't even >have to check the compatible or use the approach suggested by Stephen. > The TLMM and the MPM are not active at the same time. However, there is a small chance they might be (a few clock cycles) when the system is going down, but even then, since we replay the interrupt from the MPM driver before the interrupts are serviced by Linux, we would not see multiple GPIO interrupts. The way we have MPM working downstream, for a wakeup GPIO IRQ - a. Application cores gets a wakeup interrupt either from RPM or GIC (if TLMM was not powered down) while still in the interrupt locked context. b. In the hardware, apps core handshakes with the RPM and then starts resuming from the platform's system idle driver. c. The first CPU to wake up calls MPM driver from the idle driver, which reads the shared memory to find the MPM pins that are set. Converts the MPM pins to their corresponding linux interrupt and replays the interrupt. d. Idle driver exits and wakeup GPIO interrupt is handled. The MPM pins are not updated after the RPM lets the application core to run. Since TLMM is functional after the RPM handshake, it takes over. Note, the downstream design is predicated on the OS-Initiated support for all MPM based SoCs which serializes the last CPU going down and the first CPU coming out of idle. Thanks, Lina
Quoting Lina Iyer (2018-11-30 10:33:17) > On Thu, Nov 29 2018 at 14:45 -0700, Lina Iyer wrote: > >On Wed, Nov 28 2018 at 17:25 -0700, Bjorn Andersson wrote: > >>On Wed 28 Nov 09:39 PST 2018, Lina Iyer wrote: > >> > >>>On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote: > >>>> Quoting Lina Iyer (2018-11-27 10:21:23) > >>>> > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: > > [...] > >BTW, I am discussing with the internal folks here on if we need to mask > >TLMM when the wakeup-parent is MPM. If we don't have to, we should be > >able to follow the same model as we done in this patch and don't even > >have to check the compatible or use the approach suggested by Stephen. > > > The TLMM and the MPM are not active at the same time. However, there is > a small chance they might be (a few clock cycles) when the system is > going down, but even then, since we replay the interrupt from the MPM > driver before the interrupts are serviced by Linux, we would not see > multiple GPIO interrupts. > > The way we have MPM working downstream, for a wakeup GPIO IRQ - > > a. Application cores gets a wakeup interrupt either from RPM or GIC (if > TLMM was not powered down) while still in the interrupt locked context. > > b. In the hardware, apps core handshakes with the RPM and then starts > resuming from the platform's system idle driver. > > c. The first CPU to wake up calls MPM driver from the idle driver, which > reads the shared memory to find the MPM pins that are set. Converts the > MPM pins to their corresponding linux interrupt and replays the > interrupt. > > d. Idle driver exits and wakeup GPIO interrupt is handled. > > The MPM pins are not updated after the RPM lets the application core to > run. Since TLMM is functional after the RPM handshake, it takes over. > Thanks for the background info. I don't think it really changes anything that we've discussed though. We still need to mask the IRQ in TLMM all the time when we're using the PDC and we need to leave it unmasked and replay edges that the MPM sees when we use the MPM. Should I clean up my RFC patch and post it to the list? I'd like to see hierarchical gpio irqs work in general for this problem and also the SSBI/SPMI gpio irq problem that Linus pointed out last week.
On Mon, Dec 03 2018 at 16:48 -0700, Stephen Boyd wrote: >Quoting Lina Iyer (2018-11-30 10:33:17) >> On Thu, Nov 29 2018 at 14:45 -0700, Lina Iyer wrote: >> >On Wed, Nov 28 2018 at 17:25 -0700, Bjorn Andersson wrote: >> >>On Wed 28 Nov 09:39 PST 2018, Lina Iyer wrote: >> >> >> >>>On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote: >> >>>> Quoting Lina Iyer (2018-11-27 10:21:23) >> >>>> > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote: >> >> [...] >> >BTW, I am discussing with the internal folks here on if we need to mask >> >TLMM when the wakeup-parent is MPM. If we don't have to, we should be >> >able to follow the same model as we done in this patch and don't even >> >have to check the compatible or use the approach suggested by Stephen. >> > >> The TLMM and the MPM are not active at the same time. However, there is >> a small chance they might be (a few clock cycles) when the system is >> going down, but even then, since we replay the interrupt from the MPM >> driver before the interrupts are serviced by Linux, we would not see >> multiple GPIO interrupts. >> >> The way we have MPM working downstream, for a wakeup GPIO IRQ - >> >> a. Application cores gets a wakeup interrupt either from RPM or GIC (if >> TLMM was not powered down) while still in the interrupt locked context. >> >> b. In the hardware, apps core handshakes with the RPM and then starts >> resuming from the platform's system idle driver. >> >> c. The first CPU to wake up calls MPM driver from the idle driver, which >> reads the shared memory to find the MPM pins that are set. Converts the >> MPM pins to their corresponding linux interrupt and replays the >> interrupt. >> >> d. Idle driver exits and wakeup GPIO interrupt is handled. >> >> The MPM pins are not updated after the RPM lets the application core to >> run. Since TLMM is functional after the RPM handshake, it takes over. >> > >Thanks for the background info. I don't think it really changes anything >that we've discussed though. We still need to mask the IRQ in TLMM all >the time when we're using the PDC and we need to leave it unmasked and >replay edges that the MPM sees when we use the MPM. Should I clean up my >RFC patch and post it to the list? I have started to work on this. But feel free to post your version if you have it ready. Thanks for the review Stephen. I think I understand now where you are getting with it. Sorry about all the back and forth. Thanks, Lina >I'd like to see hierarchical gpio >irqs work in general for this problem and also the SSBI/SPMI gpio irq >problem that Linus pointed out last week. >
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt index 665aadb5ea28..bedfa0b57fa6 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt @@ -29,6 +29,17 @@ SDM845 platform. Definition: must be 2. Specifying the pin number and flags, as defined in <dt-bindings/interrupt-controller/irq.h> +- wakeup-parent: + Usage: optional + Value type: <phandle> + Definition: A phandle to the wakeup interrupt controller for the SoC. + +- wakeup-irq: + Usage: optional: + Value type: <u32 array> + Definition: Specifies the map of the gpio and the corresponding PDC + output port. + - gpio-controller: Usage: required Value type: <none> @@ -53,7 +64,6 @@ pin, a group, or a list of pins or groups. This configuration can include the mux function to select on those pin(s)/group(s), and various pin configuration parameters, such as pull-up, drive strength, etc. - PIN CONFIGURATION NODES: The name of each subnode is not important; all subnodes should be enumerated @@ -160,6 +170,25 @@ Example: #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; + wake-parent = <&pdc>; + wake-irq = + <1 30>, <3 31>, <5 32>, <10 33>, <11 34>, + <20 35>, <22 36>, <24 37>, <26 38>, <30 39>, + <31 117>, <32 41>, <34 42>, <36 43>, <37 44>, + <38 45>, <39 46>, <40 47>, <41 115>, <43 49>, + <44 50>, <46 51>, <48 52>, <49 118>, <52 54>, + <53 55>, <54 56>, <56 57>, <57 58>, <58 59>, + <59 60>, <60 61>, <61 62>, <62 63>, <63 64>, + <64 65>, <66 66>, <68 67>, <71 68>, <73 69>, + <77 70>, <78 71>, <79 72>, <80 73>, <84 74>, + <85 75>, <86 76>, <88 77>, <89 116>, <91 79>, + <92 80>, <95 81>, <96 82>, <97 83>, <101 84>, + <103 85>, <104 86>, <115 90>, <116 91>, + <117 92>, <118 93>, <119 94>, <120 95>, + <121 96>, <122 97>, <123 98>, <124 99>, + <125 100>, <127 102>, <128 103>, <129 104>, + <130 105>, <132 106>, <133 107>, <145 108>; + qup9_active: qup9-active { mux {
SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO routed to the PDC as interrupts that can be used to wake the system up from deep low power modes and suspend. Signed-off-by: Lina Iyer <ilina@codeaurora.org> --- .../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 31 ++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-)