PM(?) problems on v3.3-rc1 on OMAP3

PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

Hi,

I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
related to PM.

First, when I boot up, the console (via USB serial) is very laggy, it
often takes many seconds until the key pressed appears so it's more or
less unusable.

Second, I compile DSS as modules, and don't load them. Looking at
debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are
increasing. What is making DSS powerdomain switch back and forth?

Third, when I load the DSS modules, I see only ON state increasing for
dss_pwrdm, as it should be. However, I'm getting constant stream of sync
losts from DSS, and the display doesn't basically work at all.

I can see MPU pwrdm going into RET a lot, and if I do "while true; do
echo foo; done", which I presume basically prevents RET for MPU, the
display becomes stable.

This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2
broken?), although this is happening all the time. In this case, as in
Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for
DSS fclk on OPP2. And I'm not aware of any other constraints for DSS
(well, memory throughput, but that should cause fifo underflows).

Is there a way to lock the OPP to the full power OPP?

Is there a way to see the OPP being used?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Govindraj]

On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
> related to PM.
>
> First, when I boot up, the console (via USB serial) is very laggy, it
> often takes many seconds until the key pressed appears so it's more or
> less unusable.

can you try enabling CONFIG_CPU_IDLE ?

>
> Second, I compile DSS as modules, and don't load them. Looking at
> debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are
> increasing. What is making DSS powerdomain switch back and forth?
>
> Third, when I load the DSS modules, I see only ON state increasing for
> dss_pwrdm, as it should be. However, I'm getting constant stream of sync
> losts from DSS, and the display doesn't basically work at all.
>
> I can see MPU pwrdm going into RET a lot, and if I do "while true; do
> echo foo; done", which I presume basically prevents RET for MPU, the
> display becomes stable.
>
> This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2
> broken?), although this is happening all the time. In this case, as in
> Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for
> DSS fclk on OPP2. And I'm not aware of any other constraints for DSS
> (well, memory throughput, but that should cause fifo underflows).
>
> Is there a way to lock the OPP to the full power OPP?
>
> Is there a way to see the OPP being used?
>
>  Tomi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote:
> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi,
> >
> > I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
> > related to PM.
> >
> > First, when I boot up, the console (via USB serial) is very laggy, it
> > often takes many seconds until the key pressed appears so it's more or
> > less unusable.
> 
> can you try enabling CONFIG_CPU_IDLE ?

Enabling CPU_IDLE does remove the problems. I don't know what it's
supposed to do, but it seems to keep the MPU and DSS in ON state all the
time, so the problem disappears.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Govindraj]

On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote:
>> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > Hi,
>> >
>> > I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
>> > related to PM.
>> >
>> > First, when I boot up, the console (via USB serial) is very laggy, it
>> > often takes many seconds until the key pressed appears so it's more or
>> > less unusable.
>>
>> can you try enabling CONFIG_CPU_IDLE ?
>
> Enabling CPU_IDLE does remove the problems. I don't know what it's
> supposed to do, but it seems to keep the MPU and DSS in ON state all the
> time, so the problem disappears.

3.3-rc1 has uart runtime patches merged we have removed uart dependency
for system to enter low powers states and used pm_qos calls,
but pm_qos api's seem do get activated only by enabling  config_cpu_idle.

Question to kevin/Paul,

Shouldn't system be doing wfi if cpu_idle is not enabled ?

since we are mapping omap3_pm_idle to pm_idle thread
system enters low power states even if config_cpu_idle is not enabled.
Is this expected behavior?

--
Thanks,
Govindraj.R

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Jean Pihet]

Govindraj,

On Fri, Jan 20, 2012 at 12:21 PM, Govindraj <govindraj.ti@gmail.com> wrote:
> On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote:
>>> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> > Hi,
>>> >
>>> > I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
>>> > related to PM.
>>> >
>>> > First, when I boot up, the console (via USB serial) is very laggy, it
>>> > often takes many seconds until the key pressed appears so it's more or
>>> > less unusable.
>>>
>>> can you try enabling CONFIG_CPU_IDLE ?
>>
>> Enabling CPU_IDLE does remove the problems. I don't know what it's
>> supposed to do, but it seems to keep the MPU and DSS in ON state all the
>> time, so the problem disappears.
>
> 3.3-rc1 has uart runtime patches merged we have removed uart dependency
> for system to enter low powers states and used pm_qos calls,
> but pm_qos api's seem do get activated only by enabling  config_cpu_idle.
>
> Question to kevin/Paul,
>
> Shouldn't system be doing wfi if cpu_idle is not enabled ?
>
> since we are mapping omap3_pm_idle to pm_idle thread
> system enters low power states even if config_cpu_idle is not enabled.
> Is this expected behavior?
Yes the wfi instruction gets executed in all cases.
However with CPU_IDLE enabled a valid C-state is selected, depending
on the requested PM QoS constraints. Then the MPU and CORE next power
states are programmed accordingly.

Cf. code in arch/arm/mach-omap2/cpuidle34xx.c which is conditionally
compiled on the CPU_IDLE option.

Jean
>
> --
> Thanks,
> Govindraj.R
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Govindraj]

On Fri, Jan 20, 2012 at 6:02 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> Govindraj,
>
> On Fri, Jan 20, 2012 at 12:21 PM, Govindraj <govindraj.ti@gmail.com> wrote:
>> On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote:
>>>> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>> > Hi,
>>>> >
>>>> > I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
>>>> > related to PM.
>>>> >
>>>> > First, when I boot up, the console (via USB serial) is very laggy, it
>>>> > often takes many seconds until the key pressed appears so it's more or
>>>> > less unusable.
>>>>
>>>> can you try enabling CONFIG_CPU_IDLE ?
>>>
>>> Enabling CPU_IDLE does remove the problems. I don't know what it's
>>> supposed to do, but it seems to keep the MPU and DSS in ON state all the
>>> time, so the problem disappears.
>>
>> 3.3-rc1 has uart runtime patches merged we have removed uart dependency
>> for system to enter low powers states and used pm_qos calls,
>> but pm_qos api's seem do get activated only by enabling  config_cpu_idle.
>>
>> Question to kevin/Paul,
>>
>> Shouldn't system be doing wfi if cpu_idle is not enabled ?
>>
>> since we are mapping omap3_pm_idle to pm_idle thread
>> system enters low power states even if config_cpu_idle is not enabled.
>> Is this expected behavior?

> Yes the wfi instruction gets executed in all cases.
> However with CPU_IDLE enabled a valid C-state is selected, depending
> on the requested PM QoS constraints. Then the MPU and CORE next power
> states are programmed accordingly.
>

okay, but if cpuidle is not selected shouldn't it prevent system from going
to low power state.


--
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Paul Walmsley]

On Fri, 20 Jan 2012, Govindraj wrote:

> 3.3-rc1 has uart runtime patches merged we have removed uart dependency
> for system to enter low powers states and used pm_qos calls,
> but pm_qos api's seem do get activated only by enabling  config_cpu_idle.
> 
> Question to kevin/Paul,
> 
> Shouldn't system be doing wfi if cpu_idle is not enabled ?
> 
> since we are mapping omap3_pm_idle to pm_idle thread
> system enters low power states even if config_cpu_idle is not enabled.
> Is this expected behavior?

Yes.


- Paul

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Paul Walmsley]

On Fri, 20 Jan 2012, Tomi Valkeinen wrote:

> On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote:
> > On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > > Hi,
> > >
> > > I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
> > > related to PM.
> > >
> > > First, when I boot up, the console (via USB serial) is very laggy, it
> > > often takes many seconds until the key pressed appears so it's more or
> > > less unusable.
> > 
> > can you try enabling CONFIG_CPU_IDLE ?
> 
> Enabling CPU_IDLE does remove the problems. I don't know what it's
> supposed to do, but it seems to keep the MPU and DSS in ON state all the
> time, so the problem disappears.

Enabling CONFIG_CPU_IDLE doesn't fix it for me.  Maybe that's because 
I'm just using omap2plus_defconfig.


- Paul

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Govindraj]

On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
> related to PM.
>
> First, when I boot up, the console (via USB serial) is very laggy, it
> often takes many seconds until the key pressed appears so it's more or
> less unusable.
>
> Second, I compile DSS as modules, and don't load them. Looking at
> debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are
> increasing. What is making DSS powerdomain switch back and forth?
>
> Third, when I load the DSS modules, I see only ON state increasing for
> dss_pwrdm, as it should be. However, I'm getting constant stream of sync
> losts from DSS, and the display doesn't basically work at all.
>
> I can see MPU pwrdm going into RET a lot, and if I do "while true; do
> echo foo; done", which I presume basically prevents RET for MPU, the
> display becomes stable.
>
> This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2
> broken?), although this is happening all the time. In this case, as in
> Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for
> DSS fclk on OPP2. And I'm not aware of any other constraints for DSS
> (well, memory throughput, but that should cause fifo underflows).
>
> Is there a way to lock the OPP to the full power OPP?
>

btw,

I think enabling cpu_idle and performance governor to should ensure that.

However enabling performance governor boot fails.

failure logs as in here [1]. I was using latest mainline and beagle -XM

--
Thanks,
Govindraj.R

[1]:

http://pastebin.com/9ZfB2V6B

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote:
> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

> > Is there a way to lock the OPP to the full power OPP?
> >
> 
> btw,
> 
> I think enabling cpu_idle and performance governor to should ensure that.
> 
> However enabling performance governor boot fails.

I thought so too, and tried it but got the same crash as you.

However, I'd imagine that if I don't enable CPU idle or the governors,
the board would stay in full power mode always. But this doesn't seem to
be the case.

Then again, I don't see how CPU power management could affect the DSS
directly. So it's probably something like: cpu goes to RET -> something
else is allowed go to lower power state (L3?) -> DSS breaks.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Jean Pihet]

Tomi,

On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote:
>> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> > Is there a way to lock the OPP to the full power OPP?
>> >
>>
>> btw,
>>
>> I think enabling cpu_idle and performance governor to should ensure that.
>>
>> However enabling performance governor boot fails.
>
> I thought so too, and tried it but got the same crash as you.
>
> However, I'd imagine that if I don't enable CPU idle or the governors,
> the board would stay in full power mode always. But this doesn't seem to
> be the case.
>
> Then again, I don't see how CPU power management could affect the DSS
> directly. So it's probably something like: cpu goes to RET -> something
> else is allowed go to lower power state (L3?) -> DSS breaks.
It is probably related to the CORE state. Can you check if CORE goes
to low power mode when CPU_IDLE is enabled?
To prevent the CORE from going into a too-low power mode you need to
request a PM QoS constraint, as Govindraj explained here above.

Hope this helps!

Jean

>
>  Tomi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

On Fri, 2012-01-20 at 13:34 +0100, Jean Pihet wrote:
> Tomi,
> 
> On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote:
> >> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >
> >> > Is there a way to lock the OPP to the full power OPP?
> >> >
> >>
> >> btw,
> >>
> >> I think enabling cpu_idle and performance governor to should ensure that.
> >>
> >> However enabling performance governor boot fails.
> >
> > I thought so too, and tried it but got the same crash as you.
> >
> > However, I'd imagine that if I don't enable CPU idle or the governors,
> > the board would stay in full power mode always. But this doesn't seem to
> > be the case.
> >
> > Then again, I don't see how CPU power management could affect the DSS
> > directly. So it's probably something like: cpu goes to RET -> something
> > else is allowed go to lower power state (L3?) -> DSS breaks.
> It is probably related to the CORE state. Can you check if CORE goes
> to low power mode when CPU_IDLE is enabled?

This is without CPU_IDLE, i.e. when I'm having problems:

# cat /debug/pm_debug/count |grep -i core
core_pwrdm
(ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0

According to that, core is always on.

> To prevent the CORE from going into a too-low power mode you need to
> request a PM QoS constraint, as Govindraj explained here above.

What different power modes there are? With the clock configs I'm using
(small display, low clock rates), both OPP100 and OPP50 should work
fine.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Jean Pihet]

Tomi,

On Fri, Jan 20, 2012 at 1:40 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2012-01-20 at 13:34 +0100, Jean Pihet wrote:
>> Tomi,
>>
>> On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote:
>> >> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> >
>> >> > Is there a way to lock the OPP to the full power OPP?
>> >> >
>> >>
>> >> btw,
>> >>
>> >> I think enabling cpu_idle and performance governor to should ensure that.
>> >>
>> >> However enabling performance governor boot fails.
>> >
>> > I thought so too, and tried it but got the same crash as you.
>> >
>> > However, I'd imagine that if I don't enable CPU idle or the governors,
>> > the board would stay in full power mode always. But this doesn't seem to
>> > be the case.
>> >
>> > Then again, I don't see how CPU power management could affect the DSS
>> > directly. So it's probably something like: cpu goes to RET -> something
>> > else is allowed go to lower power state (L3?) -> DSS breaks.
>> It is probably related to the CORE state. Can you check if CORE goes
>> to low power mode when CPU_IDLE is enabled?
>
> This is without CPU_IDLE, i.e. when I'm having problems:
>
> # cat /debug/pm_debug/count |grep -i core
> core_pwrdm
> (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
>
> According to that, core is always on.
>
>> To prevent the CORE from going into a too-low power mode you need to
>> request a PM QoS constraint, as Govindraj explained here above.
>
> What different power modes there are? With the clock configs I'm using
> (small display, low clock rates), both OPP100 and OPP50 should work
> fine.
CPU_IDLE is not about the OPP (i.e. frequencies), it is about the
power domains states (ON, RET ...).
Without CPU_IDLE enabled the power domains will try to transition to
the default power states (programmed in the PRCM registers). By
default all power states are programmed to RET or OFF.
In all cases CPU_IDLE should be enabled to ensure the proper
interaction between the cpuidle and PM QoS frameworks.

You can try the following in order to isolate the problem:
1. check if the CORE and DSS are hitting a low power state. The MPU
state should not have a direct impact on the DSS; the CORE state has a
direct effect on DSS since it drives the memory controller,
2. use a fixed frequency for the MPU, by enabling the userspace or the
performance cpufreq governor. This should rule out an MPU performance
problem.

>
>  Tomi
>

Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3660 bytes --]

On Fri, 2012-01-20 at 14:36 +0100, Jean Pihet wrote:
> Tomi,
> 
> On Fri, Jan 20, 2012 at 1:40 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Fri, 2012-01-20 at 13:34 +0100, Jean Pihet wrote:
> >> Tomi,
> >>
> >> On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> > On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote:
> >> >> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> >
> >> >> > Is there a way to lock the OPP to the full power OPP?
> >> >> >
> >> >>
> >> >> btw,
> >> >>
> >> >> I think enabling cpu_idle and performance governor to should ensure that.
> >> >>
> >> >> However enabling performance governor boot fails.
> >> >
> >> > I thought so too, and tried it but got the same crash as you.
> >> >
> >> > However, I'd imagine that if I don't enable CPU idle or the governors,
> >> > the board would stay in full power mode always. But this doesn't seem to
> >> > be the case.
> >> >
> >> > Then again, I don't see how CPU power management could affect the DSS
> >> > directly. So it's probably something like: cpu goes to RET -> something
> >> > else is allowed go to lower power state (L3?) -> DSS breaks.
> >> It is probably related to the CORE state. Can you check if CORE goes
> >> to low power mode when CPU_IDLE is enabled?
> >
> > This is without CPU_IDLE, i.e. when I'm having problems:
> >
> > # cat /debug/pm_debug/count |grep -i core
> > core_pwrdm
> > (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
> >
> > According to that, core is always on.
> >
> >> To prevent the CORE from going into a too-low power mode you need to
> >> request a PM QoS constraint, as Govindraj explained here above.
> >
> > What different power modes there are? With the clock configs I'm using
> > (small display, low clock rates), both OPP100 and OPP50 should work
> > fine.
> CPU_IDLE is not about the OPP (i.e. frequencies), it is about the
> power domains states (ON, RET ...).
> Without CPU_IDLE enabled the power domains will try to transition to
> the default power states (programmed in the PRCM registers). By
> default all power states are programmed to RET or OFF.
> In all cases CPU_IDLE should be enabled to ensure the proper
> interaction between the cpuidle and PM QoS frameworks.

Hmm, So CPU_IDLE is also about other power domains than mpu? What does
it do? The CONFIG_CPU_IDLE help text doesn't say much.

And I'm still confused about why it would be needed. If I enable DSS,
that should enable and keep dss powerdomain in ON state, and the
pm/hwmod framework (or something =) should also enable core when DSS is
enabled.

And with low func clock frequencies DSS should operate in all OPPs.

So everything should be in order, with or without CPU_IDLE, right? Or
does core go to sleep even if DSS is enabled? But then again,
pm_debug/count shows that core is always ON.

> You can try the following in order to isolate the problem:
> 1. check if the CORE and DSS are hitting a low power state. The MPU
> state should not have a direct impact on the DSS; the CORE state has a
> direct effect on DSS since it drives the memory controller,

According to pm_debug/count file, core and dss are ON.

> 2. use a fixed frequency for the MPU, by enabling the userspace or the
> performance cpufreq governor. This should rule out an MPU performance
> problem.

Yep. But that'll have to wait until enabling cpufreq doesn't crash the
kernel. But I can't see how MPU could affect DSS, as after DSS is
enabled, the MPU doesn't do anything about it.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Fri, 20 Jan 2012 17:00:09 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com>
wrote:


> Hmm, So CPU_IDLE is also about other power domains than mpu? What does
> it do? The CONFIG_CPU_IDLE help text doesn't say much.

On OMAP3x, CPU_IDLE is about the MPU and CORE power domains .. and about PER
to some extent I think.

Different CPU_IDLE states put one or both of MPU and CORE into lower power
states (RET or OFF).  If a domain is turned off, then the code restores stuff
afterwards.

But CPU_IDLE also does stuff with clocks, and I think this is where the issue
is.

I modified my kernel to refuse any CPU_IDLE state where MPU or CORE were
anything but ON - so only C1 and C2 were allowed.
I still had problems with DSS SYNC.

I then modified the C2 state so that it didn't allow the clocks to
auto-idle.  This is the main difference between C1 and C2 I think.

i.e. in omap3_enter_idle() in cpuidle34xx.c, I enforced the

		pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
		pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);

and 

		pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
		pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);

loops for C1 - they are normally only active for C1.

This allowed DSS to work fine.  It also removed my issues with HDQ.

This code disables the auto-idling of some clocks ... not entirely sure of
the details.

So it seems that it isn't a low power state but rather some clock being
allowed to turn off which is the problem.

I guess I could selective try denying idle on each clock domain until I find
the one that is the problem..

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Sun, 2012-01-22 at 22:11 +1100, NeilBrown wrote:

> This code disables the auto-idling of some clocks ... not entirely sure of
> the details.
> 
> So it seems that it isn't a low power state but rather some clock being
> allowed to turn off which is the problem.
> 
> I guess I could selective try denying idle on each clock domain until I find
> the one that is the problem..

I also did some testing: Normally DISPC's SIDLEMODE is set to smart idle
and MIDLEMODE to smart standby. Changing either of them to no idle or no
standby (respectively) removes the sync lost problem. But I guess that
doesn't tell much, except that the problem is some kind of idle/wakeup
problem.

Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
(with SIDLEMODE/IDLEMODE in smart mode) also removes the problem.

Again, my understanding of OMAP PM is rather limited, but could this be
the problem? Something (core/L3/whatever) goes to idle mode and when DSS
needs to fetch data or requires a clock, and DSS is not able to wake the
other component up?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Paul Walmsley]

On Mon, 23 Jan 2012, Tomi Valkeinen wrote:

> Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
> (with SIDLEMODE/IDLEMODE in smart mode) also removes the problem.

Sounds like you've nailed it.

What is perplexing is that the hwmod code should be setting this by 
default in omap_hwmod.c:_enable_sysc().  I wonder why that is not 
happening.


- Paul

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Mon, 2012-01-23 at 02:04 -0700, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> 
> > Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
> > (with SIDLEMODE/IDLEMODE in smart mode) also removes the problem.
> 
> Sounds like you've nailed it.
> 
> What is perplexing is that the hwmod code should be setting this by 
> default in omap_hwmod.c:_enable_sysc().  I wonder why that is not 
> happening.

It seems the omap2_dispc_sysc is missing SYSC_HAS_ENAWAKEUP. I wonder if
that's a mistake or by purpose...

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Paul Walmsley]

On Mon, 23 Jan 2012, Tomi Valkeinen wrote:

> On Mon, 2012-01-23 at 02:04 -0700, Paul Walmsley wrote:
> > On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> > 
> > > Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
> > > (with SIDLEMODE/IDLEMODE in smart mode) also removes the problem.
> > 
> > Sounds like you've nailed it.
> > 
> > What is perplexing is that the hwmod code should be setting this by 
> > default in omap_hwmod.c:_enable_sysc().  I wonder why that is not 
> > happening.
> 
> It seems the omap2_dispc_sysc is missing SYSC_HAS_ENAWAKEUP. I wonder if
> that's a mistake or by purpose...

That's almost certainly a mistake.  It's documented in the 34xx vZR TRM 
and so far I don't know of any reason for omitting any of those bits.

I just searched my linux-omap folder for the original patch for this.  It 
seems to be

Date: Mon, 3 Jan 2011 18:20:53 +0530
From: Guruswamy Senthilvadivu <svadivu@ti.com>
Subject: [PATCH v3 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC

and it was missing in that patch.  Guess I missed it when I reviewed this 
patch.  Sigh...

Want to spin a quick patch for v3.3-rc1 to add it?


- Paul

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Mon, 2012-01-23 at 02:31 -0700, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> 
> > On Mon, 2012-01-23 at 02:04 -0700, Paul Walmsley wrote:
> > > On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> > > 
> > > > Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
> > > > (with SIDLEMODE/IDLEMODE in smart mode) also removes the problem.
> > > 
> > > Sounds like you've nailed it.
> > > 
> > > What is perplexing is that the hwmod code should be setting this by 
> > > default in omap_hwmod.c:_enable_sysc().  I wonder why that is not 
> > > happening.
> > 
> > It seems the omap2_dispc_sysc is missing SYSC_HAS_ENAWAKEUP. I wonder if
> > that's a mistake or by purpose...
> 
> That's almost certainly a mistake.  It's documented in the 34xx vZR TRM 
> and so far I don't know of any reason for omitting any of those bits.
> 
> I just searched my linux-omap folder for the original patch for this.  It 
> seems to be
> 
> Date: Mon, 3 Jan 2011 18:20:53 +0530
> From: Guruswamy Senthilvadivu <svadivu@ti.com>
> Subject: [PATCH v3 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC
> 
> and it was missing in that patch.  Guess I missed it when I reviewed this 
> patch.  Sigh...
> 
> Want to spin a quick patch for v3.3-rc1 to add it?

I think there are other bits missing also. CLOCKACTIVITY is missing for
DISPC. And DSI doesn't have any SYSC flags defined... I'll try to go
through them all.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Paul Walmsley]

On Mon, 23 Jan 2012, Tomi Valkeinen wrote:

> On Mon, 2012-01-23 at 02:31 -0700, Paul Walmsley wrote:
>
> > Want to spin a quick patch for v3.3-rc1 to add it?
> 
> I think there are other bits missing also. CLOCKACTIVITY is missing for
> DISPC. And DSI doesn't have any SYSC flags defined... I'll try to go
> through them all.

Might be best to do a minimal patch for the 3.3-rc series and stable trees 
that just sets the SYSC_HAS_ENAWAKEUP flag?  Then we can queue up a 
larger patch to fix the rest of the bits for the 3.4 merge window...


- Paul

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Mon, 2012-01-23 at 04:02 -0700, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> 
> > On Mon, 2012-01-23 at 02:31 -0700, Paul Walmsley wrote:
> >
> > > Want to spin a quick patch for v3.3-rc1 to add it?
> > 
> > I think there are other bits missing also. CLOCKACTIVITY is missing for
> > DISPC. And DSI doesn't have any SYSC flags defined... I'll try to go
> > through them all.
> 
> Might be best to do a minimal patch for the 3.3-rc series and stable trees 
> that just sets the SYSC_HAS_ENAWAKEUP flag?  Then we can queue up a 
> larger patch to fix the rest of the bits for the 3.4 merge window...

True. But the patch will be slightly larger than just trivial flag
addition, as OMAP2 doesn't have ENWAKEUP, and the current dispc
hwmod_class is shared between OMAP2 and OMAP3.

So I guess I'll split that and add ENWAKEUP to OMAP3's hwmod data.

And regarding clock activity, it seems a flag HWMOD_SET_DEFAULT_CLOCKACT
is also needed before the clockactivity is set to HW. But there's a XXX
comment above it, and I'm not sure what that's about.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Mon, 2012-01-23 at 02:04 -0700, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> 
> > Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
> > (with SIDLEMODE/IDLEMODE in smart mode) also removes the problem.
> 
> Sounds like you've nailed it.

By the way, there's still something funny with DSS powerdomain. As I
said in the original post:

> Second, I compile DSS as modules, and don't load them. Looking at
> debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are
> increasing. What is making DSS powerdomain switch back and forth?

I can see the above also after I've loaded and then unloaded the DSS
modules.

There seems to be usecount of one for dss_pwrdm (pm_debug/count shows
dss_clkdm->dss_pwrdm (1)) and usecount of 4 for dss_ick.

Any ideas? I remember somebody (Benoit?) saying that the
hwmod/omap_device code keeps ick allocated, but even so I'd presume that
DSS stays in RET is it's not used.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Govindraj]

On Fri, Jan 20, 2012 at 5:31 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote:
>> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> > Is there a way to lock the OPP to the full power OPP?
>> >
>>
>> btw,
>>
>> I think enabling cpu_idle and performance governor to should ensure that.
>>
>> However enabling performance governor boot fails.
>
> I thought so too, and tried it but got the same crash as you.
>
> However, I'd imagine that if I don't enable CPU idle or the governors,
> the board would stay in full power mode always. But this doesn't seem to
> be the case.
>

AFAIK if we are not using cpuidle/governors
then opp value will be retained from what the bootloader configures it.

However I am not sure whether bootloader will set it in highest opp.
Still trying to find a way to know it.

> Then again, I don't see how CPU power management could affect the DSS
> directly. So it's probably something like: cpu goes to RET -> something
> else is allowed go to lower power state (L3?) -> DSS breaks.

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Shubhrajyoti]

On Friday 20 January 2012 05:26 PM, Govindraj wrote:
> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Hi,
>>
>> I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
>> related to PM.
>>
>> First, when I boot up, the console (via USB serial) is very laggy, it
>> often takes many seconds until the key pressed appears so it's more or
>> less unusable.
>>
>> Second, I compile DSS as modules, and don't load them. Looking at
>> debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are
>> increasing. What is making DSS powerdomain switch back and forth?
>>
>> Third, when I load the DSS modules, I see only ON state increasing for
>> dss_pwrdm, as it should be. However, I'm getting constant stream of sync
>> losts from DSS, and the display doesn't basically work at all.
>>
>> I can see MPU pwrdm going into RET a lot, and if I do "while true; do
>> echo foo; done", which I presume basically prevents RET for MPU, the
>> display becomes stable.
>>
>> This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2
>> broken?), although this is happening all the time. In this case, as in
>> Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for
>> DSS fclk on OPP2. And I'm not aware of any other constraints for DSS
>> (well, memory throughput, but that should cause fifo underflows).
>>
>> Is there a way to lock the OPP to the full power OPP?
The other way could be to  use userspace governor and set
it manually.

Also the governor could be changed through sysfs.

> btw,
>
> I think enabling cpu_idle and performance governor to should ensure that.
>
> However enabling performance governor boot fails.
>
> failure logs as in here [1]. I was using latest mainline and beagle -XM
>
> --
> Thanks,
> Govindraj.R
>
> [1]:
>
> http://pastebin.com/9ZfB2V6B
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Paul Walmsley]

On Fri, 20 Jan 2012, Tomi Valkeinen wrote:

> I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably
> related to PM.
> 
> First, when I boot up, the console (via USB serial) is very laggy, it
> often takes many seconds until the key pressed appears so it's more or
> less unusable.

Have noticed that serial is pretty broken also.  Maybe try this series:

http://marc.info/?l=linux-omap&m=132713119729167&w=2
http://marc.info/?l=linux-omap&m=132713119229165&w=2
http://marc.info/?l=linux-omap&m=132713119829168&w=2

which is also available via git from

git://git.pwsan.com/linux-2.6

in the branch "omap_serial_fixes_3.3rc"


- Paul

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Paul Walmsley]

On Fri, 20 Jan 2012, Tomi Valkeinen wrote:

> Third, when I load the DSS modules, I see only ON state increasing for
> dss_pwrdm, as it should be. However, I'm getting constant stream of sync
> losts from DSS, and the display doesn't basically work at all.
> 
> I can see MPU pwrdm going into RET a lot, and if I do "while true; do
> echo foo; done", which I presume basically prevents RET for MPU, the
> display becomes stable.

If this particular problem persists after you apply the patch set that I 
sent earlier, it suggests that something in the DSS is sensitive to the 
amount of time it takes the MPU to wake up and service an interrupt when 
the MPU powerdomain is in a low-power state.  Total guess, but perhaps  
omap_dispc_irq_handler() is getting called after each frame and needs to 
run within a certain bounded time when that happens?


- Paul

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Sat, 2012-01-21 at 00:47 -0700, Paul Walmsley wrote:
> On Fri, 20 Jan 2012, Tomi Valkeinen wrote:
> 
> > Third, when I load the DSS modules, I see only ON state increasing for
> > dss_pwrdm, as it should be. However, I'm getting constant stream of sync
> > losts from DSS, and the display doesn't basically work at all.
> > 
> > I can see MPU pwrdm going into RET a lot, and if I do "while true; do
> > echo foo; done", which I presume basically prevents RET for MPU, the
> > display becomes stable.
> 
> If this particular problem persists after you apply the patch set that I 
> sent earlier, it suggests that something in the DSS is sensitive to the 
> amount of time it takes the MPU to wake up and service an interrupt when 
> the MPU powerdomain is in a low-power state.  Total guess, but perhaps  
> omap_dispc_irq_handler() is getting called after each frame and needs to 
> run within a certain bounded time when that happens?

No. After the DSS has been configured and started (by the MPU), it runs
by itself, reading the pixels from the memory displaying them on the
screen. Only when the user wants to change the configs or the frame, the
MPU does something. And interrupts are only needed to handle the
changing of configs or frame data using VSYNCs as the interval. The user
probably doesn't like it if the VSYNC irq is handled a few seconds
later, but the DSS HW doesn't care, and functions normally.

In this case something is affecting the DSS (clocks? powers?), or the
memory, or the process of reading the pixels. I really don't see the MPU
or IRQs affecting this problem, except indirectly.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On Sat, 21 Jan 2012 17:57:07 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com>
wrote:

> On Sat, 2012-01-21 at 00:47 -0700, Paul Walmsley wrote:
> > On Fri, 20 Jan 2012, Tomi Valkeinen wrote:
> > 
> > > Third, when I load the DSS modules, I see only ON state increasing for
> > > dss_pwrdm, as it should be. However, I'm getting constant stream of sync
> > > losts from DSS, and the display doesn't basically work at all.
> > > 
> > > I can see MPU pwrdm going into RET a lot, and if I do "while true; do
> > > echo foo; done", which I presume basically prevents RET for MPU, the
> > > display becomes stable.
> > 
> > If this particular problem persists after you apply the patch set that I 
> > sent earlier, it suggests that something in the DSS is sensitive to the 
> > amount of time it takes the MPU to wake up and service an interrupt when 
> > the MPU powerdomain is in a low-power state.  Total guess, but perhaps  
> > omap_dispc_irq_handler() is getting called after each frame and needs to 
> > run within a certain bounded time when that happens?
> 
> No. After the DSS has been configured and started (by the MPU), it runs
> by itself, reading the pixels from the memory displaying them on the
> screen. Only when the user wants to change the configs or the frame, the
> MPU does something. And interrupts are only needed to handle the
> changing of configs or frame data using VSYNCs as the interval. The user
> probably doesn't like it if the VSYNC irq is handled a few seconds
> later, but the DSS HW doesn't care, and functions normally.
> 
> In this case something is affecting the DSS (clocks? powers?), or the
> memory, or the process of reading the pixels. I really don't see the MPU
> or IRQs affecting this problem, except indirectly.

Which clocks, exactly, are important?

I collected some clock.c tracing while dss was repeatedly complaining about
losing SYNC, and notice that omap_96m_fck was being enabled and disabled in
hardware.
omap_96m_fck is upstream for dss_96m_fck which provides the tv_dac_clk.

Could it be this clock turning on and off which causes the problem?

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

On Sun, 2012-01-22 at 07:46 +1100, NeilBrown wrote:
> On Sat, 21 Jan 2012 17:57:07 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com>
> wrote:

> > In this case something is affecting the DSS (clocks? powers?), or the
> > memory, or the process of reading the pixels. I really don't see the MPU
> > or IRQs affecting this problem, except indirectly.
> 
> Which clocks, exactly, are important?
> 
> I collected some clock.c tracing while dss was repeatedly complaining about
> losing SYNC, and notice that omap_96m_fck was being enabled and disabled in
> hardware.
> omap_96m_fck is upstream for dss_96m_fck which provides the tv_dac_clk.
> 
> Could it be this clock turning on and off which causes the problem?

I don't think 96m clock is important. At least I'm testing with plain
DPI, not tv-out. And I think missing 96m clock would just lead to a
missing image on the tv, not sync losts.

For OMAP3 DSS when using DPI the following clocks are important:

DPLL4_ALWON_FCLKOUTM4X2 (i.e. DSS1_ALWON_FCLK) (dss func clock)
DSS_L3_ICLK (to fetch pixels)
DSS_L4_ICLK (to configure dss registers)

I don't think any other clocks are used.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Paul Walmsley]

On Sat, 21 Jan 2012, Tomi Valkeinen wrote:

> On Sat, 2012-01-21 at 00:47 -0700, Paul Walmsley wrote:
> > On Fri, 20 Jan 2012, Tomi Valkeinen wrote:
> > 
> > > Third, when I load the DSS modules, I see only ON state increasing for
> > > dss_pwrdm, as it should be. However, I'm getting constant stream of sync
> > > losts from DSS, and the display doesn't basically work at all.
> > > 
> > > I can see MPU pwrdm going into RET a lot, and if I do "while true; do
> > > echo foo; done", which I presume basically prevents RET for MPU, the
> > > display becomes stable.
> > 
> > If this particular problem persists after you apply the patch set that I 
> > sent earlier, it suggests that something in the DSS is sensitive to the 
> > amount of time it takes the MPU to wake up and service an interrupt when 
> > the MPU powerdomain is in a low-power state.  Total guess, but perhaps  
> > omap_dispc_irq_handler() is getting called after each frame and needs to 
> > run within a certain bounded time when that happens?
> 
> No. After the DSS has been configured and started (by the MPU), it runs
> by itself, reading the pixels from the memory displaying them on the
> screen. Only when the user wants to change the configs or the frame, the
> MPU does something. And interrupts are only needed to handle the
> changing of configs or frame data using VSYNCs as the interval. The user
> probably doesn't like it if the VSYNC irq is handled a few seconds
> later, but the DSS HW doesn't care, and functions normally.
> 
> In this case something is affecting the DSS (clocks? powers?), or the
> memory, or the process of reading the pixels. I really don't see the MPU
> or IRQs affecting this problem, except indirectly.

Okay, thanks for the quick response.  

Would you expect to see these "sync lost" messages if the DSS FIFO(s) are 
underflowing?  Or would that return a different error?  Am wondering if 
CORE may be entering some low power state, so DSS FIFO refill may be 
taking too long.


- Paul

Re: PM(?) problems on v3.3-rc1 on OMAP3

[Valkeinen, Tomi]

On Sat, Jan 21, 2012 at 10:47 PM, Paul Walmsley <paul@pwsan.com> wrote:
> On Sat, 21 Jan 2012, Tomi Valkeinen wrote:
>
>> On Sat, 2012-01-21 at 00:47 -0700, Paul Walmsley wrote:
>> > On Fri, 20 Jan 2012, Tomi Valkeinen wrote:
>> >
>> > > Third, when I load the DSS modules, I see only ON state increasing for
>> > > dss_pwrdm, as it should be. However, I'm getting constant stream of sync
>> > > losts from DSS, and the display doesn't basically work at all.
>> > >
>> > > I can see MPU pwrdm going into RET a lot, and if I do "while true; do
>> > > echo foo; done", which I presume basically prevents RET for MPU, the
>> > > display becomes stable.
>> >
>> > If this particular problem persists after you apply the patch set that I
>> > sent earlier, it suggests that something in the DSS is sensitive to the
>> > amount of time it takes the MPU to wake up and service an interrupt when
>> > the MPU powerdomain is in a low-power state.  Total guess, but perhaps
>> > omap_dispc_irq_handler() is getting called after each frame and needs to
>> > run within a certain bounded time when that happens?
>>
>> No. After the DSS has been configured and started (by the MPU), it runs
>> by itself, reading the pixels from the memory displaying them on the
>> screen. Only when the user wants to change the configs or the frame, the
>> MPU does something. And interrupts are only needed to handle the
>> changing of configs or frame data using VSYNCs as the interval. The user
>> probably doesn't like it if the VSYNC irq is handled a few seconds
>> later, but the DSS HW doesn't care, and functions normally.
>>
>> In this case something is affecting the DSS (clocks? powers?), or the
>> memory, or the process of reading the pixels. I really don't see the MPU
>> or IRQs affecting this problem, except indirectly.
>
> Okay, thanks for the quick response.
>
> Would you expect to see these "sync lost" messages if the DSS FIFO(s) are
> underflowing?  Or would that return a different error?  Am wondering if
> CORE may be entering some low power state, so DSS FIFO refill may be
> taking too long.

I would expect to see FIFO_UNDERFLOW errors. Then again, I have to
admit I'm not totally sure what SYNC LOST error means. My
understanding is that it's about DSS internal timings and fifos, for
example when DSS is scaling the image and if the scaler cannot get
pixels fast enough from the preceding HW block.

 Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html