From: Rob Herring <robh@kernel.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-spi <linux-spi@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/2] spi: dt-bindings: spi-controller: add wakeup-source and interrupts
Date: Fri, 15 Nov 2019 07:52:22 -0600 [thread overview]
Message-ID: <CAL_JsqKUXPTC-fmUowpaHQpuKTfgfQ6D2n7kOZgkYt+MS7OfaA@mail.gmail.com> (raw)
In-Reply-To: <CAKdAkRQBrKOUTW8puakA26ODYW9=0H4VhwFhGQAqMs-cMmj3CQ@mail.gmail.com>
On Thu, Nov 14, 2019 at 5:09 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Thu, Nov 14, 2019 at 2:26 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Nov 12, 2019 at 11:36:53AM -0800, Dmitry Torokhov wrote:
> > > On Tue, Nov 12, 2019 at 07:15:47PM +0000, Mark Brown wrote:
> > > > On Tue, Nov 12, 2019 at 11:03:28AM -0800, Dmitry Torokhov wrote:
> > > > > On Tue, Nov 12, 2019 at 12:03:07PM +0000, Mark Brown wrote:
> > > > > > On Mon, Nov 11, 2019 at 09:54:10PM -0800, Dmitry Torokhov wrote:
> > > >
> > > > > > > + interrupts:
> > > > > > > + items:
> > > > > > > + - description: main interrupt (attention) line.
> > > > > > > + - description: dedicated wakeup interrupt.
> > > > > > > + minItems: 1 # The wakeup interrupt is optional.
> > > >
> > > > > > > + interrupt-names:
> > > > > > > + items:
> > > > > > > + - const: irq
> > > > > > > + - const: wakeup
> > > > > > > + minItems: 1
> > > >
> > > > > > How will this interact with a SPI device that defines interrupts at the
> > > > > > device level, possibly more than one of them? Especially if the device
> > > > > > has its own idea what the interrupts should be called.
> > > >
> > > > > My understanding that individual drivers should be able to override
> > > > > whatever the default behavior core has configured, and the device can
> > > > > establish their own mapping. We have this in I2C and I believe this
> > > > > works well.
> > > >
> > > > > Is the concern about the device tree scheme or SPI core handling?
> > > >
> > > > Both really.
> > >
> > > So as I mentioned, the driver is not forced to use the interrupt
> > > supplied by the SPI core, and the worst thing is that the core
> > > configures the main IRQ as wakeirq and driver would need to call
> > > dev_pm_clear_wake_irq() before switching to correct one. I expect there
> > > will be just a few drivers needing that and many more would benefit from
> > > the default behavior and not needing to repeat the same boilerplate
> > > code.
> > >
> > > As far as scheme goes - I hope that Rob could confirm that we can
> > > override number of interrupts and names in consumers of the binding, as
> > > needed.
> >
> > This won't work. A device schema doesn't override what's defined here,
> > but just further constrains this schema.
> >
> > You could define a "spi irq" schema which devices can include if they
> > want to, but I don't think this pattern is that common to SPI devices.
> > There's not any spec behind compared to say alert irq for SMBus.
> >
> > The 'wakeup' irq name is standardized (for DT), but that's not SPI
> > specific. About all we could define there is 'wakeup-source' is boolean
> > and if there is more than one interrupt, one should be named 'wakeup'.
>
> OK, so what I am hearing is "interrupt"/"interrupt-names" properties
> should be defined in individual device's bindings, and wakeup-source
> can stay in spi-controller.yaml, right?
It could, but it's not SPI specific. I think we should convert
bindings/power/wakeup-source.txt instead. Something like this:
select: true
properties:
wakeup-source:
type: boolean
description: ...
if:
properties:
interrupt-names:
contains:
const: wakeup
required:
- interrupt-names
then:
required:
- wakeup-source
dependencies:
wakeup-source: [ interrupts ]
Rob
> And as far as SPI core goes, we can still do what I proposed, because
> we already handle "first" interrupt as the default one and the drivers
> can override as needed anyway...
>
> Thanks.
>
> --
> Dmitry
next prev parent reply other threads:[~2019-11-15 13:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-12 5:54 [PATCH 0/2] spi: add wakeup handling to SPI core Dmitry Torokhov
2019-11-12 5:54 ` [PATCH 1/2] spi: dt-bindings: spi-controller: add wakeup-source and interrupts Dmitry Torokhov
2019-11-12 12:03 ` Mark Brown
2019-11-12 19:03 ` Dmitry Torokhov
2019-11-12 19:15 ` Mark Brown
2019-11-12 19:36 ` Dmitry Torokhov
2019-11-12 19:42 ` Mark Brown
2019-11-14 22:26 ` Rob Herring
2019-11-14 23:08 ` Dmitry Torokhov
2019-11-15 13:52 ` Rob Herring [this message]
2019-11-15 15:22 ` Mark Brown
2019-11-15 19:43 ` Rob Herring
2019-11-12 5:54 ` [PATCH 2/2] spi: wire up wakeup-source/wakeirq handling Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAL_JsqKUXPTC-fmUowpaHQpuKTfgfQ6D2n7kOZgkYt+MS7OfaA@mail.gmail.com \
--to=robh@kernel.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mark.rutland@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).