public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Kalliguddi, Hema" <hemahk@ti.com>
Cc: "Cousson, Benoit" <b-cousson@ti.com>,
	"Basak, Partha" <p-basak2@ti.com>,
	"paul@pwsan.com" <paul@pwsan.com>,
	"Nayak, Rajendra" <rnayak@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: On the APIs for Enabling and Disabling Wakeup capability.
Date: Fri, 18 Jun 2010 07:58:37 -0700	[thread overview]
Message-ID: <87ljacbd5u.fsf@deeprootsystems.com> (raw)
In-Reply-To: <E0D41E29EB0DAC4E9F3FF173962E9E940270056DEE@dbde02.ent.ti.com> (Hema Kalliguddi's message of "Fri\, 18 Jun 2010 14\:29\:12 +0530")

"Kalliguddi, Hema" <hemahk@ti.com> writes:

> Hi Benoit,
>
> I have 2 cases in usb for the need of separate API for setting the auto idle bit.
>
> 1. Below the link for omap3430TRM. Please refer 24.1.5.4.2 and 24.1.5.4.3 there is note not to set smart
> idle and autoidle bit simultaneously. Suggestion is to set the auto idle 0 before setting smart idle. Then set to 1.

Maybe this sequence should be enforced by the hwmod code itself,
rather than the knowledge living in the driver.

However, based on the errata below, auto-idle will always be zero so
the there should be no conflict in setting smart-idle and auto-idle
simultaneously today.

> This applicable for omap4 as well.  I don't have the omap4430 pblic TRM to share.
> http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf 
>
> 2. There is a Errata in OMAP3 errata #1.59 that If auto idle is set then the USB can't  wakeup the system by
> usb external events. The suggested workaround is to disable the autoIdle for omap3.

This one could be handled at init time in usb-musb.c by setting
HWMOD_NO_OCP_AUTOIDLE for the hwmod with a comment summarizing this
errata.

Note also that Errata 1.166 is another one related to MUSB auto-idle
and we have a workaround in the PM branch to ensure that MUSB
auto-idle is disabled in the idle path since it may be re-enabled
after an off-mode transition.

Kevin

>
>>-----Original Message-----
>>From: Cousson, Benoit 
>>Sent: Thursday, June 17, 2010 3:04 PM
>>To: Kalliguddi, Hema; Kevin Hilman; Basak, Partha
>>Cc: paul@pwsan.com; Nayak, Rajendra; linux-omap@vger.kernel.org
>>Subject: RE: On the APIs for Enabling and Disabling Wakeup capability.
>>
>>Hi Hema,
>>
>>>From: linux-omap-owner@vger.kernel.org 
>>>
>>>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?
>>
>>The whole issue with exposing all the low level stuff at driver level
>>is that the hwmod abstraction become less and less useful.
>>Drivers will start hacking with that for no good reason. And 
>>then we will start adding again some omap version specific 
>>hacks in the driver.
>>
>>Could you provide the full errata description of that USB_OTG 
>>issue? Or at least that TRM part you are talking about.
>>
>>Thanks,
>>Benoit
>>
>>>Regards,
>>>Hema
>>> 
>>>
>>>>
>>Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 
>>Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
>> 
>>-----Original Message-----
>>
>>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>>>>Sent: Thursday, June 17, 2010 5:56 AM
>>>>To: Basak, Partha
>>>>Cc: paul@pwsan.com; Kalliguddi, Hema; Nayak, Rajendra; 
>>>>linux-omap@vger.kernel.org
>>>>Subject: Re: On the APIs for Enabling and Disabling Wakeup 
>>capability.
>>>>
>>>>"Basak, Partha" <p-basak2@ti.com> 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@vger.kernel.org
>>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
--
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

  reply	other threads:[~2010-06-18 14:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16 14:39 On the APIs for Enabling and Disabling Wakeup capability Basak, Partha
2010-06-16 14:58 ` Basak, Partha
2010-06-17  0:25 ` Kevin Hilman
2010-06-17  3:42   ` Kalliguddi, Hema
2010-06-17  9:34     ` Cousson, Benoit
2010-06-18  8:59       ` Kalliguddi, Hema
2010-06-18 14:58         ` Kevin Hilman [this message]
2010-06-22 10:29           ` Basak, Partha
2010-06-23 20:31             ` Kevin Hilman
2010-06-24 14:54               ` Kalliguddi, Hema
2010-06-24 15:04                 ` Basak, Partha
2010-06-28 14:25                 ` Kalliguddi, Hema
2010-06-28 16:25                   ` Kevin Hilman
2010-06-24 14:42           ` Kalliguddi, Hema
2010-06-27  3:05     ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ljacbd5u.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=b-cousson@ti.com \
    --cc=hemahk@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=p-basak2@ti.com \
    --cc=paul@pwsan.com \
    --cc=rnayak@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox