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 <paul@xxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
- 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
