From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Mark Brown <broonie@kernel.org>
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 15:58:19 +0200 [thread overview]
Message-ID: <20181214135819.GA2735@localhost.localdomain> (raw)
In-Reply-To: <20181207131418.GB6510@sirena.org.uk>
On Fri, Dec 07, 2018 at 01:14:18PM +0000, Mark Brown wrote:
> On Fri, Dec 07, 2018 at 09:58:29AM +0200, Matti Vaittinen wrote:
> > On Wed, Dec 05, 2018 at 05:27:01PM +0000, Mark Brown wrote:
>
> > d->domain = irq_domain_add_linear(map->dev->of_node,
> > chip->num_irqs,
> > ®map_domain_ops, d);
>
> > where map->dev->of_node points the node added to regmap. And as we
> > really want to use the i2c to access registers, we should have done the
> > regmap using:
>
> > devm_regmap_init_i2c(i2c, ®map);
>
> > where the i2c is the struct i2c_client *. The dev in i2c_client is the
> > i2c device - which has of_node pointing at the "main i2c node" - not the
> > sub block nodes. Hence all irq chips created by regmap_add_irq_chip for
> > this physical i2c slave device will point to the same DT node.
>
> Hrm, right. You'd need to have a proxy regmap for the child devices for
> that. Not ideal.
>
> > bool mask_writeonly:1;
> > + bool no_of:1;
> >
> > and in the regmap_add_irq_chip do:
>
> > node = (chip->no_of) ? NULL : map->dev->of_node;
> > d->domain = irq_domain_add_linear(node, chip->num_irqs,
> > ®map_domain_ops, d);
>
> > 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.
> > > The mapping isn't guaranteed to be a 1:1 mapping - one way this hardware
> > > gets structured is that the central interrupt controller is saying which
> > > IP block is flagging an interrupt rather than which register has an
> > > interrupt set in it. You can then have either more than one detailed
> > > status register for that IP
>
> > Correct. But I guess the IP blocks often have limited set of registers for the
> > "sub interrupts". For such cases my idea would work, right. My RFC
> > handled case where there is many 'sub registers' to read for one 'main
> > bit.
>
> 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...
> > > or several smaller IPs reporting through a
> > > single detailed status register.
>
> > I think that if we have more than two layers of irqs (main and sub) -
> > then we should do cascaded controllers.
>
> Yeah, and my first thought here is that we should just be using cascaded
> controllers all the time (but like I say I'm not 100% certain on that).
>
> > > Right, it's about working out which subregister to read - the point is
> > > you can do this by adding a link in either direction, I'm suggesting
> > > doing it from the individual interrupt to the main register since we
> > > already have individual data structures for those and it feels less
> > > likely to run into hard to represent corner cases.
>
> > 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.
--
Matti Vaittinen
ROHM Semiconductors
~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
next prev parent reply other threads:[~2018-12-14 14:17 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 [this message]
2018-12-14 17:26 ` Mark Brown
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=20181214135819.GA2735@localhost.localdomain \
--to=matti.vaittinen@fi.rohmeurope.com \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--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.