I dont have a Lauterbach but your argument seems valid. If:    +
device was in retention(CSWR) and the next state was supposed to be
OFF   + the device did not hit off   + by the time the code shown runs
the device is still in CSWR(say like the abe or ducati that would be
expected not to go to ON right away)
Then   + there is something you'd like to know about but no event will
be generated

-evt
On Sun, Jan 29, 2012 at 10:10 AM, eric van tassell [off-list ref] wrote:

I dont have a Lauterbach but your argument seems valid. If:

   + device was in retention(CSWR) and the next state was supposed to be OFF
+ the device did not hit off
+ by the time the code shown runs the device is still in CSWR(say like the abe or ducati that would be expected not to go to ON right away)

Then

there is something you'd like to know about but no event will be generated

-evt

On Sun, Jan 29, 2012 at 4:08 AM, Paul Walmsley [off-list ref] wrote:

quoted

Hi Jean

Quick question on the tracing in _pwrdm_state_switch().

That section of the code reads:

       state = pwrdm_read_pwrst(pwrdm);

...

       case PWRDM_STATE_PREV:
               prev = pwrdm_read_prev_pwrst(pwrdm);
               if (pwrdm->state != prev)
                       pwrdm->state_counter[prev]++;
               if (prev == PWRDM_POWER_RET)
                       _update_logic_membank_counters(pwrdm);
               /*
                * If the power domain did not hit the desired state,
                * generate a trace event with both the desired and hit states
                */
               if (state != prev) {
                       trace_state = (PWRDM_TRACE_STATES_FLAG |
                                      ((state & OMAP_POWERSTATE_MASK) << 8) |
                                      ((prev & OMAP_POWERSTATE_MASK) << 0));
                       trace_power_domain_target(pwrdm->name, trace_state,
                                                 smp_processor_id());
               }

This code is called after returning from WFI.  It appears to compare the
powerdomain's current power state ('state') with the powerdomain's
previous power state ('prev').  But it appears to me that it should
instead compare the powerdomain's intended power state ('pwrdm->state')
with 'prev' ?  The rationale is that the PRCM could have brought that
powerdomain up to a higher power state than 'pwrdm->state' during the
wakeup process.

What do you think?


- Paul
--
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

--
- evt
(Eric van Tassell)
twitter: evt_texelsoft
linked-in: linkedin.com/in/evttxl

--
- evt
(Eric van Tassell)
twitter: evt_texelsoft
linked-in: linkedin.com/in/evttxl
--
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