From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [Qualcomm PM8921 MFD 2/6] mfd: pm8xxx: Add irq support
Date: Wed, 2 Mar 2011 22:46:16 +0000 [thread overview]
Message-ID: <20110302224616.GB32325@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1299104001-5240-3-git-send-email-adharmap@codeaurora.org>
On Wed, Mar 02, 2011 at 02:13:17PM -0800, adharmap at codeaurora.org wrote:
>
> Change-Id: Ibb23878cd382af9a750d62ab49482f5dc72e3714
> Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Remove the change IDs from upstream submissions. The kernel doesn't use
gerritt.
> struct pm8921 {
> - struct device *dev;
> + struct device *dev;
> + struct device *irq_dev;
Is it really useful to register a struct device purely for the interrupt
controller? I'd have expected this to be core functionality of the
device. The fact that you need to store the device at all is a bit odd
too as you're using the MFD API.
> static struct pm8xxx_drvdata pm8921_drvdata = {
> - .pmic_readb = pm8921_readb,
> - .pmic_writeb = pm8921_writeb,
> - .pmic_read_buf = pm8921_read_buf,
> - .pmic_write_buf = pm8921_write_buf,
> + .pmic_readb = pm8921_readb,
> + .pmic_writeb = pm8921_writeb,
> + .pmic_read_buf = pm8921_read_buf,
> + .pmic_write_buf = pm8921_write_buf,
> + .pmic_read_irq_stat = pm8921_read_irq_stat,
> +};
It'd seem better to indent things as per the final driver in the first
patch - this reindentation creates a lot of noise in the diff.
> goto err_read_rev;
> }
> - pr_info("PMIC revision: %02X\n", val);
> + pr_info("PMIC revision 1: %02X\n", val);
> + rev = val;
>
Again, do this in the first patch.
> +static int
> +pm8xxx_read_block(const struct pm_irq_chip *chip, u8 bp, u8 *ip)
> +{
> + int rc;
> +
> + rc = pm8xxx_writeb(chip->dev->parent,
> + SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
> + if (rc) {
> + pr_err("Failed Selecting Block %d rc=%d\n", bp, rc);
> + goto bail_out;
> + }
> +
> + rc = pm8xxx_readb(chip->dev->parent,
> + SSBI_REG_ADDR_IRQ_IT_STATUS, ip);
> + if (rc)
> + pr_err("Failed Reading Status rc=%d\n", rc);
> +bail_out:
> + return rc;
> +}
The namespacing here is odd, this looks like it should be a generic API
not a block specific one.
> + /* Check IRQ bits */
> + for (k = 0; k < 8; k++) {
> + if (bits & (1 << k)) {
> + pmirq = block * 8 + k;
> + irq = pmirq + chip->irq_base;
> + /* Check spurious interrupts */
> + if (((1 << k) & chip->irqs_allowed[block])) {
> + /* Found one */
> + chip->irqs_to_handle[*handled] = irq;
> + (*handled)++;
> + } else { /* Clear and mask wrong one */
> + config = PM_IRQF_W_C_M |
> + (k << PM_IRQF_BITS_SHIFT);
> +
> + pm8xxx_config_irq(chip,
> + block, config);
> +
> + if (pm8xxx_can_print())
> + pr_err("Spurious IRQ: %d "
> + "[block, bit]="
> + "[%d, %d]\n",
> + irq, block, k);
> + }
The generic IRQ code should be able to take care of spurious interrupts
for you? It's a bit surprising that there's all this logic - I'd expect
an IRQ chip to just defer logic about which interrupts are valid and so
on to the generic IRQ code.
> #include <linux/device.h>
> +#include <linux/mfd/pm8xxx/irq.h>
> +
> +#define NR_PM8921_IRQS 256
Traditionally this'd be namespaced like this:
+#define PM8921_NR_IRQS 256
next prev parent reply other threads:[~2011-03-02 22:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-02 22:13 [Qualcomm PM8921 MFD 0/6] *** SUBJECT HERE *** adharmap at codeaurora.org
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 1/6] mfd: pm8921: Add PMIC 8921 core driver adharmap at codeaurora.org
2011-03-02 22:28 ` Mark Brown
2011-03-03 3:38 ` Abhijeet Dharmapurikar
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 2/6] mfd: pm8xxx: Add irq support adharmap at codeaurora.org
2011-03-02 22:46 ` Mark Brown [this message]
2011-03-03 4:38 ` Abhijeet Dharmapurikar
2011-03-03 15:22 ` Mark Brown
2011-03-03 22:55 ` Abhijeet Dharmapurikar
2011-03-04 11:12 ` Mark Brown
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 3/6] gpio: pm8xxx-gpio: Add pm8xxx gpio driver adharmap at codeaurora.org
2011-07-08 15:44 ` Greg KH
2011-07-08 17:23 ` Abhijeet Dharmapurikar
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 4/6] mfd: pm8xxx-mpp: Add pm8xxx MPP driver adharmap at codeaurora.org
2011-07-08 14:57 ` Greg KH
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 5/6] MAINTAINERS: Add pmic8921, pmic8xxx subdevices maintainers adharmap at codeaurora.org
2011-03-02 22:50 ` Joe Perches
2011-03-03 4:41 ` Abhijeet Dharmapurikar
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 6/6] msm: board-8960: Add support for pm8921 adharmap at codeaurora.org
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=20110302224616.GB32325@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.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).