* [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards @ 2016-04-18 18:20 H. Nikolaus Schaller 2016-04-18 18:20 ` [PATCH v2 1/5] ARM: dts: twl6030: describe gpadc H. Nikolaus Schaller ` (5 more replies) 0 siblings, 6 replies; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-18 18:20 UTC (permalink / raw) To: Benoît Cousson, Tony Lindgren, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King Cc: ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel, H. Nikolaus Schaller This patch series adds DT nodes for: * twl6030 gpadc for omap4 based boards (Pandaboard ES) * twl6037 gpadc for omap5 based board (OMAP5EVM) * omap5-board-common: ckobuffer (needed for high quality twl6040 audio) * fix range problem with omap5 pinmux H. Nikolaus Schaller (5): ARM: dts: twl6030: describe gpadc ARM: dts: omap5-board-common: describe gpadc for Palmas ARM: dts: omap5: fix range of permitted wakeup pinmux registers ARM: dts: omap5: describe control for ckobuffer ARM: dts: omap5-board-common: set up ckobuffer for twl6040 arch/arm/boot/dts/omap5-board-common.dtsi | 24 ++++++++++++++++++++++++ arch/arm/boot/dts/omap5.dtsi | 12 +++++++++++- arch/arm/boot/dts/twl6030.dtsi | 6 ++++++ 3 files changed, 41 insertions(+), 1 deletion(-) -- 2.7.3 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v2 1/5] ARM: dts: twl6030: describe gpadc 2016-04-18 18:20 [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller @ 2016-04-18 18:20 ` H. Nikolaus Schaller 2016-04-26 17:26 ` Tony Lindgren 2016-04-18 18:20 ` [PATCH v2 2/5] ARM: dts: omap5-board-common: describe gpadc for Palmas H. Nikolaus Schaller ` (4 subsequent siblings) 5 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-18 18:20 UTC (permalink / raw) To: Benoît Cousson, Tony Lindgren, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King Cc: ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel, H. Nikolaus Schaller tested on Pandaboard ES. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> --- arch/arm/boot/dts/twl6030.dtsi | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi index 55eb35f..c45f97f 100644 --- a/arch/arm/boot/dts/twl6030.dtsi +++ b/arch/arm/boot/dts/twl6030.dtsi @@ -99,4 +99,10 @@ compatible = "ti,twl6030-pwmled"; #pwm-cells = <2>; }; + + gpadc { + compatible = "ti,twl6030-gpadc"; + interrupts = <3>; + #io-channel-cells = <1>; + }; }; -- 2.7.3 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v2 1/5] ARM: dts: twl6030: describe gpadc 2016-04-18 18:20 ` [PATCH v2 1/5] ARM: dts: twl6030: describe gpadc H. Nikolaus Schaller @ 2016-04-26 17:26 ` Tony Lindgren 0 siblings, 0 replies; 30+ messages in thread From: Tony Lindgren @ 2016-04-26 17:26 UTC (permalink / raw) To: H. Nikolaus Schaller Cc: Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: > tested on Pandaboard ES. > > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > --- > arch/arm/boot/dts/twl6030.dtsi | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi > index 55eb35f..c45f97f 100644 > --- a/arch/arm/boot/dts/twl6030.dtsi > +++ b/arch/arm/boot/dts/twl6030.dtsi > @@ -99,4 +99,10 @@ > compatible = "ti,twl6030-pwmled"; > #pwm-cells = <2>; > }; > + > + gpadc { > + compatible = "ti,twl6030-gpadc"; > + interrupts = <3>; > + #io-channel-cells = <1>; > + }; > }; Applying patches 1 & 2 into omap-for-v4.7/dt thanks. Tony ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v2 2/5] ARM: dts: omap5-board-common: describe gpadc for Palmas 2016-04-18 18:20 [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller 2016-04-18 18:20 ` [PATCH v2 1/5] ARM: dts: twl6030: describe gpadc H. Nikolaus Schaller @ 2016-04-18 18:20 ` H. Nikolaus Schaller 2016-04-18 18:20 ` [PATCH v2 3/5] ARM: dts: omap5: fix range of permitted wakeup pinmux registers H. Nikolaus Schaller ` (3 subsequent siblings) 5 siblings, 0 replies; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-18 18:20 UTC (permalink / raw) To: Benoît Cousson, Tony Lindgren, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King Cc: ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel, H. Nikolaus Schaller tested on OMP5432 EVM Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> --- arch/arm/boot/dts/omap5-board-common.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index 902657d..c0da5ff 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -391,6 +391,16 @@ ti,backup-battery-charge-high-current; }; + gpadc { + compatible = "ti,palmas-gpadc"; + interrupts = <18 0 + 16 0 + 17 0>; + #io-channel-cells = <1>; + ti,channel0-current-microamp = <5>; + ti,channel3-current-microamp = <10>; + }; + palmas_pmic { compatible = "ti,palmas-pmic"; interrupt-parent = <&palmas>; -- 2.7.3 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 3/5] ARM: dts: omap5: fix range of permitted wakeup pinmux registers 2016-04-18 18:20 [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller 2016-04-18 18:20 ` [PATCH v2 1/5] ARM: dts: twl6030: describe gpadc H. Nikolaus Schaller 2016-04-18 18:20 ` [PATCH v2 2/5] ARM: dts: omap5-board-common: describe gpadc for Palmas H. Nikolaus Schaller @ 2016-04-18 18:20 ` H. Nikolaus Schaller 2016-04-26 17:23 ` Tony Lindgren 2016-04-18 18:21 ` [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer H. Nikolaus Schaller ` (2 subsequent siblings) 5 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-18 18:20 UTC (permalink / raw) To: Benoît Cousson, Tony Lindgren, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King Cc: ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel, H. Nikolaus Schaller otherwise we can't define gpio1_wk14 Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> --- arch/arm/boot/dts/omap5.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 38805eb..120b6b8 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -269,7 +269,7 @@ omap5_pmx_wkup: pinmux@c840 { compatible = "ti,omap5-padconf", "pinctrl-single"; - reg = <0xc840 0x0038>; + reg = <0xc840 0x003c>; #address-cells = <1>; #size-cells = <0>; #interrupt-cells = <1>; -- 2.7.3 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v2 3/5] ARM: dts: omap5: fix range of permitted wakeup pinmux registers 2016-04-18 18:20 ` [PATCH v2 3/5] ARM: dts: omap5: fix range of permitted wakeup pinmux registers H. Nikolaus Schaller @ 2016-04-26 17:23 ` Tony Lindgren 0 siblings, 0 replies; 30+ messages in thread From: Tony Lindgren @ 2016-04-26 17:23 UTC (permalink / raw) To: H. Nikolaus Schaller Cc: Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: > otherwise we can't define gpio1_wk14 Applying this one into omap-for-v4.6/fixes-rc5 thanks. Regards, Tony ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-18 18:20 [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller ` (2 preceding siblings ...) 2016-04-18 18:20 ` [PATCH v2 3/5] ARM: dts: omap5: fix range of permitted wakeup pinmux registers H. Nikolaus Schaller @ 2016-04-18 18:21 ` H. Nikolaus Schaller 2016-04-26 17:27 ` Tony Lindgren 2016-04-18 18:21 ` [PATCH v2 5/5] ARM: dts: omap5-board-common: set up ckobuffer for twl6040 H. Nikolaus Schaller 2016-04-26 15:00 ` [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller 5 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-18 18:21 UTC (permalink / raw) To: Benoît Cousson, Tony Lindgren, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King Cc: ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel, H. Nikolaus Schaller OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> --- arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 120b6b8..1d9050f 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -277,6 +277,16 @@ pinctrl-single,register-width = <16>; pinctrl-single,function-mask = <0x7fff>; }; + + omap5_control_ckobuffer: pinmux@cdb4 { + compatible = "ti,omap5-padconf", + "pinctrl-single"; + reg = <0xcdb4 4>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-single,register-width = <32>; + pinctrl-single,function-mask = <0xf0000000>; + }; }; ocmcram: ocmcram@40300000 { -- 2.7.3 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-18 18:21 ` [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer H. Nikolaus Schaller @ 2016-04-26 17:27 ` Tony Lindgren 2016-04-27 6:04 ` H. Nikolaus Schaller 0 siblings, 1 reply; 30+ messages in thread From: Tony Lindgren @ 2016-04-26 17:27 UTC (permalink / raw) To: H. Nikolaus Schaller, Tero Kristo Cc: Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel Tero, * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: > OMAP5 has a register to control if the ckobuffer is enabled > and defines the polarity. ckobuffer is required to drive a twl6040 > with the system clock. Hence, add the pinctrl,single to the > OMAP5 SoC description so that omap5-board-common can > set up the ckobuffer as required. Is this really a mux or should it be a mux clock? Regards, Tony > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > --- > arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi > index 120b6b8..1d9050f 100644 > --- a/arch/arm/boot/dts/omap5.dtsi > +++ b/arch/arm/boot/dts/omap5.dtsi > @@ -277,6 +277,16 @@ > pinctrl-single,register-width = <16>; > pinctrl-single,function-mask = <0x7fff>; > }; > + > + omap5_control_ckobuffer: pinmux@cdb4 { > + compatible = "ti,omap5-padconf", > + "pinctrl-single"; > + reg = <0xcdb4 4>; > + #address-cells = <1>; > + #size-cells = <0>; > + pinctrl-single,register-width = <32>; > + pinctrl-single,function-mask = <0xf0000000>; > + }; > }; > > ocmcram: ocmcram@40300000 { > -- > 2.7.3 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-26 17:27 ` Tony Lindgren @ 2016-04-27 6:04 ` H. Nikolaus Schaller 2016-04-27 12:31 ` Tero Kristo 0 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-27 6:04 UTC (permalink / raw) To: Tony Lindgren Cc: Tero Kristo, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel > Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: > > Tero, > > * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >> OMAP5 has a register to control if the ckobuffer is enabled >> and defines the polarity. ckobuffer is required to drive a twl6040 >> with the system clock. Hence, add the pinctrl,single to the >> OMAP5 SoC description so that omap5-board-common can >> set up the ckobuffer as required. > > Is this really a mux or should it be a mux clock? It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad. The register is part of the CTRL_MODULE_WKUP. The clock signal is the xtal master clock of the whole SoC. Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon. Therefore I would say it is about padconf and not clock or clock mux related. It just happens to be a clock signal which can be routed to this pad. BR, Nikolaus > > Regards, > > Tony > >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >> --- >> arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >> index 120b6b8..1d9050f 100644 >> --- a/arch/arm/boot/dts/omap5.dtsi >> +++ b/arch/arm/boot/dts/omap5.dtsi >> @@ -277,6 +277,16 @@ >> pinctrl-single,register-width = <16>; >> pinctrl-single,function-mask = <0x7fff>; >> }; >> + >> + omap5_control_ckobuffer: pinmux@cdb4 { >> + compatible = "ti,omap5-padconf", >> + "pinctrl-single"; >> + reg = <0xcdb4 4>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-single,register-width = <32>; >> + pinctrl-single,function-mask = <0xf0000000>; >> + }; >> }; >> >> ocmcram: ocmcram@40300000 { >> -- >> 2.7.3 >> ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-27 6:04 ` H. Nikolaus Schaller @ 2016-04-27 12:31 ` Tero Kristo 2016-04-27 13:10 ` H. Nikolaus Schaller 0 siblings, 1 reply; 30+ messages in thread From: Tero Kristo @ 2016-04-27 12:31 UTC (permalink / raw) To: H. Nikolaus Schaller, Tony Lindgren, Ujfalusi, Peter Cc: Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel On 27/04/16 09:04, H. Nikolaus Schaller wrote: > >> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >> >> Tero, >> >> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>> OMAP5 has a register to control if the ckobuffer is enabled >>> and defines the polarity. ckobuffer is required to drive a twl6040 >>> with the system clock. Hence, add the pinctrl,single to the >>> OMAP5 SoC description so that omap5-board-common can >>> set up the ckobuffer as required. >> >> Is this really a mux or should it be a mux clock? > > It is a pinmux setting for the clock out buffer to choose what signal > (and polarity) is presented on the fref_xtal_clk pad. > > The register is part of the CTRL_MODULE_WKUP. > The clock signal is the xtal master clock of the whole SoC. > > Although there is a bit to choose an alternate clock, there is no > alternate in the OMAP5 silicon. > > Therefore I would say it is about padconf and not clock or clock mux > related. > > It just happens to be a clock signal which can be routed to this > pad. The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me. I could not find any documentation related to the ckobuffer usage though, maybe Peter can provide some insight? I think you spent some considerable time bringing up twl6040 a few years back... -Tero > > BR, > Nikolaus > >> >> Regards, >> >> Tony >> >>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >>> --- >>> arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >>> index 120b6b8..1d9050f 100644 >>> --- a/arch/arm/boot/dts/omap5.dtsi >>> +++ b/arch/arm/boot/dts/omap5.dtsi >>> @@ -277,6 +277,16 @@ >>> pinctrl-single,register-width = <16>; >>> pinctrl-single,function-mask = <0x7fff>; >>> }; >>> + >>> + omap5_control_ckobuffer: pinmux@cdb4 { >>> + compatible = "ti,omap5-padconf", >>> + "pinctrl-single"; >>> + reg = <0xcdb4 4>; >>> + #address-cells = <1>; >>> + #size-cells = <0>; >>> + pinctrl-single,register-width = <32>; >>> + pinctrl-single,function-mask = <0xf0000000>; >>> + }; >>> }; >>> >>> ocmcram: ocmcram@40300000 { >>> -- >>> 2.7.3 >>> > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-27 12:31 ` Tero Kristo @ 2016-04-27 13:10 ` H. Nikolaus Schaller 2016-04-27 14:10 ` Tero Kristo 0 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-27 13:10 UTC (permalink / raw) To: Tero Kristo, Ujfalusi, Peter Cc: Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel > Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: > > On 27/04/16 09:04, H. Nikolaus Schaller wrote: >> >>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>> >>> Tero, >>> >>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>> OMAP5 has a register to control if the ckobuffer is enabled >>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>> with the system clock. Hence, add the pinctrl,single to the >>>> OMAP5 SoC description so that omap5-board-common can >>>> set up the ckobuffer as required. >>> >>> Is this really a mux or should it be a mux clock? >> >> It is a pinmux setting for the clock out buffer to choose what signal >> (and polarity) is presented on the fref_xtal_clk pad. >> >> The register is part of the CTRL_MODULE_WKUP. >> The clock signal is the xtal master clock of the whole SoC. >> >> Although there is a bit to choose an alternate clock, there is no >> alternate in the OMAP5 silicon. >> >> Therefore I would say it is about padconf and not clock or clock mux >> related. >> >> It just happens to be a clock signal which can be routed to this >> pad. > > The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me. Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl. The control register for the clock output buffer is part of the CTRL_MODULE_WKUP, which includes the well known pin controls of gpio1_wk but also this ckobuffer control. So it is grouped with these in a single control register block of the SoC. See "19.6.5.1 CTRL_MODULE_WKUP_PAD" of the TRM. And IMHO, the naming "buffer" indicates that it controls the pad buffer (like all pinmux) and not the clock. Yes, of course if can be described differently, as you propose. And one might argue that the twl6040 might want to request its master clock input (19.2 MHz) which could turn on the buffer on demand. The question it raises to me are: * isn't it "overkill" to describe a static pinmux register setup (it does not need to be turned on/off during operation) as mux (without function in OMAP5 SoC) + gate? * does it require new driver code to correctly write to the control register? * does it work if the twl6040 is hooked up differently? > > I could not find any documentation related to the ckobuffer usage though, On the EVM it is the FREF_XTAL_OUT (Ball L33) which goes as signal H_SYSCLK through a jumper (R87) and then as signal P_SYSCLK to the MCLK (Ball K7) of the twl6040. Description of FREF_XTAL_OUT is in section 3.3.1 of the TRM. > maybe Peter can provide some insight? > I think you spent some considerable time bringing up twl6040 a few years back... Yes, that would certainly help to decide how to proceed. > > > -Tero BR and thanks, NIkolaus > >> >> BR, >> Nikolaus >> >>> >>> Regards, >>> >>> Tony >>> >>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >>>> --- >>>> arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++ >>>> 1 file changed, 10 insertions(+) >>>> >>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >>>> index 120b6b8..1d9050f 100644 >>>> --- a/arch/arm/boot/dts/omap5.dtsi >>>> +++ b/arch/arm/boot/dts/omap5.dtsi >>>> @@ -277,6 +277,16 @@ >>>> pinctrl-single,register-width = <16>; >>>> pinctrl-single,function-mask = <0x7fff>; >>>> }; >>>> + >>>> + omap5_control_ckobuffer: pinmux@cdb4 { >>>> + compatible = "ti,omap5-padconf", >>>> + "pinctrl-single"; >>>> + reg = <0xcdb4 4>; >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + pinctrl-single,register-width = <32>; >>>> + pinctrl-single,function-mask = <0xf0000000>; >>>> + }; >>>> }; >>>> >>>> ocmcram: ocmcram@40300000 { >>>> -- >>>> 2.7.3 >>>> >> > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-27 13:10 ` H. Nikolaus Schaller @ 2016-04-27 14:10 ` Tero Kristo 2016-04-27 14:23 ` Peter Ujfalusi 0 siblings, 1 reply; 30+ messages in thread From: Tero Kristo @ 2016-04-27 14:10 UTC (permalink / raw) To: H. Nikolaus Schaller, Ujfalusi, Peter Cc: Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel On 27/04/16 16:10, H. Nikolaus Schaller wrote: > >> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >> >> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>> >>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>> >>>> Tero, >>>> >>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>> with the system clock. Hence, add the pinctrl,single to the >>>>> OMAP5 SoC description so that omap5-board-common can >>>>> set up the ckobuffer as required. >>>> >>>> Is this really a mux or should it be a mux clock? >>> >>> It is a pinmux setting for the clock out buffer to choose what signal >>> (and polarity) is presented on the fref_xtal_clk pad. >>> >>> The register is part of the CTRL_MODULE_WKUP. >>> The clock signal is the xtal master clock of the whole SoC. >>> >>> Although there is a bit to choose an alternate clock, there is no >>> alternate in the OMAP5 silicon. >>> >>> Therefore I would say it is about padconf and not clock or clock mux >>> related. >>> >>> It just happens to be a clock signal which can be routed to this >>> pad. >> >> The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me. > > Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl. It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin. > > The control register for the clock output buffer is part of the CTRL_MODULE_WKUP, which includes the well known pin controls of gpio1_wk but also this ckobuffer control. So it is grouped with these in a single control register block of the SoC. See "19.6.5.1 CTRL_MODULE_WKUP_PAD" of the TRM. > > And IMHO, the naming "buffer" indicates that it controls the pad buffer (like all pinmux) and not the clock. > > Yes, of course if can be described differently, as you propose. And one might argue that the twl6040 might want to request its master clock input (19.2 MHz) which could turn on the buffer on demand. From logic point of view, it might be better to describe it as a clock node, so TWL6040 driver can ask for a clock and ask it be enabled. > > The question it raises to me are: > * isn't it "overkill" to describe a static pinmux register setup (it does not need to be turned on/off during operation) as mux (without function in OMAP5 SoC) + gate? If the mux doesn't exist in hardware, no need to worry about it then. > * does it require new driver code to correctly write to the control register? No, we should just be able to add some beef in the DT to describe the clock nodes. > * does it work if the twl6040 is hooked up differently? Define hooked up differently. Does the setup you propose work in that case? > >> >> I could not find any documentation related to the ckobuffer usage though, > > On the EVM it is the FREF_XTAL_OUT (Ball L33) which goes as signal H_SYSCLK through a jumper (R87) and then as signal P_SYSCLK to the MCLK (Ball K7) of the twl6040. > > Description of FREF_XTAL_OUT is in section 3.3.1 of the TRM. I was just looking for ckobuffer but the TRM indeed seems to talk about this as FREF_XTAL_CLK. It looks like there is probably no mux in the hardware. The bit of doc I am missing right now is the description of the SCM register in relation to what hardware actually does. Namely, some bits in the register are rather a mystery to me. -Tero > >> maybe Peter can provide some insight? >> I think you spent some considerable time bringing up twl6040 a few years back... > > Yes, that would certainly help to decide how to proceed. > >> > >> >> -Tero > > BR and thanks, > NIkolaus > >> >>> >>> BR, >>> Nikolaus >>> >>>> >>>> Regards, >>>> >>>> Tony >>>> >>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >>>>> --- >>>>> arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++ >>>>> 1 file changed, 10 insertions(+) >>>>> >>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >>>>> index 120b6b8..1d9050f 100644 >>>>> --- a/arch/arm/boot/dts/omap5.dtsi >>>>> +++ b/arch/arm/boot/dts/omap5.dtsi >>>>> @@ -277,6 +277,16 @@ >>>>> pinctrl-single,register-width = <16>; >>>>> pinctrl-single,function-mask = <0x7fff>; >>>>> }; >>>>> + >>>>> + omap5_control_ckobuffer: pinmux@cdb4 { >>>>> + compatible = "ti,omap5-padconf", >>>>> + "pinctrl-single"; >>>>> + reg = <0xcdb4 4>; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <0>; >>>>> + pinctrl-single,register-width = <32>; >>>>> + pinctrl-single,function-mask = <0xf0000000>; >>>>> + }; >>>>> }; >>>>> >>>>> ocmcram: ocmcram@40300000 { >>>>> -- >>>>> 2.7.3 >>>>> >>> >> > > -- > 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 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-27 14:10 ` Tero Kristo @ 2016-04-27 14:23 ` Peter Ujfalusi 2016-04-27 14:35 ` H. Nikolaus Schaller 0 siblings, 1 reply; 30+ messages in thread From: Peter Ujfalusi @ 2016-04-27 14:23 UTC (permalink / raw) To: Tero Kristo, H. Nikolaus Schaller Cc: Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel On 04/27/2016 05:10 PM, Tero Kristo wrote: > On 27/04/16 16:10, H. Nikolaus Schaller wrote: >> >>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>> >>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>> >>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>> >>>>> Tero, >>>>> >>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>> set up the ckobuffer as required. >>>>> >>>>> Is this really a mux or should it be a mux clock? >>>> >>>> It is a pinmux setting for the clock out buffer to choose what signal >>>> (and polarity) is presented on the fref_xtal_clk pad. >>>> >>>> The register is part of the CTRL_MODULE_WKUP. >>>> The clock signal is the xtal master clock of the whole SoC. >>>> >>>> Although there is a bit to choose an alternate clock, there is no >>>> alternate in the OMAP5 silicon. >>>> >>>> Therefore I would say it is about padconf and not clock or clock mux >>>> related. >>>> >>>> It just happens to be a clock signal which can be routed to this >>>> pad. >>> >>> The two could very well be implemented as clock nodes, a mux and a gate. >>> This would describe the hardware functionality better imo, if the >>> assumptions made here are correct. Implementing the control as pinctrl >>> hacks looks rather weird to me. >> >> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >> proper use of pinctrl. > > It is just the level of abstraction we are talking about here. If it is a > clock we are controlling, we should rather control it as a clock (higher level > abstraction), not a pin. I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does not have real use. Then we can add clk API support for this. On most OMAP4 devices the clock is always on, so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock). -- Péter ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-27 14:23 ` Peter Ujfalusi @ 2016-04-27 14:35 ` H. Nikolaus Schaller 2016-04-28 8:03 ` Tero Kristo 0 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-27 14:35 UTC (permalink / raw) To: Peter Ujfalusi Cc: Tero Kristo, Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel HI, > Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: > > On 04/27/2016 05:10 PM, Tero Kristo wrote: >> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>> >>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>>> >>>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>>> >>>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>>> >>>>>> Tero, >>>>>> >>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>>> set up the ckobuffer as required. >>>>>> >>>>>> Is this really a mux or should it be a mux clock? >>>>> >>>>> It is a pinmux setting for the clock out buffer to choose what signal >>>>> (and polarity) is presented on the fref_xtal_clk pad. >>>>> >>>>> The register is part of the CTRL_MODULE_WKUP. >>>>> The clock signal is the xtal master clock of the whole SoC. >>>>> >>>>> Although there is a bit to choose an alternate clock, there is no >>>>> alternate in the OMAP5 silicon. >>>>> >>>>> Therefore I would say it is about padconf and not clock or clock mux >>>>> related. >>>>> >>>>> It just happens to be a clock signal which can be routed to this >>>>> pad. >>>> >>>> The two could very well be implemented as clock nodes, a mux and a gate. >>>> This would describe the hardware functionality better imo, if the >>>> assumptions made here are correct. Implementing the control as pinctrl >>>> hacks looks rather weird to me. >>> >>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >>> proper use of pinctrl. >> >> It is just the level of abstraction we are talking about here. If it is a >> clock we are controlling, we should rather control it as a clock (higher level >> abstraction), not a pin. > > I second this. I think it is better to have a simple gate clock and handle > only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does > not have real use. > > Then we can add clk API support for this. On most OMAP4 devices the clock is > always on, this is why I am raising the question if we really want to control it on the omap5 or just turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on as a pinctrl is IMHO sufficient for all practical purposes. > so the board DTS file need to provide a dummy clock, or we can make > the high precision clock also as optional (on panda both OMAP4 and twl6040 > uses the same reference clock). Hm. It looks as if implementing this (and clock gating) is beyond my experiences. But I am happy to test a proposal on our omap5 board. BR and thanks, Nikolaus ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-27 14:35 ` H. Nikolaus Schaller @ 2016-04-28 8:03 ` Tero Kristo 2016-04-28 9:12 ` H. Nikolaus Schaller 0 siblings, 1 reply; 30+ messages in thread From: Tero Kristo @ 2016-04-28 8:03 UTC (permalink / raw) To: H. Nikolaus Schaller, Peter Ujfalusi Cc: Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel On 27/04/16 17:35, H. Nikolaus Schaller wrote: > HI, > >> Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >> >> On 04/27/2016 05:10 PM, Tero Kristo wrote: >>> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>>> >>>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>>>> >>>>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>>>> >>>>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>>>> >>>>>>> Tero, >>>>>>> >>>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>>>> set up the ckobuffer as required. >>>>>>> >>>>>>> Is this really a mux or should it be a mux clock? >>>>>> >>>>>> It is a pinmux setting for the clock out buffer to choose what signal >>>>>> (and polarity) is presented on the fref_xtal_clk pad. >>>>>> >>>>>> The register is part of the CTRL_MODULE_WKUP. >>>>>> The clock signal is the xtal master clock of the whole SoC. >>>>>> >>>>>> Although there is a bit to choose an alternate clock, there is no >>>>>> alternate in the OMAP5 silicon. >>>>>> >>>>>> Therefore I would say it is about padconf and not clock or clock mux >>>>>> related. >>>>>> >>>>>> It just happens to be a clock signal which can be routed to this >>>>>> pad. >>>>> >>>>> The two could very well be implemented as clock nodes, a mux and a gate. >>>>> This would describe the hardware functionality better imo, if the >>>>> assumptions made here are correct. Implementing the control as pinctrl >>>>> hacks looks rather weird to me. >>>> >>>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >>>> proper use of pinctrl. >>> >>> It is just the level of abstraction we are talking about here. If it is a >>> clock we are controlling, we should rather control it as a clock (higher level >>> abstraction), not a pin. >> >> I second this. I think it is better to have a simple gate clock and handle >> only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does >> not have real use. >> >> Then we can add clk API support for this. On most OMAP4 devices the clock is >> always on, > > this is why I am raising the question if we really want to control it on the omap5 or just > turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on > as a pinctrl is IMHO sufficient for all practical purposes. > >> so the board DTS file need to provide a dummy clock, or we can make >> the high precision clock also as optional (on panda both OMAP4 and twl6040 >> uses the same reference clock). > > Hm. It looks as if implementing this (and clock gating) is beyond my experiences. > But I am happy to test a proposal on our omap5 board. > > BR and thanks, > Nikolaus See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed. From: Tero Kristo <t-kristo@ti.com> Date: Thu, 28 Apr 2016 11:00:57 +0300 Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck Signed-off-by: Tero Kristo <t-kristo@ti.com> --- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- include/linux/clk/ti.h | 1 + 4 files changed, 49 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 38805eb..bdc6528 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -277,6 +277,28 @@ pinctrl-single,register-width = <16>; pinctrl-single,function-mask = <0x7fff>; }; + + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { + compatible = "ti,omap5-scm-wkup-pad-conf", + "simple-bus"; + reg = <0xcda0 0x60>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xcda0 0x60>; + + scm_wkup_pad_conf: scm_conf@0 { + compatible = "syscon", "simple-bus"; + reg = <0x0 0x60>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x60>; + + scm_wkup_pad_conf_clocks: clocks@0 { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + }; }; ocmcram: ocmcram@40300000 { diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi index 83b425f..f970dac 100644 --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi @@ -1388,3 +1388,13 @@ reg = <0x021c>; }; }; + +&scm_wkup_pad_conf_clocks { + fref_xtal_ck: fref_xtal_ck { + #clocks-cells = <0>; + compatible = "ti,gate-clock"; + clocks = <&sys_clkin>; + ti,bit-shift = <28>; + reg = <0x14>; + }; +}; diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 1662071..5956641 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void) struct control_init_data { int index; + void __iomem *mem; s16 offset; }; @@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = { .offset = -OMAP2_CONTROL_GENERAL, }; +static const struct control_init_data ctrl_aux_data = { + .index = TI_CLKM_CTRL_AUX, +}; + static const struct of_device_id omap_scrm_dt_match_table[] = { { .compatible = "ti,am3-scm", .data = &ctrl_data }, { .compatible = "ti,am4-scm", .data = &ctrl_data }, @@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = { { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, { } }; @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) struct device_node *np; const struct of_device_id *match; struct control_init_data *data; + void __iomem *mem; for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { data = (struct control_init_data *)match->data; - omap2_ctrl_base = of_iomap(np, 0); - if (!omap2_ctrl_base) + mem = of_iomap(np, 0); + if (!mem) return -ENOMEM; - omap2_ctrl_offset = data->offset; + if (data->index == TI_CLKM_CTRL) { + omap2_ctrl_base = mem; + omap2_ctrl_offset = data->offset; + } + + data->mem = mem; } return 0; @@ -713,7 +725,7 @@ int __init omap_control_init(void) } else { /* No scm_conf found, direct access */ ret = omap2_clk_provider_init(np, data->index, NULL, - omap2_ctrl_base); + data->mem); if (ret) return ret; } diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h index dc5164a..be25aa8 100644 --- a/include/linux/clk/ti.h +++ b/include/linux/clk/ti.h @@ -195,6 +195,7 @@ enum { TI_CLKM_PRM, TI_CLKM_SCRM, TI_CLKM_CTRL, + TI_CLKM_CTRL_AUX, TI_CLKM_PLLSS, CLK_MAX_MEMMAPS }; ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-28 8:03 ` Tero Kristo @ 2016-04-28 9:12 ` H. Nikolaus Schaller 2016-04-28 13:23 ` Tero Kristo 0 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-28 9:12 UTC (permalink / raw) To: Tero Kristo Cc: Peter Ujfalusi, Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel Hi Tero, > Am 28.04.2016 um 10:03 schrieb Tero Kristo <t-kristo@ti.com>: > > On 27/04/16 17:35, H. Nikolaus Schaller wrote: >> HI, >> >>> Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >>> >>> On 04/27/2016 05:10 PM, Tero Kristo wrote: >>>> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>>>> >>>>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>>>>> >>>>>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>>>>> >>>>>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>>>>> >>>>>>>> Tero, >>>>>>>> >>>>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>>>>> set up the ckobuffer as required. >>>>>>>> >>>>>>>> Is this really a mux or should it be a mux clock? >>>>>>> >>>>>>> It is a pinmux setting for the clock out buffer to choose what signal >>>>>>> (and polarity) is presented on the fref_xtal_clk pad. >>>>>>> >>>>>>> The register is part of the CTRL_MODULE_WKUP. >>>>>>> The clock signal is the xtal master clock of the whole SoC. >>>>>>> >>>>>>> Although there is a bit to choose an alternate clock, there is no >>>>>>> alternate in the OMAP5 silicon. >>>>>>> >>>>>>> Therefore I would say it is about padconf and not clock or clock mux >>>>>>> related. >>>>>>> >>>>>>> It just happens to be a clock signal which can be routed to this >>>>>>> pad. >>>>>> >>>>>> The two could very well be implemented as clock nodes, a mux and a gate. >>>>>> This would describe the hardware functionality better imo, if the >>>>>> assumptions made here are correct. Implementing the control as pinctrl >>>>>> hacks looks rather weird to me. >>>>> >>>>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >>>>> proper use of pinctrl. >>>> >>>> It is just the level of abstraction we are talking about here. If it is a >>>> clock we are controlling, we should rather control it as a clock (higher level >>>> abstraction), not a pin. >>> >>> I second this. I think it is better to have a simple gate clock and handle >>> only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does >>> not have real use. >>> >>> Then we can add clk API support for this. On most OMAP4 devices the clock is >>> always on, >> >> this is why I am raising the question if we really want to control it on the omap5 or just >> turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on >> as a pinctrl is IMHO sufficient for all practical purposes. >> >>> so the board DTS file need to provide a dummy clock, or we can make >>> the high precision clock also as optional (on panda both OMAP4 and twl6040 >>> uses the same reference clock). >> >> Hm. It looks as if implementing this (and clock gating) is beyond my experiences. >> But I am happy to test a proposal on our omap5 board. >> >> BR and thanks, >> Nikolaus > > See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed. Looks interesting, although quite complex to enable a single SoC pad at boot time... Will asap study how it works and test. And of course report results. Thanks and BR, Nikolaus > > From: Tero Kristo <t-kristo@ti.com> > Date: Thu, 28 Apr 2016 11:00:57 +0300 > Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck > > Signed-off-by: Tero Kristo <t-kristo@ti.com> > --- > arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ > arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ > arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- > include/linux/clk/ti.h | 1 + > 4 files changed, 49 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi > index 38805eb..bdc6528 100644 > --- a/arch/arm/boot/dts/omap5.dtsi > +++ b/arch/arm/boot/dts/omap5.dtsi > @@ -277,6 +277,28 @@ > pinctrl-single,register-width = <16>; > pinctrl-single,function-mask = <0x7fff>; > }; > + > + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { > + compatible = "ti,omap5-scm-wkup-pad-conf", > + "simple-bus"; > + reg = <0xcda0 0x60>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0xcda0 0x60>; > + > + scm_wkup_pad_conf: scm_conf@0 { > + compatible = "syscon", "simple-bus"; > + reg = <0x0 0x60>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0x0 0x60>; > + > + scm_wkup_pad_conf_clocks: clocks@0 { > + #address-cells = <1>; > + #size-cells = <0>; > + }; > + }; > + }; > }; > > ocmcram: ocmcram@40300000 { > diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi > index 83b425f..f970dac 100644 > --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi > +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi > @@ -1388,3 +1388,13 @@ > reg = <0x021c>; > }; > }; > + > +&scm_wkup_pad_conf_clocks { > + fref_xtal_ck: fref_xtal_ck { > + #clocks-cells = <0>; > + compatible = "ti,gate-clock"; > + clocks = <&sys_clkin>; > + ti,bit-shift = <28>; > + reg = <0x14>; > + }; > +}; > diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c > index 1662071..5956641 100644 > --- a/arch/arm/mach-omap2/control.c > +++ b/arch/arm/mach-omap2/control.c > @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void) > > struct control_init_data { > int index; > + void __iomem *mem; > s16 offset; > }; > > @@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = { > .offset = -OMAP2_CONTROL_GENERAL, > }; > > +static const struct control_init_data ctrl_aux_data = { > + .index = TI_CLKM_CTRL_AUX, > +}; > + > static const struct of_device_id omap_scrm_dt_match_table[] = { > { .compatible = "ti,am3-scm", .data = &ctrl_data }, > { .compatible = "ti,am4-scm", .data = &ctrl_data }, > @@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = { > { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, > { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, > { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, > + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, > { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, > { } > }; > @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) > struct device_node *np; > const struct of_device_id *match; > struct control_init_data *data; > + void __iomem *mem; > > for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { > data = (struct control_init_data *)match->data; > > - omap2_ctrl_base = of_iomap(np, 0); > - if (!omap2_ctrl_base) > + mem = of_iomap(np, 0); > + if (!mem) > return -ENOMEM; > > - omap2_ctrl_offset = data->offset; > + if (data->index == TI_CLKM_CTRL) { > + omap2_ctrl_base = mem; > + omap2_ctrl_offset = data->offset; > + } > + > + data->mem = mem; > } > > return 0; > @@ -713,7 +725,7 @@ int __init omap_control_init(void) > } else { > /* No scm_conf found, direct access */ > ret = omap2_clk_provider_init(np, data->index, NULL, > - omap2_ctrl_base); > + data->mem); > if (ret) > return ret; > } > diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h > index dc5164a..be25aa8 100644 > --- a/include/linux/clk/ti.h > +++ b/include/linux/clk/ti.h > @@ -195,6 +195,7 @@ enum { > TI_CLKM_PRM, > TI_CLKM_SCRM, > TI_CLKM_CTRL, > + TI_CLKM_CTRL_AUX, > TI_CLKM_PLLSS, > CLK_MAX_MEMMAPS > }; ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-28 9:12 ` H. Nikolaus Schaller @ 2016-04-28 13:23 ` Tero Kristo 2016-05-09 11:18 ` H. Nikolaus Schaller 0 siblings, 1 reply; 30+ messages in thread From: Tero Kristo @ 2016-04-28 13:23 UTC (permalink / raw) To: H. Nikolaus Schaller Cc: Peter Ujfalusi, Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel On 28/04/16 12:12, H. Nikolaus Schaller wrote: > Hi Tero, > >> Am 28.04.2016 um 10:03 schrieb Tero Kristo <t-kristo@ti.com>: >> >> On 27/04/16 17:35, H. Nikolaus Schaller wrote: >>> HI, >>> >>>> Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >>>> >>>> On 04/27/2016 05:10 PM, Tero Kristo wrote: >>>>> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>>>>> >>>>>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>>>>>> >>>>>>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>>>>>> >>>>>>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>>>>>> >>>>>>>>> Tero, >>>>>>>>> >>>>>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>>>>>> set up the ckobuffer as required. >>>>>>>>> >>>>>>>>> Is this really a mux or should it be a mux clock? >>>>>>>> >>>>>>>> It is a pinmux setting for the clock out buffer to choose what signal >>>>>>>> (and polarity) is presented on the fref_xtal_clk pad. >>>>>>>> >>>>>>>> The register is part of the CTRL_MODULE_WKUP. >>>>>>>> The clock signal is the xtal master clock of the whole SoC. >>>>>>>> >>>>>>>> Although there is a bit to choose an alternate clock, there is no >>>>>>>> alternate in the OMAP5 silicon. >>>>>>>> >>>>>>>> Therefore I would say it is about padconf and not clock or clock mux >>>>>>>> related. >>>>>>>> >>>>>>>> It just happens to be a clock signal which can be routed to this >>>>>>>> pad. >>>>>>> >>>>>>> The two could very well be implemented as clock nodes, a mux and a gate. >>>>>>> This would describe the hardware functionality better imo, if the >>>>>>> assumptions made here are correct. Implementing the control as pinctrl >>>>>>> hacks looks rather weird to me. >>>>>> >>>>>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >>>>>> proper use of pinctrl. >>>>> >>>>> It is just the level of abstraction we are talking about here. If it is a >>>>> clock we are controlling, we should rather control it as a clock (higher level >>>>> abstraction), not a pin. >>>> >>>> I second this. I think it is better to have a simple gate clock and handle >>>> only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does >>>> not have real use. >>>> >>>> Then we can add clk API support for this. On most OMAP4 devices the clock is >>>> always on, >>> >>> this is why I am raising the question if we really want to control it on the omap5 or just >>> turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on >>> as a pinctrl is IMHO sufficient for all practical purposes. >>> >>>> so the board DTS file need to provide a dummy clock, or we can make >>>> the high precision clock also as optional (on panda both OMAP4 and twl6040 >>>> uses the same reference clock). >>> >>> Hm. It looks as if implementing this (and clock gating) is beyond my experiences. >>> But I am happy to test a proposal on our omap5 board. >>> >>> BR and thanks, >>> Nikolaus >> >> See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed. > > Looks interesting, although quite complex to enable a single SoC pad at boot time... Yea it gives plenty of other things for you also. syscon, integration with clock framework, etc. > > Will asap study how it works and test. And of course report results. Thanks, Tero. > > Thanks and BR, > Nikolaus > >> >> From: Tero Kristo <t-kristo@ti.com> >> Date: Thu, 28 Apr 2016 11:00:57 +0300 >> Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck >> >> Signed-off-by: Tero Kristo <t-kristo@ti.com> >> --- >> arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ >> arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ >> arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- >> include/linux/clk/ti.h | 1 + >> 4 files changed, 49 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >> index 38805eb..bdc6528 100644 >> --- a/arch/arm/boot/dts/omap5.dtsi >> +++ b/arch/arm/boot/dts/omap5.dtsi >> @@ -277,6 +277,28 @@ >> pinctrl-single,register-width = <16>; >> pinctrl-single,function-mask = <0x7fff>; >> }; >> + >> + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { >> + compatible = "ti,omap5-scm-wkup-pad-conf", >> + "simple-bus"; >> + reg = <0xcda0 0x60>; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0 0xcda0 0x60>; >> + >> + scm_wkup_pad_conf: scm_conf@0 { >> + compatible = "syscon", "simple-bus"; >> + reg = <0x0 0x60>; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0 0x0 0x60>; >> + >> + scm_wkup_pad_conf_clocks: clocks@0 { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + }; >> + }; >> + }; >> }; >> >> ocmcram: ocmcram@40300000 { >> diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi >> index 83b425f..f970dac 100644 >> --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi >> +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi >> @@ -1388,3 +1388,13 @@ >> reg = <0x021c>; >> }; >> }; >> + >> +&scm_wkup_pad_conf_clocks { >> + fref_xtal_ck: fref_xtal_ck { >> + #clocks-cells = <0>; >> + compatible = "ti,gate-clock"; >> + clocks = <&sys_clkin>; >> + ti,bit-shift = <28>; >> + reg = <0x14>; >> + }; >> +}; >> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >> index 1662071..5956641 100644 >> --- a/arch/arm/mach-omap2/control.c >> +++ b/arch/arm/mach-omap2/control.c >> @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void) >> >> struct control_init_data { >> int index; >> + void __iomem *mem; >> s16 offset; >> }; >> >> @@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = { >> .offset = -OMAP2_CONTROL_GENERAL, >> }; >> >> +static const struct control_init_data ctrl_aux_data = { >> + .index = TI_CLKM_CTRL_AUX, >> +}; >> + >> static const struct of_device_id omap_scrm_dt_match_table[] = { >> { .compatible = "ti,am3-scm", .data = &ctrl_data }, >> { .compatible = "ti,am4-scm", .data = &ctrl_data }, >> @@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = { >> { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, >> { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, >> { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, >> + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, >> { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, >> { } >> }; >> @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) >> struct device_node *np; >> const struct of_device_id *match; >> struct control_init_data *data; >> + void __iomem *mem; >> >> for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { >> data = (struct control_init_data *)match->data; >> >> - omap2_ctrl_base = of_iomap(np, 0); >> - if (!omap2_ctrl_base) >> + mem = of_iomap(np, 0); >> + if (!mem) >> return -ENOMEM; >> >> - omap2_ctrl_offset = data->offset; >> + if (data->index == TI_CLKM_CTRL) { >> + omap2_ctrl_base = mem; >> + omap2_ctrl_offset = data->offset; >> + } >> + >> + data->mem = mem; >> } >> >> return 0; >> @@ -713,7 +725,7 @@ int __init omap_control_init(void) >> } else { >> /* No scm_conf found, direct access */ >> ret = omap2_clk_provider_init(np, data->index, NULL, >> - omap2_ctrl_base); >> + data->mem); >> if (ret) >> return ret; >> } >> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h >> index dc5164a..be25aa8 100644 >> --- a/include/linux/clk/ti.h >> +++ b/include/linux/clk/ti.h >> @@ -195,6 +195,7 @@ enum { >> TI_CLKM_PRM, >> TI_CLKM_SCRM, >> TI_CLKM_CTRL, >> + TI_CLKM_CTRL_AUX, >> TI_CLKM_PLLSS, >> CLK_MAX_MEMMAPS >> }; > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-04-28 13:23 ` Tero Kristo @ 2016-05-09 11:18 ` H. Nikolaus Schaller 2016-05-09 11:52 ` Tero Kristo 0 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-05-09 11:18 UTC (permalink / raw) To: Tero Kristo Cc: Peter Ujfalusi, Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel Hi, > Am 28.04.2016 um 15:23 schrieb Tero Kristo <t-kristo@ti.com>: > > On 28/04/16 12:12, H. Nikolaus Schaller wrote: >> Hi Tero, >> >>> Am 28.04.2016 um 10:03 schrieb Tero Kristo <t-kristo@ti.com>: >>> >>> On 27/04/16 17:35, H. Nikolaus Schaller wrote: >>>> HI, >>>> >>>>> Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >>>>> >>>>> On 04/27/2016 05:10 PM, Tero Kristo wrote: >>>>>> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>>>>>> >>>>>>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>>>>>>> >>>>>>>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>>>>>>> >>>>>>>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>>>>>>> >>>>>>>>>> Tero, >>>>>>>>>> >>>>>>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>>>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>>>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>>>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>>>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>>>>>>> set up the ckobuffer as required. >>>>>>>>>> >>>>>>>>>> Is this really a mux or should it be a mux clock? >>>>>>>>> >>>>>>>>> It is a pinmux setting for the clock out buffer to choose what signal >>>>>>>>> (and polarity) is presented on the fref_xtal_clk pad. >>>>>>>>> >>>>>>>>> The register is part of the CTRL_MODULE_WKUP. >>>>>>>>> The clock signal is the xtal master clock of the whole SoC. >>>>>>>>> >>>>>>>>> Although there is a bit to choose an alternate clock, there is no >>>>>>>>> alternate in the OMAP5 silicon. >>>>>>>>> >>>>>>>>> Therefore I would say it is about padconf and not clock or clock mux >>>>>>>>> related. >>>>>>>>> >>>>>>>>> It just happens to be a clock signal which can be routed to this >>>>>>>>> pad. >>>>>>>> >>>>>>>> The two could very well be implemented as clock nodes, a mux and a gate. >>>>>>>> This would describe the hardware functionality better imo, if the >>>>>>>> assumptions made here are correct. Implementing the control as pinctrl >>>>>>>> hacks looks rather weird to me. >>>>>>> >>>>>>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >>>>>>> proper use of pinctrl. >>>>>> >>>>>> It is just the level of abstraction we are talking about here. If it is a >>>>>> clock we are controlling, we should rather control it as a clock (higher level >>>>>> abstraction), not a pin. >>>>> >>>>> I second this. I think it is better to have a simple gate clock and handle >>>>> only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does >>>>> not have real use. >>>>> >>>>> Then we can add clk API support for this. On most OMAP4 devices the clock is >>>>> always on, >>>> >>>> this is why I am raising the question if we really want to control it on the omap5 or just >>>> turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on >>>> as a pinctrl is IMHO sufficient for all practical purposes. >>>> >>>>> so the board DTS file need to provide a dummy clock, or we can make >>>>> the high precision clock also as optional (on panda both OMAP4 and twl6040 >>>>> uses the same reference clock). >>>> >>>> Hm. It looks as if implementing this (and clock gating) is beyond my experiences. >>>> But I am happy to test a proposal on our omap5 board. >>>> >>>> BR and thanks, >>>> Nikolaus >>> >>> See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed. >> >> Looks interesting, although quite complex to enable a single SoC pad at boot time... > > Yea it gives plenty of other things for you also. syscon, integration with clock framework, etc. > >> >> Will asap study how it works and test. And of course report results. > > Thanks, Tero. > >> >> Thanks and BR, >> Nikolaus >> >>> >>> From: Tero Kristo <t-kristo@ti.com> >>> Date: Thu, 28 Apr 2016 11:00:57 +0300 >>> Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck >>> >>> Signed-off-by: Tero Kristo <t-kristo@ti.com> >>> --- >>> arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ >>> arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ >>> arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- >>> include/linux/clk/ti.h | 1 + >>> 4 files changed, 49 insertions(+), 4 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >>> index 38805eb..bdc6528 100644 >>> --- a/arch/arm/boot/dts/omap5.dtsi >>> +++ b/arch/arm/boot/dts/omap5.dtsi >>> @@ -277,6 +277,28 @@ >>> pinctrl-single,register-width = <16>; >>> pinctrl-single,function-mask = <0x7fff>; >>> }; >>> + >>> + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { >>> + compatible = "ti,omap5-scm-wkup-pad-conf", >>> + "simple-bus"; >>> + reg = <0xcda0 0x60>; >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + ranges = <0 0xcda0 0x60>; >>> + >>> + scm_wkup_pad_conf: scm_conf@0 { >>> + compatible = "syscon", "simple-bus"; >>> + reg = <0x0 0x60>; >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + ranges = <0 0x0 0x60>; >>> + >>> + scm_wkup_pad_conf_clocks: clocks@0 { >>> + #address-cells = <1>; >>> + #size-cells = <0>; >>> + }; >>> + }; >>> + }; >>> }; >>> >>> ocmcram: ocmcram@40300000 { >>> diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi >>> index 83b425f..f970dac 100644 >>> --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi >>> +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi >>> @@ -1388,3 +1388,13 @@ >>> reg = <0x021c>; >>> }; >>> }; >>> + >>> +&scm_wkup_pad_conf_clocks { >>> + fref_xtal_ck: fref_xtal_ck { >>> + #clocks-cells = <0>; >>> + compatible = "ti,gate-clock"; >>> + clocks = <&sys_clkin>; >>> + ti,bit-shift = <28>; >>> + reg = <0x14>; >>> + }; >>> +}; >>> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >>> index 1662071..5956641 100644 >>> --- a/arch/arm/mach-omap2/control.c >>> +++ b/arch/arm/mach-omap2/control.c >>> @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void) >>> >>> struct control_init_data { >>> int index; >>> + void __iomem *mem; >>> s16 offset; >>> }; >>> >>> @@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = { >>> .offset = -OMAP2_CONTROL_GENERAL, >>> }; >>> >>> +static const struct control_init_data ctrl_aux_data = { >>> + .index = TI_CLKM_CTRL_AUX, >>> +}; >>> + >>> static const struct of_device_id omap_scrm_dt_match_table[] = { >>> { .compatible = "ti,am3-scm", .data = &ctrl_data }, >>> { .compatible = "ti,am4-scm", .data = &ctrl_data }, >>> @@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = { >>> { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, >>> { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, >>> { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, >>> + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, >>> { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, >>> { } >>> }; >>> @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) >>> struct device_node *np; >>> const struct of_device_id *match; >>> struct control_init_data *data; >>> + void __iomem *mem; >>> >>> for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { >>> data = (struct control_init_data *)match->data; >>> >>> - omap2_ctrl_base = of_iomap(np, 0); >>> - if (!omap2_ctrl_base) >>> + mem = of_iomap(np, 0); >>> + if (!mem) >>> return -ENOMEM; >>> >>> - omap2_ctrl_offset = data->offset; >>> + if (data->index == TI_CLKM_CTRL) { >>> + omap2_ctrl_base = mem; >>> + omap2_ctrl_offset = data->offset; >>> + } >>> + >>> + data->mem = mem; >>> } >>> >>> return 0; >>> @@ -713,7 +725,7 @@ int __init omap_control_init(void) >>> } else { >>> /* No scm_conf found, direct access */ >>> ret = omap2_clk_provider_init(np, data->index, NULL, >>> - omap2_ctrl_base); >>> + data->mem); >>> if (ret) >>> return ret; >>> } >>> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h >>> index dc5164a..be25aa8 100644 >>> --- a/include/linux/clk/ti.h >>> +++ b/include/linux/clk/ti.h >>> @@ -195,6 +195,7 @@ enum { >>> TI_CLKM_PRM, >>> TI_CLKM_SCRM, >>> TI_CLKM_CTRL, >>> + TI_CLKM_CTRL_AUX, >>> TI_CLKM_PLLSS, >>> CLK_MAX_MEMMAPS >>> }; >> > finally I found some time to apply your patches. Sorry for the long time. Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through amixer so it is created on the digital input side of the twl6040). So I think your patch is missing a detail compared to my simple solution. BR, Nikolaus ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 11:18 ` H. Nikolaus Schaller @ 2016-05-09 11:52 ` Tero Kristo 2016-05-09 12:10 ` Peter Ujfalusi 2016-05-10 5:45 ` H. Nikolaus Schaller 0 siblings, 2 replies; 30+ messages in thread From: Tero Kristo @ 2016-05-09 11:52 UTC (permalink / raw) To: H. Nikolaus Schaller Cc: Peter Ujfalusi, Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel On 09/05/16 14:18, H. Nikolaus Schaller wrote: > Hi, > >> Am 28.04.2016 um 15:23 schrieb Tero Kristo <t-kristo@ti.com>: >> >> On 28/04/16 12:12, H. Nikolaus Schaller wrote: >>> Hi Tero, >>> >>>> Am 28.04.2016 um 10:03 schrieb Tero Kristo <t-kristo@ti.com>: >>>> >>>> On 27/04/16 17:35, H. Nikolaus Schaller wrote: >>>>> HI, >>>>> >>>>>> Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >>>>>> >>>>>> On 04/27/2016 05:10 PM, Tero Kristo wrote: >>>>>>> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>>>>>>> >>>>>>>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>>>>>>>> >>>>>>>>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>>>>>>>> >>>>>>>>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>>>>>>>> >>>>>>>>>>> Tero, >>>>>>>>>>> >>>>>>>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>>>>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>>>>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>>>>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>>>>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>>>>>>>> set up the ckobuffer as required. >>>>>>>>>>> >>>>>>>>>>> Is this really a mux or should it be a mux clock? >>>>>>>>>> >>>>>>>>>> It is a pinmux setting for the clock out buffer to choose what signal >>>>>>>>>> (and polarity) is presented on the fref_xtal_clk pad. >>>>>>>>>> >>>>>>>>>> The register is part of the CTRL_MODULE_WKUP. >>>>>>>>>> The clock signal is the xtal master clock of the whole SoC. >>>>>>>>>> >>>>>>>>>> Although there is a bit to choose an alternate clock, there is no >>>>>>>>>> alternate in the OMAP5 silicon. >>>>>>>>>> >>>>>>>>>> Therefore I would say it is about padconf and not clock or clock mux >>>>>>>>>> related. >>>>>>>>>> >>>>>>>>>> It just happens to be a clock signal which can be routed to this >>>>>>>>>> pad. >>>>>>>>> >>>>>>>>> The two could very well be implemented as clock nodes, a mux and a gate. >>>>>>>>> This would describe the hardware functionality better imo, if the >>>>>>>>> assumptions made here are correct. Implementing the control as pinctrl >>>>>>>>> hacks looks rather weird to me. >>>>>>>> >>>>>>>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >>>>>>>> proper use of pinctrl. >>>>>>> >>>>>>> It is just the level of abstraction we are talking about here. If it is a >>>>>>> clock we are controlling, we should rather control it as a clock (higher level >>>>>>> abstraction), not a pin. >>>>>> >>>>>> I second this. I think it is better to have a simple gate clock and handle >>>>>> only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does >>>>>> not have real use. >>>>>> >>>>>> Then we can add clk API support for this. On most OMAP4 devices the clock is >>>>>> always on, >>>>> >>>>> this is why I am raising the question if we really want to control it on the omap5 or just >>>>> turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on >>>>> as a pinctrl is IMHO sufficient for all practical purposes. >>>>> >>>>>> so the board DTS file need to provide a dummy clock, or we can make >>>>>> the high precision clock also as optional (on panda both OMAP4 and twl6040 >>>>>> uses the same reference clock). >>>>> >>>>> Hm. It looks as if implementing this (and clock gating) is beyond my experiences. >>>>> But I am happy to test a proposal on our omap5 board. >>>>> >>>>> BR and thanks, >>>>> Nikolaus >>>> >>>> See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed. >>> >>> Looks interesting, although quite complex to enable a single SoC pad at boot time... >> >> Yea it gives plenty of other things for you also. syscon, integration with clock framework, etc. >> >>> >>> Will asap study how it works and test. And of course report results. >> >> Thanks, Tero. >> >>> >>> Thanks and BR, >>> Nikolaus >>> >>>> >>>> From: Tero Kristo <t-kristo@ti.com> >>>> Date: Thu, 28 Apr 2016 11:00:57 +0300 >>>> Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck >>>> >>>> Signed-off-by: Tero Kristo <t-kristo@ti.com> >>>> --- >>>> arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ >>>> arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ >>>> arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- >>>> include/linux/clk/ti.h | 1 + >>>> 4 files changed, 49 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >>>> index 38805eb..bdc6528 100644 >>>> --- a/arch/arm/boot/dts/omap5.dtsi >>>> +++ b/arch/arm/boot/dts/omap5.dtsi >>>> @@ -277,6 +277,28 @@ >>>> pinctrl-single,register-width = <16>; >>>> pinctrl-single,function-mask = <0x7fff>; >>>> }; >>>> + >>>> + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { >>>> + compatible = "ti,omap5-scm-wkup-pad-conf", >>>> + "simple-bus"; >>>> + reg = <0xcda0 0x60>; >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + ranges = <0 0xcda0 0x60>; >>>> + >>>> + scm_wkup_pad_conf: scm_conf@0 { >>>> + compatible = "syscon", "simple-bus"; >>>> + reg = <0x0 0x60>; >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + ranges = <0 0x0 0x60>; >>>> + >>>> + scm_wkup_pad_conf_clocks: clocks@0 { >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + }; >>>> + }; >>>> + }; >>>> }; >>>> >>>> ocmcram: ocmcram@40300000 { >>>> diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>> index 83b425f..f970dac 100644 >>>> --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>> +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>> @@ -1388,3 +1388,13 @@ >>>> reg = <0x021c>; >>>> }; >>>> }; >>>> + >>>> +&scm_wkup_pad_conf_clocks { >>>> + fref_xtal_ck: fref_xtal_ck { >>>> + #clocks-cells = <0>; >>>> + compatible = "ti,gate-clock"; >>>> + clocks = <&sys_clkin>; >>>> + ti,bit-shift = <28>; >>>> + reg = <0x14>; >>>> + }; >>>> +}; >>>> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >>>> index 1662071..5956641 100644 >>>> --- a/arch/arm/mach-omap2/control.c >>>> +++ b/arch/arm/mach-omap2/control.c >>>> @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void) >>>> >>>> struct control_init_data { >>>> int index; >>>> + void __iomem *mem; >>>> s16 offset; >>>> }; >>>> >>>> @@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = { >>>> .offset = -OMAP2_CONTROL_GENERAL, >>>> }; >>>> >>>> +static const struct control_init_data ctrl_aux_data = { >>>> + .index = TI_CLKM_CTRL_AUX, >>>> +}; >>>> + >>>> static const struct of_device_id omap_scrm_dt_match_table[] = { >>>> { .compatible = "ti,am3-scm", .data = &ctrl_data }, >>>> { .compatible = "ti,am4-scm", .data = &ctrl_data }, >>>> @@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = { >>>> { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, >>>> { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, >>>> { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, >>>> + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, >>>> { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, >>>> { } >>>> }; >>>> @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) >>>> struct device_node *np; >>>> const struct of_device_id *match; >>>> struct control_init_data *data; >>>> + void __iomem *mem; >>>> >>>> for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { >>>> data = (struct control_init_data *)match->data; >>>> >>>> - omap2_ctrl_base = of_iomap(np, 0); >>>> - if (!omap2_ctrl_base) >>>> + mem = of_iomap(np, 0); >>>> + if (!mem) >>>> return -ENOMEM; >>>> >>>> - omap2_ctrl_offset = data->offset; >>>> + if (data->index == TI_CLKM_CTRL) { >>>> + omap2_ctrl_base = mem; >>>> + omap2_ctrl_offset = data->offset; >>>> + } >>>> + >>>> + data->mem = mem; >>>> } >>>> >>>> return 0; >>>> @@ -713,7 +725,7 @@ int __init omap_control_init(void) >>>> } else { >>>> /* No scm_conf found, direct access */ >>>> ret = omap2_clk_provider_init(np, data->index, NULL, >>>> - omap2_ctrl_base); >>>> + data->mem); >>>> if (ret) >>>> return ret; >>>> } >>>> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h >>>> index dc5164a..be25aa8 100644 >>>> --- a/include/linux/clk/ti.h >>>> +++ b/include/linux/clk/ti.h >>>> @@ -195,6 +195,7 @@ enum { >>>> TI_CLKM_PRM, >>>> TI_CLKM_SCRM, >>>> TI_CLKM_CTRL, >>>> + TI_CLKM_CTRL_AUX, >>>> TI_CLKM_PLLSS, >>>> CLK_MAX_MEMMAPS >>>> }; >>> >> > > finally I found some time to apply your patches. Sorry for the long time. > > Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. > I get no sound on the twl6040 - just white noise (which can be controlled in level through > amixer so it is created on the digital input side of the twl6040). > > So I think your patch is missing a detail compared to my simple solution. Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch. -Tero > > 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 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 11:52 ` Tero Kristo @ 2016-05-09 12:10 ` Peter Ujfalusi 2016-05-09 12:32 ` [Kernel] " Peter Ujfalusi 2016-05-10 5:45 ` H. Nikolaus Schaller 1 sibling, 1 reply; 30+ messages in thread From: Peter Ujfalusi @ 2016-05-09 12:10 UTC (permalink / raw) To: Tero Kristo, H. Nikolaus Schaller Cc: Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel On 05/09/16 14:52, Tero Kristo wrote: > On 09/05/16 14:18, H. Nikolaus Schaller wrote: >> Hi, >> >>> Am 28.04.2016 um 15:23 schrieb Tero Kristo <t-kristo@ti.com>: >>> >>> On 28/04/16 12:12, H. Nikolaus Schaller wrote: >>>> Hi Tero, >>>> >>>>> Am 28.04.2016 um 10:03 schrieb Tero Kristo <t-kristo@ti.com>: >>>>> >>>>> On 27/04/16 17:35, H. Nikolaus Schaller wrote: >>>>>> HI, >>>>>> >>>>>>> Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >>>>>>> >>>>>>> On 04/27/2016 05:10 PM, Tero Kristo wrote: >>>>>>>> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>>>>>>>> >>>>>>>>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>>>>>>>>> >>>>>>>>>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>>>>>>>>> >>>>>>>>>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>>>>>>>>> >>>>>>>>>>>> Tero, >>>>>>>>>>>> >>>>>>>>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>>>>>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>>>>>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>>>>>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>>>>>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>>>>>>>>> set up the ckobuffer as required. >>>>>>>>>>>> >>>>>>>>>>>> Is this really a mux or should it be a mux clock? >>>>>>>>>>> >>>>>>>>>>> It is a pinmux setting for the clock out buffer to choose what signal >>>>>>>>>>> (and polarity) is presented on the fref_xtal_clk pad. >>>>>>>>>>> >>>>>>>>>>> The register is part of the CTRL_MODULE_WKUP. >>>>>>>>>>> The clock signal is the xtal master clock of the whole SoC. >>>>>>>>>>> >>>>>>>>>>> Although there is a bit to choose an alternate clock, there is no >>>>>>>>>>> alternate in the OMAP5 silicon. >>>>>>>>>>> >>>>>>>>>>> Therefore I would say it is about padconf and not clock or clock mux >>>>>>>>>>> related. >>>>>>>>>>> >>>>>>>>>>> It just happens to be a clock signal which can be routed to this >>>>>>>>>>> pad. >>>>>>>>>> >>>>>>>>>> The two could very well be implemented as clock nodes, a mux and a >>>>>>>>>> gate. >>>>>>>>>> This would describe the hardware functionality better imo, if the >>>>>>>>>> assumptions made here are correct. Implementing the control as pinctrl >>>>>>>>>> hacks looks rather weird to me. >>>>>>>>> >>>>>>>>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >>>>>>>>> proper use of pinctrl. >>>>>>>> >>>>>>>> It is just the level of abstraction we are talking about here. If it is a >>>>>>>> clock we are controlling, we should rather control it as a clock >>>>>>>> (higher level >>>>>>>> abstraction), not a pin. >>>>>>> >>>>>>> I second this. I think it is better to have a simple gate clock and handle >>>>>>> only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits >>>>>>> does >>>>>>> not have real use. >>>>>>> >>>>>>> Then we can add clk API support for this. On most OMAP4 devices the >>>>>>> clock is >>>>>>> always on, >>>>>> >>>>>> this is why I am raising the question if we really want to control it on >>>>>> the omap5 or just >>>>>> turn it on for all omap5 boards like the omap4 appears to do... I.e. if >>>>>> turning the pin on >>>>>> as a pinctrl is IMHO sufficient for all practical purposes. >>>>>> >>>>>>> so the board DTS file need to provide a dummy clock, or we can make >>>>>>> the high precision clock also as optional (on panda both OMAP4 and twl6040 >>>>>>> uses the same reference clock). >>>>>> >>>>>> Hm. It looks as if implementing this (and clock gating) is beyond my >>>>>> experiences. >>>>>> But I am happy to test a proposal on our omap5 board. >>>>>> >>>>>> BR and thanks, >>>>>> Nikolaus >>>>> >>>>> See the inline patch, this implements the fref_xtal_ck. I had to add some >>>>> kernel code also to cope with the new SCM area, but the same area can now >>>>> be accessed via syscon also if needed. >>>> >>>> Looks interesting, although quite complex to enable a single SoC pad at >>>> boot time... >>> >>> Yea it gives plenty of other things for you also. syscon, integration with >>> clock framework, etc. >>> >>>> >>>> Will asap study how it works and test. And of course report results. >>> >>> Thanks, Tero. >>> >>>> >>>> Thanks and BR, >>>> Nikolaus >>>> >>>>> >>>>> From: Tero Kristo <t-kristo@ti.com> >>>>> Date: Thu, 28 Apr 2016 11:00:57 +0300 >>>>> Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck >>>>> >>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com> >>>>> --- >>>>> arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ >>>>> arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ >>>>> arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- >>>>> include/linux/clk/ti.h | 1 + >>>>> 4 files changed, 49 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >>>>> index 38805eb..bdc6528 100644 >>>>> --- a/arch/arm/boot/dts/omap5.dtsi >>>>> +++ b/arch/arm/boot/dts/omap5.dtsi >>>>> @@ -277,6 +277,28 @@ >>>>> pinctrl-single,register-width = <16>; >>>>> pinctrl-single,function-mask = <0x7fff>; >>>>> }; >>>>> + >>>>> + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { >>>>> + compatible = "ti,omap5-scm-wkup-pad-conf", >>>>> + "simple-bus"; >>>>> + reg = <0xcda0 0x60>; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <1>; >>>>> + ranges = <0 0xcda0 0x60>; >>>>> + >>>>> + scm_wkup_pad_conf: scm_conf@0 { >>>>> + compatible = "syscon", "simple-bus"; >>>>> + reg = <0x0 0x60>; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <1>; >>>>> + ranges = <0 0x0 0x60>; >>>>> + >>>>> + scm_wkup_pad_conf_clocks: clocks@0 { >>>>> + #address-cells = <1>; >>>>> + #size-cells = <0>; >>>>> + }; >>>>> + }; >>>>> + }; >>>>> }; >>>>> >>>>> ocmcram: ocmcram@40300000 { >>>>> diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>>> b/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>>> index 83b425f..f970dac 100644 >>>>> --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>>> +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>>> @@ -1388,3 +1388,13 @@ >>>>> reg = <0x021c>; >>>>> }; >>>>> }; >>>>> + >>>>> +&scm_wkup_pad_conf_clocks { >>>>> + fref_xtal_ck: fref_xtal_ck { >>>>> + #clocks-cells = <0>; >>>>> + compatible = "ti,gate-clock"; >>>>> + clocks = <&sys_clkin>; >>>>> + ti,bit-shift = <28>; >>>>> + reg = <0x14>; >>>>> + }; >>>>> +}; >>>>> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >>>>> index 1662071..5956641 100644 >>>>> --- a/arch/arm/mach-omap2/control.c >>>>> +++ b/arch/arm/mach-omap2/control.c >>>>> @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void) >>>>> >>>>> struct control_init_data { >>>>> int index; >>>>> + void __iomem *mem; >>>>> s16 offset; >>>>> }; >>>>> >>>>> @@ -635,6 +636,10 @@ static const struct control_init_data >>>>> omap2_ctrl_data = { >>>>> .offset = -OMAP2_CONTROL_GENERAL, >>>>> }; >>>>> >>>>> +static const struct control_init_data ctrl_aux_data = { >>>>> + .index = TI_CLKM_CTRL_AUX, >>>>> +}; >>>>> + >>>>> static const struct of_device_id omap_scrm_dt_match_table[] = { >>>>> { .compatible = "ti,am3-scm", .data = &ctrl_data }, >>>>> { .compatible = "ti,am4-scm", .data = &ctrl_data }, >>>>> @@ -644,6 +649,7 @@ static const struct of_device_id >>>>> omap_scrm_dt_match_table[] = { >>>>> { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, >>>>> { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, >>>>> { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, >>>>> + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, >>>>> { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, >>>>> { } >>>>> }; >>>>> @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) >>>>> struct device_node *np; >>>>> const struct of_device_id *match; >>>>> struct control_init_data *data; >>>>> + void __iomem *mem; >>>>> >>>>> for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { >>>>> data = (struct control_init_data *)match->data; >>>>> >>>>> - omap2_ctrl_base = of_iomap(np, 0); >>>>> - if (!omap2_ctrl_base) >>>>> + mem = of_iomap(np, 0); >>>>> + if (!mem) >>>>> return -ENOMEM; >>>>> >>>>> - omap2_ctrl_offset = data->offset; >>>>> + if (data->index == TI_CLKM_CTRL) { >>>>> + omap2_ctrl_base = mem; >>>>> + omap2_ctrl_offset = data->offset; >>>>> + } >>>>> + >>>>> + data->mem = mem; >>>>> } >>>>> >>>>> return 0; >>>>> @@ -713,7 +725,7 @@ int __init omap_control_init(void) >>>>> } else { >>>>> /* No scm_conf found, direct access */ >>>>> ret = omap2_clk_provider_init(np, data->index, NULL, >>>>> - omap2_ctrl_base); >>>>> + data->mem); >>>>> if (ret) >>>>> return ret; >>>>> } >>>>> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h >>>>> index dc5164a..be25aa8 100644 >>>>> --- a/include/linux/clk/ti.h >>>>> +++ b/include/linux/clk/ti.h >>>>> @@ -195,6 +195,7 @@ enum { >>>>> TI_CLKM_PRM, >>>>> TI_CLKM_SCRM, >>>>> TI_CLKM_CTRL, >>>>> + TI_CLKM_CTRL_AUX, >>>>> TI_CLKM_PLLSS, >>>>> CLK_MAX_MEMMAPS >>>>> }; >>>> >>> >> >> finally I found some time to apply your patches. Sorry for the long time. >> >> Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. >> I get no sound on the twl6040 - just white noise (which can be controlled in >> level through >> amixer so it is created on the digital input side of the twl6040). >> >> So I think your patch is missing a detail compared to my simple solution. > > Did you implement anything on the audio driver side? The audio driver must > enable the clock implemented by this patch. I did, can test it in 10 minutes or so... > > -Tero > >> >> 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 >> > -- Péter ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Kernel] [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 12:10 ` Peter Ujfalusi @ 2016-05-09 12:32 ` Peter Ujfalusi 2016-05-09 12:46 ` Peter Ujfalusi 2016-05-09 19:44 ` Peter Ujfalusi 0 siblings, 2 replies; 30+ messages in thread From: Peter Ujfalusi @ 2016-05-09 12:32 UTC (permalink / raw) To: Tero Kristo, H. Nikolaus Schaller Cc: Mark Rutland, devicetree, Discussions about the Letux Kernel, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren, kernel, LKML, Rob Herring, Laxman Dewangan, Benoît Cousson, Kumar Gala, Marek Belisko, linux-omap [-- Attachment #1: Type: text/plain, Size: 914 bytes --] On 05/09/16 15:10, Peter Ujfalusi wrote: >>> finally I found some time to apply your patches. Sorry for the long time. >>> >>> Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. >>> I get no sound on the twl6040 - just white noise (which can be controlled in >>> level through >>> amixer so it is created on the digital input side of the twl6040). >>> >>> So I think your patch is missing a detail compared to my simple solution. >> >> Did you implement anything on the audio driver side? The audio driver must >> enable the clock implemented by this patch. > > I did, can test it in 10 minutes or so... might work, but linux-next is not booting on omap5-uevm :o I don't know why... In any case I have attached the 3 patches I have for this, including Tero's ported to linux-next. Patch 3 might need to be done per board probably, but this should be good for testing. -- Péter [-- Attachment #2: 0001-ARM-omap5-add-support-for-fref_xtal_ck.patch --] [-- Type: text/x-patch, Size: 4172 bytes --] >From d492ada3f7734eb1e4999c68ef0950c1ace9a6c8 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi <peter.ujfalusi@ti.com> Date: Mon, 9 May 2016 15:17:50 +0300 Subject: [PATCH 1/3] ARM: omap5: add support for fref_xtal_ck Signed-off-by: Tero Kristo <t-kristo@ti.com> --- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- include/linux/clk/ti.h | 1 + 4 files changed, 49 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 84c10195e79b..d0d6a6c6fcc3 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -198,6 +198,28 @@ }; }; }; + + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { + compatible = "ti,omap5-scm-wkup-pad-conf", + "simple-bus"; + reg = <0xcda0 0x60>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xcda0 0x60>; + + scm_wkup_pad_conf: scm_conf@0 { + compatible = "syscon", "simple-bus"; + reg = <0x0 0x60>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x60>; + + scm_wkup_pad_conf_clocks: clocks@0 { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + }; }; cm_core_aon: cm_core_aon@4000 { diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi index 4899c2359d0a..2450ea635c65 100644 --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi @@ -1388,3 +1388,13 @@ reg = <0x021c>; }; }; + +&scm_wkup_pad_conf_clocks { + fref_xtal_ck: fref_xtal_ck { + #clocks-cells = <0>; + compatible = "ti,gate-clock"; + clocks = <&sys_clkin>; + ti,bit-shift = <28>; + reg = <0x14>; + }; +}; diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 1662071bb2cc..595664173e49 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void) struct control_init_data { int index; + void __iomem *mem; s16 offset; }; @@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = { .offset = -OMAP2_CONTROL_GENERAL, }; +static const struct control_init_data ctrl_aux_data = { + .index = TI_CLKM_CTRL_AUX, +}; + static const struct of_device_id omap_scrm_dt_match_table[] = { { .compatible = "ti,am3-scm", .data = &ctrl_data }, { .compatible = "ti,am4-scm", .data = &ctrl_data }, @@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = { { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, { } }; @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) struct device_node *np; const struct of_device_id *match; struct control_init_data *data; + void __iomem *mem; for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { data = (struct control_init_data *)match->data; - omap2_ctrl_base = of_iomap(np, 0); - if (!omap2_ctrl_base) + mem = of_iomap(np, 0); + if (!mem) return -ENOMEM; - omap2_ctrl_offset = data->offset; + if (data->index == TI_CLKM_CTRL) { + omap2_ctrl_base = mem; + omap2_ctrl_offset = data->offset; + } + + data->mem = mem; } return 0; @@ -713,7 +725,7 @@ int __init omap_control_init(void) } else { /* No scm_conf found, direct access */ ret = omap2_clk_provider_init(np, data->index, NULL, - omap2_ctrl_base); + data->mem); if (ret) return ret; } diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h index 6110fe09ed18..5431f17a36bc 100644 --- a/include/linux/clk/ti.h +++ b/include/linux/clk/ti.h @@ -197,6 +197,7 @@ enum { TI_CLKM_PRM, TI_CLKM_SCRM, TI_CLKM_CTRL, + TI_CLKM_CTRL_AUX, TI_CLKM_PLLSS, CLK_MAX_MEMMAPS }; -- 2.8.2 [-- Attachment #3: 0002-mfd-twl6040-Handle-mclk-for-HPPLL-via-clock-API.patch --] [-- Type: text/x-patch, Size: 2769 bytes --] >From d1099793e9189c6bb9514cfbed38638f0873a53d Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi <peter.ujfalusi@ti.com> Date: Mon, 9 May 2016 15:24:40 +0300 Subject: [PATCH 2/3] mfd: twl6040: Handle mclk (for HPPLL) via clock API Support for mclk handling via clock API Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> --- drivers/mfd/twl6040.c | 27 ++++++++++++++++++++------- include/linux/mfd/twl6040.h | 3 ++- 2 files changed, 22 insertions(+), 8 deletions(-) diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 08a693cd38cc..32b72b65a0f0 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -291,7 +291,9 @@ int twl6040_power(struct twl6040 *twl6040, int on) if (twl6040->power_count++) goto out; - clk_prepare_enable(twl6040->clk32k); + clk_prepare_enable(twl6040->clk32k_clk); + if (twl6040->pll == TWL6040_SYSCLK_SEL_HPPLL) + clk_prepare_enable(twl6040->mclk_clk); /* Allow writes to the chip */ regcache_cache_only(twl6040->regmap, false); @@ -349,7 +351,10 @@ int twl6040_power(struct twl6040 *twl6040, int on) twl6040->sysclk = 0; twl6040->mclk = 0; - clk_disable_unprepare(twl6040->clk32k); + if (twl6040->pll == TWL6040_SYSCLK_SEL_HPPLL) + clk_disable_unprepare(twl6040->mclk_clk); + + clk_disable_unprepare(twl6040->clk32k_clk); } out: @@ -645,12 +650,20 @@ static int twl6040_probe(struct i2c_client *client, i2c_set_clientdata(client, twl6040); - twl6040->clk32k = devm_clk_get(&client->dev, "clk32k"); - if (IS_ERR(twl6040->clk32k)) { - if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER) + twl6040->clk32k_clk = devm_clk_get(&client->dev, "clk32k_clk"); + if (IS_ERR(twl6040->clk32k_clk)) { + if (PTR_ERR(twl6040->clk32k_clk) == -EPROBE_DEFER) + return -EPROBE_DEFER; + dev_info(&client->dev, "clk32k_clk is not handled\n"); + twl6040->clk32k_clk = NULL; + } + + twl6040->mclk_clk = devm_clk_get(&client->dev, "mclk"); + if (IS_ERR(twl6040->mclk_clk)) { + if (PTR_ERR(twl6040->mclk_clk) == -EPROBE_DEFER) return -EPROBE_DEFER; - dev_info(&client->dev, "clk32k is not handled\n"); - twl6040->clk32k = NULL; + dev_info(&client->dev, "mclk is not handled\n"); + twl6040->mclk_clk = NULL; } twl6040->supplies[0].supply = "vio"; diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index 8f9fc3d26e6d..a7c50e54f3e0 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -224,7 +224,8 @@ struct twl6040 { struct regmap *regmap; struct regmap_irq_chip_data *irq_data; struct regulator_bulk_data supplies[2]; /* supplies for vio, v2v1 */ - struct clk *clk32k; + struct clk *clk32k_clk; + struct clk *mclk_clk; struct mutex mutex; struct mutex irq_mutex; struct mfd_cell cells[TWL6040_CELLS]; -- 2.8.2 [-- Attachment #4: 0003-ARM-dts-omap5-board-common-Add-phandle-for-mclk-cloc.patch --] [-- Type: text/x-patch, Size: 899 bytes --] >From 87714553b1f803f9c08d32c2c61dc980ddbb1b78 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi <peter.ujfalusi@ti.com> Date: Mon, 9 May 2016 15:26:11 +0300 Subject: [PATCH 3/3] ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040 it is used for hppll. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> --- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index a3a631fb77aa..4caad4dc5d41 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -649,8 +649,8 @@ v2v1-supply = <&smps9_reg>; enable-active-high; - clocks = <&clk32kgaudio>; - clock-names = "clk32k"; + clocks = <&clk32kgaudio>, <&fref_xtal_ck>; + clock-names = "clk32k", "mclk"; }; }; -- 2.8.2 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [Kernel] [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 12:32 ` [Kernel] " Peter Ujfalusi @ 2016-05-09 12:46 ` Peter Ujfalusi 2016-05-09 13:52 ` Peter Ujfalusi 2016-05-09 19:44 ` Peter Ujfalusi 1 sibling, 1 reply; 30+ messages in thread From: Peter Ujfalusi @ 2016-05-09 12:46 UTC (permalink / raw) To: Tero Kristo, H. Nikolaus Schaller Cc: Mark Rutland, devicetree, linux-omap, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala, LKML, Rob Herring, Laxman Dewangan, Benoît Cousson, kernel, Marek Belisko, Discussions about the Letux Kernel On 05/09/16 15:32, Peter Ujfalusi wrote: > On 05/09/16 15:10, Peter Ujfalusi wrote: > >>>> finally I found some time to apply your patches. Sorry for the long time. >>>> >>>> Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. >>>> I get no sound on the twl6040 - just white noise (which can be controlled in >>>> level through >>>> amixer so it is created on the digital input side of the twl6040). >>>> >>>> So I think your patch is missing a detail compared to my simple solution. >>> >>> Did you implement anything on the audio driver side? The audio driver must >>> enable the clock implemented by this patch. >> >> I did, can test it in 10 minutes or so... > > might work, but linux-next is not booting on omap5-uevm :o I don't know why... Applying Tero's alone makes the board not to boot, so something there... I can not see anything even with low-level debugging enabled :( I can not debug it further today, will look at this tomorrow. > In any case I have attached the 3 patches I have for this, including Tero's > ported to linux-next. > > Patch 3 might need to be done per board probably, but this should be good for > testing. > > > > _______________________________________________ > Kernel mailing list > Kernel@pyra-handheld.com > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel > -- Péter ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Kernel] [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 12:46 ` Peter Ujfalusi @ 2016-05-09 13:52 ` Peter Ujfalusi 2016-05-09 14:09 ` Tero Kristo 0 siblings, 1 reply; 30+ messages in thread From: Peter Ujfalusi @ 2016-05-09 13:52 UTC (permalink / raw) To: Tero Kristo, H. Nikolaus Schaller Cc: Mark Rutland, devicetree, Discussions about the Letux Kernel, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren, kernel, LKML, Rob Herring, Laxman Dewangan, Benoît Cousson, Kumar Gala, Marek Belisko, linux-omap On 05/09/16 15:46, Peter Ujfalusi wrote: > On 05/09/16 15:32, Peter Ujfalusi wrote: >> On 05/09/16 15:10, Peter Ujfalusi wrote: >> >>>>> finally I found some time to apply your patches. Sorry for the long time. >>>>> >>>>> Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. >>>>> I get no sound on the twl6040 - just white noise (which can be controlled in >>>>> level through >>>>> amixer so it is created on the digital input side of the twl6040). >>>>> >>>>> So I think your patch is missing a detail compared to my simple solution. >>>> >>>> Did you implement anything on the audio driver side? The audio driver must >>>> enable the clock implemented by this patch. >>> >>> I did, can test it in 10 minutes or so... >> >> might work, but linux-next is not booting on omap5-uevm :o I don't know why... > > Applying Tero's alone makes the board not to boot, so something there... I can > not see anything even with low-level debugging enabled :( I can not debug it > further today, will look at this tomorrow. The crash is in arch/arm/mach-omap2/control.c:omap_control_init() the syscon_node_to_regmap() returns with error for the new omap5_scm_wkup_pad_conf node. The other syscon was OK, but becasue of the return PTR_ERR(syscon) the board will not boot... Tero: any idea? >> In any case I have attached the 3 patches I have for this, including Tero's >> ported to linux-next. >> >> Patch 3 might need to be done per board probably, but this should be good for >> testing. >> >> >> >> _______________________________________________ >> Kernel mailing list >> Kernel@pyra-handheld.com >> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel >> > > -- Péter ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Kernel] [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 13:52 ` Peter Ujfalusi @ 2016-05-09 14:09 ` Tero Kristo 2016-05-09 15:28 ` Peter Ujfalusi 0 siblings, 1 reply; 30+ messages in thread From: Tero Kristo @ 2016-05-09 14:09 UTC (permalink / raw) To: Peter Ujfalusi, H. Nikolaus Schaller Cc: Mark Rutland, devicetree, Discussions about the Letux Kernel, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren, kernel, LKML, Rob Herring, Laxman Dewangan, Benoît Cousson, Kumar Gala, Marek Belisko, linux-omap On 09/05/16 16:52, Peter Ujfalusi wrote: > On 05/09/16 15:46, Peter Ujfalusi wrote: >> On 05/09/16 15:32, Peter Ujfalusi wrote: >>> On 05/09/16 15:10, Peter Ujfalusi wrote: >>> >>>>>> finally I found some time to apply your patches. Sorry for the long time. >>>>>> >>>>>> Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. >>>>>> I get no sound on the twl6040 - just white noise (which can be controlled in >>>>>> level through >>>>>> amixer so it is created on the digital input side of the twl6040). >>>>>> >>>>>> So I think your patch is missing a detail compared to my simple solution. >>>>> >>>>> Did you implement anything on the audio driver side? The audio driver must >>>>> enable the clock implemented by this patch. >>>> >>>> I did, can test it in 10 minutes or so... >>> >>> might work, but linux-next is not booting on omap5-uevm :o I don't know why... >> >> Applying Tero's alone makes the board not to boot, so something there... I can >> not see anything even with low-level debugging enabled :( I can not debug it >> further today, will look at this tomorrow. > > The crash is in arch/arm/mach-omap2/control.c:omap_control_init() > > the syscon_node_to_regmap() returns with error for the new > omap5_scm_wkup_pad_conf node. The other syscon was OK, but becasue of the > return PTR_ERR(syscon) the board will not boot... > > Tero: any idea? I can check this tomorrow at my end. -Tero > >>> In any case I have attached the 3 patches I have for this, including Tero's >>> ported to linux-next. >>> >>> Patch 3 might need to be done per board probably, but this should be good for >>> testing. >>> >>> >>> >>> _______________________________________________ >>> Kernel mailing list >>> Kernel@pyra-handheld.com >>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel >>> >> >> > > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Kernel] [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 14:09 ` Tero Kristo @ 2016-05-09 15:28 ` Peter Ujfalusi 0 siblings, 0 replies; 30+ messages in thread From: Peter Ujfalusi @ 2016-05-09 15:28 UTC (permalink / raw) To: Tero Kristo, H. Nikolaus Schaller Cc: Mark Rutland, devicetree, Discussions about the Letux Kernel, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren, kernel, LKML, Rob Herring, Laxman Dewangan, Benoît Cousson, Kumar Gala, Marek Belisko, linux-omap On 05/09/2016 05:09 PM, Tero Kristo wrote: >>> Applying Tero's alone makes the board not to boot, so something there... I can >>> not see anything even with low-level debugging enabled :( I can not debug it >>> further today, will look at this tomorrow. >> >> The crash is in arch/arm/mach-omap2/control.c:omap_control_init() >> >> the syscon_node_to_regmap() returns with error for the new >> omap5_scm_wkup_pad_conf node. The other syscon was OK, but becasue of the >> return PTR_ERR(syscon) the board will not boot... >> >> Tero: any idea? > > I can check this tomorrow at my end. Aargh, I think I know why, I have placed the omap5_scm_wkup_pad_conf node to a wrong place. The inline patch did not applied so I did it by hand... I can boot test it tomorrow. > > -Tero > >> >>>> In any case I have attached the 3 patches I have for this, including Tero's >>>> ported to linux-next. >>>> >>>> Patch 3 might need to be done per board probably, but this should be good for >>>> testing. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Kernel mailing list >>>> Kernel@pyra-handheld.com >>>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel >>>> >>> >>> >> >> > -- Péter ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Kernel] [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 12:32 ` [Kernel] " Peter Ujfalusi 2016-05-09 12:46 ` Peter Ujfalusi @ 2016-05-09 19:44 ` Peter Ujfalusi 1 sibling, 0 replies; 30+ messages in thread From: Peter Ujfalusi @ 2016-05-09 19:44 UTC (permalink / raw) To: Tero Kristo, H. Nikolaus Schaller Cc: Mark Rutland, devicetree, linux-omap, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren, Kumar Gala, LKML, Rob Herring, Laxman Dewangan, Benoît Cousson, kernel, Marek Belisko, Discussions about the Letux Kernel On 05/09/2016 03:32 PM, Peter Ujfalusi wrote: > On 05/09/16 15:10, Peter Ujfalusi wrote: > >>>> finally I found some time to apply your patches. Sorry for the long time. >>>> >>>> Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. >>>> I get no sound on the twl6040 - just white noise (which can be controlled in >>>> level through >>>> amixer so it is created on the digital input side of the twl6040). >>>> >>>> So I think your patch is missing a detail compared to my simple solution. >>> >>> Did you implement anything on the audio driver side? The audio driver must >>> enable the clock implemented by this patch. >> >> I did, can test it in 10 minutes or so... > > might work, but linux-next is not booting on omap5-uevm :o I don't know why... > > In any case I have attached the 3 patches I have for this, including Tero's > ported to linux-next. > > Patch 3 might need to be done per board probably, but this should be good for > testing. Please ignore these patches, I got HPPLL mode working, I need to clean the patches up first and I will send it for testing tomorrow. -- Péter ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer 2016-05-09 11:52 ` Tero Kristo 2016-05-09 12:10 ` Peter Ujfalusi @ 2016-05-10 5:45 ` H. Nikolaus Schaller 1 sibling, 0 replies; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-05-10 5:45 UTC (permalink / raw) To: Tero Kristo Cc: Peter Ujfalusi, Tony Lindgren, Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, kernel, Discussions about the Letux Kernel Hi, > Am 09.05.2016 um 13:52 schrieb Tero Kristo <t-kristo@ti.com>: > > On 09/05/16 14:18, H. Nikolaus Schaller wrote: >> Hi, >> >>> Am 28.04.2016 um 15:23 schrieb Tero Kristo <t-kristo@ti.com>: >>> >>> On 28/04/16 12:12, H. Nikolaus Schaller wrote: >>>> Hi Tero, >>>> >>>>> Am 28.04.2016 um 10:03 schrieb Tero Kristo <t-kristo@ti.com>: >>>>> >>>>> On 27/04/16 17:35, H. Nikolaus Schaller wrote: >>>>>> HI, >>>>>> >>>>>>> Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >>>>>>> >>>>>>> On 04/27/2016 05:10 PM, Tero Kristo wrote: >>>>>>>> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>>>>>>>> >>>>>>>>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@ti.com>: >>>>>>>>>> >>>>>>>>>> On 27/04/16 09:04, H. Nikolaus Schaller wrote: >>>>>>>>>>> >>>>>>>>>>>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@atomide.com>: >>>>>>>>>>>> >>>>>>>>>>>> Tero, >>>>>>>>>>>> >>>>>>>>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [160418 11:23]: >>>>>>>>>>>>> OMAP5 has a register to control if the ckobuffer is enabled >>>>>>>>>>>>> and defines the polarity. ckobuffer is required to drive a twl6040 >>>>>>>>>>>>> with the system clock. Hence, add the pinctrl,single to the >>>>>>>>>>>>> OMAP5 SoC description so that omap5-board-common can >>>>>>>>>>>>> set up the ckobuffer as required. >>>>>>>>>>>> >>>>>>>>>>>> Is this really a mux or should it be a mux clock? >>>>>>>>>>> >>>>>>>>>>> It is a pinmux setting for the clock out buffer to choose what signal >>>>>>>>>>> (and polarity) is presented on the fref_xtal_clk pad. >>>>>>>>>>> >>>>>>>>>>> The register is part of the CTRL_MODULE_WKUP. >>>>>>>>>>> The clock signal is the xtal master clock of the whole SoC. >>>>>>>>>>> >>>>>>>>>>> Although there is a bit to choose an alternate clock, there is no >>>>>>>>>>> alternate in the OMAP5 silicon. >>>>>>>>>>> >>>>>>>>>>> Therefore I would say it is about padconf and not clock or clock mux >>>>>>>>>>> related. >>>>>>>>>>> >>>>>>>>>>> It just happens to be a clock signal which can be routed to this >>>>>>>>>>> pad. >>>>>>>>>> >>>>>>>>>> The two could very well be implemented as clock nodes, a mux and a gate. >>>>>>>>>> This would describe the hardware functionality better imo, if the >>>>>>>>>> assumptions made here are correct. Implementing the control as pinctrl >>>>>>>>>> hacks looks rather weird to me. >>>>>>>>> >>>>>>>>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% >>>>>>>>> proper use of pinctrl. >>>>>>>> >>>>>>>> It is just the level of abstraction we are talking about here. If it is a >>>>>>>> clock we are controlling, we should rather control it as a clock (higher level >>>>>>>> abstraction), not a pin. >>>>>>> >>>>>>> I second this. I think it is better to have a simple gate clock and handle >>>>>>> only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does >>>>>>> not have real use. >>>>>>> >>>>>>> Then we can add clk API support for this. On most OMAP4 devices the clock is >>>>>>> always on, >>>>>> >>>>>> this is why I am raising the question if we really want to control it on the omap5 or just >>>>>> turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on >>>>>> as a pinctrl is IMHO sufficient for all practical purposes. >>>>>> >>>>>>> so the board DTS file need to provide a dummy clock, or we can make >>>>>>> the high precision clock also as optional (on panda both OMAP4 and twl6040 >>>>>>> uses the same reference clock). >>>>>> >>>>>> Hm. It looks as if implementing this (and clock gating) is beyond my experiences. >>>>>> But I am happy to test a proposal on our omap5 board. >>>>>> >>>>>> BR and thanks, >>>>>> Nikolaus >>>>> >>>>> See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed. >>>> >>>> Looks interesting, although quite complex to enable a single SoC pad at boot time... >>> >>> Yea it gives plenty of other things for you also. syscon, integration with clock framework, etc. >>> >>>> >>>> Will asap study how it works and test. And of course report results. >>> >>> Thanks, Tero. >>> >>>> >>>> Thanks and BR, >>>> Nikolaus >>>> >>>>> >>>>> From: Tero Kristo <t-kristo@ti.com> >>>>> Date: Thu, 28 Apr 2016 11:00:57 +0300 >>>>> Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck >>>>> >>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com> >>>>> --- >>>>> arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ >>>>> arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ >>>>> arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- >>>>> include/linux/clk/ti.h | 1 + >>>>> 4 files changed, 49 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >>>>> index 38805eb..bdc6528 100644 >>>>> --- a/arch/arm/boot/dts/omap5.dtsi >>>>> +++ b/arch/arm/boot/dts/omap5.dtsi >>>>> @@ -277,6 +277,28 @@ >>>>> pinctrl-single,register-width = <16>; >>>>> pinctrl-single,function-mask = <0x7fff>; >>>>> }; >>>>> + >>>>> + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { >>>>> + compatible = "ti,omap5-scm-wkup-pad-conf", >>>>> + "simple-bus"; >>>>> + reg = <0xcda0 0x60>; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <1>; >>>>> + ranges = <0 0xcda0 0x60>; >>>>> + >>>>> + scm_wkup_pad_conf: scm_conf@0 { >>>>> + compatible = "syscon", "simple-bus"; >>>>> + reg = <0x0 0x60>; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <1>; >>>>> + ranges = <0 0x0 0x60>; >>>>> + >>>>> + scm_wkup_pad_conf_clocks: clocks@0 { >>>>> + #address-cells = <1>; >>>>> + #size-cells = <0>; >>>>> + }; >>>>> + }; >>>>> + }; >>>>> }; >>>>> >>>>> ocmcram: ocmcram@40300000 { >>>>> diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>>> index 83b425f..f970dac 100644 >>>>> --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>>> +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi >>>>> @@ -1388,3 +1388,13 @@ >>>>> reg = <0x021c>; >>>>> }; >>>>> }; >>>>> + >>>>> +&scm_wkup_pad_conf_clocks { >>>>> + fref_xtal_ck: fref_xtal_ck { >>>>> + #clocks-cells = <0>; >>>>> + compatible = "ti,gate-clock"; >>>>> + clocks = <&sys_clkin>; >>>>> + ti,bit-shift = <28>; >>>>> + reg = <0x14>; >>>>> + }; >>>>> +}; >>>>> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c >>>>> index 1662071..5956641 100644 >>>>> --- a/arch/arm/mach-omap2/control.c >>>>> +++ b/arch/arm/mach-omap2/control.c >>>>> @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void) >>>>> >>>>> struct control_init_data { >>>>> int index; >>>>> + void __iomem *mem; >>>>> s16 offset; >>>>> }; >>>>> >>>>> @@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = { >>>>> .offset = -OMAP2_CONTROL_GENERAL, >>>>> }; >>>>> >>>>> +static const struct control_init_data ctrl_aux_data = { >>>>> + .index = TI_CLKM_CTRL_AUX, >>>>> +}; >>>>> + >>>>> static const struct of_device_id omap_scrm_dt_match_table[] = { >>>>> { .compatible = "ti,am3-scm", .data = &ctrl_data }, >>>>> { .compatible = "ti,am4-scm", .data = &ctrl_data }, >>>>> @@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = { >>>>> { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, >>>>> { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, >>>>> { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, >>>>> + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, >>>>> { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, >>>>> { } >>>>> }; >>>>> @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) >>>>> struct device_node *np; >>>>> const struct of_device_id *match; >>>>> struct control_init_data *data; >>>>> + void __iomem *mem; >>>>> >>>>> for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { >>>>> data = (struct control_init_data *)match->data; >>>>> >>>>> - omap2_ctrl_base = of_iomap(np, 0); >>>>> - if (!omap2_ctrl_base) >>>>> + mem = of_iomap(np, 0); >>>>> + if (!mem) >>>>> return -ENOMEM; >>>>> >>>>> - omap2_ctrl_offset = data->offset; >>>>> + if (data->index == TI_CLKM_CTRL) { >>>>> + omap2_ctrl_base = mem; >>>>> + omap2_ctrl_offset = data->offset; >>>>> + } >>>>> + >>>>> + data->mem = mem; >>>>> } >>>>> >>>>> return 0; >>>>> @@ -713,7 +725,7 @@ int __init omap_control_init(void) >>>>> } else { >>>>> /* No scm_conf found, direct access */ >>>>> ret = omap2_clk_provider_init(np, data->index, NULL, >>>>> - omap2_ctrl_base); >>>>> + data->mem); >>>>> if (ret) >>>>> return ret; >>>>> } >>>>> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h >>>>> index dc5164a..be25aa8 100644 >>>>> --- a/include/linux/clk/ti.h >>>>> +++ b/include/linux/clk/ti.h >>>>> @@ -195,6 +195,7 @@ enum { >>>>> TI_CLKM_PRM, >>>>> TI_CLKM_SCRM, >>>>> TI_CLKM_CTRL, >>>>> + TI_CLKM_CTRL_AUX, >>>>> TI_CLKM_PLLSS, >>>>> CLK_MAX_MEMMAPS >>>>> }; >>>> >>> >> >> finally I found some time to apply your patches. Sorry for the long time. >> >> Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. >> I get no sound on the twl6040 - just white noise (which can be controlled in level through >> amixer so it is created on the digital input side of the twl6040). >> >> So I think your patch is missing a detail compared to my simple solution. > > Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch. No. My patch just did configure the omap5 side because that was sufficient. Peter seems to work on a solution, so I will wait for that. BR, Nikolaus ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v2 5/5] ARM: dts: omap5-board-common: set up ckobuffer for twl6040 2016-04-18 18:20 [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller ` (3 preceding siblings ...) 2016-04-18 18:21 ` [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer H. Nikolaus Schaller @ 2016-04-18 18:21 ` H. Nikolaus Schaller 2016-04-26 15:00 ` [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller 5 siblings, 0 replies; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-18 18:21 UTC (permalink / raw) To: Benoît Cousson, Tony Lindgren, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King Cc: ldewangan, linux-omap, devicetree, linux-kernel, marek, kernel, letux-kernel, H. Nikolaus Schaller Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> --- arch/arm/boot/dts/omap5-board-common.dtsi | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index c0da5ff..e89bef3 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -130,6 +130,20 @@ }; }; +&omap5_control_ckobuffer { + ckobuffer: pinmux_ckobuffer { + pinctrl-single,pins = < + /* CONTROL.CONTROL_CKOBUFFER[28] CKOBUFFER_CLK_EN := 1 */ + 0x0 0x10000000 + >; + }; +}; + +&sound { + pinctrl-names = "default"; + pinctrl-0 = <&ckobuffer>; +}; + &gpio8 { /* TI trees use GPIO instead of msecure, see also muxing */ p234 { -- 2.7.3 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards 2016-04-18 18:20 [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller ` (4 preceding siblings ...) 2016-04-18 18:21 ` [PATCH v2 5/5] ARM: dts: omap5-board-common: set up ckobuffer for twl6040 H. Nikolaus Schaller @ 2016-04-26 15:00 ` H. Nikolaus Schaller 2016-04-26 17:28 ` Tony Lindgren 5 siblings, 1 reply; 30+ messages in thread From: H. Nikolaus Schaller @ 2016-04-26 15:00 UTC (permalink / raw) To: Benoît Cousson, Tony Lindgren, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King Cc: Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, Discussions about the Letux Kernel ping. > Am 18.04.2016 um 20:20 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > > This patch series adds DT nodes for: > * twl6030 gpadc for omap4 based boards (Pandaboard ES) > * twl6037 gpadc for omap5 based board (OMAP5EVM) > * omap5-board-common: ckobuffer (needed for high quality twl6040 audio) > * fix range problem with omap5 pinmux > > > H. Nikolaus Schaller (5): > ARM: dts: twl6030: describe gpadc > ARM: dts: omap5-board-common: describe gpadc for Palmas > ARM: dts: omap5: fix range of permitted wakeup pinmux registers > ARM: dts: omap5: describe control for ckobuffer > ARM: dts: omap5-board-common: set up ckobuffer for twl6040 > > arch/arm/boot/dts/omap5-board-common.dtsi | 24 ++++++++++++++++++++++++ > arch/arm/boot/dts/omap5.dtsi | 12 +++++++++++- > arch/arm/boot/dts/twl6030.dtsi | 6 ++++++ > 3 files changed, 41 insertions(+), 1 deletion(-) > > -- > 2.7.3 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards 2016-04-26 15:00 ` [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller @ 2016-04-26 17:28 ` Tony Lindgren 0 siblings, 0 replies; 30+ messages in thread From: Tony Lindgren @ 2016-04-26 17:28 UTC (permalink / raw) To: H. Nikolaus Schaller Cc: Benoît Cousson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Laxman Dewangan, linux-omap, devicetree, LKML, Marek Belisko, Discussions about the Letux Kernel * H. Nikolaus Schaller <hns@goldelico.com> [160426 08:02]: > ping. > > > Am 18.04.2016 um 20:20 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > > > > This patch series adds DT nodes for: > > * twl6030 gpadc for omap4 based boards (Pandaboard ES) > > * twl6037 gpadc for omap5 based board (OMAP5EVM) > > * omap5-board-common: ckobuffer (needed for high quality twl6040 audio) > > * fix range problem with omap5 pinmux > > > > > > H. Nikolaus Schaller (5): > > ARM: dts: twl6030: describe gpadc > > ARM: dts: omap5-board-common: describe gpadc for Palmas > > ARM: dts: omap5: fix range of permitted wakeup pinmux registers > > ARM: dts: omap5: describe control for ckobuffer > > ARM: dts: omap5-board-common: set up ckobuffer for twl6040 > > > > arch/arm/boot/dts/omap5-board-common.dtsi | 24 ++++++++++++++++++++++++ > > arch/arm/boot/dts/omap5.dtsi | 12 +++++++++++- > > arch/arm/boot/dts/twl6030.dtsi | 6 ++++++ > > 3 files changed, 41 insertions(+), 1 deletion(-) Thanks for the reminder, I had somehow untagged this thread. Picked one into fixes, two into next, and two Tero should review. Tony ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2016-05-10 5:46 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-18 18:20 [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller 2016-04-18 18:20 ` [PATCH v2 1/5] ARM: dts: twl6030: describe gpadc H. Nikolaus Schaller 2016-04-26 17:26 ` Tony Lindgren 2016-04-18 18:20 ` [PATCH v2 2/5] ARM: dts: omap5-board-common: describe gpadc for Palmas H. Nikolaus Schaller 2016-04-18 18:20 ` [PATCH v2 3/5] ARM: dts: omap5: fix range of permitted wakeup pinmux registers H. Nikolaus Schaller 2016-04-26 17:23 ` Tony Lindgren 2016-04-18 18:21 ` [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer H. Nikolaus Schaller 2016-04-26 17:27 ` Tony Lindgren 2016-04-27 6:04 ` H. Nikolaus Schaller 2016-04-27 12:31 ` Tero Kristo 2016-04-27 13:10 ` H. Nikolaus Schaller 2016-04-27 14:10 ` Tero Kristo 2016-04-27 14:23 ` Peter Ujfalusi 2016-04-27 14:35 ` H. Nikolaus Schaller 2016-04-28 8:03 ` Tero Kristo 2016-04-28 9:12 ` H. Nikolaus Schaller 2016-04-28 13:23 ` Tero Kristo 2016-05-09 11:18 ` H. Nikolaus Schaller 2016-05-09 11:52 ` Tero Kristo 2016-05-09 12:10 ` Peter Ujfalusi 2016-05-09 12:32 ` [Kernel] " Peter Ujfalusi 2016-05-09 12:46 ` Peter Ujfalusi 2016-05-09 13:52 ` Peter Ujfalusi 2016-05-09 14:09 ` Tero Kristo 2016-05-09 15:28 ` Peter Ujfalusi 2016-05-09 19:44 ` Peter Ujfalusi 2016-05-10 5:45 ` H. Nikolaus Schaller 2016-04-18 18:21 ` [PATCH v2 5/5] ARM: dts: omap5-board-common: set up ckobuffer for twl6040 H. Nikolaus Schaller 2016-04-26 15:00 ` [PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards H. Nikolaus Schaller 2016-04-26 17:28 ` Tony Lindgren
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).