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
