linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).