* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-07 11:37 UTC (permalink / raw)
To: Valkeinen, Tomi
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <1307429547.1858.10.camel@deskari>
On 6/7/2011 8:52 AM, Valkeinen, Tomi wrote:
> On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote:
>
>> Before doing that, could you maybe just try something to make OMAP4
>> looks a little bit more like OMAP3?
>>
>> dss_fck -> ick
>> dss_dss_fck -> main_clk
>>
>> That should ensure that both modulemode and the PRCM fclk will be
>> managed by pm_runtime.
>
> I made the changes as you suggested, and while I haven't made the
> changes to omapdss yet to see if I can remove the dispc_runtime_get/put
> style function, I can boot up and start the dss.
>
> However, after booting up but before enabling the dss driver, I can see
> that the clock counts are:
>
> dss_tv_clk 0
> dss_sys_clk 0
> dss_fck 7
> dss_dss_clk 0
> dss_48mhz_clk 0
>
> So the modulemode is set for all dss hwmods? Isn't this exactly how it's
> _not_ meant to be, as modulemode should be set only after enabling the
> fck?
The issue is that there is only one modulemode for the whole DSS.
Potentially only the dss_hwmod should have it. But then you have to
ensure that this device is enabled before any other DSS devices.
If you cannot do that at your level, we will have to set a hwmod
dependency between DSS modules and the main DSS subsystem.
For the moment we do not have such HW dependencies.
Benoit
>
> Tomi
>
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index b374cd0..d7d86b6 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -1133,7 +1133,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dma_addrs[] = {
> static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
> .master =&omap44xx_l3_main_2_hwmod,
> .slave =&omap44xx_dss_hwmod,
> - .clk = "l3_div_ck",
> + .clk = "dss_fck",
> .addr = omap44xx_dss_dma_addrs,
> .addr_cnt = ARRAY_SIZE(omap44xx_dss_dma_addrs),
> .user = OCP_USER_SDMA,
> @@ -1170,7 +1170,7 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
> static struct omap_hwmod omap44xx_dss_hwmod = {
> .name = "dss_core",
> .class =&omap44xx_dss_hwmod_class,
> - .main_clk = "dss_fck",
> + .main_clk = "dss_dss_clk",
> .prcm = {
> .omap4 = {
> .clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
> @@ -1230,7 +1230,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dispc_dma_addrs[] = {
> static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dispc = {
> .master =&omap44xx_l3_main_2_hwmod,
> .slave =&omap44xx_dss_dispc_hwmod,
> - .clk = "l3_div_ck",
> + .clk = "dss_fck",
> .addr = omap44xx_dss_dispc_dma_addrs,
> .addr_cnt = ARRAY_SIZE(omap44xx_dss_dispc_dma_addrs),
> .user = OCP_USER_SDMA,
> @@ -1279,7 +1279,7 @@ static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dss_dispc_irqs),
> .sdma_reqs = omap44xx_dss_dispc_sdma_reqs,
> .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_dispc_sdma_reqs),
> - .main_clk = "dss_fck",
> + .main_clk = "dss_dss_clk",
> .prcm = {
> .omap4 = {
> .clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
> @@ -1335,7 +1335,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dsi1_dma_addrs[] = {
> static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dsi1 = {
> .master =&omap44xx_l3_main_2_hwmod,
> .slave =&omap44xx_dss_dsi1_hwmod,
> - .clk = "l3_div_ck",
> + .clk = "dss_fck",
> .addr = omap44xx_dss_dsi1_dma_addrs,
> .addr_cnt = ARRAY_SIZE(omap44xx_dss_dsi1_dma_addrs),
> .user = OCP_USER_SDMA,
> @@ -1377,7 +1377,7 @@ static struct omap_hwmod omap44xx_dss_dsi1_hwmod = {
> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dss_dsi1_irqs),
> .sdma_reqs = omap44xx_dss_dsi1_sdma_reqs,
> .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_dsi1_sdma_reqs),
> - .main_clk = "dss_fck",
> + .main_clk = "dss_dss_clk",
> .prcm = {
> .omap4 = {
> .clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
> @@ -1412,7 +1412,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dsi2_dma_addrs[] = {
> static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dsi2 = {
> .master =&omap44xx_l3_main_2_hwmod,
> .slave =&omap44xx_dss_dsi2_hwmod,
> - .clk = "l3_div_ck",
> + .clk = "dss_fck",
> .addr = omap44xx_dss_dsi2_dma_addrs,
> .addr_cnt = ARRAY_SIZE(omap44xx_dss_dsi2_dma_addrs),
> .user = OCP_USER_SDMA,
> @@ -1449,7 +1449,7 @@ static struct omap_hwmod omap44xx_dss_dsi2_hwmod = {
> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dss_dsi2_irqs),
> .sdma_reqs = omap44xx_dss_dsi2_sdma_reqs,
> .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_dsi2_sdma_reqs),
> - .main_clk = "dss_fck",
> + .main_clk = "dss_dss_clk",
> .prcm = {
> .omap4 = {
> .clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
> @@ -1502,7 +1502,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_hdmi_dma_addrs[] = {
> static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_hdmi = {
> .master =&omap44xx_l3_main_2_hwmod,
> .slave =&omap44xx_dss_hdmi_hwmod,
> - .clk = "l3_div_ck",
> + .clk = "dss_fck",
> .addr = omap44xx_dss_hdmi_dma_addrs,
> .addr_cnt = ARRAY_SIZE(omap44xx_dss_hdmi_dma_addrs),
> .user = OCP_USER_SDMA,
> @@ -1544,7 +1544,7 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dss_hdmi_irqs),
> .sdma_reqs = omap44xx_dss_hdmi_sdma_reqs,
> .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_hdmi_sdma_reqs),
> - .main_clk = "dss_fck",
> + .main_clk = "dss_dss_clk",
> .prcm = {
> .omap4 = {
> .clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
> @@ -1595,7 +1595,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_rfbi_dma_addrs[] = {
> static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_rfbi = {
> .master =&omap44xx_l3_main_2_hwmod,
> .slave =&omap44xx_dss_rfbi_hwmod,
> - .clk = "l3_div_ck",
> + .clk = "dss_fck",
> .addr = omap44xx_dss_rfbi_dma_addrs,
> .addr_cnt = ARRAY_SIZE(omap44xx_dss_rfbi_dma_addrs),
> .user = OCP_USER_SDMA,
> @@ -1634,7 +1634,7 @@ static struct omap_hwmod omap44xx_dss_rfbi_hwmod = {
> .class =&omap44xx_rfbi_hwmod_class,
> .sdma_reqs = omap44xx_dss_rfbi_sdma_reqs,
> .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_rfbi_sdma_reqs),
> - .main_clk = "dss_fck",
> + .main_clk = "dss_dss_clk",
> .prcm = {
> .omap4 = {
> .clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
> @@ -1670,7 +1670,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_venc_dma_addrs[] = {
> static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_venc = {
> .master =&omap44xx_l3_main_2_hwmod,
> .slave =&omap44xx_dss_venc_hwmod,
> - .clk = "l3_div_ck",
> + .clk = "dss_fck",
> .addr = omap44xx_dss_venc_dma_addrs,
> .addr_cnt = ARRAY_SIZE(omap44xx_dss_venc_dma_addrs),
> .user = OCP_USER_SDMA,
> @@ -1707,7 +1707,7 @@ static struct omap_hwmod_opt_clk venc_opt_clks[] = {
> static struct omap_hwmod omap44xx_dss_venc_hwmod = {
> .name = "dss_venc",
> .class =&omap44xx_venc_hwmod_class,
> - .main_clk = "dss_fck",
> + .main_clk = "dss_dss_clk",
> .prcm = {
> .omap4 = {
> .clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
>
>
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-07 9:08 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <1307429547.1858.10.camel@deskari>
On Tue, 2011-06-07 at 09:52 +0300, Tomi Valkeinen wrote:
> On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote:
>
> > Before doing that, could you maybe just try something to make OMAP4
> > looks a little bit more like OMAP3?
> >
> > dss_fck -> ick
> > dss_dss_fck -> main_clk
> >
> > That should ensure that both modulemode and the PRCM fclk will be
> > managed by pm_runtime.
>
> I made the changes as you suggested, and while I haven't made the
> changes to omapdss yet to see if I can remove the dispc_runtime_get/put
> style function, I can boot up and start the dss.
>
> However, after booting up but before enabling the dss driver, I can see
> that the clock counts are:
>
> dss_tv_clk 0
> dss_sys_clk 0
> dss_fck 7
> dss_dss_clk 0
> dss_48mhz_clk 0
>
> So the modulemode is set for all dss hwmods? Isn't this exactly how it's
> _not_ meant to be, as modulemode should be set only after enabling the
> fck?
This also seems to keep the DSS from going to RET or OFF, at least in
the TI internal PM testing tree.
So is the PM side buggy there, and it shouldn't care about the
modulemode being enabled if other clocks are off, or is it the hwmod
side that's buggy, and it should disable the modulemode also?
Tomi
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-07 7:27 UTC (permalink / raw)
To: Valkeinen, Tomi
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <1307431291.1858.15.camel@deskari>
On 6/7/2011 9:21 AM, Valkeinen, Tomi wrote:
> On Tue, 2011-06-07 at 09:12 +0200, Cousson, Benoit wrote:
>> On 6/7/2011 8:47 AM, Valkeinen, Tomi wrote:
>
>>> I'd rather hope the optional clock could be enabled whenever the driver
>>> needs it, between enabling and disabling the hwmod.
>>
>> Yeah, this is the case most of the time, except for you.
>
> Are you talking only about the DSS_FCLK opt-clock from PRCM, or all DSS
> opt clocks (sys clk, hdmi clk, tv clk, dac clock)?
>
> I hope the rest of the opt clocks can be enabled later. Although I guess
> all/many of them will be needed during reset, but that should be already
> handled by the hwmod fmwk.
Yes, sorry, for the confusion, but the point is that they all look the
same to me :-)
The PRCM does not make any difference for any of these opt_clock, they
are all under SW control.
Except that one of them must be enabled because internally it is used as
a functional clock.
Benoit
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-07 7:21 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <4DEDCF73.9030607@ti.com>
On Tue, 2011-06-07 at 09:12 +0200, Cousson, Benoit wrote:
> On 6/7/2011 8:47 AM, Valkeinen, Tomi wrote:
> > I'd rather hope the optional clock could be enabled whenever the driver
> > needs it, between enabling and disabling the hwmod.
>
> Yeah, this is the case most of the time, except for you.
Are you talking only about the DSS_FCLK opt-clock from PRCM, or all DSS
opt clocks (sys clk, hdmi clk, tv clk, dac clock)?
I hope the rest of the opt clocks can be enabled later. Although I guess
all/many of them will be needed during reset, but that should be already
handled by the hwmod fmwk.
Tomi
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-07 7:12 UTC (permalink / raw)
To: Valkeinen, Tomi
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <1307429265.1858.6.camel@deskari>
On 6/7/2011 8:47 AM, Valkeinen, Tomi wrote:
> On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
>
>> That terminology in the PRCM just means that an opt clock will not be
>> handled automatically by the PRCM and will require SW control.
>> This is not the case for mandatory clock. Upon module enable the PRCM
>> will ensure that all mandatory clocks (functional and interface) are
>> enabled automagically. If the clock is marked as optional it means that
>> the SW will have to enable it explicitly before enabling the module.
>
> Is that correct? This would mean that whenever a hwmod has opt clock, it
> needs to implement similar hack functions that are present in this
> patch, to be able to enable the opt clock before enabling the hwmod, and
> to disable the opt clock after disabling the hwmod.
No, because most hwmods with opt_clock does have a real main_clk as
well. In the case of the GPIO, the driver need to enable the opt clock
only if the debounce feature is needed.
In general we always have one main functional clock to enable the module
first.
> I'd rather hope the optional clock could be enabled whenever the driver
> needs it, between enabling and disabling the hwmod.
Yeah, this is the case most of the time, except for you.
> If it's required that the opt clocks are enabled before enabling the
> hwmod, what is the point of having them as optional and driver
> controlled? The hwmod fmwk could as well handle the opt clocks in that
> case.
There is no point... It is just due to the particular clock setting
required by the DSS. That specific case was simply not taken into
account originally. You are just the first one to hit that issue :-(
Just because the DSS can choose its main functional clock, the HW team
decided to mark them all as opt clock, in order to let the SW decide
which one to use.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-07 6:52 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <4DECF215.5020505@ti.com>
On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote:
> Before doing that, could you maybe just try something to make OMAP4
> looks a little bit more like OMAP3?
>
> dss_fck -> ick
> dss_dss_fck -> main_clk
>
> That should ensure that both modulemode and the PRCM fclk will be
> managed by pm_runtime.
I made the changes as you suggested, and while I haven't made the
changes to omapdss yet to see if I can remove the dispc_runtime_get/put
style function, I can boot up and start the dss.
However, after booting up but before enabling the dss driver, I can see
that the clock counts are:
dss_tv_clk 0
dss_sys_clk 0
dss_fck 7
dss_dss_clk 0
dss_48mhz_clk 0
So the modulemode is set for all dss hwmods? Isn't this exactly how it's
_not_ meant to be, as modulemode should be set only after enabling the
fck?
Tomi
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index b374cd0..d7d86b6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1133,7 +1133,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1170,7 +1170,7 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
static struct omap_hwmod omap44xx_dss_hwmod = {
.name = "dss_core",
.class = &omap44xx_dss_hwmod_class,
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_clk",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
@@ -1230,7 +1230,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dispc_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dispc = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_dispc_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_dispc_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dispc_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1279,7 +1279,7 @@ static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dss_dispc_irqs),
.sdma_reqs = omap44xx_dss_dispc_sdma_reqs,
.sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_dispc_sdma_reqs),
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_clk",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
@@ -1335,7 +1335,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dsi1_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dsi1 = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_dsi1_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_dsi1_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dsi1_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1377,7 +1377,7 @@ static struct omap_hwmod omap44xx_dss_dsi1_hwmod = {
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dss_dsi1_irqs),
.sdma_reqs = omap44xx_dss_dsi1_sdma_reqs,
.sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_dsi1_sdma_reqs),
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_clk",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
@@ -1412,7 +1412,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dsi2_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dsi2 = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_dsi2_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_dsi2_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dsi2_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1449,7 +1449,7 @@ static struct omap_hwmod omap44xx_dss_dsi2_hwmod = {
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dss_dsi2_irqs),
.sdma_reqs = omap44xx_dss_dsi2_sdma_reqs,
.sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_dsi2_sdma_reqs),
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_clk",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
@@ -1502,7 +1502,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_hdmi_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_hdmi = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_hdmi_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_hdmi_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_hdmi_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1544,7 +1544,7 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dss_hdmi_irqs),
.sdma_reqs = omap44xx_dss_hdmi_sdma_reqs,
.sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_hdmi_sdma_reqs),
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_clk",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
@@ -1595,7 +1595,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_rfbi_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_rfbi = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_rfbi_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_rfbi_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_rfbi_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1634,7 +1634,7 @@ static struct omap_hwmod omap44xx_dss_rfbi_hwmod = {
.class = &omap44xx_rfbi_hwmod_class,
.sdma_reqs = omap44xx_dss_rfbi_sdma_reqs,
.sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dss_rfbi_sdma_reqs),
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_clk",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
@@ -1670,7 +1670,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_venc_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_venc = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_venc_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_venc_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_venc_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1707,7 +1707,7 @@ static struct omap_hwmod_opt_clk venc_opt_clks[] = {
static struct omap_hwmod omap44xx_dss_venc_hwmod = {
.name = "dss_venc",
.class = &omap44xx_venc_hwmod_class,
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_clk",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
^ permalink raw reply related
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-07 6:47 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <4DECCE90.6070201@ti.com>
On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
> That terminology in the PRCM just means that an opt clock will not be
> handled automatically by the PRCM and will require SW control.
> This is not the case for mandatory clock. Upon module enable the PRCM
> will ensure that all mandatory clocks (functional and interface) are
> enabled automagically. If the clock is marked as optional it means that
> the SW will have to enable it explicitly before enabling the module.
Is that correct? This would mean that whenever a hwmod has opt clock, it
needs to implement similar hack functions that are present in this
patch, to be able to enable the opt clock before enabling the hwmod, and
to disable the opt clock after disabling the hwmod.
I'd rather hope the optional clock could be enabled whenever the driver
needs it, between enabling and disabling the hwmod.
If it's required that the opt clocks are enabled before enabling the
hwmod, what is the point of having them as optional and driver
controlled? The hwmod fmwk could as well handle the opt clocks in that
case.
Tomi
^ permalink raw reply
* Re: [Patch 2/2 resend] Prevent vga16fb from accessing hw after it
From: Bruno Prémont @ 2011-06-06 20:08 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110524223221.741ffbc0@neptune.home>
On Mon, 06 June 2011 Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, May 24, 2011 at 10:32:21PM +0200, Bruno Pr??mont wrote:
> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> > index 5aac00e..bd9f93b 100644
> > --- a/drivers/video/fbmem.c
> > +++ b/drivers/video/fbmem.c
> > @@ -1661,6 +1661,11 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
> > device_destroy(fb_class, MKDEV(FB_MAJOR, i));
> > event.info = fb_info;
> > fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> > + if (fb_info->fbops->fb_unregistered) {
> > + mutex_lock(&fb_info->lock);
> > + fb_info->fbops->fb_unregistered(fb_info);
> > + mutex_unlock(&fb_info->lock);
> > + }
> >
> > /* this may free fb info */
> > put_fb_info(fb_info);
>
> I'm not sure I really see the point, given that you can already do all of
> the same work by tying in to the notifier chain. See for example the
> sh_mobile_hdmi driver and its unreg notifier.
You can but is it a good idea to hook the driver itself to notifier chain
and do the work to find out if the info it's being notified for is one it
cares about?
In addition, if driver gets informed via the notifier it's unknown if kernel
users or driver get notified first, thus fb driver cannot give all kernel
users opportunity to cleanup before cleaning-up itself.
At best notification order depends on loading order of modules for fb driver
and kernel fb user (like fbcon).
Bruno
^ permalink raw reply
* Re: [PATCH 21/29] s3fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-06 16:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1306364301-8195-22-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Tormod,
On Friday 03 June 2011 11:26:51 Tormod Volden wrote:
> On Thu, May 26, 2011 at 6:31 PM, Laurent Pinchart wrote:
> > On Thursday 26 May 2011 16:12:21 Tormod Volden wrote:
> >> On Thu, May 26, 2011 at 12:58 AM, Laurent Pinchart wrote:
> >> > We must not use any information in the passed var besides xoffset,
> >> > yoffset and vmode as otherwise applications might abuse it. Also use
> >> > the aligned fix.line_length and not the (possible) unaligned
> >> > xres_virtual.
> >> >
> >> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> > Cc: Antonino Daplas <adaplas@gmail.com>
> >> > ---
> >> > drivers/video/savage/savagefb_driver.c | 16 +++++++---------
> >> > 1 files changed, 7 insertions(+), 9 deletions(-)
> >>
> >> The patch title is misleading, this is not the s3fb driver but the
> >> savagefb driver.
> >
> > Yes, sorry about that. I've fixed the patch title, as well as the next
> > patch.
>
> Hi Laurent,
> I haven't seen any updated patch posted,
That's because I haven't posted the updated patches yet :-) I was waiting for
more review.
> but anyway, the patch looks otherwise correct to me, and I have tested it on
> my Savage TwisterK:
>
> Reviewed-by: Tormod Volden <debian.tormod@gmail.com>
Thank you.
It's been a week and a half since I posted the first version, I'll now send an
updated one with correct titles and Acked-by/Reviewed-by lines.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-06 15:28 UTC (permalink / raw)
To: Valkeinen, Tomi
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <1307368525.1910.50.camel@deskari>
On 6/6/2011 3:55 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-06-06 at 15:46 +0200, Cousson, Benoit wrote:
>> On 6/6/2011 3:21 PM, Valkeinen, Tomi wrote:
>>> On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
>>>> On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
>>>>> On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
>>>
>>>>> In this long term solution, if the dss_fclk is the main_clk, how does
>>>>> the framework handle the situation when we want to switch from the
>>>>> standard DSS fclk to the one from DSI PLL?
>>>>
>>>> That part cannot be done by the hwmod fmwk anyway. The goal of the fmwk
>>>> is to ensure that the module is accessible by the driver whatever the
>>>> PRCM clock used.
>>>> Enabling the DSI PLL will require the PRCM clock to be enabled first.
>>>>
>>>> Using the DSI PLL as the fclk is doable, but is it really useful or needed?
>>>
>>> Yes, it's useful and needed. It gives us much finer control to the clock
>>> frequencies, and so allows us to go to higher frequencies and also more
>>> exactly to the required pixel clock.
>>>
>>>> Assuming you need that mode, you will always have to explicitly switch
>>>> from DSI to PRCM clock before trying to disable the DSS.
>>>> This is something you will have to do inside the DSS driver. It should
>>>> be transparent to the hwmod fmwk.
>>>
>>> This sounds ok.
>>>
>>> I think the main question is how do we disable the standard DSS fclk
>>> from PRCM when using DSI PLL? As far as I know, disabling that clock
>>> will allow some areas of OMAP to be shut down even while DSS is working.
>>> So from power management point of view it sounds a needed feature.
>>
>> Yes, at least in theory, but considering that any use case that will
>> require the DSI PLL will use a LCD panel + backlight, or an OLED panel
>> that will consume 50 times more than the 186 MHz clock, I do not think
>> it is really needed.
>> Moreover, that clock is generated by the PER DPLL that will be always
>> enabled in most usecase because it does generate the UART, I2C and most
>> basic peripherals clocks. If we cannot gate the PER DPLL, there is no
>> saving to expect from gating the DSS fclk only.
>> Bottom-line is that there is no practical power saving to expect from
>> that mode.
>>
>>> If the clock is main_clk for the HWMOD, it sounds to me it's always
>>> enabled if the HWMOD is enabled?
>>
>> Yes, but that sounds to me a good trade off to avoid unnecessary
>> complexity in your driver or in the hwmod fmwk.
>
> Ok, if there are no real power savings there, then I agree, it's
> pointless to add that complexity.
>
> So how do we go forward in short term? I'd very much like to remove all
> the "silly" code from the DSS pm_runtime patch series caused by this
> opt_clock handling. Is it possible to get some kind of a temporary
> solution in the hwmod framework which would somehow solve this from DSS
> driver's point of view? A flag that causes hwmod fmwk to enable
> opt-clocks automatically? Or is it possible to have more than one
> mandatory clock?
Before doing that, could you maybe just try something to make OMAP4
looks a little bit more like OMAP3?
dss_fck -> ick
dss_dss_fck -> main_clk
That should ensure that both modulemode and the PRCM fclk will be
managed by pm_runtime.
I just did a basic patch for the first module, you should maybe change
some other entries.
Regards,
Benoit
---
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 614d680..4dfd18a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1134,7 +1134,7 @@ static struct omap_hwmod_addr_space
omap44xx_dss_dma_addrs[] = {
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_hwmod,
- .clk = "l3_div_ck",
+ .clk = "dss_fck",
.addr = omap44xx_dss_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dma_addrs),
.user = OCP_USER_SDMA,
@@ -1167,14 +1167,13 @@ static struct omap_hwmod_ocp_if
*omap44xx_dss_slaves[] = {
static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = "sys_clk", .clk = "dss_sys_clk" },
{ .role = "tv_clk", .clk = "dss_tv_clk" },
- { .role = "dss_clk", .clk = "dss_dss_clk" },
{ .role = "video_clk", .clk = "dss_48mhz_clk" },
};
static struct omap_hwmod omap44xx_dss_hwmod = {
.name = "dss_core",
.class = &omap44xx_dss_hwmod_class,
- .main_clk = "dss_fck",
+ .main_clk = "dss_dss_fck",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
^ permalink raw reply related
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-06 13:55 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <4DECDA3A.7080808@ti.com>
On Mon, 2011-06-06 at 15:46 +0200, Cousson, Benoit wrote:
> On 6/6/2011 3:21 PM, Valkeinen, Tomi wrote:
> > On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
> >> On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
> >>> On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
> >
> >>> In this long term solution, if the dss_fclk is the main_clk, how does
> >>> the framework handle the situation when we want to switch from the
> >>> standard DSS fclk to the one from DSI PLL?
> >>
> >> That part cannot be done by the hwmod fmwk anyway. The goal of the fmwk
> >> is to ensure that the module is accessible by the driver whatever the
> >> PRCM clock used.
> >> Enabling the DSI PLL will require the PRCM clock to be enabled first.
> >>
> >> Using the DSI PLL as the fclk is doable, but is it really useful or needed?
> >
> > Yes, it's useful and needed. It gives us much finer control to the clock
> > frequencies, and so allows us to go to higher frequencies and also more
> > exactly to the required pixel clock.
> >
> >> Assuming you need that mode, you will always have to explicitly switch
> >> from DSI to PRCM clock before trying to disable the DSS.
> >> This is something you will have to do inside the DSS driver. It should
> >> be transparent to the hwmod fmwk.
> >
> > This sounds ok.
> >
> > I think the main question is how do we disable the standard DSS fclk
> > from PRCM when using DSI PLL? As far as I know, disabling that clock
> > will allow some areas of OMAP to be shut down even while DSS is working.
> > So from power management point of view it sounds a needed feature.
>
> Yes, at least in theory, but considering that any use case that will
> require the DSI PLL will use a LCD panel + backlight, or an OLED panel
> that will consume 50 times more than the 186 MHz clock, I do not think
> it is really needed.
> Moreover, that clock is generated by the PER DPLL that will be always
> enabled in most usecase because it does generate the UART, I2C and most
> basic peripherals clocks. If we cannot gate the PER DPLL, there is no
> saving to expect from gating the DSS fclk only.
> Bottom-line is that there is no practical power saving to expect from
> that mode.
>
> > If the clock is main_clk for the HWMOD, it sounds to me it's always
> > enabled if the HWMOD is enabled?
>
> Yes, but that sounds to me a good trade off to avoid unnecessary
> complexity in your driver or in the hwmod fmwk.
Ok, if there are no real power savings there, then I agree, it's
pointless to add that complexity.
So how do we go forward in short term? I'd very much like to remove all
the "silly" code from the DSS pm_runtime patch series caused by this
opt_clock handling. Is it possible to get some kind of a temporary
solution in the hwmod framework which would somehow solve this from DSS
driver's point of view? A flag that causes hwmod fmwk to enable
opt-clocks automatically? Or is it possible to have more than one
mandatory clock?
This way when your long-term solution is done, the driver would not need
any changes.
Tomi
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-06 13:46 UTC (permalink / raw)
To: Valkeinen, Tomi
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <1307366474.1910.44.camel@deskari>
On 6/6/2011 3:21 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
>> On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
>>> On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
>
>>> In this long term solution, if the dss_fclk is the main_clk, how does
>>> the framework handle the situation when we want to switch from the
>>> standard DSS fclk to the one from DSI PLL?
>>
>> That part cannot be done by the hwmod fmwk anyway. The goal of the fmwk
>> is to ensure that the module is accessible by the driver whatever the
>> PRCM clock used.
>> Enabling the DSI PLL will require the PRCM clock to be enabled first.
>>
>> Using the DSI PLL as the fclk is doable, but is it really useful or needed?
>
> Yes, it's useful and needed. It gives us much finer control to the clock
> frequencies, and so allows us to go to higher frequencies and also more
> exactly to the required pixel clock.
>
>> Assuming you need that mode, you will always have to explicitly switch
>> from DSI to PRCM clock before trying to disable the DSS.
>> This is something you will have to do inside the DSS driver. It should
>> be transparent to the hwmod fmwk.
>
> This sounds ok.
>
> I think the main question is how do we disable the standard DSS fclk
> from PRCM when using DSI PLL? As far as I know, disabling that clock
> will allow some areas of OMAP to be shut down even while DSS is working.
> So from power management point of view it sounds a needed feature.
Yes, at least in theory, but considering that any use case that will
require the DSI PLL will use a LCD panel + backlight, or an OLED panel
that will consume 50 times more than the 186 MHz clock, I do not think
it is really needed.
Moreover, that clock is generated by the PER DPLL that will be always
enabled in most usecase because it does generate the UART, I2C and most
basic peripherals clocks. If we cannot gate the PER DPLL, there is no
saving to expect from gating the DSS fclk only.
Bottom-line is that there is no practical power saving to expect from
that mode.
> If the clock is main_clk for the HWMOD, it sounds to me it's always
> enabled if the HWMOD is enabled?
Yes, but that sounds to me a good trade off to avoid unnecessary
complexity in your driver or in the hwmod fmwk.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: fix usage of wrong registers in suspend/resume
From: Hubert Feurstein @ 2011-06-06 13:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1307350251-5767-1-git-send-email-h.feurstein@gmail.com>
Or it must be this way:
---
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 4484c72..c2ceae4 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1085,7 +1085,7 @@ static int atmel_lcdfb_suspend(struct
platform_device *pdev, pm_message_t mesg)
*/
lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL);
- sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
+ sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_CTR);
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
if (sinfo->atmel_lcdfb_power_control)
sinfo->atmel_lcdfb_power_control(0);
--
So which solution was originally intended?
Best regards
Hubert
2011/6/6 Hubert Feurstein <h.feurstein@gmail.com>:
> I assume the intention was to set the contrast value to 0 and not
> the contrast control register (in atmel_lcdfb_suspend). And in
> atmel_lcdfb_resume the contrast value should be restored.
>
> Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
> drivers/video/atmel_lcdfb.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 4484c72..2ed7ec1 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -1086,7 +1086,7 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
> lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL);
>
> sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
> - lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
> + lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, 0);
> if (sinfo->atmel_lcdfb_power_control)
> sinfo->atmel_lcdfb_power_control(0);
>
> @@ -1105,7 +1105,7 @@ static int atmel_lcdfb_resume(struct platform_device *pdev)
> atmel_lcdfb_start(sinfo);
> if (sinfo->atmel_lcdfb_power_control)
> sinfo->atmel_lcdfb_power_control(1);
> - lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, sinfo->saved_lcdcon);
> + lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, sinfo->saved_lcdcon);
>
> /* Enable FIFO & DMA errors */
> lcdc_writel(sinfo, ATMEL_LCDC_IER, ATMEL_LCDC_UFLWI
> --
> 1.7.1
>
>
^ permalink raw reply related
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-06 13:21 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <4DECD2D7.6030207@ti.com>
On Mon, 2011-06-06 at 15:15 +0200, Cousson, Benoit wrote:
> On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
> > On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
> > In this long term solution, if the dss_fclk is the main_clk, how does
> > the framework handle the situation when we want to switch from the
> > standard DSS fclk to the one from DSI PLL?
>
> That part cannot be done by the hwmod fmwk anyway. The goal of the fmwk
> is to ensure that the module is accessible by the driver whatever the
> PRCM clock used.
> Enabling the DSI PLL will require the PRCM clock to be enabled first.
>
> Using the DSI PLL as the fclk is doable, but is it really useful or needed?
Yes, it's useful and needed. It gives us much finer control to the clock
frequencies, and so allows us to go to higher frequencies and also more
exactly to the required pixel clock.
> Assuming you need that mode, you will always have to explicitly switch
> from DSI to PRCM clock before trying to disable the DSS.
> This is something you will have to do inside the DSS driver. It should
> be transparent to the hwmod fmwk.
This sounds ok.
I think the main question is how do we disable the standard DSS fclk
from PRCM when using DSI PLL? As far as I know, disabling that clock
will allow some areas of OMAP to be shut down even while DSS is working.
So from power management point of view it sounds a needed feature.
If the clock is main_clk for the HWMOD, it sounds to me it's always
enabled if the HWMOD is enabled?
Tomi
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-06 13:15 UTC (permalink / raw)
To: Valkeinen, Tomi
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <1307365290.1910.39.camel@deskari>
On 6/6/2011 3:01 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
>> Hi Tomi,
>>
>> On 6/4/2011 10:01 AM, Valkeinen, Tomi wrote:
>>> On Fri, 2011-06-03 at 15:53 -0700, Kevin Hilman wrote:
>>>> Tomi Valkeinen<tomi.valkeinen@ti.com> writes:
>>>>
>>>>> Hi Kevin,
>>>>>
>>>>> On Fri, 2011-06-03 at 09:45 -0700, Kevin Hilman wrote:
>>>>>> Tomi Valkeinen<tomi.valkeinen@ti.com> writes:
>>>>>>
>>>>>>> Use PM runtime and HWMOD support to handle enabling and disabling of DSS
>>>>>>> modules.
>>>>>>>
>>>>>>> Each DSS module will have get and put functions which can be used to
>>>>>>> enable and disable that module. The functions use pm_runtime and hwmod
>>>>>>> opt-clocks to enable the hardware.
>>>>>>>
>>>>>>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> +int dispc_runtime_get(void)
>>>>>>> +{
>>>>>>> + int r;
>>>>>>> +
>>>>>>> + mutex_lock(&dispc.runtime_lock);
>>>>>>
>>>>>> It's not clear to me what the lock is trying to protect. I guess it's
>>>>>> the counter? I don't think it should be needed...
>>>>>
>>>>> Yes, the counter. I don't think
>>>>>
>>>>> if (dispc.runtime_count++ = 0)
>>>>>
>>>>> is thread safe.
>>>>
>>>> OK, if it's just the counter, you can drop the mutex and use an atomic
>>>> variable and use atomic_inc(), atomic_dec() etc. Then it will be clear
>>>> from reading what exactly is protected.
>>>
>>> Hmm, sorry, my mistake. It's actually for the whole function: we can't
>>> do "put" before the whole "get" has finished. Otherwise we could end up,
>>> for example, disabling a clock before enabling it.
>>>
>>>>>>> + if (dispc.runtime_count++ = 0) {
>>>>>>
>>>>>> You shouldn't need your own use-counting here. The runtime PM core is
>>>>>> already doing usage counting.
>>>>>>
>>>>>> Instead, you need to use the ->runtime_suspend() and ->runtime_resume()
>>>>>> callbacks (in dev_pm_ops). These callbacks are called by the runtime PM
>>>>>> core when the usage count goes to/from zero.
>>>>>
>>>>> Yes, I wish I could do that =).
>>>>>
>>>>> I tried to explain this in the 00-patch, I guess I should've explained
>>>>> it in this patch also. Perhaps also in a comment.
>>>>
>>>> Oops, my fault. I didn't read the whole 00 patch. I'm pretty ignorant
>>>> about DSS, so I was focused in on the runtime PM implementation only.
>>>> Sorry about that.
>>>>
>>>>> From the introduction:
>>>>>
>>>>> ---
>>>>>
>>>>> Due to DSS' peculiar clock setup the code is not as elegant as I'd like. The
>>>>> problem is that on OMAP4 we have to enable an optional clock before calling
>>>>> pm_runtime_get(), and similarly we need to keep the optional clock enabled
>>>>> until after pm_runtime_put() has been called.
>>>>
>>>> Just to clarify, what exactly does the opt clock have to be enabled for?
>>>
>>> I'm not sure if this is a valid definition, but in my mind the opt clock
>>> has two uses: 1) a functional clock, to make the HW tick and registers
>>> accessible, and 2) act as a source clock for the outgoing pixel clock.
>>
>> That terminology in the PRCM just means that an opt clock will not be
>> handled automatically by the PRCM and will require SW control.
>> This is not the case for mandatory clock. Upon module enable the PRCM
>> will ensure that all mandatory clocks (functional and interface) are
>> enabled automagically. If the clock is marked as optional it means that
>> the SW will have to enable it explicitly before enabling the module.
>>
>> The modulemode was not there previously on OMAP2& 3, but it is more or
>> less equivalent to icken=1 + fcken=1.
>> This idea was to hide the explicit clock management especially for the
>> iclk that were already supposed to always be in autoidle.
>>
>> Since the current hwmod + clock fmwks are still based on the previous
>> clock centric approach we used to have on OMAP2& 3, we cannot match
>> properly the modulemode to any clock and thus cannot handle properly the
>> DSS fclk as the main clock instead of the optional clock.
>>
>> A temporary option will be to consider the modulemode as the interface
>> clock and thus remove it from the main_clk and replace it by the real
>> DSS fclk.
>>
>> It should work be will unfortunately not be compliant with PRCM
>> recommendation to enable the modulemode once every clocks are enabled.
>>
>> The long term solution is to update the hwmod fmwk to handle the
>> modulemode directly and not through the clock fmwk. It will allow the
>> main_clk to be connnected to the dss_fclk.
>>
>> You will not have that nasty opt_clock issue anymore.
>
> In this long term solution, if the dss_fclk is the main_clk, how does
> the framework handle the situation when we want to switch from the
> standard DSS fclk to the one from DSI PLL?
That part cannot be done by the hwmod fmwk anyway. The goal of the fmwk
is to ensure that the module is accessible by the driver whatever the
PRCM clock used.
Enabling the DSI PLL will require the PRCM clock to be enabled first.
Using the DSI PLL as the fclk is doable, but is it really useful or needed?
Assuming you need that mode, you will always have to explicitly switch
from DSI to PRCM clock before trying to disable the DSS.
This is something you will have to do inside the DSS driver. It should
be transparent to the hwmod fmwk.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-06 13:01 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <4DECCE90.6070201@ti.com>
On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
> Hi Tomi,
>
> On 6/4/2011 10:01 AM, Valkeinen, Tomi wrote:
> > On Fri, 2011-06-03 at 15:53 -0700, Kevin Hilman wrote:
> >> Tomi Valkeinen<tomi.valkeinen@ti.com> writes:
> >>
> >>> Hi Kevin,
> >>>
> >>> On Fri, 2011-06-03 at 09:45 -0700, Kevin Hilman wrote:
> >>>> Tomi Valkeinen<tomi.valkeinen@ti.com> writes:
> >>>>
> >>>>> Use PM runtime and HWMOD support to handle enabling and disabling of DSS
> >>>>> modules.
> >>>>>
> >>>>> Each DSS module will have get and put functions which can be used to
> >>>>> enable and disable that module. The functions use pm_runtime and hwmod
> >>>>> opt-clocks to enable the hardware.
> >>>>>
> >>>>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> >>>>
> >>>> [...]
> >>>>
> >>>>> +int dispc_runtime_get(void)
> >>>>> +{
> >>>>> + int r;
> >>>>> +
> >>>>> + mutex_lock(&dispc.runtime_lock);
> >>>>
> >>>> It's not clear to me what the lock is trying to protect. I guess it's
> >>>> the counter? I don't think it should be needed...
> >>>
> >>> Yes, the counter. I don't think
> >>>
> >>> if (dispc.runtime_count++ = 0)
> >>>
> >>> is thread safe.
> >>
> >> OK, if it's just the counter, you can drop the mutex and use an atomic
> >> variable and use atomic_inc(), atomic_dec() etc. Then it will be clear
> >> from reading what exactly is protected.
> >
> > Hmm, sorry, my mistake. It's actually for the whole function: we can't
> > do "put" before the whole "get" has finished. Otherwise we could end up,
> > for example, disabling a clock before enabling it.
> >
> >>>>> + if (dispc.runtime_count++ = 0) {
> >>>>
> >>>> You shouldn't need your own use-counting here. The runtime PM core is
> >>>> already doing usage counting.
> >>>>
> >>>> Instead, you need to use the ->runtime_suspend() and ->runtime_resume()
> >>>> callbacks (in dev_pm_ops). These callbacks are called by the runtime PM
> >>>> core when the usage count goes to/from zero.
> >>>
> >>> Yes, I wish I could do that =).
> >>>
> >>> I tried to explain this in the 00-patch, I guess I should've explained
> >>> it in this patch also. Perhaps also in a comment.
> >>
> >> Oops, my fault. I didn't read the whole 00 patch. I'm pretty ignorant
> >> about DSS, so I was focused in on the runtime PM implementation only.
> >> Sorry about that.
> >>
> >>> From the introduction:
> >>>
> >>> ---
> >>>
> >>> Due to DSS' peculiar clock setup the code is not as elegant as I'd like. The
> >>> problem is that on OMAP4 we have to enable an optional clock before calling
> >>> pm_runtime_get(), and similarly we need to keep the optional clock enabled
> >>> until after pm_runtime_put() has been called.
> >>
> >> Just to clarify, what exactly does the opt clock have to be enabled for?
> >
> > I'm not sure if this is a valid definition, but in my mind the opt clock
> > has two uses: 1) a functional clock, to make the HW tick and registers
> > accessible, and 2) act as a source clock for the outgoing pixel clock.
>
> That terminology in the PRCM just means that an opt clock will not be
> handled automatically by the PRCM and will require SW control.
> This is not the case for mandatory clock. Upon module enable the PRCM
> will ensure that all mandatory clocks (functional and interface) are
> enabled automagically. If the clock is marked as optional it means that
> the SW will have to enable it explicitly before enabling the module.
>
> The modulemode was not there previously on OMAP2 & 3, but it is more or
> less equivalent to icken=1 + fcken=1.
> This idea was to hide the explicit clock management especially for the
> iclk that were already supposed to always be in autoidle.
>
> Since the current hwmod + clock fmwks are still based on the previous
> clock centric approach we used to have on OMAP2 & 3, we cannot match
> properly the modulemode to any clock and thus cannot handle properly the
> DSS fclk as the main clock instead of the optional clock.
>
> A temporary option will be to consider the modulemode as the interface
> clock and thus remove it from the main_clk and replace it by the real
> DSS fclk.
>
> It should work be will unfortunately not be compliant with PRCM
> recommendation to enable the modulemode once every clocks are enabled.
>
> The long term solution is to update the hwmod fmwk to handle the
> modulemode directly and not through the clock fmwk. It will allow the
> main_clk to be connnected to the dss_fclk.
>
> You will not have that nasty opt_clock issue anymore.
In this long term solution, if the dss_fclk is the main_clk, how does
the framework handle the situation when we want to switch from the
standard DSS fclk to the one from DSI PLL?
Tomi
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-06 12:56 UTC (permalink / raw)
To: Valkeinen, Tomi
Cc: Hilman, Kevin, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, paul@pwsan.com
In-Reply-To: <1307174504.1777.24.camel@lappyti>
Hi Tomi,
On 6/4/2011 10:01 AM, Valkeinen, Tomi wrote:
> On Fri, 2011-06-03 at 15:53 -0700, Kevin Hilman wrote:
>> Tomi Valkeinen<tomi.valkeinen@ti.com> writes:
>>
>>> Hi Kevin,
>>>
>>> On Fri, 2011-06-03 at 09:45 -0700, Kevin Hilman wrote:
>>>> Tomi Valkeinen<tomi.valkeinen@ti.com> writes:
>>>>
>>>>> Use PM runtime and HWMOD support to handle enabling and disabling of DSS
>>>>> modules.
>>>>>
>>>>> Each DSS module will have get and put functions which can be used to
>>>>> enable and disable that module. The functions use pm_runtime and hwmod
>>>>> opt-clocks to enable the hardware.
>>>>>
>>>>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
>>>>
>>>> [...]
>>>>
>>>>> +int dispc_runtime_get(void)
>>>>> +{
>>>>> + int r;
>>>>> +
>>>>> + mutex_lock(&dispc.runtime_lock);
>>>>
>>>> It's not clear to me what the lock is trying to protect. I guess it's
>>>> the counter? I don't think it should be needed...
>>>
>>> Yes, the counter. I don't think
>>>
>>> if (dispc.runtime_count++ = 0)
>>>
>>> is thread safe.
>>
>> OK, if it's just the counter, you can drop the mutex and use an atomic
>> variable and use atomic_inc(), atomic_dec() etc. Then it will be clear
>> from reading what exactly is protected.
>
> Hmm, sorry, my mistake. It's actually for the whole function: we can't
> do "put" before the whole "get" has finished. Otherwise we could end up,
> for example, disabling a clock before enabling it.
>
>>>>> + if (dispc.runtime_count++ = 0) {
>>>>
>>>> You shouldn't need your own use-counting here. The runtime PM core is
>>>> already doing usage counting.
>>>>
>>>> Instead, you need to use the ->runtime_suspend() and ->runtime_resume()
>>>> callbacks (in dev_pm_ops). These callbacks are called by the runtime PM
>>>> core when the usage count goes to/from zero.
>>>
>>> Yes, I wish I could do that =).
>>>
>>> I tried to explain this in the 00-patch, I guess I should've explained
>>> it in this patch also. Perhaps also in a comment.
>>
>> Oops, my fault. I didn't read the whole 00 patch. I'm pretty ignorant
>> about DSS, so I was focused in on the runtime PM implementation only.
>> Sorry about that.
>>
>>> From the introduction:
>>>
>>> ---
>>>
>>> Due to DSS' peculiar clock setup the code is not as elegant as I'd like. The
>>> problem is that on OMAP4 we have to enable an optional clock before calling
>>> pm_runtime_get(), and similarly we need to keep the optional clock enabled
>>> until after pm_runtime_put() has been called.
>>
>> Just to clarify, what exactly does the opt clock have to be enabled for?
>
> I'm not sure if this is a valid definition, but in my mind the opt clock
> has two uses: 1) a functional clock, to make the HW tick and registers
> accessible, and 2) act as a source clock for the outgoing pixel clock.
That terminology in the PRCM just means that an opt clock will not be
handled automatically by the PRCM and will require SW control.
This is not the case for mandatory clock. Upon module enable the PRCM
will ensure that all mandatory clocks (functional and interface) are
enabled automagically. If the clock is marked as optional it means that
the SW will have to enable it explicitly before enabling the module.
The modulemode was not there previously on OMAP2 & 3, but it is more or
less equivalent to icken=1 + fcken=1.
This idea was to hide the explicit clock management especially for the
iclk that were already supposed to always be in autoidle.
Since the current hwmod + clock fmwks are still based on the previous
clock centric approach we used to have on OMAP2 & 3, we cannot match
properly the modulemode to any clock and thus cannot handle properly the
DSS fclk as the main clock instead of the optional clock.
A temporary option will be to consider the modulemode as the interface
clock and thus remove it from the main_clk and replace it by the real
DSS fclk.
It should work be will unfortunately not be compliant with PRCM
recommendation to enable the modulemode once every clocks are enabled.
The long term solution is to update the hwmod fmwk to handle the
modulemode directly and not through the clock fmwk. It will allow the
main_clk to be connnected to the dss_fclk.
You will not have that nasty opt_clock issue anymore.
Regards,
Benoit
^ permalink raw reply
* Re: [GIT PULL] fbdev fixes for 3.0-rc2
From: Bruno Prémont @ 2011-06-06 9:39 UTC (permalink / raw)
To: Paul Mundt; +Cc: Linus Torvalds, linux-fbdev, linux-kernel
In-Reply-To: <20110606091556.GG26101@linux-sh.org>
On Mon, 6 Jun 2011 18:15:57 Paul Mundt <lethal@linux-sh.org> wrote:
> On Mon, Jun 06, 2011 at 06:04:58PM +0900, Linus Torvalds wrote:
> > On Mon, Jun 6, 2011 at 12:39 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > >
> > > Bruno Pr??????????????????mont (1):
> > > ?? ?? ??video: Fix use-after-free by vga16fb on rmmod
> >
> > Do you even *look* at what you ask me to pull from you?
> >
> > Spend a bit of effort in not sending obviously bogus and corrupted
> > authorship patches. That one has Bruno's name correctly in the
> > sign-off, but you've done something horrible to it in the authorship.
> >
> That's how I got it from patchwork, so it looks like it was mangled
> already on the way in. I assumed it was just my console that was screwing
> it up, but it looks to be in a similar state in the list archives, too.
Hm, patchwork's mail headers look correct but its post-decoding display
is mangled (hard to guess what multiple transcodings it did!). (your
mail-client also dislikes non-ascii characters)
From archives, marc.info seems not to handle charsets at all - it dumps
the bytes and flags them as iso-8859-1 (don't know what other archives
you were looking at, marc.info being the only one listed at vger)
The only not so usual thing I see in my From header is that just the
lastname is being encoded and base64 is being used (while
quoted-printable is more common).
Bruno
^ permalink raw reply
* Re: [GIT PULL] fbdev fixes for 3.0-rc2
From: Paul Mundt @ 2011-06-06 9:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <BANLkTik1nLG6f27JkR0kBvcJEoqUrq602A@mail.gmail.com>
On Mon, Jun 06, 2011 at 06:04:58PM +0900, Linus Torvalds wrote:
> On Mon, Jun 6, 2011 at 12:39 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> >
> > Bruno Pr??????????????????mont (1):
> > ?? ?? ??video: Fix use-after-free by vga16fb on rmmod
>
> Do you even *look* at what you ask me to pull from you?
>
> Spend a bit of effort in not sending obviously bogus and corrupted
> authorship patches. That one has Bruno's name correctly in the
> sign-off, but you've done something horrible to it in the authorship.
>
That's how I got it from patchwork, so it looks like it was mangled
already on the way in. I assumed it was just my console that was screwing
it up, but it looks to be in a similar state in the list archives, too.
In any event, I've fixed it up and pushed out a cleaned up version, sorry
for the noise.
^ permalink raw reply
* Re: [GIT PULL] fbdev fixes for 3.0-rc2
From: Linus Torvalds @ 2011-06-06 9:04 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <20110606033900.GF26101@linux-sh.org>
On Mon, Jun 6, 2011 at 12:39 PM, Paul Mundt <lethal@linux-sh.org> wrote:
>
> Bruno Prémont (1):
> video: Fix use-after-free by vga16fb on rmmod
Do you even *look* at what you ask me to pull from you?
Spend a bit of effort in not sending obviously bogus and corrupted
authorship patches. That one has Bruno's name correctly in the
sign-off, but you've done something horrible to it in the authorship.
Linus
^ permalink raw reply
* [PATCH] atmel_lcdfb: fix usage of wrong registers in suspend/resume
From: Hubert Feurstein @ 2011-06-06 8:50 UTC (permalink / raw)
To: linux-fbdev
I assume the intention was to set the contrast value to 0 and not
the contrast control register (in atmel_lcdfb_suspend). And in
atmel_lcdfb_resume the contrast value should be restored.
Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
drivers/video/atmel_lcdfb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 4484c72..2ed7ec1 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1086,7 +1086,7 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL);
sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
- lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
+ lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, 0);
if (sinfo->atmel_lcdfb_power_control)
sinfo->atmel_lcdfb_power_control(0);
@@ -1105,7 +1105,7 @@ static int atmel_lcdfb_resume(struct platform_device *pdev)
atmel_lcdfb_start(sinfo);
if (sinfo->atmel_lcdfb_power_control)
sinfo->atmel_lcdfb_power_control(1);
- lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, sinfo->saved_lcdcon);
+ lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, sinfo->saved_lcdcon);
/* Enable FIFO & DMA errors */
lcdc_writel(sinfo, ATMEL_LCDC_IER, ATMEL_LCDC_UFLWI
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 01/27] OMAP: change get_context_loss_count ret value to
From: Tomi Valkeinen @ 2011-06-06 7:28 UTC (permalink / raw)
To: Kevin Hilman, paul; +Cc: linux-omap, linux-fbdev, b-cousson
In-Reply-To: <871uzaj2oy.fsf@ti.com>
On Fri, 2011-06-03 at 09:32 -0700, Kevin Hilman wrote:
> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
>
> > get_context_loss_count functions return context loss count as u32, and
> > zero means an error. However, zero is also returned when context has
> > never been lost and could also be returned when the context loss count
> > has wrapped and goes to zero.
> >
> > Change the functions to return an int, with negative value meaning an
> > error.
> >
> > OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
> > hsmmc code handles the returned value as an int, with negative value
> > meaning an error, this patch actually fixes hsmmc code also.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Acked-by: Kevin Hilman <khilman@ti.com>
>
> This one should be separated out into a fix for v3.0-rc, and queued by
> Paul (also Cc'd to linux-arm-kernel.)
Yup, I added it here for completeness to get a working patch series. The
same patch has also been sent separately.
Tomi
^ permalink raw reply
* Re: [PATCH 03/27] OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after use
From: Tomi Valkeinen @ 2011-06-06 7:21 UTC (permalink / raw)
To: Archit Taneja
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Cousson, Benoit, paul@pwsan.com, Hilman, Kevin
In-Reply-To: <4DEC6889.6020607@ti.com>
On Mon, 2011-06-06 at 11:11 +0530, Archit Taneja wrote:
> Hi,
>
> On Friday 03 June 2011 03:30 PM, Valkeinen, Tomi wrote:
> > LANEx_ULPS_SIG2 bits are left on after entering ULPS. This doesn't cause
> > any problems currently, as DSI HW is reset when it is enabled. However,
> > if the reset is not done, operation fails if the bits are still set.
> >
> > So reset the bits after entering ULPS to ensure operation even without
> > HW reset.
> >
> > Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> > ---
> > drivers/video/omap2/dss/dsi.c | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> > index 69c2d4f..4496d09 100644
> > --- a/drivers/video/omap2/dss/dsi.c
> > +++ b/drivers/video/omap2/dss/dsi.c
> > @@ -3395,6 +3395,10 @@ static int dsi_enter_ulps(struct platform_device *dsidev)
> > dsi_unregister_isr_cio(dsidev, dsi_completion_handler,&completion,
> > DSI_CIO_IRQ_ULPSACTIVENOT_ALL0);
> >
> > + /* Reset LANEx_ULPS_SIG2 */
> > + REG_FLD_MOD(dsidev, DSI_COMPLEXIO_CFG2, (0<< 0) | (0<< 1) | (0<< 2),
> > + 7, 5);
> > +
>
> We may need to reset more lanes based on the number of lanes the panel
> is using. We could calculate a mask here instead.
Yes, I noticed that but I decided just to fix the bug here. The same
bits are set a few lines earlier.
We should go through all the lane configs in dsi.c, and come up with a
way to easily get the necessary masks.
Tomi
^ permalink raw reply
* Re: [PATCH 03/27] OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after use
From: Archit Taneja @ 2011-06-06 5:53 UTC (permalink / raw)
To: Valkeinen, Tomi
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Cousson, Benoit, paul@pwsan.com, Hilman, Kevin
In-Reply-To: <1307095237-14805-4-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Friday 03 June 2011 03:30 PM, Valkeinen, Tomi wrote:
> LANEx_ULPS_SIG2 bits are left on after entering ULPS. This doesn't cause
> any problems currently, as DSI HW is reset when it is enabled. However,
> if the reset is not done, operation fails if the bits are still set.
>
> So reset the bits after entering ULPS to ensure operation even without
> HW reset.
>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dsi.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 69c2d4f..4496d09 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -3395,6 +3395,10 @@ static int dsi_enter_ulps(struct platform_device *dsidev)
> dsi_unregister_isr_cio(dsidev, dsi_completion_handler,&completion,
> DSI_CIO_IRQ_ULPSACTIVENOT_ALL0);
>
> + /* Reset LANEx_ULPS_SIG2 */
> + REG_FLD_MOD(dsidev, DSI_COMPLEXIO_CFG2, (0<< 0) | (0<< 1) | (0<< 2),
> + 7, 5);
> +
We may need to reset more lanes based on the number of lanes the panel
is using. We could calculate a mask here instead.
Archit
> dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_ULPS);
>
> dsi_if_enable(dsidev, false);
^ permalink raw reply
* [GIT PULL] fbdev fixes for 3.0-rc2
From: Paul Mundt @ 2011-06-06 3:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/fbdev-3.x.git fbdev-fixes-for-linus
Which contains:
Andy Lutomirski (3):
efifb: Enable write-combining
efifb: Fix mismatched request/release_mem_region
efifb: Disallow manual bind and unbind
Bruno Prémont (1):
video: Fix use-after-free by vga16fb on rmmod
Joe Perches (1):
video: Convert vmalloc/memset to vzalloc
Julia Lawall (2):
drivers/video/imxfb.c: add missing clk_put
drivers/video/pxa168fb.c: add missing clk_put
Paul Mundt (1):
fbdev: sh_mobile_lcdcfb: Fix up fallout from MERAM changes.
Steven Miao (1):
fbdev: bf537-lq035: add missing blacklight properties type
Tormod Volden (1):
savagefb: Use panel CVT mode as default
drivers/video/arcfb.c | 5 +--
drivers/video/bf537-lq035.c | 1 +
drivers/video/broadsheetfb.c | 4 +--
drivers/video/efifb.c | 34 ++++++++++++++++++++-----------
drivers/video/hecubafb.c | 5 +--
drivers/video/imxfb.c | 4 +-
drivers/video/metronomefb.c | 4 +--
drivers/video/modedb.c | 1 +
drivers/video/pxa168fb.c | 17 +++++++++------
drivers/video/savage/savagefb_driver.c | 16 +++++++++++++++
drivers/video/sh_mobile_lcdcfb.c | 4 +-
drivers/video/vga16fb.c | 2 +
drivers/video/xen-fbfront.c | 3 +-
13 files changed, 63 insertions(+), 37 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox