From: Mark Brown <broonie@kernel.org>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'Nicolin Chen'" <Guangyu.Chen@freescale.com>,
"Li.Xiubo@freescale.com" <Li.Xiubo@freescale.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
Date: Thu, 27 Mar 2014 13:05:29 +0000 [thread overview]
Message-ID: <20140327130529.GK30768@sirena.org.uk> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6EA538@AcuExch.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
On Thu, Mar 27, 2014 at 09:41:20AM +0000, David Laight wrote:
> From: Mark Brown
> > The trace is already conditional? I'd also expect to see the driver
> > only acknowledging sources it knows about and only reporting that the
> > interrupt was handled if it saw one of them - right now all interrupts
> > are unconditionally acknowleged.
> The traces are separately conditional on their own bits.
> That is a lot of checks that will normally be false.
Oh, I see what you mean. I'm not sure that level of optimisation is
worth it, the overhead of taking an interrupt in the first place is
going to dwarf the optimisation and the indentation probably won't help
writing clear messages.
> Also the driver may need to clear all the active interrupt
> bits in order to make the IRQ go away.
> It should trace that bits it doesn't expect to be set though.
The interrupt core will eventually take care of it if the interrupt is
left screaming with nothing handling it (and provide diagnostics). I
would *hope* that this is only happening for unmasked interrupt sources
we explicitly unmask anyway, we really don't want interrupts on FIFO
level changes.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-03-27 13:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 11:48 [PATCH] ASoC: fsl_sai: Add isr to deal with error flag Nicolin Chen
2014-03-26 11:59 ` David Laight
2014-03-27 1:14 ` Mark Brown
2014-03-27 2:29 ` [alsa-devel] " Nicolin Chen
2014-03-27 9:41 ` David Laight
2014-03-27 13:05 ` Mark Brown [this message]
2014-03-27 2:13 ` Li.Xiubo
2014-03-27 2:36 ` Nicolin Chen
2014-03-27 2:53 ` Li.Xiubo
2014-03-27 2:56 ` Nicolin Chen
2014-03-27 3:41 ` Li.Xiubo
2014-03-27 3:31 ` Nicolin Chen
2014-03-27 4:06 ` Li.Xiubo
2014-03-27 3:57 ` Nicolin Chen
2014-03-27 4:18 ` Li.Xiubo
2014-03-27 10:54 ` Mark Brown
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=20140327130529.GK30768@sirena.org.uk \
--to=broonie@kernel.org \
--cc=David.Laight@ACULAB.COM \
--cc=Guangyu.Chen@freescale.com \
--cc=Li.Xiubo@freescale.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox