Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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.
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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.
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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.
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 > < 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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 > < 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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 < 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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 < 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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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.
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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.
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 >> --- >> .../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 >> >> +- wakeup-parent: >> + Usage: optional >> + Value type: >> + 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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 >> --- >> .../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 >> >> +- wakeup-parent: >> + Usage: optional >> + Value type: >> + 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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
> >> ---
> >> .../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
> >>
> >> +- wakeup-parent:
> >> + Usage: optional
> >> + Value type:
> >> + 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.
I'm not sure why Marc wanted the pdc to GIC SPI line mapping to come
from DT. I guess there were some contiguous ranges in there so making
the mapping in DT works OK enough because there are only a few ranges to
handle, but the GPIO map seems quite scattered so I don't see much of a
benefit to trying to compress it.
I'm hacking on this code to make it all nice and clean, but here's my
current WIP patch that at least works well enough for me to get gpio
irqs at runtime. I haven't tested the suspend path yet, but presumably
if irqs are working at runtime and the device isn't suspended then any
wakeup irqs will be kept unmasked at the PDC and things would "just
work". This is on top of these patches and the gpio hierarchical
irqdomain patch.
A couple suggestions for starting points:
1) We could have PDC get a phandle to TLMM so that we can match up
the irq domain in PDC to the irq domain inside TLMM with a
irq domain ops::match/select function instead of using a token
to match this up.
2) The PDC driver could be a little more friendly about globals
and actually pass around pointers to things via the irq domain
void pointer member.
3) We could have the GPIO PDC domain be a child domain of the main
PDC domain and just map between GPIO number space and PDC
number space. Otherwise we duplicate some code between the two
alloc implementations for trigger type remapping.
---8<
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index faa7d61b9d6c..39abc06b3a3a 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -13,12 +13,13 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
#define PDC_MAX_IRQS 126
+#define PDC_MAX_GPIO_IRQS 256
#define CLEAR_INTR(reg, intr) (reg & ~(1 << intr))
#define ENABLE_INTR(reg, intr) (reg | (1 << intr))
@@ -32,6 +33,11 @@ struct pdc_pin_region {
u32 cnt;
};
+struct pdc_gpio_pin_map {
+ unsigned int gpio;
+ u32 pdc_pin;
+};
+
static DEFINE_RAW_SPINLOCK(pdc_lock);
static void __iomem *pdc_base;
static struct pdc_pin_region *pdc_region;
@@ -47,9 +53,8 @@ static u32 pdc_reg_read(int reg, u32 i)
return readl_relaxed(pdc_base + reg + i * sizeof(u32));
}
-static void pdc_enable_intr(struct irq_data *d, bool on)
+static void pdc_enable_intr(irq_hw_number_t pin_out, bool on)
{
- int
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
> >> ---
> >> .../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
> >>
> >> +- wakeup-parent:
> >> + Usage: optional
> >> + Value type:
> >> + 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.
I'm not sure why Marc wanted the pdc to GIC SPI line mapping to come
from DT. I guess there were some contiguous ranges in there so making
the mapping in DT works OK enough because there are only a few ranges to
handle, but the GPIO map seems quite scattered so I don't see much of a
benefit to trying to compress it.
I'm hacking on this code to make it all nice and clean, but here's my
current WIP patch that at least works well enough for me to get gpio
irqs at runtime. I haven't tested the suspend path yet, but presumably
if irqs are working at runtime and the device isn't suspended then any
wakeup irqs will be kept unmasked at the PDC and things would "just
work". This is on top of these patches and the gpio hierarchical
irqdomain patch.
A couple suggestions for starting points:
1) We could have PDC get a phandle to TLMM so that we can match up
the irq domain in PDC to the irq domain inside TLMM with a
irq domain ops::match/select function instead of using a token
to match this up.
2) The PDC driver could be a little more friendly about globals
and actually pass around pointers to things via the irq domain
void pointer member.
3) We could have the GPIO PDC domain be a child domain of the main
PDC domain and just map between GPIO number space and PDC
number space. Otherwise we duplicate some code between the two
alloc implementations for trigger type remapping.
---8<
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index faa7d61b9d6c..39abc06b3a3a 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -13,12 +13,13 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
#define PDC_MAX_IRQS 126
+#define PDC_MAX_GPIO_IRQS 256
#define CLEAR_INTR(reg, intr) (reg & ~(1 << intr))
#define ENABLE_INTR(reg, intr) (reg | (1 << intr))
@@ -32,6 +33,11 @@ struct pdc_pin_region {
u32 cnt;
};
+struct pdc_gpio_pin_map {
+ unsigned int gpio;
+ u32 pdc_pin;
+};
+
static DEFINE_RAW_SPINLOCK(pdc_lock);
static void __iomem *pdc_base;
static struct pdc_pin_region *pdc_region;
@@ -47,9 +53,8 @@ static u32 pdc_reg_read(int reg, u32 i)
return readl_relaxed(pdc_base + reg + i * sizeof(u32));
}
-static void pdc_enable_intr(struct irq_data *d, bool on)
+static void pdc_enable_intr(irq_hw_number_t pin_out, bool on)
{
- int
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 --- .../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 +- wakeup-parent: + Usage: optional + Value type: + 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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 --- .../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 +- wakeup-parent: + Usage: optional + Value type: + 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
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 > --- > .../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 > > +- wakeup-parent: > + Usage: optional > + Value type: > + 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.
Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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 > --- > .../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 > > +- wakeup-parent: > + Usage: optional > + Value type: > + 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.
[RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
---
.../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
+- wakeup-parent:
+ Usage: optional
+ Value type:
+ Definition: A phandle to the wakeup interrupt controller for the SoC.
+
+- wakeup-irq:
+ Usage: optional:
+ Value type:
+ Definition: Specifies the map of the gpio and the corresponding PDC
+ output port.
+
- gpio-controller:
Usage: required
Value type:
@@ -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 = <>;
+ 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 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
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
---
.../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
+- wakeup-parent:
+ Usage: optional
+ Value type:
+ Definition: A phandle to the wakeup interrupt controller for the SoC.
+
+- wakeup-irq:
+ Usage: optional:
+ Value type:
+ Definition: Specifies the map of the gpio and the corresponding PDC
+ output port.
+
- gpio-controller:
Usage: required
Value type:
@@ -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 = <>;
+ 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 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
