| Message ID | 1351859566-24818-14-git-send-email-vaibhav.bedia@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11/02/2012 01:32 PM, Vaibhav Bedia wrote: > Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Even simple patches need a simple changelog. Kevin > arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > index bb31bff..e2cbf24 100644 > --- a/arch/arm/boot/dts/am33xx.dtsi > +++ b/arch/arm/boot/dts/am33xx.dtsi > @@ -210,5 +210,16 @@ > interrupt-parent = <&intc>; > interrupts = <91>; > }; > + > + ocmcram: ocmcram@40300000 { > + compatible = "ti,ocmcram"; > + ti,hwmods = "ocmcram"; > + ti,no_idle_on_suspend; > + }; > + > + wkup_m3: wkup_m3@44d00000 { > + compatible = "ti,wkup_m3"; > + ti,hwmods = "wkup_m3"; > + }; > }; > }; > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Nov 03, 2012 at 17:46:06, Kevin Hilman wrote: > On 11/02/2012 01:32 PM, Vaibhav Bedia wrote: > > Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> > > Even simple patches need a simple changelog. Again, sorry about this. Will take care in the future. Regards, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote: > Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> > --- > arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > index bb31bff..e2cbf24 100644 > --- a/arch/arm/boot/dts/am33xx.dtsi > +++ b/arch/arm/boot/dts/am33xx.dtsi > @@ -210,5 +210,16 @@ > interrupt-parent = <&intc>; > interrupts = <91>; > }; > + > + ocmcram: ocmcram@40300000 { > + compatible = "ti,ocmcram"; > + ti,hwmods = "ocmcram"; > + ti,no_idle_on_suspend; > + }; Whats the intention behind adding OCMRAM ? Sorry if I missed any comments from the cover letter ? Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote: > On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote: > > Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> > > --- > > arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++ > > 1 files changed, 11 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > > index bb31bff..e2cbf24 100644 > > --- a/arch/arm/boot/dts/am33xx.dtsi > > +++ b/arch/arm/boot/dts/am33xx.dtsi > > @@ -210,5 +210,16 @@ > > interrupt-parent = <&intc>; > > interrupts = <91>; > > }; > > + > > + ocmcram: ocmcram@40300000 { > > + compatible = "ti,ocmcram"; > > + ti,hwmods = "ocmcram"; > > + ti,no_idle_on_suspend; > > + }; > Whats the intention behind adding OCMRAM ? > Sorry if I missed any comments from the cover letter ? > We need a mechanism to ensure that the clock to OCMC is kept running during boot and that it doesn't get disabled as part of the suspend sequence. Since the hwmod data for OCMC is already present and we have the no_idle_on_suspend flag for hwmod entries we get the desired behavior. This could also have been done via the clock tree but looks like we want to avoid adding leaf nodes in the clock data, hence the hwmod + DT approach. Regards, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote: > On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote: >> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote: >>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> >>> --- >>> arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++ >>> 1 files changed, 11 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>> index bb31bff..e2cbf24 100644 >>> --- a/arch/arm/boot/dts/am33xx.dtsi >>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>> @@ -210,5 +210,16 @@ >>> interrupt-parent = <&intc>; >>> interrupts = <91>; >>> }; >>> + >>> + ocmcram: ocmcram@40300000 { >>> + compatible = "ti,ocmcram"; >>> + ti,hwmods = "ocmcram"; >>> + ti,no_idle_on_suspend; >>> + }; >> Whats the intention behind adding OCMRAM ? >> Sorry if I missed any comments from the cover letter ? >> > > We need a mechanism to ensure that the clock to OCMC is kept running > during boot and that it doesn't get disabled as part of the suspend > sequence. Since the hwmod data for OCMC is already present and we have > the no_idle_on_suspend flag for hwmod entries we get the desired behavior. > On OMAP the OCMC RAM is always clocked and doesn't need any special clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only. Isn't it same on AMXX ? > This could also have been done via the clock tree but looks like we > want to avoid adding leaf nodes in the clock data, hence the hwmod + > DT approach. > Sure. I was just trying to see why AMXX is different with OMAP here. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote: > On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote: >> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote: >>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> >>> --- >>> arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++ >>> 1 files changed, 11 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>> index bb31bff..e2cbf24 100644 >>> --- a/arch/arm/boot/dts/am33xx.dtsi >>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>> @@ -210,5 +210,16 @@ >>> interrupt-parent = <&intc>; >>> interrupts = <91>; >>> }; >>> + >>> + ocmcram: ocmcram@40300000 { >>> + compatible = "ti,ocmcram"; >>> + ti,hwmods = "ocmcram"; >>> + ti,no_idle_on_suspend; >>> + }; >> Whats the intention behind adding OCMRAM ? >> Sorry if I missed any comments from the cover letter ? >> > > We need a mechanism to ensure that the clock to OCMC is kept running > during boot and that it doesn't get disabled as part of the suspend > sequence. Since the hwmod data for OCMC is already present and we have > the no_idle_on_suspend flag for hwmod entries we get the desired behavior. > > This could also have been done via the clock tree but looks like we > want to avoid adding leaf nodes in the clock data, hence the hwmod + > DT approach. > OK. I was just comparing the OCMC RAM on OMAP which is always clocked and hence didn't need any of the above. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote: [...] > > > On OMAP the OCMC RAM is always clocked and doesn't need any special > clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only. > Isn't it same on AMXX ? > On AM33xx, OCMC RAM is in PER domain and the corresponding CLKCLTR module mode fields are r/w. OCMC RAM needs to be disabled as part of the DeepSleep0 entry to let PER domain transition. Regards, Vaibhav -- 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
"Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes: > On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote: > [...] >> > >> On OMAP the OCMC RAM is always clocked and doesn't need any special >> clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only. >> Isn't it same on AMXX ? >> > > On AM33xx, OCMC RAM is in PER domain and the corresponding CLKCLTR module > mode fields are r/w. OCMC RAM needs to be disabled as part of the DeepSleep0 > entry to let PER domain transition. After DeepSleep0, the ROM code is being given an address in OCMC RAM to jump to. If OCMC RAM is disabled as part of suspend, this means that OCMC RAM contents are maintained even though PER domain transitions? If so, that needs to be more clearly documented. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 06 November 2012 12:59 AM, Kevin Hilman wrote: > "Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes: > >> On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote: >> [...] >>>> >>> On OMAP the OCMC RAM is always clocked and doesn't need any special >>> clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only. >>> Isn't it same on AMXX ? >>> >> >> On AM33xx, OCMC RAM is in PER domain and the corresponding CLKCLTR module >> mode fields are r/w. OCMC RAM needs to be disabled as part of the DeepSleep0 >> entry to let PER domain transition. > > After DeepSleep0, the ROM code is being given an address in OCMC RAM to > jump to. If OCMC RAM is disabled as part of suspend, this means that > OCMC RAM contents are maintained even though PER domain transitions? > > If so, that needs to be more clearly documented. > Thats very good point. How does OCMC RAM retains the contents without clock ? Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 06 November 2012 02:49 AM, Santosh Shilimkar wrote: > On Tuesday 06 November 2012 12:59 AM, Kevin Hilman wrote: >> "Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes: >> >>> On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote: >>> [...] >>>>> >>>> On OMAP the OCMC RAM is always clocked and doesn't need any special >>>> clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only. >>>> Isn't it same on AMXX ? >>>> >>> >>> On AM33xx, OCMC RAM is in PER domain and the corresponding CLKCLTR >>> module >>> mode fields are r/w. OCMC RAM needs to be disabled as part of the >>> DeepSleep0 >>> entry to let PER domain transition. >> >> After DeepSleep0, the ROM code is being given an address in OCMC RAM to >> jump to. If OCMC RAM is disabled as part of suspend, this means that >> OCMC RAM contents are maintained even though PER domain transitions? >> >> If so, that needs to be more clearly documented. >> > Thats very good point. How does OCMC RAM retains the contents without > clock ? > Ignore the question. I figured out from other patch changelog the OCMC RAM supports retention. Please have that clearly captured in change log. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 06, 2012 at 03:15:10, Shilimkar, Santosh wrote: > On Tuesday 06 November 2012 02:49 AM, Santosh Shilimkar wrote: > > On Tuesday 06 November 2012 12:59 AM, Kevin Hilman wrote: > >> "Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes: > >> > >>> On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote: > >>> [...] > >>>>> > >>>> On OMAP the OCMC RAM is always clocked and doesn't need any special > >>>> clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only. > >>>> Isn't it same on AMXX ? > >>>> > >>> > >>> On AM33xx, OCMC RAM is in PER domain and the corresponding CLKCLTR > >>> module > >>> mode fields are r/w. OCMC RAM needs to be disabled as part of the > >>> DeepSleep0 > >>> entry to let PER domain transition. > >> > >> After DeepSleep0, the ROM code is being given an address in OCMC RAM to > >> jump to. If OCMC RAM is disabled as part of suspend, this means that > >> OCMC RAM contents are maintained even though PER domain transitions? > >> > >> If so, that needs to be more clearly documented. > >> > > Thats very good point. How does OCMC RAM retains the contents without > > clock ? > > > Ignore the question. I figured out from other patch changelog the OCMC > RAM supports retention. Please have that clearly captured in > change log. > Yes, OCMC RAM support retention. Will document that here also. Regards, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index bb31bff..e2cbf24 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -210,5 +210,16 @@ interrupt-parent = <&intc>; interrupts = <91>; }; + + ocmcram: ocmcram@40300000 { + compatible = "ti,ocmcram"; + ti,hwmods = "ocmcram"; + ti,no_idle_on_suspend; + }; + + wkup_m3: wkup_m3@44d00000 { + compatible = "ti,wkup_m3"; + ti,hwmods = "wkup_m3"; + }; }; };
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> --- arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)