From: Lee Jones <lee.jones@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/7] mfd: pm8921: Migrate to irqdomains
Date: Tue, 7 Jan 2014 08:22:33 +0000 [thread overview]
Message-ID: <20140107082233.GB3182@lee--X1> (raw)
In-Reply-To: <52CB1323.6080200@codeaurora.org>
> >> unsigned int num_irqs;
> >> unsigned int num_blocks;
> >> unsigned int num_masters;
> >> @@ -138,7 +137,7 @@ static int pm8xxx_irq_block_handler(struct pm_irq_chip *chip, int block)
> >> for (i = 0; i < 8; i++) {
> >> if (bits & (1 << i)) {
> >> pmirq = block * 8 + i;
> >> - irq = pmirq + chip->irq_base;
> >> + irq = irq_find_mapping(chip->domain, pmirq);
> > Going by this patch only, it appears you're calling irq_find_mapping()
> > before you've called irq_create_mapping(). This won't work, so unless
> > you've called the latter in a previous patch, you should ensure that
> > you do so.
> >
>
> Interrupts seem to work. I think that's because the mapping is created
> when the consumer drivers call request_irq().
>
> From what I can tell, if we call irq_find_mapping() and there is no
> mapping associated with it then we have a spurious irq. If that happens
> we'll call handle_generic_irq() with 0 and that will cause
> handle_bad_irq() to be called and a debug message to be logged. That
> seems like a good outcome.
I would try to adhere to the documentation in case we are missing
something or some of the semantics change. Please read:
Documentation/IRQ-domain.txt. Specifically, "=== irq_domain usage ==="
from line 39, which says to call irq_create_mapping() to indeed, create
the mapping.
> > What does the sizeof(u8) add here?
> >
>
> This was just keeping the same code that was already there. I will do
> sizeof(chip->config[0]) instead which is more future proof if that array
> changes type later on.
Ah, now I see what it's doing. Perhaps brackets would be of use to
ensure readers aren't confused. I also think the sizeof() would be
helpful too, so:
chip = devm_kzalloc(&pdev->dev, sizeof(*chip) +
(sizeof(chip->config[0]) * nirqs), GFP_KERNEL);
> >> + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >> +}
> > Can't you use the MFD core instead?
> >
>
> Are you suggesting using mfd_add_devices()? At first glance it looks
> like that would require an array of mfd_cell structures that do nothing
> besides match compatible strings in the DT. Using of_platform_populate()
> achieves the same goal and doesn't require an array of mfd_cell
> structures for each different pm8xxx chip that comes along, meaning
> simpler code.
I'm inclined to agree, but playing Devil's advocate here, as a device
using the MFD subsystem it's often clearer to readers and other people
looking for examples if the MFD core functionality is used. For
instance, I now have no idea what devices the PM8xxx encompasses
without looking at the DTS file. A small cell structure is a small
price to pay for code clarity IMHO.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-01-07 8:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-23 20:45 [PATCH v2 0/7] Modernize pm8921 with irqdomains, regmap, DT Stephen Boyd
2013-12-23 20:45 ` [PATCH v2 1/7] mfd: Move pm8xxx-irq.c contents into only driver that uses it Stephen Boyd
2014-01-06 14:47 ` Lee Jones
2013-12-23 20:45 ` [PATCH v2 2/7] mfd: pm8921: Update for genirq changes Stephen Boyd
2013-12-23 20:45 ` [PATCH v2 3/7] mfd: pm8921: Migrate to irqdomains Stephen Boyd
2014-01-06 15:53 ` Lee Jones
2014-01-06 20:33 ` Stephen Boyd
2014-01-07 8:22 ` Lee Jones [this message]
2014-01-07 19:54 ` Stephen Boyd
2014-01-08 8:14 ` Lee Jones
2013-12-23 20:46 ` [PATCH v2 4/7] mfd: ssbi: Add regmap read/write helpers Stephen Boyd
2013-12-24 12:54 ` Mark Brown
2013-12-26 19:41 ` Stephen Boyd
2013-12-28 14:52 ` Mark Brown
2014-01-06 11:50 ` Lee Jones
2014-01-06 22:26 ` Stephen Boyd
2013-12-23 20:46 ` [PATCH v2 5/7] mfd: pm8921: Use ssbi regmap Stephen Boyd
2013-12-30 12:34 ` Mark Brown
2013-12-23 20:46 ` [PATCH v2 6/7] mfd: pm8921: Add DT match table Stephen Boyd
2014-01-06 11:52 ` Lee Jones
2014-01-06 18:03 ` Stephen Boyd
[not found] ` <1387831563-13535-1-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-12-23 20:46 ` [PATCH v2 7/7] devicetree: bindings: Document PM8921/8058 PMICs Stephen Boyd
2014-01-06 11:53 ` Lee Jones
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=20140107082233.GB3182@lee--X1 \
--to=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sameo@linux.intel.com \
--cc=sboyd@codeaurora.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).