| Message ID | b4a6fe205cbb1a9eddc4e5f63fa05d299641313d.1451995297.git.hns@goldelico.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: > tested on OMP5432 EVM > > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > --- > arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi > index 5cf76a1..30c0d3b 100644 > --- a/arch/arm/boot/dts/omap5-board-common.dtsi > +++ b/arch/arm/boot/dts/omap5-board-common.dtsi > @@ -358,6 +358,14 @@ > #clock-cells = <0>; > }; > > + rtc { > + compatible = "ti,palmas-rtc"; > + interrupt-parent = <&palmas>; > + interrupts = <8 IRQ_TYPE_NONE>; IRQ_TYPE_NONE is not correct here -> it should have some polarity - if it had none, there'd be no interrupt, right? > + ti,backup-battery-chargeable; > + ti,backup-battery-charge-high-current; > + }; > + > palmas_pmic { > compatible = "ti,palmas-pmic"; > interrupt-parent = <&palmas>; >
* Nishanth Menon <nm@ti.com> [160105 15:40]: > On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: > > tested on OMP5432 EVM > > > > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > > --- > > arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi > > index 5cf76a1..30c0d3b 100644 > > --- a/arch/arm/boot/dts/omap5-board-common.dtsi > > +++ b/arch/arm/boot/dts/omap5-board-common.dtsi > > @@ -358,6 +358,14 @@ > > #clock-cells = <0>; > > }; > > > > + rtc { > > + compatible = "ti,palmas-rtc"; > > + interrupt-parent = <&palmas>; > > + interrupts = <8 IRQ_TYPE_NONE>; > > IRQ_TYPE_NONE is not correct here -> it should have some polarity - if > it had none, there'd be no interrupt, right? Also I'm not seeing just zeroes coming from RTC after typing hwclock on omap5-uevm. It's working on x15 though. Nikolaus, is hwclock command working for you on omap5-uevm? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@ti.com>: > On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: >> tested on OMP5432 EVM >> >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >> --- >> arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi >> index 5cf76a1..30c0d3b 100644 >> --- a/arch/arm/boot/dts/omap5-board-common.dtsi >> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi >> @@ -358,6 +358,14 @@ >> #clock-cells = <0>; >> }; >> >> + rtc { >> + compatible = "ti,palmas-rtc"; >> + interrupt-parent = <&palmas>; >> + interrupts = <8 IRQ_TYPE_NONE>; > > IRQ_TYPE_NONE is not correct here -> it should have some polarity - if > it had none, there'd be no interrupt, right? Well, it just translates IRQ_TYPE_NONE through Linux/include/dt-bindings/interrupt-controller/irq.h to interrupts = <8 0>; which is given as an example in Documentation//devicetree/bindings/rtc/rtc-palmas.txt Since I don't know anything about the rtc driver beyond the bindings documentation I assume it is correct... I have added Laxman Dewangan because he introduced this interrupts = <8 0>; > >> + ti,backup-battery-chargeable; >> + ti,backup-battery-charge-high-current; >> + }; >> + >> palmas_pmic { >> compatible = "ti,palmas-pmic"; >> interrupt-parent = <&palmas>; >> > > > -- > Regards, > Nishanth Menon BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony@atomide.com>: > * Nishanth Menon <nm@ti.com> [160105 15:40]: >> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: >>> tested on OMP5432 EVM >>> >>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >>> --- >>> arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi >>> index 5cf76a1..30c0d3b 100644 >>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi >>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi >>> @@ -358,6 +358,14 @@ >>> #clock-cells = <0>; >>> }; >>> >>> + rtc { >>> + compatible = "ti,palmas-rtc"; >>> + interrupt-parent = <&palmas>; >>> + interrupts = <8 IRQ_TYPE_NONE>; >> >> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if >> it had none, there'd be no interrupt, right? > > Also I'm not seeing just zeroes coming from RTC after typing hwclock > on omap5-uevm. It's working on x15 though. > > Nikolaus, is hwclock command working for you on omap5-uevm? Well, yes and no. It appears it *was* working when tested last time (we sometimes have months of delay for submitting patches upstream). I have found an SD image with 4.3-rc6 with this patch in the dtb and there it works. With 4.4-rc8 it does not work. hwclock command hangs for 10 seconds (I guess some timeout). I have checked the dtb and in both cases it is interrupts = <8 0>; xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts 0000000: 0000 0008 0000 0000 So I think something has changed in the rtc driver or somewhere else. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote: > Hi, > > Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@ti.com>: > >> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: >>> + rtc { >>> + compatible = "ti,palmas-rtc"; >>> + interrupt-parent = <&palmas>; >>> + interrupts = <8 IRQ_TYPE_NONE>; >> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if >> it had none, there'd be no interrupt, right? > Well, it just translates IRQ_TYPE_NONE through > > Linux/include/dt-bindings/interrupt-controller/irq.h > > to > > interrupts = <8 0>; > > which is given as an example in > > Documentation//devicetree/bindings/rtc/rtc-palmas.txt > > Since I don't know anything about the rtc driver beyond the bindings documentation I assume it is correct... > I have added Laxman Dewangan because he introduced this interrupts = <8 0>; > As this is for palmas interrupt controller, it does not use the second field for interrupt from RTC. So there is no really any polarity. It can be set to 0. The second argument will be used for GPIOs mainly. However, support need to be added on GPIO driver for rising/falling configuration. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/06/2016 02:13 AM, Laxman Dewangan wrote: > > On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote: >> Hi, >> >> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@ti.com>: >> >>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: >>>> + rtc { >>>> + compatible = "ti,palmas-rtc"; >>>> + interrupt-parent = <&palmas>; >>>> + interrupts = <8 IRQ_TYPE_NONE>; >>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if >>> it had none, there'd be no interrupt, right? >> Well, it just translates IRQ_TYPE_NONE through >> >> Linux/include/dt-bindings/interrupt-controller/irq.h >> >> to >> >> interrupts = <8 0>; >> >> which is given as an example in >> >> Documentation//devicetree/bindings/rtc/rtc-palmas.txt >> >> Since I don't know anything about the rtc driver beyond the bindings >> documentation I assume it is correct... >> I have added Laxman Dewangan because he introduced this interrupts = >> <8 0>; >> > > As this is for palmas interrupt controller, it does not use the second > field for interrupt from RTC. > So there is no really any polarity. It can be set to 0. > > The second argument will be used for GPIOs mainly. However, support need > to be added on GPIO driver for rising/falling configuration. Device tree represents the hardware - not to reflect how the driver works. if the driver is wrong, fix it. the interrupt polarity needs to be described in DT. based on palmas like designs, you should probably use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside the SoC as it reaches Secondary interrupt handlers(SIH) registers.
Hi, * H. Nikolaus Schaller <hns@goldelico.com> [160106 00:12]: > Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony@atomide.com>: > > > > Also I'm not seeing just zeroes coming from RTC after typing hwclock > > on omap5-uevm. It's working on x15 though. > > > > Nikolaus, is hwclock command working for you on omap5-uevm? > > Well, yes and no. It appears it *was* working when tested last time > (we sometimes have months of delay for submitting patches upstream). > > I have found an SD image with 4.3-rc6 with this patch in the dtb and > there it works. With 4.4-rc8 it does not work. hwclock command hangs for > 10 seconds (I guess some timeout). > > I have checked the dtb and in both cases it is interrupts = <8 0>; > > xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts > 0000000: 0000 0008 0000 0000 > > So I think something has changed in the rtc driver or somewhere else. I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for RTC, and I still don't have hwclock working with RTC. It seems you have some additional patches there that make it work? I guess it could also be a bootloader change if it's a different SD image that works for you. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, Am 06.01.2016 um 17:41 schrieb Tony Lindgren <tony@atomide.com>: > Hi, > > * H. Nikolaus Schaller <hns@goldelico.com> [160106 00:12]: >> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony@atomide.com>: >>> >>> Also I'm not seeing just zeroes coming from RTC after typing hwclock >>> on omap5-uevm. It's working on x15 though. >>> >>> Nikolaus, is hwclock command working for you on omap5-uevm? >> >> Well, yes and no. It appears it *was* working when tested last time >> (we sometimes have months of delay for submitting patches upstream). >> >> I have found an SD image with 4.3-rc6 with this patch in the dtb and >> there it works. With 4.4-rc8 it does not work. hwclock command hangs for >> 10 seconds (I guess some timeout). >> >> I have checked the dtb and in both cases it is interrupts = <8 0>; >> >> xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts >> 0000000: 0000 0008 0000 0000 >> >> So I think something has changed in the rtc driver or somewhere else. > > I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for > RTC, and I still don't have hwclock working with RTC. > > It seems you have some additional patches there that make it work? Hm. Not that I am aware of. We just did add the rtc nodes but did not touch palmas drivers (except adding the gpadc of this patch series). > > I guess it could also be a bootloader change if it's a different > SD image that works for you. Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from source. I will try to find out if it makes a difference. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* H. Nikolaus Schaller <hns@goldelico.com> [160106 08:48]: > Hi Tony, > > Am 06.01.2016 um 17:41 schrieb Tony Lindgren <tony@atomide.com>: > > > Hi, > > > > * H. Nikolaus Schaller <hns@goldelico.com> [160106 00:12]: > >> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony@atomide.com>: > >>> > >>> Also I'm not seeing just zeroes coming from RTC after typing hwclock > >>> on omap5-uevm. It's working on x15 though. > >>> > >>> Nikolaus, is hwclock command working for you on omap5-uevm? > >> > >> Well, yes and no. It appears it *was* working when tested last time > >> (we sometimes have months of delay for submitting patches upstream). > >> > >> I have found an SD image with 4.3-rc6 with this patch in the dtb and > >> there it works. With 4.4-rc8 it does not work. hwclock command hangs for > >> 10 seconds (I guess some timeout). > >> > >> I have checked the dtb and in both cases it is interrupts = <8 0>; > >> > >> xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts > >> 0000000: 0000 0008 0000 0000 > >> > >> So I think something has changed in the rtc driver or somewhere else. > > > > I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for > > RTC, and I still don't have hwclock working with RTC. > > > > It seems you have some additional patches there that make it work? > > Hm. Not that I am aware of. We just did add the rtc nodes but did not > touch palmas drivers (except adding the gpadc of this patch series). OK > > I guess it could also be a bootloader change if it's a different > > SD image that works for you. > > Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from > source. I will try to find out if it makes a difference. OK. It could be also some .config change with something built-in? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon <nm@ti.com> wrote: > On 01/06/2016 02:13 AM, Laxman Dewangan wrote: >> >> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote: >>> Hi, >>> >>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@ti.com>: >>> >>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: >>>>> + rtc { >>>>> + compatible = "ti,palmas-rtc"; >>>>> + interrupt-parent = <&palmas>; >>>>> + interrupts = <8 IRQ_TYPE_NONE>; >>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if >>>> it had none, there'd be no interrupt, right? >>> Well, it just translates IRQ_TYPE_NONE through >>> >>> Linux/include/dt-bindings/interrupt-controller/irq.h >>> >>> to >>> >>> interrupts = <8 0>; >>> >>> which is given as an example in >>> >>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt >>> >>> Since I don't know anything about the rtc driver beyond the bindings >>> documentation I assume it is correct... >>> I have added Laxman Dewangan because he introduced this interrupts = >>> <8 0>; >>> >> >> As this is for palmas interrupt controller, it does not use the second >> field for interrupt from RTC. >> So there is no really any polarity. It can be set to 0. >> >> The second argument will be used for GPIOs mainly. However, support need >> to be added on GPIO driver for rising/falling configuration. > > > Device tree represents the hardware - not to reflect how the driver > works. if the driver is wrong, fix it. the interrupt polarity needs to > be described in DT. based on palmas like designs, you should probably > use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside > the SoC as it reaches Secondary interrupt handlers(SIH) registers. If the trigger type is not programmable, then not setting the trigger type in the DT is fine. Internal connections are often not documented. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/06/2016 01:34 PM, Rob Herring wrote: > On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon <nm@ti.com> wrote: >> On 01/06/2016 02:13 AM, Laxman Dewangan wrote: >>> >>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote: >>>> Hi, >>>> >>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@ti.com>: >>>> >>>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: >>>>>> + rtc { >>>>>> + compatible = "ti,palmas-rtc"; >>>>>> + interrupt-parent = <&palmas>; >>>>>> + interrupts = <8 IRQ_TYPE_NONE>; >>>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if >>>>> it had none, there'd be no interrupt, right? >>>> Well, it just translates IRQ_TYPE_NONE through >>>> >>>> Linux/include/dt-bindings/interrupt-controller/irq.h >>>> >>>> to >>>> >>>> interrupts = <8 0>; >>>> >>>> which is given as an example in >>>> >>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt >>>> >>>> Since I don't know anything about the rtc driver beyond the bindings >>>> documentation I assume it is correct... >>>> I have added Laxman Dewangan because he introduced this interrupts = >>>> <8 0>; >>>> >>> >>> As this is for palmas interrupt controller, it does not use the second >>> field for interrupt from RTC. >>> So there is no really any polarity. It can be set to 0. >>> >>> The second argument will be used for GPIOs mainly. However, support need >>> to be added on GPIO driver for rising/falling configuration. >> >> >> Device tree represents the hardware - not to reflect how the driver >> works. if the driver is wrong, fix it. the interrupt polarity needs to >> be described in DT. based on palmas like designs, you should probably >> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside >> the SoC as it reaches Secondary interrupt handlers(SIH) registers. > > If the trigger type is not programmable, then not setting the trigger > type in the DT is fine. Internal connections are often not documented. > Weird, that is not what I got feedback when I send https://patchwork.ozlabs.org/patch/381125/ If this is the new norm, I retract my objection.
Tony, it is strange. It now works under unknown conditions - without any obvoius change. Am 06.01.2016 um 18:09 schrieb Tony Lindgren <tony@atomide.com>: > * H. Nikolaus Schaller <hns@goldelico.com> [160106 08:48]: >> Hi Tony, >> >> Am 06.01.2016 um 17:41 schrieb Tony Lindgren <tony@atomide.com>: >> >>> Hi, >>> >>> * H. Nikolaus Schaller <hns@goldelico.com> [160106 00:12]: >>>> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony@atomide.com>: >>>>> >>>>> Also I'm not seeing just zeroes coming from RTC after typing hwclock >>>>> on omap5-uevm. It's working on x15 though. >>>>> >>>>> Nikolaus, is hwclock command working for you on omap5-uevm? >>>> >>>> Well, yes and no. It appears it *was* working when tested last time >>>> (we sometimes have months of delay for submitting patches upstream). >>>> >>>> I have found an SD image with 4.3-rc6 with this patch in the dtb and >>>> there it works. With 4.4-rc8 it does not work. hwclock command hangs for >>>> 10 seconds (I guess some timeout). >>>> >>>> I have checked the dtb and in both cases it is interrupts = <8 0>; >>>> >>>> xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts >>>> 0000000: 0000 0008 0000 0000 >>>> >>>> So I think something has changed in the rtc driver or somewhere else. >>> >>> I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for >>> RTC, and I still don't have hwclock working with RTC. >>> >>> It seems you have some additional patches there that make it work? >> >> Hm. Not that I am aware of. We just did add the rtc nodes but did not >> touch palmas drivers (except adding the gpadc of this patch series). > > OK > >>> I guess it could also be a bootloader change if it's a different >>> SD image that works for you. >> >> Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from >> source. I will try to find out if it makes a difference. > > OK. It could be also some .config change with something built-in? I have compared /proc/config.gz from both systems and /sys/firmware/fdt with no significant and obvious change. Then I booted the 4.4-rc8 again and this time it worked. To verify, I have checked out linux-next this morning, cherry-picked this palmas rtc patch, compiled with omap2plus defconfig, and used the omap5-uevm.dtb. And hwclock works after doing a modprobe rtc_palmas. Then I did the same with official v4.4-rc8 and hwclock hangs. And now our 4.4-rc8 production kernel hangs again as well. Even if I use the DTB from the 4.3 kernel. So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in linux-next and unrelated to this DT patch. But I have no hint or idea what it is. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]: > Tony, > it is strange. It now works under unknown conditions - without any obvoius change. > > Am 06.01.2016 um 18:09 schrieb Tony Lindgren <tony@atomide.com>: > > > > OK. It could be also some .config change with something built-in? > > I have compared /proc/config.gz from both systems and /sys/firmware/fdt > with no significant and obvious change. > > Then I booted the 4.4-rc8 again and this time it worked. > > To verify, I have checked out linux-next this morning, cherry-picked this palmas > rtc patch, compiled with omap2plus defconfig, and used the omap5-uevm.dtb. And > hwclock works after doing a modprobe rtc_palmas. Weird. No luck here with current linux next or anything. > Then I did the same with official v4.4-rc8 and hwclock hangs. And now our > 4.4-rc8 production kernel hangs again as well. Even if I use the > DTB from the 4.3 kernel. I'm not seeing the RTC second increase in u-boot either, this should show it: # i2c md 0x48 0x100 Of course the rtc may not be enabled in u-boot unlike for x15. > So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in > linux-next and unrelated to this DT patch. > > But I have no hint or idea what it is. Or something hangs the RTC? And the back-up battery has to drain to reset the RTC somehow? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@atomide.com>: > * H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]: >> Tony, >> it is strange. It now works under unknown conditions - without any obvoius change. >> >> Am 06.01.2016 um 18:09 schrieb Tony Lindgren <tony@atomide.com>: >>> >>> OK. It could be also some .config change with something built-in? >> >> I have compared /proc/config.gz from both systems and /sys/firmware/fdt >> with no significant and obvious change. >> >> Then I booted the 4.4-rc8 again and this time it worked. >> >> To verify, I have checked out linux-next this morning, cherry-picked this palmas >> rtc patch, compiled with omap2plus defconfig, and used the omap5-uevm.dtb. And >> hwclock works after doing a modprobe rtc_palmas. > > Weird. No luck here with current linux next or anything. > >> Then I did the same with official v4.4-rc8 and hwclock hangs. And now our >> 4.4-rc8 production kernel hangs again as well. Even if I use the >> DTB from the 4.3 kernel. > > I'm not seeing the RTC second increase in u-boot either, this > should show it: > > # i2c md 0x48 0x100 > > Of course the rtc may not be enabled in u-boot unlike for x15. > >> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in >> linux-next and unrelated to this DT patch. >> >> But I have no hint or idea what it is. > > Or something hangs the RTC? And the back-up battery has to drain to > reset the RTC somehow? Indeed it could be something like this. I already suspected that it depends on boot order of some components. But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch should enable (and not fix potential driver issues). BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* H. Nikolaus Schaller <hns@goldelico.com> [160108 10:33]: > Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@atomide.com>: > > * H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]: > > > >> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in > >> linux-next and unrelated to this DT patch. > >> > >> But I have no hint or idea what it is. > > > > Or something hangs the RTC? And the back-up battery has to drain to > > reset the RTC somehow? > > Indeed it could be something like this. I already suspected that it depends > on boot order of some components. > > But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch > should enable (and not fix potential driver issues). Yes no problems with $subject patch. It's just the we also need to figure out why RTC does not work :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 08.01.2016 um 20:04 schrieb Tony Lindgren <tony@atomide.com>: > * H. Nikolaus Schaller <hns@goldelico.com> [160108 10:33]: >> Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@atomide.com>: >>> * H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]: >>> >>>> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in >>>> linux-next and unrelated to this DT patch. >>>> >>>> But I have no hint or idea what it is. >>> >>> Or something hangs the RTC? And the back-up battery has to drain to >>> reset the RTC somehow? >> >> Indeed it could be something like this. I already suspected that it depends >> on boot order of some components. >> >> But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch >> should enable (and not fix potential driver issues). > > Yes no problems with $subject patch. It's just the we also need > to figure out why RTC does not work :) Yes indeed. I can not focus on that at the moment but as soon as we have the new Pyra handheld devices (with OMAP5+Palmas) running, there will be more developers to look at it. BR, Nikolaus-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* H. Nikolaus Schaller <hns@goldelico.com> [160108 11:32]: > > Am 08.01.2016 um 20:04 schrieb Tony Lindgren <tony@atomide.com>: > > > * H. Nikolaus Schaller <hns@goldelico.com> [160108 10:33]: > >> Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@atomide.com>: > >>> * H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]: > >>> > >>>> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in > >>>> linux-next and unrelated to this DT patch. > >>>> > >>>> But I have no hint or idea what it is. > >>> > >>> Or something hangs the RTC? And the back-up battery has to drain to > >>> reset the RTC somehow? > >> > >> Indeed it could be something like this. I already suspected that it depends > >> on boot order of some components. > >> > >> But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch > >> should enable (and not fix potential driver issues). > > > > Yes no problems with $subject patch. It's just the we also need > > to figure out why RTC does not work :) > > Yes indeed. I can not focus on that at the moment but as soon as we have > the new Pyra handheld devices (with OMAP5+Palmas) running, there will > be more developers to look at it. OK so the issue is that the twl msecure pin should be high to enable the RTC registers. We used to have that code with platform_data, but no longer have it with device tree based booting. I'll send a patch for that. Curiously setting jumper j5 on beagle-x15 that controls what used to be the msecure and now is powerhold, does the opposite.. The device boots automatically but RTC is stopped? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index 5cf76a1..30c0d3b 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -358,6 +358,14 @@ #clock-cells = <0>; }; + rtc { + compatible = "ti,palmas-rtc"; + interrupt-parent = <&palmas>; + interrupts = <8 IRQ_TYPE_NONE>; + ti,backup-battery-chargeable; + ti,backup-battery-charge-high-current; + }; + palmas_pmic { compatible = "ti,palmas-pmic"; interrupt-parent = <&palmas>;
tested on OMP5432 EVM Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> --- arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+)