On Fri, Jul 6, 2012 at 6:09 PM, Tony Lindgren <t...@atomide.com> wrote:
> * Munegowda, Keshava <keshava_mgo...@ti.com> [120706 05:30]:
>> On Fri, Jul 6, 2012 at 5:37 PM, Tony Lindgren <t...@atomide.com> wrote:
>> >
>> > I think it's best to fix things properly, even if it means that it will
>> > take longer and go into next kernel version.
>>
>> This requires ehci remote wakeup feature to be implemented, which
>> will take at least to 3 months to
>> get reviewed in opensource.
>> hence for now kevin is also agreed to disable it by default;
>
> Why does echi need a "remote wakeup" feature? If you're talking about
> echi wake-up events, I don't see how that would affect core retention.
Hi Tony
the cpu should hit the retention in idle; in this case, up on
usb bus suspend ( no device connected) , if I cut the clock, then later
device detection happen through I/O wakeup, so implementing the
ehci remote wakeup using I/O chain handler ensure the retention in idle too.
now, with the existing ehci driver in mainline, whether device connected or not
the clocks are not cut and prevents the retention in idle.
so, I need to implement the ehci clock gating mechanism through I/O interrupts
in bus spend /resume . This activity will take some time.
regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
