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.com \
--cc=B04825@freescale.com \
--cc=Dipen.Dudhat@freescale.com \
--cc=Maneesh.Gupta@freescale.com \
--cc=R58472@freescale.com \
--cc=Vishnu@freescale.com \
--cc=dan.j.williams@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=iws@ovro.caltech.edu \
--cc=linuxppc-dev@ozlabs.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 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.