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:khilman@xxxxxxxxxxxxxxxxxxx] >Sent: Thursday, June 17, 2010 5:56 AM >To: Basak, Partha >Cc: paul@xxxxxxxxx; Kalliguddi, Hema; Nayak, Rajendra; >linux-omap@xxxxxxxxxxxxxxx >Subject: Re: On the APIs for Enabling and Disabling Wakeup capability. > >"Basak, Partha" <p-basak2@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
