From: Mark Brown <broonie@kernel.org>
To: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] regmap-irq: add "main register" and level-irq support
Date: Fri, 14 Dec 2018 17:26:19 +0000 [thread overview]
Message-ID: <20181214172619.GC6467@sirena.org.uk> (raw)
In-Reply-To: <20181214135819.GA2735@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]
On Fri, Dec 14, 2018 at 03:58:19PM +0200, Matti Vaittinen wrote:
> On Fri, Dec 07, 2018 at 01:14:18PM +0000, Mark Brown wrote:
> > > Then we could have chip->no_of set for the 'main irq chip' and for those
> > > chips we don't wan't to expose via DT. In my case I would leave no_of
> > > unset only for the irq-chip which I created for the GPIO? Is this a
> > > silly idea?
> > That's worth a shot, yes - I'd need to see it fully fleshed out I think
> > but it looks sensible (no ternery operator please).
> Do you think this would be benefical even if we add the 'main irq
> support'? If so, I can generate a patch out of this. I think this would
> really suffice for my current need - but this stops wokrking as soon as
> more than one sub-irq-chip want's to expose interrupts via DT.
Hrm, yeah. That's a thing. I think I'd misvisualized the DT change as
being the other way around for some reason.
> > Your idea definitely works for the current case, yes - I'm just thinking
> > about future edge and extension cases.
> I could send an example on how the driver utilizing the original RFC
> interface would look like. I am starting to think it was not *that* bad
> after all...
That might help, yes.
> > > I see your point now. But as I said, I am not sure we should add the
> > > overhead of 'main irq bit description' for simple cases just to cover
> > > the corner cases. Yet I can try seeing what I can come up with if you
> > > think this is the way to go.
> > If you could take a look that'd be great.
> I did some experiment. I will post this as another RFC - but I am really
> not terribly happy about it. It's complex (well, in my opinion) and I am
> not sure the driver interface is much easier. But you can see it
> yourself.
Great, I'll take a proper look on Monday. Thanks for putting the time
in here!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-12-14 17:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 8:59 [RFC] regmap-irq: add "main register" and level-irq support Matti Vaittinen
2018-12-04 17:21 ` Mark Brown
2018-12-05 8:22 ` Matti Vaittinen
2018-12-05 17:27 ` Mark Brown
2018-12-07 7:58 ` Matti Vaittinen
2018-12-07 13:14 ` Mark Brown
2018-12-14 13:58 ` Matti Vaittinen
2018-12-14 17:26 ` Mark Brown [this message]
2018-12-17 8:19 ` Matti Vaittinen
2018-12-17 8:30 ` Matti Vaittinen
2018-12-17 18:50 ` Mark Brown
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=20181214172619.GC6467@sirena.org.uk \
--to=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=rafael@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.