From: Douglas Gilbert <dgilbert@interlog.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Ludovic Desroches <ludovic.desroches@atmel.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rtc: rtc-at91rm9200: use a variable for storing IMR
Date: Wed, 20 Mar 2013 21:15:23 -0400 [thread overview]
Message-ID: <514A5F2B.8030707@interlog.com> (raw)
In-Reply-To: <20130320145006.f1431c1528325ff93a298790@linux-foundation.org>
On 13-03-20 05:50 PM, Andrew Morton wrote:
> On Fri, 15 Mar 2013 18:37:12 +0100 Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>
>> On some revisions of AT91 SoCs, the RTC IMR register is not working.
>> Instead of elaborating a workaround for that specific SoC or IP version,
>> we simply use a software variable to store the Interrupt Mask Register and
>> modify it for each enabling/disabling of an interrupt. The overhead of this
>> is negligible anyway.
>
> This description doesn't really allow me or others to work out whether
> the fix should be included in 3.9 or backported into earlier kernels.
>
> So please, when fixing a bug do include a full description of the
> user-visible effects of that bug. And your opinion regarding the
> -mainline and -stable decision is always useful.
The interrupt mask register (IMR) for the RTC is broken
on the AT91SAM9x5 sub-family of SoCs (good overview of the
members here: http://www.eewiki.net/display/linuxonarm/AT91SAM9x5 ).
The "user visible effect" is the RTC doesn't work.
That sub-family is less than two years old and only has devicetree
(DT) support and came online circa lk 3.7 . The dust is yet to
settle on the DT stuff at least for AT91 SoCs (translation:
lots of stuff is still broken, so much that it is hard to know
where to start).
The fix in the patch is pretty simple: just shadow the silicon
IMR register with a variable in the driver. Some older SoCs (pre-DT)
use the the rtc-at91rm9200 driver (e.g. obviously the AT91RM9200)
and they should not be impacted by the change. There shouldn't
be a large volume of interrupts associated with a RTC.
Compared to a relatively stable kernel subsystem like SCSI, what
is happening in the ARM architecture with DT is huge and ongoing.
So I think you either need new rules or suspend some of the stricter
rules applied to more stable subsystems. Just my two cents worth.
Doug Gilbert
who hasn't seen that frill-necked lizard for a while
next prev parent reply other threads:[~2013-03-21 1:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-15 17:37 [PATCH] rtc: rtc-at91rm9200: use a variable for storing IMR Nicolas Ferre
2013-03-20 21:50 ` Andrew Morton
2013-03-21 1:15 ` Douglas Gilbert [this message]
2013-03-21 21:33 ` Andrew Morton
2013-03-21 9:46 ` Nicolas Ferre
2013-03-26 19:27 ` Johan Hovold
2013-03-26 21:09 ` Douglas Gilbert
2013-03-28 9:57 ` Johan Hovold
2013-03-28 16:16 ` Nicolas Ferre
2013-03-29 15:57 ` Johan Hovold
2013-03-28 18:20 ` Douglas Gilbert
2013-03-29 15:45 ` Nicolas Ferre
2013-03-29 16:01 ` Johan Hovold
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=514A5F2B.8030707@interlog.com \
--to=dgilbert@interlog.com \
--cc=akpm@linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.desroches@atmel.com \
--cc=nicolas.ferre@atmel.com \
--cc=plagnioj@jcrosoft.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox