Thread (22 messages) 22 messages, 5 authors, 2019-04-04

Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes

From: Brian Norris <briannorris@chromium.org>
Date: 2019-02-28 02:35:44
Also in: linux-arm-kernel, linux-devicetree, linux-pm, linux-rockchip, linux-wireless, lkml

Hi Rafael,

On Wed, Feb 27, 2019 at 3:04 PM Rafael J. Wysocki [off-list ref] wrote:
On Wed, Feb 27, 2019 at 9:58 PM Brian Norris [off-list ref] wrote:
quoted
On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
quoted
So I'd argue that we should add an optional 'wake-gpio' DT property
instead to the generic PCI device binding, and leave the interrupt
binding and discovery alone.
So I think Mark Rutland already shot that one down; it's conceptually an
interrupt from the device's perspective.
Perhaps I shouldn't speak for Mark, but I am basically quoting him off IRC.
Which device are you talking about?  The one that signals wakeup?  If
so, then I beg to differ.
Yes, the endpoint device.
On ACPI platforms WAKE# is represented as an ACPI GPE that is signaled
through SCI and handled at a different level (on HW-reduced ACPI it
actually can be a GPIO interrupt, but it still is handled with the
help of AML).  The driver of the device signaling wakeup need not even
be aware that WAKE# has been asserted.
Frankly, ACPI is not relevant to how we represent WAKE# in DT, IMO.
Also, we're talking about the *device*, not the driver. When talking
about Device Tree, that distinction is relevant.

So while the driver need not be aware (and I agree! it only needs to
care about enabling/disabling wake), *something* should be aware, and
the signal that "something" should be receiving is simply "did WAKE
happen"? That sounds basically like the device is signalling an
interrupt to me.

Maybe this goes back to some confusion we had elsewhere: what is the
meaning of "interrupt" in device tree?
quoted
We just need to figure out a good way of representing it that doesn't stomp on the existing INTx
definitions.
WAKE# is a signal that is converted into an interrupt, but that
interrupt may arrive at some place your driver has nothing to do with.
I could agree with that, perhaps. But that's also what Device Tree is
all about, really. We describe the relation between devices. So some
other <foo> handles events that are triggered by <bar>, so we use a
phandle to relate <bar> to <foo>.
It generally doesn't make sense to represent it as an interrupt for
the target device.
What would you suggest then? I'm not clearly understanding how you
think we should (a) describe (in DT) and (b) implement this WAKE#
handling.

Brian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help