From: Scott Wood <scottwood@freescale•com>
To: "Ira W. Snyder" <iws@ovro•caltech.edu>
Cc: herbert@gondor•apana.org.au, B04825@freescale•com,
linuxppc-dev@ozlabs•org, Vishnu@freescale•com,
Dipen.Dudhat@freescale•com, dan.j.williams@intel•com,
Maneesh.Gupta@freescale•com, R58472@freescale•com
Subject: Re: [PATCH 6/8] fsldma: simplify IRQ probing and handling
Date: Wed, 06 Jan 2010 14:51:30 -0600 [thread overview]
Message-ID: <4B44F7D2.4050909@freescale.com> (raw)
In-Reply-To: <20100106183951.GC26426@ovro.caltech.edu>
Ira W. Snyder wrote:
> I don't think this would break any existing hardware. The 83xx all
> shares one IRQ line, and the 85xx/86xx only have per-channel interrupts,
> right? (I'm not an 85xx/86xx guy, I've only got 83xx experience). This
> is what the device trees suggest, anyway.
Right.
>> It looks like the other problem is that the controller interrupt handler
>> is assuming only one bit will be set in the summary register. It should
>> call the channel handler for each bit that is set.
>>
>
> Ok. I thought about doing this, but my changed approach seemed easier.
>
> On the 83xx, we should only need to call the per-channel handler once
> for each group of 8 bits. The original code used ffs(), which seems a
> little wrong. Why call the handler twice if both EOSI and EOCDI are set
> for a channel?
Sorry, I meant call it once per channel that has bits set.
> Should I use a loop + mask, or is there some other neat
> trick I can use?
After you process one channel, it shouldn't have any bits set (and if it
does, it's a new event that needs to be processed), so you could use the
current ffs approach with a while (summary reg != 0) loop around it.
> Ok. All of the in-tree 83xx device trees have 5 interrupts listed. With
> the changes described above, we'll only call request_irq() once in that
> case, and use the per-controller interrupt.
>
> I'll leave the documentation alone, with the exception of marking the
> per-controller interrupt optional.
Hmm, that description is specific to 83xx, and such chips really should
have the controller interrupt specified. The per-channel interrupt
should not be optional, though.
-Scott
next prev parent reply other threads:[~2010-01-06 20:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-01 6:10 fsldma: cleanup driver and fix async_tx compatibility Ira W. Snyder
2010-01-01 6:10 ` [PATCH 1/8] fsldma: reduce kernel text size Ira W. Snyder
2010-01-01 6:10 ` [PATCH 2/8] fsldma: remove unused structure members Ira W. Snyder
2010-01-01 6:10 ` [PATCH 3/8] fsldma: rename struct fsl_dma_chan to struct fsldma_chan Ira W. Snyder
2010-01-01 6:10 ` [PATCH 4/8] fsldma: rename dest to dst for uniformity Ira W. Snyder
2010-01-01 6:10 ` [PATCH 5/8] fsldma: clean up the OF subsystem routines Ira W. Snyder
2010-01-01 6:10 ` [PATCH 6/8] fsldma: simplify IRQ probing and handling Ira W. Snyder
2010-01-06 18:02 ` Scott Wood
2010-01-06 18:39 ` Ira W. Snyder
2010-01-06 20:51 ` Scott Wood [this message]
2010-01-01 6:10 ` [PATCH 7/8] fsldma: rename fsl_chan to fchan Ira W. Snyder
2010-01-06 18:04 ` Scott Wood
2010-01-06 18:19 ` Ira W. Snyder
2010-01-06 18:27 ` Scott Wood
2010-01-06 18:40 ` Ira W. Snyder
2010-01-01 6:10 ` [PATCH 8/8] fsldma: major cleanups and fixes Ira W. Snyder
2010-01-05 6:08 ` fsldma: cleanup driver and fix async_tx compatibility Dudhat Dipen-B09055
2010-01-11 5:47 ` Dudhat Dipen-B09055
2010-01-11 16:29 ` Ira W. Snyder
2010-02-02 7:50 ` Dudhat Dipen-B09055
2010-02-02 15:04 ` Dan Williams
-- strict thread matches above, loose matches on Subject: below --
2010-01-06 23:33 [PATCH 0/8 v2] " Ira W. Snyder
2010-01-06 23:34 ` [PATCH 6/8] fsldma: simplify IRQ probing and handling Ira W. Snyder
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=4B44F7D2.4050909@freescale.com \
--to=scottwood@freescale$(echo .)com \
--cc=B04825@freescale$(echo .)com \
--cc=Dipen.Dudhat@freescale$(echo .)com \
--cc=Maneesh.Gupta@freescale$(echo .)com \
--cc=R58472@freescale$(echo .)com \
--cc=Vishnu@freescale$(echo .)com \
--cc=dan.j.williams@intel$(echo .)com \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=iws@ovro$(echo .)caltech.edu \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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