| Message ID | 1355136122-30729-2-git-send-email-gregory.clement@free-electrons.com |
|---|---|
| State | Accepted |
| Headers | show |
Dear Gregory CLEMENT, On Mon, 10 Dec 2012 11:42:01 +0100, Gregory CLEMENT wrote: > + rtc@10300 { > + compatible = "marvell,orion-rtc"; > + reg = <0xd0010300 0x20>; > + interrupts = <50>; > + }; Maybe an explicit status = "okay" here? Thomas
On Mon, 10 Dec 2012 16:28:19 +0100, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Gregory CLEMENT, > > On Mon, 10 Dec 2012 11:42:01 +0100, Gregory CLEMENT wrote: > > > + rtc@10300 { > > + compatible = "marvell,orion-rtc"; > > + reg = <0xd0010300 0x20>; > > + interrupts = <50>; > > + }; > > Maybe an explicit status = "okay" here? Only necessary if it is typical for the device to get disabled. I don't add status="okay" properties unless it is to enable a device previously disabled with status="disabled" g.
Dear Grant Likely, On Mon, 10 Dec 2012 21:47:55 +0000, Grant Likely wrote: > > Maybe an explicit status = "okay" here? > > Only necessary if it is typical for the device to get disabled. I don't > add status="okay" properties unless it is to enable a device previously > disabled with status="disabled" Ok, thanks for clarifying what the best practice is. This device being internal to the SoC and having no dependency on external components, it is indeed always available. Thanks again for the clarification! Thomas
On Mon, Dec 10, 2012 at 11:37:23PM +0100, Thomas Petazzoni wrote: > Dear Grant Likely, > > On Mon, 10 Dec 2012 21:47:55 +0000, Grant Likely wrote: > > > > Maybe an explicit status = "okay" here? > > > > Only necessary if it is typical for the device to get disabled. I don't > > add status="okay" properties unless it is to enable a device previously > > disabled with status="disabled" > > Ok, thanks for clarifying what the best practice is. This device being > internal to the SoC and having no dependency on external components, it > is indeed always available. Hi Thomas This is not actually true. Its dependent on at least one external component, a battery. The driver determines at load time if the clock is ticking. There are a few Kirkwood and XP designs which use an external i2c RTC, because the battery recommended by Marvell is mechanically not so easy to attached to the board, in a robust way. So i expect some boards will disable this from there own .dts file. However, defaulting to enabled would make sense. Andrew
Dear Andrew Lunn, On Tue, 11 Dec 2012 07:00:50 +0100, Andrew Lunn wrote: > This is not actually true. Its dependent on at least one external > component, a battery. The driver determines at load time if the clock > is ticking. > > There are a few Kirkwood and XP designs which use an external i2c RTC, > because the battery recommended by Marvell is mechanically not so easy > to attached to the board, in a robust way. > > So i expect some boards will disable this from there own .dts file. > However, defaulting to enabled would make sense. Ok, thanks for the clarification! Indeed, the OpenBlocks for example has a RTC on I2C, so maybe it'll want to disable the on-SoC RTC. Best regards, Thomas
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi index cf6c48a..86dccfa 100644 --- a/arch/arm/boot/dts/armada-370-xp.dtsi +++ b/arch/arm/boot/dts/armada-370-xp.dtsi @@ -129,6 +129,12 @@ clocks = <&coreclk 0>; status = "disabled"; }; + + rtc@10300 { + compatible = "marvell,orion-rtc"; + reg = <0xd0010300 0x20>; + interrupts = <50>; + }; }; }; diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 19c03ab..9356f75 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -994,7 +994,7 @@ config RTC_DRV_TX4939 config RTC_DRV_MV tristate "Marvell SoC RTC" - depends on ARCH_KIRKWOOD || ARCH_DOVE + depends on ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU help If you say yes here you will get support for the in-chip RTC that can be found in some of Marvell's SoC devices, such as