[PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device
Haojian Zhuang
haojian.zhuang at gmail.com
Mon Dec 3 00:33:39 EST 2012
On Mon, Dec 3, 2012 at 9:39 AM, Chao Xie <xiechao.mail at gmail.com> wrote:
> On Fri, Nov 30, 2012 at 3:04 PM, Haojian Zhuang
> <haojian.zhuang at gmail.com> wrote:
>> On Thu, Nov 29, 2012 at 6:25 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>>> On Wed, Nov 28, 2012 at 09:21:07PM -0500, Chao Xie wrote:
>>>> The original sa1100_rtc_open/sa1100_rtc_release will be called
>>>> when the /dev/rtc0 is opened or closed.
>>>> In fact, these two functions will enable/disable the clock, and
>>>> register/unregister the irqs.
>>>> User application will use /dev/rtc0 to read the rtc time or set
>>>> the alarm. The rtc should still run indepent of open/close the
>>>> rtc device.
>>>> So only enable clock and register the irqs when probe the device,
>>>> and disable clock and unregister the irqs when remove the device.
>>>
>>> NAK. I don't think you properly understand what's going on here if you
>>> think moving the entire open and release functions into the probe and
>>> remove functions is the right thing to do.
>>
>> Since PXA27x & PXA3xx supports dual rtc device at the same time,
>> user could choose use either of rtc at run time. Then clk & irq are setup
>> in open().
>>
>> Chao,
>> So you shouldn't remove them into probe().
>
> How can user to choose one RTC?
/dev/rtc0 & /dev/rtc1.
The user can choose the rtc by iteself. Is it right?
> The user API, for example "date" will open the device, get the time
> and then close the device.
"date" command is always using /dev/rtc. It's the alias of rtc0 or rtc1.
> WHen set a alarm, it is the same routine. open->set->close.
> The open routine will enable clock and register irq, close will
> disable the clock and unregister irq. It means that if only open is
> invoked, rtc begins to work, and after close is invoked rtc stops
> working. It means that the user can not get correct time and can not
> get right alarm.
More information about the linux-arm-kernel
mailing list