Kevin,
Kevin,

There is no errata in the USB which needs the Enable/Disable wakeup to be done 
Seperately. If it can be handled with omap_devie_enable/idle Apis it is 
sufficient.

But there is a need of setting the Auto idle bit seperately as for the USBOTG 
there is a need to set the Autoidle only after configuring the smart idle. It 
is recommended in the TRM not set the auto idle and smart idle together.
This I discussed with Partha he sent a mail to you.

For setting autoidle there is an api at hwmod layer but not yet omap device 
layer.
Is there a plan to add API at omap device layer for enabling/disabling the 
autoidle?

Regards,
Hema
 

>-----Original Message-----
>From: Kevin Hilman [mailto:[email protected]] 
>Sent: Thursday, June 17, 2010 5:56 AM
>To: Basak, Partha
>Cc: [email protected]; Kalliguddi, Hema; Nayak, Rajendra; 
>[email protected]
>Subject: Re: On the APIs for Enabling and Disabling Wakeup capability.
>
>"Basak, Partha" <[email protected]> writes:
>
>> I wanted to close on the introduction of two new OMAP device APIs
>> omap_device_enable_wakeup () & omap_device_disable_wakeup() in
>> omap_device layer.
>>
>> These APIs are potentially needed by the USB driver (via function
>> pointers) to work around some USB erratum.
>>
>> Alternatively, can we call omap_hwmod_enable_wakeup() via function
>> pointer?  Is it agreeable to call these from driver code (via
>> function pointers)in some special cases such as to handle some
>> errata?
>
>Hi Partha,
>
>First, we need to dig up the Errata details for that USB problem to
>better understand the USB-specific issue.
>
>In addition, Paul and I discussed the option of automatically managing
>the wakeup during the hwmod enable/idle, since there isn't really a
>need to have the wakeup enabled when the hwmod is active.
>
>Do you see any disadvantages to that?  That would be much cleaner than
>manually managing the wakeup feature per-driver.
>
>Kevin
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to