* 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 11:51 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: <4DEE0D7E.6090309@ti.com>
On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
> 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.
Does that change anything? Isn't the above (modulemode enabled before
opt clock) still true, even if it was enabled only once for the dss_core
hwmod?
And for PM, it doesn't matter if the dss_fck is enabled once or seven
times, I presume a use count of one will still prevent RET or OFF?
> 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.
I can do this in the driver, and in fact I already do. The dss_core
hwmod is enabled by all the other hwmods before they do anything.
My reasoning for this dependency is that the dss_core contains for
example the clock mux registers, and other misc registers used by most
other dss modules. But I'm not sure if this dependency should be in the
hwmod level or not.
Tomi
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-07 16:43 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: <1307447504.1858.37.camel@deskari>
On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
> On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
>> 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.
>
> Does that change anything? Isn't the above (modulemode enabled before
> opt clock) still true, even if it was enabled only once for the dss_core
> hwmod?
It does not really change anything, but it is more accurate.
Modulemode need to be enable after the opt clocks that act as a
functional clock and before enabling HW_AUTO for the clockdomain.
The important parameter is the clock domain mode change. It is another
issue that we have to fix. It might not affect you for the moment.
> And for PM, it doesn't matter if the dss_fck is enabled once or seven
> times, I presume a use count of one will still prevent RET or OFF?
>
>> 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.
>
> I can do this in the driver, and in fact I already do. The dss_core
> hwmod is enabled by all the other hwmods before they do anything.
>
> My reasoning for this dependency is that the dss_core contains for
> example the clock mux registers, and other misc registers used by most
> other dss modules. But I'm not sure if this dependency should be in the
> hwmod level or not.
It makes sense for me as well to have that dependency between drivers.
Having it for hwmod for my point of view will make the hwmod state out
of sync with the driver that manage it potentially. That kind of hard
coded dependencies at hwmod level should maybe be considered only if the
dependent hwmod does not belong to any driver.
Benoit
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Tomi Valkeinen @ 2011-06-08 7: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: <4DEE5537.7060008@ti.com>
On Tue, 2011-06-07 at 18:43 +0200, Cousson, Benoit wrote:
> On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
> > On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
> >> 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.
> >
> > Does that change anything? Isn't the above (modulemode enabled before
> > opt clock) still true, even if it was enabled only once for the dss_core
> > hwmod?
>
> It does not really change anything, but it is more accurate.
> Modulemode need to be enable after the opt clocks that act as a
> functional clock and before enabling HW_AUTO for the clockdomain.
>
> The important parameter is the clock domain mode change. It is another
> issue that we have to fix. It might not affect you for the moment.
Ok. But the main issue now is the PM. If I change the clocks in hwmod
data as you suggested, dss_fck will always stay enabled and prevent RET
and OFF. So the fix is not acceptable even for temporary use.
So is there some way to fix this, or shall we just go forward with the
current patch series having the somewhat hacky way to use pm_runtime?
I would personally like to get the driver right from the start, even if
that means more hacks in the hwmod fmwk (because that's where the
problems are). But if that is very difficult, I'm fine with the current
patch series.
Tomi
^ permalink raw reply
* [PATCH 1/3] video: s3c-fb: fix misleading kfree in remove function
From: Jingoo Han @ 2011-06-08 10:43 UTC (permalink / raw)
To: linux-fbdev
This patch fixes misleading kfree in remove function.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..148e19d 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1487,11 +1487,10 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
- kfree(sfb);
-
pm_runtime_put_sync(sfb->dev);
pm_runtime_disable(sfb->dev);
+ kfree(sfb);
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH] video: s3c-fb: fix virtual resolution checking
From: Jingoo Han @ 2011-06-08 10:43 UTC (permalink / raw)
To: linux-fbdev
This patch fixes mishandling in virtual resolution checking.
Previously, virtual resolution is changed to virtual_x and virtual_y
which mean the size for buffer allocation, when s3c_fb_check_var is
called by fb_check_var. However, it is meaningless, since virtual_x
and virtual_y are fixed and user cannot change virtual resolution.
Therefore, virtual resolution should be more than resolution
such as xres and yres.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..e48129a 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -235,13 +235,12 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct s3c_fb_win *win = info->par;
- struct s3c_fb_pd_win *windata = win->windata;
struct s3c_fb *sfb = win->parent;
dev_dbg(sfb->dev, "checking parameters\n");
- var->xres_virtual = max((unsigned int)windata->virtual_x, var->xres);
- var->yres_virtual = max((unsigned int)windata->virtual_y, var->yres);
+ var->xres_virtual = max(var->xres_virtual, var->xres);
+ var->yres_virtual = max(var->yres_virtual, var->yres);
if (!s3c_fb_validate_win_bpp(win, var->bits_per_pixel)) {
dev_dbg(sfb->dev, "win %d: unsupported bpp %d\n",
--
1.7.1
^ permalink raw reply related
* [PATCH] video: s3c-fb: move enabling channel for window
From: Jingoo Han @ 2011-06-08 10:43 UTC (permalink / raw)
To: linux-fbdev
This patch moves enabling channel for window, because there should
be enabling channel before enabling window. If the sequence is
reversed, it makes the problem in displaying images to lcd panel.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..4f1bc39 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -558,6 +558,13 @@ static int s3c_fb_set_par(struct fb_info *info)
vidosd_set_alpha(win, alpha);
vidosd_set_size(win, data);
+ /* Enable DMA channel for this window */
+ if (sfb->variant.has_shadowcon) {
+ data = readl(sfb->regs + SHADOWCON);
+ data |= SHADOWCON_CHx_ENABLE(win_no);
+ writel(data, sfb->regs + SHADOWCON);
+ }
+
data = WINCONx_ENWIN;
/* note, since we have to round up the bits-per-pixel, we end up
@@ -637,13 +644,6 @@ static int s3c_fb_set_par(struct fb_info *info)
writel(data, regs + sfb->variant.wincon + (win_no * 4));
writel(0x0, regs + sfb->variant.winmap + (win_no * 4));
- /* Enable DMA channel for this window */
- if (sfb->variant.has_shadowcon) {
- data = readl(sfb->regs + SHADOWCON);
- data |= SHADOWCON_CHx_ENABLE(win_no);
- writel(data, sfb->regs + SHADOWCON);
- }
-
shadow_protect_win(win, 0);
return 0;
--
1.7.1
^ permalink raw reply related
* [PATCH] video: s3c-fb: fix misleading kfree in remove function
From: Jingoo Han @ 2011-06-08 10:50 UTC (permalink / raw)
To: linux-fbdev
This patch fixes misleading kfree in remove function.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..148e19d 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1487,11 +1487,10 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
- kfree(sfb);
-
pm_runtime_put_sync(sfb->dev);
pm_runtime_disable(sfb->dev);
+ kfree(sfb);
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/3] video: s3c-fb: fix misleading kfree in remove function
From: JinGoo Han @ 2011-06-08 10:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1307529797-27153-1-git-send-email-jg1.han@samsung.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 447 bytes --]
> ------- Original Message -------
> Sender : JinGoo Han<jg1.han@samsung.com>
> Date : Jun 08, 2011 19:43 (GMT+09:00)
> Title : [PATCH 1/3] video: s3c-fb: fix misleading kfree in remove function
Sorry. [PATCH 1/3] is typo.
I have just sent the patch '[PATCH] video: s3c-fb: fix misleading kfree in remove function'.
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply
* Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support
From: Cousson, Benoit @ 2011-06-08 20:39 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: <1307519752.1944.21.camel@deskari>
On 6/8/2011 9:55 AM, Valkeinen, Tomi wrote:
> On Tue, 2011-06-07 at 18:43 +0200, Cousson, Benoit wrote:
>> On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
>>> On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
>
>>>> 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.
>>>
>>> Does that change anything? Isn't the above (modulemode enabled before
>>> opt clock) still true, even if it was enabled only once for the dss_core
>>> hwmod?
>>
>> It does not really change anything, but it is more accurate.
>> Modulemode need to be enable after the opt clocks that act as a
>> functional clock and before enabling HW_AUTO for the clockdomain.
>>
>> The important parameter is the clock domain mode change. It is another
>> issue that we have to fix. It might not affect you for the moment.
>
> Ok. But the main issue now is the PM. If I change the clocks in hwmod
> data as you suggested, dss_fck will always stay enabled and prevent RET
> and OFF. So the fix is not acceptable even for temporary use.
Mmm, the issue is probably due to the way we are managing interface
clock that are usually able to autoidle. Because of that the
_disable_clocks function will not try to disable an interface clock
except if you use the following flag: OCPIF_SWSUP_IDLE.
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_hwmod,
.clk = "dss_fck",
.addr = omap44xx_dss_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dma_addrs),
.user = OCP_USER_SDMA,
+ .flags = OCPIF_SWSUP_IDLE,
>
> So is there some way to fix this, or shall we just go forward with the
> current patch series having the somewhat hacky way to use pm_runtime?
>
> I would personally like to get the driver right from the start, even if
> that means more hacks in the hwmod fmwk (because that's where the
> problems are). But if that is very difficult, I'm fine with the current
> patch series.
I hope we'll be able to fix the fmwk for 3.0.1.
Benoit
^ permalink raw reply
* [RFC] fbmem: reset file->private_data on failed fb_open()
From: Wu Fengguang @ 2011-06-09 3:06 UTC (permalink / raw)
To: Antonino A. Daplas; +Cc: Andrew Morton, linux-fbdev, LKML
I wrote this when looking at NULL dereference bug
https://bugzilla.kernel.org/show_bug.cgi?id\x18912
Will it help by clearing private_data? I have no idea at all, because
for regular files, ->release won't be called on failed ->open. Just in
case there are some exceptions in fbmem...
---
drivers/video/fbmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-next.orig/drivers/video/fbmem.c 2011-06-09 10:36:06.000000000 +0800
+++ linux-next/drivers/video/fbmem.c 2011-06-09 10:39:30.000000000 +0800
@@ -1424,26 +1424,28 @@ __releases(&info->lock)
file->private_data = info;
if (info->fbops->fb_open) {
res = info->fbops->fb_open(info,1);
if (res)
module_put(info->fbops->owner);
}
#ifdef CONFIG_FB_DEFERRED_IO
if (info->fbdefio)
fb_deferred_io_open(info, inode, file);
#endif
out:
mutex_unlock(&info->lock);
- if (res)
+ if (res) {
+ file->private_data = NULL;
put_fb_info(info);
+ }
return res;
}
static int
fb_release(struct inode *inode, struct file *file)
__acquires(&info->lock)
__releases(&info->lock)
{
struct fb_info * const info = file->private_data;
mutex_lock(&info->lock);
if (info->fbops->fb_release)
^ permalink raw reply
* [PATCH] [resend] video: s3c-fb: fix misleading kfree in remove function
From: Jingoo Han @ 2011-06-09 4:26 UTC (permalink / raw)
To: linux-fbdev
This patch fixes misleading kfree in remove function.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..148e19d 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1487,11 +1487,10 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
- kfree(sfb);
-
pm_runtime_put_sync(sfb->dev);
pm_runtime_disable(sfb->dev);
+ kfree(sfb);
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH] [resend] video: s3c-fb: fix virtual resolution checking
From: Jingoo Han @ 2011-06-09 4:26 UTC (permalink / raw)
To: linux-fbdev
This patch fixes mishandling in virtual resolution checking.
Previously, virtual resolution is changed to virtual_x and virtual_y
which mean the size for buffer allocation, when s3c_fb_check_var is
called by fb_check_var. However, it is meaningless, since virtual_x
and virtual_y are fixed and user cannot change virtual resolution.
Therefore, virtual resolution should be more than resolution
such as xres and yres.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..e48129a 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -235,13 +235,12 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct s3c_fb_win *win = info->par;
- struct s3c_fb_pd_win *windata = win->windata;
struct s3c_fb *sfb = win->parent;
dev_dbg(sfb->dev, "checking parameters\n");
- var->xres_virtual = max((unsigned int)windata->virtual_x, var->xres);
- var->yres_virtual = max((unsigned int)windata->virtual_y, var->yres);
+ var->xres_virtual = max(var->xres_virtual, var->xres);
+ var->yres_virtual = max(var->yres_virtual, var->yres);
if (!s3c_fb_validate_win_bpp(win, var->bits_per_pixel)) {
dev_dbg(sfb->dev, "win %d: unsupported bpp %d\n",
--
1.7.1
^ permalink raw reply related
* [PATCH] [resend] video: s3c-fb: move enabling channel for window
From: Jingoo Han @ 2011-06-09 4:26 UTC (permalink / raw)
To: linux-fbdev
This patch moves enabling channel for window, because there should
be enabling channel before enabling window. If the sequence is
reversed, it makes the problem in displaying images to lcd panel.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..4f1bc39 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -558,6 +558,13 @@ static int s3c_fb_set_par(struct fb_info *info)
vidosd_set_alpha(win, alpha);
vidosd_set_size(win, data);
+ /* Enable DMA channel for this window */
+ if (sfb->variant.has_shadowcon) {
+ data = readl(sfb->regs + SHADOWCON);
+ data |= SHADOWCON_CHx_ENABLE(win_no);
+ writel(data, sfb->regs + SHADOWCON);
+ }
+
data = WINCONx_ENWIN;
/* note, since we have to round up the bits-per-pixel, we end up
@@ -637,13 +644,6 @@ static int s3c_fb_set_par(struct fb_info *info)
writel(data, regs + sfb->variant.wincon + (win_no * 4));
writel(0x0, regs + sfb->variant.winmap + (win_no * 4));
- /* Enable DMA channel for this window */
- if (sfb->variant.has_shadowcon) {
- data = readl(sfb->regs + SHADOWCON);
- data |= SHADOWCON_CHx_ENABLE(win_no);
- writel(data, sfb->regs + SHADOWCON);
- }
-
shadow_protect_win(win, 0);
return 0;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] fbdev: sh_mobile_lcdc: reduce scope of a variable
From: Kuninori Morimoto @ 2011-06-09 4:28 UTC (permalink / raw)
To: linux-fbdev
Dear Paul, Guennadi
I cannot compile on current paul/master.
below patch seems breaks compile.
"ret" is still needed.
Can you revert it or apply attached patch ?
At Thu, 05 May 2011 18:32:36 +0200 (CEST),
Guennadi wrote:
>
> The "ret" variable in sh_mobile_lcdc_start() is only used at one
> location, move its definition to the inner-most scope.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> drivers/video/sh_mobile_lcdcfb.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 9bcc61b..466834c 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -469,7 +469,6 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
> int bpp = 0;
> unsigned long ldddsr;
> int k, m;
> - int ret = 0;
>
> /* enable clocks before accessing the hardware */
> for (k = 0; k < ARRAY_SIZE(priv->ch); k++) {
> @@ -538,11 +537,12 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
> lcdc_write_chan(ch, LDPMR, 0);
>
> board_cfg = &ch->cfg.board_cfg;
> - if (board_cfg->setup_sys)
> - ret = board_cfg->setup_sys(board_cfg->board_data, ch,
> - &sh_mobile_lcdc_sys_bus_ops);
> - if (ret)
> - return ret;
> + if (board_cfg->setup_sys) {
> + int ret = board_cfg->setup_sys(board_cfg->board_data,
> + ch, &sh_mobile_lcdc_sys_bus_ops);
> + if (ret)
> + return ret;
> + }
> }
>
> /* word and long word swap */
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---
drivers/video/sh_mobile_lcdcfb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 404c03b..d0a03ef 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -617,6 +617,7 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
unsigned long icb_addr_y, icb_addr_c;
int icb_pitch;
int pf;
+ int ret;
cfg = ch->cfg.meram_cfg;
mdev = priv->meram_dev;
--
Best regards
--
Kuninori Morimoto
^ permalink raw reply related
* Re: [PATCH] fbdev: sh_mobile_lcdc: reduce scope of a variable
From: Magnus Damm @ 2011-06-09 4:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <Pine.LNX.4.64.1105051831270.29735@axis700.grange>
Hi Morimoto-san,
This is already fixed in linux-2.6 git by:
commit 554cc1028603587e28ae49e9594b1508df5f29aa
Author: Paul Mundt <lethal@linux-sh.org>
Date: Thu May 26 15:01:22 2011 +0900
fbdev: sh_mobile_lcdcfb: Fix up fallout from MERAM changes.
/ magnus
On Thu, Jun 9, 2011 at 1:28 PM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
> Dear Paul, Guennadi
>
> I cannot compile on current paul/master.
> below patch seems breaks compile.
> "ret" is still needed.
>
> Can you revert it or apply attached patch ?
>
> At Thu, 05 May 2011 18:32:36 +0200 (CEST),
> Guennadi wrote:
>>
>> The "ret" variable in sh_mobile_lcdc_start() is only used at one
>> location, move its definition to the inner-most scope.
>>
>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> ---
>> drivers/video/sh_mobile_lcdcfb.c | 12 ++++++------
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
>> index 9bcc61b..466834c 100644
>> --- a/drivers/video/sh_mobile_lcdcfb.c
>> +++ b/drivers/video/sh_mobile_lcdcfb.c
>> @@ -469,7 +469,6 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
>> int bpp = 0;
>> unsigned long ldddsr;
>> int k, m;
>> - int ret = 0;
>>
>> /* enable clocks before accessing the hardware */
>> for (k = 0; k < ARRAY_SIZE(priv->ch); k++) {
>> @@ -538,11 +537,12 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
>> lcdc_write_chan(ch, LDPMR, 0);
>>
>> board_cfg = &ch->cfg.board_cfg;
>> - if (board_cfg->setup_sys)
>> - ret = board_cfg->setup_sys(board_cfg->board_data, ch,
>> - &sh_mobile_lcdc_sys_bus_ops);
>> - if (ret)
>> - return ret;
>> + if (board_cfg->setup_sys) {
>> + int ret = board_cfg->setup_sys(board_cfg->board_data,
>> + ch, &sh_mobile_lcdc_sys_bus_ops);
>> + if (ret)
>> + return ret;
>> + }
>> }
>>
>> /* word and long word swap */
>> --
>> 1.7.2.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> ---
> drivers/video/sh_mobile_lcdcfb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 404c03b..d0a03ef 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -617,6 +617,7 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
> unsigned long icb_addr_y, icb_addr_c;
> int icb_pitch;
> int pf;
> + int ret;
>
> cfg = ch->cfg.meram_cfg;
> mdev = priv->meram_dev;
> --
>
>
>
> Best regards
> --
> Kuninori Morimoto
>
>
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdc: reduce scope of a variable
From: Kuninori Morimoto @ 2011-06-09 5:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <Pine.LNX.4.64.1105051831270.29735@axis700.grange>
Hi Magnus
Thank you !!
> Hi Morimoto-san,
>
> This is already fixed in linux-2.6 git by:
>
> commit 554cc1028603587e28ae49e9594b1508df5f29aa
> Author: Paul Mundt <lethal@linux-sh.org>
> Date: Thu May 26 15:01:22 2011 +0900
>
> fbdev: sh_mobile_lcdcfb: Fix up fallout from MERAM changes.
>
> / magnus
>
> On Thu, Jun 9, 2011 at 1:28 PM, Kuninori Morimoto
> <kuninori.morimoto.gx@renesas.com> wrote:
> >
> > Dear Paul, Guennadi
> >
> > I cannot compile on current paul/master.
> > below patch seems breaks compile.
> > "ret" is still needed.
> >
> > Can you revert it or apply attached patch ?
> >
> > At Thu, 05 May 2011 18:32:36 +0200 (CEST),
> > Guennadi wrote:
> >>
> >> The "ret" variable in sh_mobile_lcdc_start() is only used at one
> >> location, move its definition to the inner-most scope.
> >>
> >> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >> ---
> >> drivers/video/sh_mobile_lcdcfb.c | 12 ++++++------
> >> 1 files changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> >> index 9bcc61b..466834c 100644
> >> --- a/drivers/video/sh_mobile_lcdcfb.c
> >> +++ b/drivers/video/sh_mobile_lcdcfb.c
> >> @@ -469,7 +469,6 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
> >> int bpp = 0;
> >> unsigned long ldddsr;
> >> int k, m;
> >> - int ret = 0;
> >>
> >> /* enable clocks before accessing the hardware */
> >> for (k = 0; k < ARRAY_SIZE(priv->ch); k++) {
> >> @@ -538,11 +537,12 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
> >> lcdc_write_chan(ch, LDPMR, 0);
> >>
> >> board_cfg = &ch->cfg.board_cfg;
> >> - if (board_cfg->setup_sys)
> >> - ret = board_cfg->setup_sys(board_cfg->board_data, ch,
> >> - &sh_mobile_lcdc_sys_bus_ops);
> >> - if (ret)
> >> - return ret;
> >> + if (board_cfg->setup_sys) {
> >> + int ret = board_cfg->setup_sys(board_cfg->board_data,
> >> + ch, &sh_mobile_lcdc_sys_bus_ops);
> >> + if (ret)
> >> + return ret;
> >> + }
> >> }
> >>
> >> /* word and long word swap */
> >> --
> >> 1.7.2.5
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > ---
> > drivers/video/sh_mobile_lcdcfb.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> > index 404c03b..d0a03ef 100644
> > --- a/drivers/video/sh_mobile_lcdcfb.c
> > +++ b/drivers/video/sh_mobile_lcdcfb.c
> > @@ -617,6 +617,7 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
> > unsigned long icb_addr_y, icb_addr_c;
> > int icb_pitch;
> > int pf;
> > + int ret;
> >
> > cfg = ch->cfg.meram_cfg;
> > mdev = priv->meram_dev;
> > --
> >
> >
> >
> > Best regards
> > --
> > Kuninori Morimoto
> >
> >
Best regards
--
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH] [resend] video: s3c-fb: fix misleading kfree in remove function
From: Paul Mundt @ 2011-06-09 6:04 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1307593591-4507-1-git-send-email-jg1.han@samsung.com>
On Thu, Jun 09, 2011 at 01:26:31PM +0900, Jingoo Han wrote:
> This patch fixes misleading kfree in remove function.
On Thu, Jun 09, 2011 at 01:26:38PM +0900, Jingoo Han wrote:
> This patch fixes mishandling in virtual resolution checking.
> Previously, virtual resolution is changed to virtual_x and virtual_y
> which mean the size for buffer allocation, when s3c_fb_check_var is
> called by fb_check_var. However, it is meaningless, since virtual_x
> and virtual_y are fixed and user cannot change virtual resolution.
> Therefore, virtual resolution should be more than resolution
> such as xres and yres.
On Thu, Jun 09, 2011 at 01:26:45PM +0900, Jingoo Han wrote:
> This patch moves enabling channel for window, because there should
> be enabling channel before enabling window. If the sequence is
> reversed, it makes the problem in displaying images to lcd panel.
All applied, thanks.
^ permalink raw reply
* Re: [RFC] fbmem: reset file->private_data on failed fb_open()
From: Bruno Prémont @ 2011-06-09 6:10 UTC (permalink / raw)
To: Wu Fengguang; +Cc: Antonino A. Daplas, Andrew Morton, linux-fbdev, LKML
In-Reply-To: <20110609030628.GA10233@localhost>
On Thu, 9 Jun 2011 11:06:28 Wu Fengguang <fengguang.wu@intel.com> wrote:
> I wrote this when looking at NULL dereference bug
> https://bugzilla.kernel.org/show_bug.cgi?id\x18912
The trace over there rather looks like closing of a framebuffer that
has been replaced (and destroyed) during boot sequence.
This action happens when switching from VESA to KMS from initrd
or early userspace boot sequence where plymouthd had already opened
vesafb.
That should hopefully be fixed by refcounting FBs as done during
2.6.39-rc7.
> Will it help by clearing private_data? I have no idea at all, because
> for regular files, ->release won't be called on failed ->open. Just in
> case there are some exceptions in fbmem...
fb devices files should be just as regular as any other device files...
> ---
> drivers/video/fbmem.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- linux-next.orig/drivers/video/fbmem.c 2011-06-09 10:36:06.000000000 +0800
> +++ linux-next/drivers/video/fbmem.c 2011-06-09 10:39:30.000000000 +0800
> @@ -1424,26 +1424,28 @@ __releases(&info->lock)
> file->private_data = info;
> if (info->fbops->fb_open) {
> res = info->fbops->fb_open(info,1);
> if (res)
> module_put(info->fbops->owner);
> }
> #ifdef CONFIG_FB_DEFERRED_IO
> if (info->fbdefio)
> fb_deferred_io_open(info, inode, file);
> #endif
> out:
> mutex_unlock(&info->lock);
> - if (res)
> + if (res) {
> + file->private_data = NULL;
> put_fb_info(info);
> + }
> return res;
> }
>
> static int
> fb_release(struct inode *inode, struct file *file)
> __acquires(&info->lock)
> __releases(&info->lock)
> {
> struct fb_info * const info = file->private_data;
>
> mutex_lock(&info->lock);
> if (info->fbops->fb_release)
^ permalink raw reply
* Re: [RFC] fbmem: reset file->private_data on failed fb_open()
From: Wu Fengguang @ 2011-06-09 6:38 UTC (permalink / raw)
To: Bruno Prémont
Cc: Antonino A. Daplas, Andrew Morton, linux-fbdev@vger.kernel.org,
LKML, thomas.creutz
In-Reply-To: <20110609081019.145ed6d5@pluto.restena.lu>
[Add CC to Thomas Creutz]
On Thu, Jun 09, 2011 at 02:10:19PM +0800, Bruno Prémont wrote:
> On Thu, 9 Jun 2011 11:06:28 Wu Fengguang <fengguang.wu@intel.com> wrote:
> > I wrote this when looking at NULL dereference bug
> > https://bugzilla.kernel.org/show_bug.cgi?id\x18912
>
> The trace over there rather looks like closing of a framebuffer that
> has been replaced (and destroyed) during boot sequence.
> This action happens when switching from VESA to KMS from initrd
> or early userspace boot sequence where plymouthd had already opened
> vesafb.
>
> That should hopefully be fixed by refcounting FBs as done during
> 2.6.39-rc7.
That's great! Then hopefully the bug can be closed?
> > Will it help by clearing private_data? I have no idea at all, because
> > for regular files, ->release won't be called on failed ->open. Just in
> > case there are some exceptions in fbmem...
>
> fb devices files should be just as regular as any other device files...
Good, thanks for the confirmation.
Thanks,
Fengguang
> > ---
> > drivers/video/fbmem.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > --- linux-next.orig/drivers/video/fbmem.c 2011-06-09 10:36:06.000000000 +0800
> > +++ linux-next/drivers/video/fbmem.c 2011-06-09 10:39:30.000000000 +0800
> > @@ -1424,26 +1424,28 @@ __releases(&info->lock)
> > file->private_data = info;
> > if (info->fbops->fb_open) {
> > res = info->fbops->fb_open(info,1);
> > if (res)
> > module_put(info->fbops->owner);
> > }
> > #ifdef CONFIG_FB_DEFERRED_IO
> > if (info->fbdefio)
> > fb_deferred_io_open(info, inode, file);
> > #endif
> > out:
> > mutex_unlock(&info->lock);
> > - if (res)
> > + if (res) {
> > + file->private_data = NULL;
> > put_fb_info(info);
> > + }
> > return res;
> > }
> >
> > static int
> > fb_release(struct inode *inode, struct file *file)
> > __acquires(&info->lock)
> > __releases(&info->lock)
> > {
> > struct fb_info * const info = file->private_data;
> >
> > mutex_lock(&info->lock);
> > if (info->fbops->fb_release)
^ permalink raw reply
* [PATCHv2 00/28] OMAP DSS runtime PM adaptation
From: Tomi Valkeinen @ 2011-06-09 13:56 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: b-cousson, paul, khilman, Tomi Valkeinen
Hi,
This patch set implements runtime PM adaptation for OMAP DSS driver.
This is second version of the set, changing the way pm_runtime is used. In this
version the omapdss' pm_runtime adaptation is written as it should be, using
pm_runtime callbacks, in which context save/restore and opt-clock
enables/disables are made.
This required changes (hacks?) to OMAP4 hwmod database, but it is meant to be
fixed when the hwmod fmwk is improved to handle the DSS clocks properly.
However, when that fix is done, omapdss driver won't need any changes.
The bulk of the code is in the "OMAP: DSS2: Use PM runtime & HWMOD support"
patch, which is a bit too large for comfort, but I haven't found out ways to
split it up.
All DSS HW modules now handle enabling and disabling of the HW block
independently via pm_runtime calls. Some DSS modules also require other DSS
modules, and for that we have functions like dispc_runtime_get/put() which can
be used to enable that module.
Previously DSS driver did reset the HW every time before taking it into use.
This can no longer be done, as HWMOD framework handles the reset. While the
driver works without resetting the HW, an error could render the HW inoperable
and currently the driver may not be able to recover. So these patches may make
the driver more unreliable on error cases.
If a way to reset the HWMOD is added to the HWMOD framework, DSS driver can
take it into use and the above mentioned problem should go away.
Tested on OMAP4 Blaze, OMAP3 Overo, OMAP2420 N800. (However, N800 needs extra
patches to get it and DSS2 running, can be found from n800 branch in my tree).
The patch set still contains "OMAP: change get_context_loss_count ret value to
int" for completeness, but the patch should go through Paul Walmsley.
These patches can be found from:
git://gitorious.org/linux-omap-dss2/linux.git pmruntime
Changes in v2:
* Add a HWMOD patch "OMAP4: HWMOD: change DSS main_clk scheme", which allows us
to use pm_runtime as it should.
* Modify "OMAP: DSS2: Use PM runtime & HWMOD support" to use pm_runtime as it
should.
Tomi
Tomi Valkeinen (28):
OMAP: change get_context_loss_count ret value to int
OMAP: DSS2: Taal: Make driver more fault tolerant
OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after use
OMAP: DSS2: Handle dpll4_m4_ck in dss_get/put_clocks
OMAP: DSS2: Clean up probe for DSS & DSI
OMAP: DSS2: Init dispc first before other components
OMAP: DSS2: Remove clk optimization at dss init
OMAP: DSS2: rewrite use of context_loss_count
OMAP: DSS2: Use omap_pm_get_dev_context_loss_count to get ctx loss
count
OMAP: DSS2: DPI: remove unneeded SYSCK enable/disable
OMAP: DSS2: Add FEAT_VENC_REQUIRES_TV_DAC_CLK
OMAP: DSS2: Add new FEAT definitions for features missing from OMAP2
OMAP: DSS2: Remove core_dump_clocks
OMAP: DSS2: Remove CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET
OMAP4: HWMOD: Modify DSS opt clocks
OMAP3: HWMOD: Add DSS opt clocks
OMAP2420: HWMOD: Add DSS opt clocks
OMAP2430: HWMOD: Add DSS opt clocks
OMAP4: HWMOD: change DSS main_clk scheme
OMAP: DSS2: Use PM runtime & HWMOD support
OMAP4: HWMOD: Remove unneeded DSS opt clocks
OMAP: DSS2: Remove unused opt_clock_available
OMAP: DSS2: DISPC: remove finegrained clk enables/disables
OMAP: DSS2: Remove unused code from display.c
OMAP: DSS2: Remove ctx loss count from dss.c
OMAP4: CLKDEV: Remove omapdss clock aliases
OMAP: DSS2: DISPC: Fix context save/restore
OMAP: DSS2: DSS: Fix context save/restore
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
arch/arm/mach-omap2/display.c | 26 +-
arch/arm/mach-omap2/omap_hwmod.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 37 ++-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 71 +++-
arch/arm/mach-omap2/powerdomain.c | 14 +-
arch/arm/mach-omap2/powerdomain.h | 2 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 4 +-
arch/arm/plat-omap/include/plat/omap_device.h | 2 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
arch/arm/plat-omap/omap-pm-noop.c | 24 +-
arch/arm/plat-omap/omap_device.c | 2 +-
drivers/video/omap2/displays/panel-taal.c | 33 +-
drivers/video/omap2/dss/Kconfig | 12 -
drivers/video/omap2/dss/core.c | 15 +-
drivers/video/omap2/dss/dispc.c | 483 +++++++++++----------
drivers/video/omap2/dss/dpi.c | 73 ++--
drivers/video/omap2/dss/dsi.c | 262 +++++++-----
drivers/video/omap2/dss/dss.c | 583 ++++++-------------------
drivers/video/omap2/dss/dss.h | 34 +-
drivers/video/omap2/dss/dss_features.c | 13 +-
drivers/video/omap2/dss/dss_features.h | 4 +
drivers/video/omap2/dss/hdmi.c | 161 +++++--
drivers/video/omap2/dss/manager.c | 8 +-
drivers/video/omap2/dss/overlay.c | 27 +-
drivers/video/omap2/dss/rfbi.c | 110 ++++-
drivers/video/omap2/dss/sdi.c | 40 ++-
drivers/video/omap2/dss/venc.c | 163 ++++++-
include/video/omapdss.h | 4 +-
31 files changed, 1214 insertions(+), 1045 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCHv2 01/28] OMAP: change get_context_loss_count ret value to int
From: Tomi Valkeinen @ 2011-06-09 13:56 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: b-cousson, paul, khilman, Tomi Valkeinen
In-Reply-To: <1307627810-3768-1-git-send-email-tomi.valkeinen@ti.com>
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>
---
arch/arm/mach-omap2/omap_hwmod.c | 2 +-
arch/arm/mach-omap2/powerdomain.c | 14 ++++++++++----
arch/arm/mach-omap2/powerdomain.h | 2 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 4 ++--
arch/arm/plat-omap/include/plat/omap_device.h | 2 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
arch/arm/plat-omap/omap-pm-noop.c | 24 +++++++++++++++++-------
arch/arm/plat-omap/omap_device.c | 2 +-
8 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..4f0d554 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2332,7 +2332,7 @@ ohsps_unlock:
* Returns the context loss count of the powerdomain assocated with @oh
* upon success, or zero if no powerdomain exists for @oh.
*/
-u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
+int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
{
struct powerdomain *pwrdm;
int ret = 0;
diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
index 9af0847..9d53a34 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -935,16 +935,16 @@ int pwrdm_post_transition(void)
* @pwrdm: struct powerdomain * to wait for
*
* Context loss count is the sum of powerdomain off-mode counter, the
- * logic off counter and the per-bank memory off counter. Returns 0
+ * logic off counter and the per-bank memory off counter. Returns negative
* (and WARNs) upon error, otherwise, returns the context loss count.
*/
-u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
{
int i, count;
if (!pwrdm) {
WARN(1, "powerdomain: %s: pwrdm is null\n", __func__);
- return 0;
+ return -ENODEV;
}
count = pwrdm->state_counter[PWRDM_POWER_OFF];
@@ -953,7 +953,13 @@ u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
for (i = 0; i < pwrdm->banks; i++)
count += pwrdm->ret_mem_off_counter[i];
- pr_debug("powerdomain: %s: context loss count = %u\n",
+ /*
+ * Context loss count has to be a non-negative value. Clear the sign
+ * bit to get a value range from 0 to INT_MAX.
+ */
+ count &= INT_MAX;
+
+ pr_debug("powerdomain: %s: context loss count = %d\n",
pwrdm->name, count);
return count;
diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
index d23d979..012827f 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -207,7 +207,7 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
int pwrdm_pre_transition(void);
int pwrdm_post_transition(void);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
-u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
extern void omap2xxx_powerdomains_init(void);
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-omap/include/plat/omap-pm.h
index c0a7520..68df031 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -350,9 +350,9 @@ unsigned long omap_pm_cpu_get_freq(void);
* driver must restore device context. If the number of context losses
* exceeds the maximum positive integer, the function will wrap to 0 and
* continue counting. Returns the number of context losses for this device,
- * or zero upon error.
+ * or negative value upon error.
*/
-u32 omap_pm_get_dev_context_loss_count(struct device *dev);
+int omap_pm_get_dev_context_loss_count(struct device *dev);
void omap_pm_enable_off_mode(void);
void omap_pm_disable_off_mode(void);
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..70d31d0 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -107,7 +107,7 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od);
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
-u32 omap_device_get_context_loss_count(struct platform_device *pdev);
+int omap_device_get_context_loss_count(struct platform_device *pdev);
/* Other */
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..8658e2d 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -598,7 +598,7 @@ int omap_hwmod_for_each_by_class(const char *classname,
void *user);
int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state);
-u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
+int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-pm-noop.c
index b0471bb2..3dc3801 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -27,7 +27,7 @@
#include <plat/omap_device.h>
static bool off_mode_enabled;
-static u32 dummy_context_loss_counter;
+static int dummy_context_loss_counter;
/*
* Device-driver-originated constraints (via board-*.c files)
@@ -311,22 +311,32 @@ void omap_pm_disable_off_mode(void)
#ifdef CONFIG_ARCH_OMAP2PLUS
-u32 omap_pm_get_dev_context_loss_count(struct device *dev)
+int omap_pm_get_dev_context_loss_count(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
- u32 count;
+ int count;
if (WARN_ON(!dev))
- return 0;
+ return -ENODEV;
if (dev->parent = &omap_device_parent) {
count = omap_device_get_context_loss_count(pdev);
} else {
WARN_ONCE(off_mode_enabled, "omap_pm: using dummy context loss counter; device %s should be converted to omap_device",
dev_name(dev));
- if (off_mode_enabled)
- dummy_context_loss_counter++;
+
count = dummy_context_loss_counter;
+
+ if (off_mode_enabled) {
+ count++;
+ /*
+ * Context loss count has to be a non-negative value.
+ * Clear the sign bit to get a value range from 0 to
+ * INT_MAX.
+ */
+ count &= INT_MAX;
+ dummy_context_loss_counter = count;
+ }
}
pr_debug("OMAP PM: context loss count for dev %s = %d\n",
@@ -337,7 +347,7 @@ u32 omap_pm_get_dev_context_loss_count(struct device *dev)
#else
-u32 omap_pm_get_dev_context_loss_count(struct device *dev)
+int omap_pm_get_dev_context_loss_count(struct device *dev)
{
return dummy_context_loss_counter;
}
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 9bbda9a..9753f71 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -310,7 +310,7 @@ static void _add_optional_clock_clkdev(struct omap_device *od,
* return the context loss counter for that hwmod, otherwise return
* zero.
*/
-u32 omap_device_get_context_loss_count(struct platform_device *pdev)
+int omap_device_get_context_loss_count(struct platform_device *pdev)
{
struct omap_device *od;
u32 ret = 0;
--
1.7.4.1
^ permalink raw reply related
* [PATCHv2 02/28] OMAP: DSS2: Taal: Make driver more fault tolerant
From: Tomi Valkeinen @ 2011-06-09 13:56 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: b-cousson, paul, khilman, Tomi Valkeinen
In-Reply-To: <1307627810-3768-1-git-send-email-tomi.valkeinen@ti.com>
If ULPS exit fails, and the following reset fails also, Taal driver was
left in state where it thinks DSI is enabled while it really isn't,
leading to crash.
This patch checks the return value of taal_panel_reset, and if that
fails, ulps_enabled is left true, causing the driver to retry ulps exit
later.
Also the return value of taal_wake_up is checked at taal_disable, and if
wake up fails, we'll skip the power_off. This could leave the panel into
a not-quite-valid state, but there's nothing we can do about it in that
situation.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays/panel-taal.c | 33 ++++++++++++++++++----------
1 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index fdd5d4ae..b82bcc1 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -504,14 +504,18 @@ static int taal_exit_ulps(struct omap_dss_device *dssdev)
return 0;
r = omapdss_dsi_display_enable(dssdev);
- if (r)
- goto err;
+ if (r) {
+ dev_err(&dssdev->dev, "failed to enable DSI\n");
+ goto err1;
+ }
omapdss_dsi_vc_enable_hs(dssdev, td->channel, true);
r = _taal_enable_te(dssdev, true);
- if (r)
- goto err;
+ if (r) {
+ dev_err(&dssdev->dev, "failed to re-enable TE");
+ goto err2;
+ }
enable_irq(gpio_to_irq(panel_data->ext_te_gpio));
@@ -521,13 +525,15 @@ static int taal_exit_ulps(struct omap_dss_device *dssdev)
return 0;
-err:
- dev_err(&dssdev->dev, "exit ULPS failed");
- r = taal_panel_reset(dssdev);
-
- enable_irq(gpio_to_irq(panel_data->ext_te_gpio));
- td->ulps_enabled = false;
+err2:
+ dev_err(&dssdev->dev, "failed to exit ULPS");
+ r = taal_panel_reset(dssdev);
+ if (!r) {
+ enable_irq(gpio_to_irq(panel_data->ext_te_gpio));
+ td->ulps_enabled = false;
+ }
+err1:
taal_queue_ulps_work(dssdev);
return r;
@@ -1317,8 +1323,11 @@ static void taal_disable(struct omap_dss_device *dssdev)
dsi_bus_lock(dssdev);
if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
- taal_wake_up(dssdev);
- taal_power_off(dssdev);
+ int r;
+
+ r = taal_wake_up(dssdev);
+ if (!r)
+ taal_power_off(dssdev);
}
dsi_bus_unlock(dssdev);
--
1.7.4.1
^ permalink raw reply related
* [PATCHv2 03/28] OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after use
From: Tomi Valkeinen @ 2011-06-09 13:56 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: b-cousson, paul, khilman, Tomi Valkeinen
In-Reply-To: <1307627810-3768-1-git-send-email-tomi.valkeinen@ti.com>
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);
+
dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_ULPS);
dsi_if_enable(dsidev, false);
--
1.7.4.1
^ permalink raw reply related
* [PATCHv2 04/28] OMAP: DSS2: Handle dpll4_m4_ck in dss_get/put_clocks
From: Tomi Valkeinen @ 2011-06-09 13:56 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: b-cousson, paul, khilman, Tomi Valkeinen
In-Reply-To: <1307627810-3768-1-git-send-email-tomi.valkeinen@ti.com>
Get and put for dpll4_m4_ck was handled in dss_init/dss_exit. Move the
code to dss_get/put_clocks(), which is a better place to handle it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dss.c | 52 ++++++++++++++++++++--------------------
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index d0b3f81..bcd4a07 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -669,7 +669,6 @@ static int dss_init(void)
int r;
u32 rev;
struct resource *dss_mem;
- struct clk *dpll4_m4_ck;
dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
if (!dss_mem) {
@@ -715,26 +714,6 @@ static int dss_init(void)
REG_FLD_MOD(DSS_CONTROL, 1, 3, 3); /* venc clock 4x enable */
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); /* venc clock mode = normal */
#endif
- if (cpu_is_omap34xx()) {
- dpll4_m4_ck = clk_get(NULL, "dpll4_m4_ck");
- if (IS_ERR(dpll4_m4_ck)) {
- DSSERR("Failed to get dpll4_m4_ck\n");
- r = PTR_ERR(dpll4_m4_ck);
- goto fail1;
- }
- } else if (cpu_is_omap44xx()) {
- dpll4_m4_ck = clk_get(NULL, "dpll_per_m5x2_ck");
- if (IS_ERR(dpll4_m4_ck)) {
- DSSERR("Failed to get dpll4_m4_ck\n");
- r = PTR_ERR(dpll4_m4_ck);
- goto fail1;
- }
- } else { /* omap24xx */
- dpll4_m4_ck = NULL;
- }
-
- dss.dpll4_m4_ck = dpll4_m4_ck;
-
dss.dsi_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.dsi_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
dss.dispc_clk_source = OMAP_DSS_CLK_SRC_FCK;
@@ -749,17 +728,12 @@ static int dss_init(void)
return 0;
-fail1:
- iounmap(dss.base);
fail0:
return r;
}
static void dss_exit(void)
{
- if (dss.dpll4_m4_ck)
- clk_put(dss.dpll4_m4_ck);
-
iounmap(dss.base);
}
@@ -845,6 +819,7 @@ static int dss_get_clock(struct clk **clock, const char *clk_name)
static int dss_get_clocks(void)
{
int r;
+ struct clk *dpll4_m4_ck;
struct omap_display_platform_data *pdata = dss.pdev->dev.platform_data;
dss.dss_ick = NULL;
@@ -884,6 +859,27 @@ static int dss_get_clocks(void)
goto err;
}
+ if (cpu_is_omap34xx()) {
+ dpll4_m4_ck = clk_get(NULL, "dpll4_m4_ck");
+ if (IS_ERR(dpll4_m4_ck)) {
+ DSSERR("Failed to get dpll4_m4_ck\n");
+ r = PTR_ERR(dpll4_m4_ck);
+ goto err;
+ }
+ } else if (cpu_is_omap44xx()) {
+ dpll4_m4_ck = clk_get(NULL, "dpll_per_m5x2_ck");
+ if (IS_ERR(dpll4_m4_ck)) {
+ DSSERR("Failed to get dpll_per_m5x2_ck\n");
+ r = PTR_ERR(dpll4_m4_ck);
+ goto err;
+ }
+ } else { /* omap24xx */
+ dpll4_m4_ck = NULL;
+ }
+
+ dss.dpll4_m4_ck = dpll4_m4_ck;
+
+
return 0;
err:
@@ -897,12 +893,16 @@ err:
clk_put(dss.dss_tv_fck);
if (dss.dss_video_fck)
clk_put(dss.dss_video_fck);
+ if (dss.dpll4_m4_ck)
+ clk_put(dss.dpll4_m4_ck);
return r;
}
static void dss_put_clocks(void)
{
+ if (dss.dpll4_m4_ck)
+ clk_put(dss.dpll4_m4_ck);
if (dss.dss_video_fck)
clk_put(dss.dss_video_fck);
if (dss.dss_tv_fck)
--
1.7.4.1
^ permalink raw reply related
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