From: Roger Quadros <rogerq@ti.com>
To: Felipe Balbi <balbi@kernel.org>
Cc: tony@atomide.com, Joao.Pinto@synopsys.com,
sergei.shtylyov@cogentembedded.com, peter.chen@freescale.com,
jun.li@freescale.com, grygorii.strashko@ti.com,
yoshihiro.shimoda.uh@renesas.com, nsekhar@ti.com, b-liu@ti.com,
linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq()
Date: Wed, 11 May 2016 14:46:13 +0300 [thread overview]
Message-ID: <57331B85.2000003@ti.com> (raw)
In-Reply-To: <87y47hexja.fsf@linux.intel.com>
On 11/05/16 12:47, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rogerq@ti.com> writes:
>>> Roger Quadros <rogerq@ti.com> writes:
>>>>>> @@ -497,8 +503,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>>>>>> /* check the DMA Status */
>>>>>> reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>>>>>>
>>>>>> - ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
>>>>>> - "dwc3-omap", omap);
>>>>>> + ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
>>>>>> + NULL, 0, "dwc3-omap", omap);
>>>>>
>>>>> if you're using threaded_irq, it's better to have a NULL top half and
>>>>> valid bottom half.
>>>>
>>>> But in this case we don't need a bottom half as there is nothing to do :).
>>>>
>>>>>
>>>>> In fact, since this will be shared, you could do a proper preparation
>>>>> and on top half check if $this device generated the IRQ and
>>>>> conditionally schedule the bottom half. Don't forget to mask device's
>>>>> interrupts from top half so you can run without IRQF_ONESHOT.
>>>>>
>>>>
>>>> Why do this at all if there is nothing to do in the bottom half?
>>>
>>> oh, but there is :-)
>>>
>>> The whole idea of threaded IRQs is that you spend as little time as
>>> possible on top half and the (strong) recommendation is that you *only*
>>> check if $this device generated the interrupt. Note that "checking if
>>> $this device generated the interrupt" will be mandatory as soon as you
>>> mark the IRQ line as shared ;-)
>>>
>>> So here's how this should look like:
>>>
>>> static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
>>> {
>>> struct dwc3_omap *omap = _omap;
>>> u32 reg;
>>>
>>> reg = readl(IRQSTATUS)
>>> if (reg) {
>>> mask_interrupts(omap);
>>> return IRQ_WAKE_THREAD;
>>> }
>>>
>>> return IRQ_HANDLED;
>>
>> This should be IRQ_NONE right?
>
> possibly, testing will say ;-)
>
>>> static irqreturn_t dwc3_omap_threaded_interrupt(int irq, void *_omap)
>>> {
>>> struct dwc3_omap *omap = _omap;
>>> u32 reg;
>>>
>>> spin_lock(&omap->lock);
>>
>> Do we really need a spin_lock for the dwc3-omap driver?
>> Currently we won't be doing anything other than just
>> clearing the irqstatus and re-enabling the interrupts.
>
> well, if there's no possibility of races, then no. But only testing will
> say for sure, I guess. I didn't really go through the entire thing just
> to a write a quick little template :-p
>
OK. Another hurdle I have is that how do I mask/unmask the interrupts?
I do not see any masking bits, only enable/disable bits.
I don't think we can use the enable/disable bits to mask as we'd loose
events while the event is disabled.
cheers,
-roger
WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq@ti.com>
To: Felipe Balbi <balbi@kernel.org>
Cc: <tony@atomide.com>, <Joao.Pinto@synopsys.com>,
<sergei.shtylyov@cogentembedded.com>, <peter.chen@freescale.com>,
<jun.li@freescale.com>, <grygorii.strashko@ti.com>,
<yoshihiro.shimoda.uh@renesas.com>, <nsekhar@ti.com>,
<b-liu@ti.com>, <linux-usb@vger.kernel.org>,
<linux-omap@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq()
Date: Wed, 11 May 2016 14:46:13 +0300 [thread overview]
Message-ID: <57331B85.2000003@ti.com> (raw)
In-Reply-To: <87y47hexja.fsf@linux.intel.com>
On 11/05/16 12:47, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rogerq@ti.com> writes:
>>> Roger Quadros <rogerq@ti.com> writes:
>>>>>> @@ -497,8 +503,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>>>>>> /* check the DMA Status */
>>>>>> reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>>>>>>
>>>>>> - ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
>>>>>> - "dwc3-omap", omap);
>>>>>> + ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
>>>>>> + NULL, 0, "dwc3-omap", omap);
>>>>>
>>>>> if you're using threaded_irq, it's better to have a NULL top half and
>>>>> valid bottom half.
>>>>
>>>> But in this case we don't need a bottom half as there is nothing to do :).
>>>>
>>>>>
>>>>> In fact, since this will be shared, you could do a proper preparation
>>>>> and on top half check if $this device generated the IRQ and
>>>>> conditionally schedule the bottom half. Don't forget to mask device's
>>>>> interrupts from top half so you can run without IRQF_ONESHOT.
>>>>>
>>>>
>>>> Why do this at all if there is nothing to do in the bottom half?
>>>
>>> oh, but there is :-)
>>>
>>> The whole idea of threaded IRQs is that you spend as little time as
>>> possible on top half and the (strong) recommendation is that you *only*
>>> check if $this device generated the interrupt. Note that "checking if
>>> $this device generated the interrupt" will be mandatory as soon as you
>>> mark the IRQ line as shared ;-)
>>>
>>> So here's how this should look like:
>>>
>>> static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
>>> {
>>> struct dwc3_omap *omap = _omap;
>>> u32 reg;
>>>
>>> reg = readl(IRQSTATUS)
>>> if (reg) {
>>> mask_interrupts(omap);
>>> return IRQ_WAKE_THREAD;
>>> }
>>>
>>> return IRQ_HANDLED;
>>
>> This should be IRQ_NONE right?
>
> possibly, testing will say ;-)
>
>>> static irqreturn_t dwc3_omap_threaded_interrupt(int irq, void *_omap)
>>> {
>>> struct dwc3_omap *omap = _omap;
>>> u32 reg;
>>>
>>> spin_lock(&omap->lock);
>>
>> Do we really need a spin_lock for the dwc3-omap driver?
>> Currently we won't be doing anything other than just
>> clearing the irqstatus and re-enabling the interrupts.
>
> well, if there's no possibility of races, then no. But only testing will
> say for sure, I guess. I didn't really go through the entire thing just
> to a write a quick little template :-p
>
OK. Another hurdle I have is that how do I mask/unmask the interrupts?
I do not see any masking bits, only enable/disable bits.
I don't think we can use the enable/disable bits to mask as we'd loose
events while the event is disabled.
cheers,
-roger
next prev parent reply other threads:[~2016-05-11 11:46 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 9:51 [PATCH v7 0/5] dwc3: omap: fixes and dual-role preparation Roger Quadros
2016-05-10 9:51 ` Roger Quadros
2016-05-10 9:51 ` [PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq() Roger Quadros
2016-05-10 9:51 ` Roger Quadros
[not found] ` <1462873919-20532-2-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
2016-05-10 9:58 ` Felipe Balbi
2016-05-10 9:58 ` Felipe Balbi
2016-05-10 10:04 ` Roger Quadros
2016-05-10 10:04 ` Roger Quadros
2016-05-10 10:12 ` Felipe Balbi
[not found] ` <87y47igr1g.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-05-10 10:21 ` Roger Quadros
2016-05-10 10:21 ` Roger Quadros
2016-05-11 8:17 ` Roger Quadros
2016-05-11 8:17 ` Roger Quadros
2016-05-11 9:47 ` Felipe Balbi
2016-05-11 11:46 ` Roger Quadros [this message]
2016-05-11 11:46 ` Roger Quadros
2016-05-11 12:39 ` Felipe Balbi
2016-05-11 13:52 ` Roger Quadros
2016-05-11 13:52 ` Roger Quadros
2016-05-10 9:51 ` [PATCH v7 2/5] usb: dwc3: omap: Mark the interrupt handler as shared Roger Quadros
2016-05-10 9:51 ` Roger Quadros
2016-05-10 9:51 ` [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT Roger Quadros
2016-05-10 9:51 ` Roger Quadros
[not found] ` <1462873919-20532-4-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
2016-05-10 9:54 ` Felipe Balbi
2016-05-10 9:54 ` Felipe Balbi
2016-05-10 9:59 ` Roger Quadros
2016-05-10 9:59 ` Roger Quadros
2016-05-10 10:04 ` Felipe Balbi
2016-05-10 10:23 ` Roger Quadros
2016-05-10 10:23 ` Roger Quadros
2016-05-10 10:33 ` Felipe Balbi
2016-05-10 10:24 ` Roger Quadros
2016-05-10 10:24 ` Roger Quadros
2016-05-10 9:51 ` [PATCH v7 4/5] usb: dwc3: omap: Pass VBUS and ID events transparently Roger Quadros
2016-05-10 9:51 ` Roger Quadros
[not found] ` <1462873919-20532-5-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
2016-05-10 9:55 ` Felipe Balbi
2016-05-10 9:55 ` Felipe Balbi
2016-05-10 10:00 ` Roger Quadros
2016-05-10 10:00 ` Roger Quadros
2016-05-10 10:05 ` Felipe Balbi
[not found] ` <871t5ai5ye.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-05-10 10:13 ` Roger Quadros
2016-05-10 10:13 ` Roger Quadros
2016-05-10 10:13 ` Felipe Balbi
2016-05-10 9:51 ` [PATCH v7 5/5] usb: dwc3: core: cleanup IRQ resources Roger Quadros
2016-05-10 9:51 ` Roger Quadros
2016-05-10 10:03 ` Felipe Balbi
2016-05-10 10:03 ` Felipe Balbi
2016-05-10 10:10 ` Roger Quadros
2016-05-10 10:10 ` Roger Quadros
2016-05-10 10:14 ` Felipe Balbi
[not found] ` <87shxqgqyw.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-05-10 11:45 ` Roger Quadros
2016-05-10 11:45 ` Roger Quadros
2016-05-10 11:48 ` Felipe Balbi
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=57331B85.2000003@ti.com \
--to=rogerq@ti.com \
--cc=Joao.Pinto@synopsys.com \
--cc=b-liu@ti.com \
--cc=balbi@kernel.org \
--cc=grygorii.strashko@ti.com \
--cc=jun.li@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=peter.chen@freescale.com \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=tony@atomide.com \
--cc=yoshihiro.shimoda.uh@renesas.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.