From: adharmap@codeaurora.org (Abhijeet Dharmapurikar)
To: linux-arm-kernel@lists.infradead.org
Subject: [Qualcomm PM8921 MFD v2 2/6] mfd: pm8xxx: Add irq support
Date: Thu, 10 Mar 2011 20:43:09 -0800 [thread overview]
Message-ID: <4D79A85D.8000301@codeaurora.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1103101126100.2787@localhost6.localdomain6>
Thomas Gleixner wrote:
> On Tue, 8 Mar 2011, Abhijeet Dharmapurikar wrote:
>> Thomas Gleixner wrote:
>>> On Mon, 7 Mar 2011, adharmap at codeaurora.org wrote:
>>>> + if (pdata->irq_pdata) {
>>> So if pdata->irq_pdata == NULL you return success. Is that correct ?
>> Yes. The board configuration may choose not to use pmic interrupts.
>
> Ok.
>
>>> Also please return early on (!pdata->irq_pdata) and avoid that extra
>>> indent level for the real code path.
>> I did not do that because there are other subdevices that I will be adding in
>> the later patches. I cannot return early. well I will change it for this
>> patch.
>
> Maybe splitting out the various init subsections into different
> functions which are called from here might be a good thing.
>
>>>> +static void pm8xxx_irq_ack(struct irq_data *d)
>>>> +{
>>>> + const struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>>>> + unsigned int pmirq = d->irq - chip->irq_base;
>>>> + u8 block, config;
>>>> +
>>>> + block = pmirq / 8;
>>>> +
>>>> + config = PM_IRQF_WRITE | chip->config[pmirq] | PM_IRQF_CLR;
>>>> + /* Keep the mask */
>>>> + if (!(chip->irqs_allowed[block] & (1 << (pmirq % 8))))
>>>> + config |= PM_IRQF_MASK_FE | PM_IRQF_MASK_RE;
>>> What's the point of this exercise? ack is called before mask and it
>> The register design is such that we cannot only clear the interrupt. One has
>> to write to the trigger bits while clearing it. Now trigger bits define
>> whether the interrupt is masked or unmasked. If unmasked they define whether
>> the interrupt rising/falling/level high/level low triggered.
>> So the code remembers which interrupts are masked and for them it clears and
>> rewrite the masked status in trigger bits. For unmasked ones it clears and
>> writes to the trigger bits essentially configuring them same way as it was
>> before. That is why the if satement to check interrupt was masked earlier,
>> chip->irqs_allowed[] maintains which interrupt are unmasked.
>>
>>> ack is called before mask and it
>>> should never be called when the interrupt is masked.
>> I didnt quite understand this comment. handle_level_irq calls mask_ack which
>> masks the interrupt and then acks it. In this case the ack is called after the
>
> Indeed, sorry. So the right way to deal with that is to provide a
> mask_ack() callback which does it in the correct order for your
> HW. That way you avoid all the local state storage.
Yes however while updating the code I noticed that I would need to keep
account of all the interrupts enabled and all the interrupts marked
wakeup. This aids in switching to the wakeup set in the suspend callback
and the enabled set in the resume callback. I will update the resume
callback to enable the interrupts in irqs_allowed(the local state
storage) in the next patch (my current patch does not do that).
IOW I need to keep the local state storage.
>
> Thanks,
>
> tglx
--
--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm
Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2011-03-11 4:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-08 6:09 [Qualcomm PM8921 MFD v2 0/6] pmic 8921 core and subdevices adharmap at codeaurora.org
2011-03-08 6:09 ` [Qualcomm PM8921 MFD v2 1/6] mfd: pm8921: Add PMIC 8921 core driver adharmap at codeaurora.org
2011-03-08 17:58 ` Randy Dunlap
2011-03-08 6:09 ` [Qualcomm PM8921 MFD v2 2/6] mfd: pm8xxx: Add irq support adharmap at codeaurora.org
2011-03-08 12:04 ` Thomas Gleixner
2011-03-09 5:21 ` Abhijeet Dharmapurikar
2011-03-10 10:32 ` Thomas Gleixner
2011-03-11 4:43 ` Abhijeet Dharmapurikar [this message]
2011-03-11 17:57 ` Thomas Gleixner
2011-03-11 19:02 ` Abhijeet Dharmapurikar
2011-03-11 19:43 ` Thomas Gleixner
2011-03-11 19:57 ` Mark Brown
2011-03-11 20:12 ` Thomas Gleixner
2011-03-11 20:06 ` Abhijeet Dharmapurikar
2011-03-11 20:37 ` Thomas Gleixner
2011-03-12 0:13 ` Abhijeet Dharmapurikar
2011-03-08 6:09 ` [Qualcomm PM8921 MFD v2 3/6] gpio: pm8xxx-gpio: Add pm8xxx gpio driver adharmap at codeaurora.org
2011-03-12 9:36 ` Grant Likely
2011-03-16 18:55 ` Abhijeet Dharmapurikar
2011-03-16 19:54 ` Grant Likely
2011-03-16 19:56 ` Mark Brown
2011-03-16 23:06 ` Grant Likely
2011-03-08 6:09 ` [Qualcomm PM8921 MFD v2 4/6] mfd: pm8xxx-mpp: Add pm8xxx MPP driver adharmap at codeaurora.org
2011-03-08 23:30 ` Mark Brown
2011-03-10 3:36 ` Abhijeet Dharmapurikar
2011-03-10 3:56 ` Trilok Soni
2011-03-10 15:13 ` Mark Brown
2011-03-08 6:09 ` [Qualcomm PM8921 MFD v2 5/6] MAINTAINERS: Add patterns for pmic 8921 files to MSM subsystem adharmap at codeaurora.org
2011-03-08 23:31 ` Mark Brown
2011-03-08 6:09 ` [Qualcomm PM8921 MFD v2 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=4D79A85D.8000301@codeaurora.org \
--to=adharmap@codeaurora.org \
--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).