From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
Laxman Dewangan <ldewangan@nvidia.com>,
Liam Girdwood <lrg@ti.com>,
linux-kernel@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org,
Gyungoh Yoo <jack.yoo@maxim-ic.com>,
Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCH] mfd: add MAX8907 core driver
Date: Thu, 26 Jul 2012 21:35:26 +0100 [thread overview]
Message-ID: <20120726203526.GD4560@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1343331630-27126-1-git-send-email-swarren@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]
On Thu, Jul 26, 2012 at 01:40:30PM -0600, Stephen Warren wrote:
> +struct max8907_irq_data {
> + int reg;
> + int mask_reg;
> + int offs; /* bit offset in mask register */
> + bool is_rtc;
> +};
This (and all the code in here) looks very much like regmap-irq (or one
of the pre-regmap drivers I wrote which were factored out to there)...
why can't we use regmap_irq?
Looking at the code it looks like a very similar pattern to the arizona
chips where you've got two IRQ domains in the chip which can be handled
with a single virtual IRQ to do the demux. We could factor that out
too easily enough, I might just do that...
> + if (!irqd_irq_disabled(d) && (value & irq_data->offs)) {
This looks very suspicious... why do we need to call
irqd_irq_disabled() here?
> + regmap_write(chip->regmap_gen, MAX8907_REG_CHG_IRQ1_MASK, irq_chg[0]);
> + regmap_write(chip->regmap_gen, MAX8907_REG_CHG_IRQ2_MASK, irq_chg[1]);
> + regmap_write(chip->regmap_gen, MAX8907_REG_ON_OFF_IRQ1_MASK,
> + irq_on[0]);
> + regmap_write(chip->regmap_gen, MAX8907_REG_ON_OFF_IRQ2_MASK,
> + irq_on[1]);
> + regmap_write(chip->regmap_rtc, MAX8907_REG_RTC_IRQ_MASK, irq_rtc);
If you have the cache enabled regmap_update_bits() is your friend here,
it'll suppress duplicate I/O.
> +static void max8907_irq_enable(struct irq_data *data)
> +{
> + /* Everything happens in max8907_irq_sync_unlock */
> +}
> +static void max8907_irq_disable(struct irq_data *data)
> +{
> + /* Everything happens in max8907_irq_sync_unlock */
> +}
The fact that these functions are empty is the second part of the above
suspicous check for disabled IRQs. We're just completely ignoring the
caller here. What would idiomatically happen is that we'd update a
variable here then write it out in the unmask.
If these functions really should be empty then they should be omitted.
> +static int max8907_irq_set_wake(struct irq_data *data, unsigned int on)
> +{
> + /* Everything happens in max8907_irq_sync_unlock */
> +
> + return 0;
> +}
Again, this doesn't look clever at all.
> + if (irqd_is_wakeup_set(d)) {
> + /* 1 -- disable, 0 -- enable */
> + switch (irq_data->mask_reg) {
This loop we should just port over into the regmap code.
> +static const struct regmap_config max8907_regmap_gen_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .volatile_reg = max8907_gen_is_volatile_reg,
> + .writeable_reg = max8907_gen_is_writeable_reg,
> + .max_register = MAX8907_REG_LDO20VOUT,
> + .cache_type = REGCACHE_RBTREE,
> +};
Your IRQ registers appear to be clear on read which means you should
have a precious_reg callback too otherwise someone looking at the
register map in debugfs can ack interrupts.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-07-26 20:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 19:40 [PATCH] mfd: add MAX8907 core driver Stephen Warren
2012-07-26 20:35 ` Mark Brown [this message]
[not found] ` <20120726203526.GD4560-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-07-26 21:14 ` Stephen Warren
2012-07-26 21:51 ` Mark Brown
2012-07-26 22:07 ` Stephen Warren
2012-07-26 22:16 ` Mark Brown
2012-07-27 6:36 ` Laxman Dewangan
-- strict thread matches above, loose matches on Subject: below --
2012-08-01 20:48 Stephen Warren
2012-08-02 16:15 ` Mark Brown
2012-08-02 17:11 ` Stephen Warren
2012-08-02 17:56 ` 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=20120726203526.GD4560@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=jack.yoo@maxim-ic.com \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=sameo@linux.intel.com \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.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 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).