From: Zev Weiss <zev@bewilderbeest.net>
To: Joel Stanley <joel@jms.id.au>
Cc: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>,
linux-aspeed <linux-aspeed@lists.ozlabs.org>,
Andrew Jeffery <andrew@aj.id.au>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Eddie James <eajames@linux.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-media@vger.kernel.org
Subject: Re: [PATCH 2/3] aspeed-video: clear spurious interrupt bits unconditionally
Date: Tue, 22 Dec 2020 13:14:33 -0600 [thread overview]
Message-ID: <20201222191433.3dgnfwyrod4tnvaf@hatter.bewilderbeest.net> (raw)
In-Reply-To: <CACPK8XczCUgqOENABoDbc-qwbMxOh=1OUyBtuHSmDG_Zo571Wg@mail.gmail.com>
On Mon, Dec 21, 2020 at 10:47:37PM CST, Joel Stanley wrote:
>On Tue, 15 Dec 2020 at 02:46, Zev Weiss <zev@bewilderbeest.net> wrote:
>>
>> Instead of testing and conditionally clearing them one by one, we can
>> instead just unconditionally clear them all at once.
>>
>> Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
>
>I had a poke at the assembly and it looks like GCC is clearing the
>bits unconditionally anyway, so removing the tests provides no change.
>
>Combining them is a good further optimization.
>
>Reviewed-by: Joel Stanley <joel@jms.id.au>
>
>A question unrelated to this patch: Do you know why the driver doesn't
>clear the status bits in the interrupt handler? I would expect it to
>write the value of sts back to the register to ack the pending
>interrupt.
>
No, I don't, and I was sort of wondering the same thing actually -- I'm
not deeply familiar with this hardware or driver though, so I was a bit
hesitant to start messing with things. (Though maybe doing so would
address the "stickiness" aspect when it does manifest.) Perhaps Eddie
or Jae can shed some light here?
Zev
next prev parent reply other threads:[~2020-12-22 19:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-15 2:45 [PATCH 0/3] aspeed-video: extend spurious interrupt handling Zev Weiss
2020-12-15 2:45 ` [PATCH 1/3] aspeed-video: add error message for unhandled interrupts Zev Weiss
2020-12-22 4:34 ` Joel Stanley
2020-12-22 19:11 ` Zev Weiss
2020-12-15 2:45 ` [PATCH 2/3] aspeed-video: clear spurious interrupt bits unconditionally Zev Weiss
2020-12-22 4:47 ` Joel Stanley
2020-12-22 19:14 ` Zev Weiss [this message]
2020-12-23 1:07 ` Joel Stanley
2020-12-23 2:53 ` Ryan Chen
2020-12-23 3:53 ` Zev Weiss
2020-12-23 5:58 ` Ryan Chen
2020-12-15 2:45 ` [PATCH 3/3] aspeed-video: add COMP_READY to VE_SPURIOUS_IRQS Zev Weiss
2020-12-22 4:49 ` Joel Stanley
2021-03-09 16:43 ` Jae Hyun Yoo
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=20201222191433.3dgnfwyrod4tnvaf@hatter.bewilderbeest.net \
--to=zev@bewilderbeest.net \
--cc=andrew@aj.id.au \
--cc=eajames@linux.ibm.com \
--cc=jae.hyun.yoo@linux.intel.com \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=openbmc@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;
as well as URLs for NNTP newsgroup(s).