[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8761qk32pj.fsf@natisbad.org>
Date: Thu, 19 Dec 2013 23:17:44 +0100
From: arno@...isbad.org (Arnaud Ebalard)
To: Alessandro Zummo <a.zummo@...ertech.it>
Cc: rtc-linux@...glegroups.com, Mark Rutland <mark.rutland@....com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
jason@...edaemon.net, Pawel Moll <pawel.moll@....com>,
Stephen Warren <swarren@...dotorg.org>,
Linus Walleij <linus.walleij@...aro.org>,
linux-kernel@...r.kernel.org,
Rob Herring <rob.herring@...xeda.com>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
Mark Brown <broonie@...nel.org>,
linux-arm-kernel@...ts.infradead.org,
Rob Landley <rob@...dley.net>,
Kumar Gala <galak@...eaurora.org>,
Grant Likely <grant.likely@...aro.org>,
Peter Huewe <peter.huewe@...ineon.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thierry Reding <treding@...dia.com>,
Guenter Roeck <linux@...ck-us.net>
Subject: Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi,
Alessandro Zummo <a.zummo@...ertech.it> writes:
> On Thu, 19 Dec 2013 11:46:24 -0500
> Jason Cooper <jason@...edaemon.net> wrote:
>
>> In the long term, should we seek out a co-maintainer for drivers/rtc?
>> Can anyone get a hold of Alessandro to get his opinion on this?
>
> I'd surely appreciate if someone can take some time to give
> a look to the patches. Most of them go thru subsystem's tree and, as
> far as I can see, I saw very relevant comments and fixes in all those
> years.
While I am at it, I wonder if you can give me some directions on the
following to add back alarm support to the ISL12057 on the specific
hardware I have.
All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
is used as main RTC clock but can also provide alarm. But the alarm
interrupt line of the chip is *not* connected to the SoC. It is
connected to some power component and can be used to wake up the NAS
when it is completely off and the alarm rings.
To me this kind of setup seems logical but it does not seem to be
directly supported by current RTC logic:
- first, I cannot test an interrupt handler implementation I had
written as the SoC will never receive any interrupt. This limits
my ability to provide one to the driver.
- what can/should be done in my .dts file to indicate that the
device does not have any IRQ line connected (and hence no interrupt
handler) to the SoC but still supports an alarm.
As a side note, the implementation I had was a working one on my
hardware (i.e. was able to wake up the device at a given time) but I had
to remove alarm code to get a basic driver accepted upstream.
To be honest, I tried and understand what RTC subsystem expects from
documentation and code w/o success. Any help appreciated on that topic.
Cheers,
a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists