All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Mark Brown <broonie@kernel.org>
Cc: mazziesaccount@gmail.com, gregkh@linuxfoundation.org,
	rafael@kernel.org, linux-kernel@vger.kernel.org,
	heikki.haikola@fi.rohmeurope.com,
	mikko.mutanen@fi.rohmeurope.com
Subject: Re: [RFC v2] regmap: regmap-irq: Add main status register support
Date: Tue, 18 Dec 2018 10:58:03 +0200	[thread overview]
Message-ID: <20181218085803.GD2477@localhost.localdomain> (raw)
In-Reply-To: <20181217173244.GE27909@sirena.org.uk>

On Mon, Dec 17, 2018 at 05:32:44PM +0000, Mark Brown wrote:
> On Fri, Dec 14, 2018 at 04:08:12PM +0200, Matti Vaittinen wrote:
> 
> > This is draft for approach proposed by Mark here:
> > http://lkml.iu.edu/hypermail/linux/kernel/1812.1/07117.html
> 
> > Pretty untested and diff is done against tree where the level active IRQ
> > support for regmap-irq was added. So please consider this just as a RFC
> > introducing the concept. I will format correct and better tested patch if
> > this is the preferred way to go.
> 
> Hrm, so the parsing code is indeed quite complicated.  I suspect it
> could be simplified if instead of trying to allocate just what's used it
> was a bit more wasteful and allocated the biggest arrays we might need
> but I'm not sure how much that'd really help so yeah, doing it the other
> way around might be better.

It might get a little bit simpler but not much I think. And the driver
interface could be a little bit simpler if we drop the support for
giving the "main bit mapping" as an array and only support giving the
main bits in the struct regmap_irqs. Then the num_main_status_bits,
num_main_regs and sub_reg_offsets could be made internal to regmap-irq.

OTOH dropping num_main_regs would add up one more thing requiring
dynamic allocation as we could not compute the number of main register
bits in advance.

I will proceed with the RFC v1 approach. Nothing prevents us from
implementing the v2 later if there is use-cases for that. But it will
take a while before I get this thing tested and user for it.
Additionally I guess we do need a bui-in from Lee as most of this kind
of devices with many sub blocks are likely to be represented as MFD
devices. I guess I should have included him in the recipient list for
the RFCs :/

Thanks for all the support this far!

Br,
	Matti Vaittinen

-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he vanished ~~~

      reply	other threads:[~2018-12-18  8:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-14 14:08 [RFC v2] regmap: regmap-irq: Add main status register support Matti Vaittinen
2018-12-17 17:32 ` Mark Brown
2018-12-18  8:58   ` Matti Vaittinen [this message]

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=20181218085803.GD2477@localhost.localdomain \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.haikola@fi.rohmeurope.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    --cc=mikko.mutanen@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.