On the APIs for Enabling and Disabling Wakeup capability.

On the APIs for Enabling and Disabling Wakeup capability.

[Basak, Partha]

Hello Paul,

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?

Thanks to clarify.
Partha

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Basak, Partha]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Basak, Partha
> Sent: Wednesday, June 16, 2010 8:10 PM
> To: paul@pwsan.com
> Cc: khilman@deeprootsystems.com; Kalliguddi, Hema; Nayak, Rajendra; linux-
> omap@vger.kernel.org
> Subject: On the APIs for Enabling and Disabling Wakeup capability.
> 
> Hello Paul,
> 
> 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.

We also need the API omap_hwmod_set_slave_idlemode to be exposed as an omap_device API. 

Net-net, the following APIs which are exported in hwmod layer needs to be wrapped under omap_device_layer as well so that drivers can use them:
omap_hwmod_enable_wakeup
omap_hwmod_disable_wakeup
omap_hwmod_set_slave_idlemode

> 
> 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?
> 
> Thanks to clarify.
> Partha
> --
> 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

Re: On the APIs for Enabling and Disabling Wakeup capability.

[Kevin Hilman]

"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

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Kalliguddi, Hema]

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@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
>

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Cousson, Benoit]

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
>

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Kalliguddi, Hema]

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.
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.

Regards,
Hema

>-----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

Re: On the APIs for Enabling and Disabling Wakeup capability.

[Kevin Hilman]

"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

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Basak, Partha]

Benoit/Kevin,

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Friday, June 18, 2010 8:29 PM
> To: Kalliguddi, Hema
> Cc: Cousson, Benoit; Basak, Partha; paul@pwsan.com; Nayak, Rajendra;
> linux-omap@vger.kernel.org
> Subject: Re: On the APIs for Enabling and Disabling Wakeup capability.
> 
> "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.
> 
Few questions:
1. Are you mentioning about the following patch:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=865f0e0b1dd25899fe30eee5c8f1dba420eea177?

Though this patch allows clearing of AutoIdle bit(signified by HWMOD_INIT_NO_IDLE) while remaining in Idle state, it does not allow the reverse, i.e. setting back the AutoIdle bit, while still remaining in Idle state. 

2. Changing the hwmod flags (oh->flags) is acceptable in run-time. Correct?

3. I believe, SysConfig settings have been a tricky area because of different h/w-errata. Instead of looking into particular errata, as and when they come in time to time and explore how to fit them in the framework, would it not be more useful to provide a more generic framework to operate on the SysConfig settings? Of course, as you suggested, the preferred approach would be to absorb the changes in the omap_device/hw-mod layer as much as possible. But unfortunately, that may not be sufficient in all situations.
 
Partha
> 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
> >>>
> >>

Re: On the APIs for Enabling and Disabling Wakeup capability.

[Kevin Hilman]

"Basak, Partha" <p-basak2@ti.com> writes:

> Benoit/Kevin,
>
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Friday, June 18, 2010 8:29 PM
>> To: Kalliguddi, Hema
>> Cc: Cousson, Benoit; Basak, Partha; paul@pwsan.com; Nayak, Rajendra;
>> linux-omap@vger.kernel.org
>> Subject: Re: On the APIs for Enabling and Disabling Wakeup capability.
>> 
>> "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.
>> 
> Few questions:
> 1. Are you mentioning about the following patch:
> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=865f0e0b1dd25899fe30eee5c8f1dba420eea177?

No, this is a totally unrelated problem related to a specific init
sequene.

> Though this patch allows clearing of AutoIdle bit(signified by
> HWMOD_INIT_NO_IDLE) while remaining in Idle state, it does not allow
> the reverse, i.e. setting back the AutoIdle bit, while still remaining
> in Idle state.

The use-case for setting the auto-idle bit while leaving the device in
idle have not been described.

> 2. Changing the hwmod flags (oh->flags) is acceptable in run-time. Correct?

For errata workarounds, in device/SoC init code yes.  In drivers, no.
Drivers should not have any knowledge of hwmod internals.

> 3. I believe, SysConfig settings have been a tricky area because of
> different h/w-errata. Instead of looking into particular errata, as
> and when they come in time to time and explore how to fit them in the
> framework, would it not be more useful to provide a more generic
> framework to operate on the SysConfig settings? Of course, as you
> suggested, the preferred approach would be to absorb the changes in
> the omap_device/hw-mod layer as much as possible. But unfortunately,
> that may not be sufficient in all situations.

For this kind of thing, I strongly prefer to better understand the
specific errata that require the special settings.

History suggests that having an API to modify sysconfig means it would
get used not just for errata workarounds but also because "it doesn't
work unless I do this."   We *really* need to better understand the
reasons behind these special cases.

Kevin

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Kalliguddi, Hema]

Kevin,
Replying on top of latest chin.

Thanks,
Hema

>-----Original Message-----
>From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>Sent: Thursday, June 24, 2010 2:01 AM
>To: Basak, Partha
>Cc: Kalliguddi, Hema; Cousson, Benoit; paul@pwsan.com; 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:
>
>> Benoit/Kevin,
>>
>>> -----Original Message-----
>>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>> Sent: Friday, June 18, 2010 8:29 PM
>>> To: Kalliguddi, Hema
>>> Cc: Cousson, Benoit; Basak, Partha; paul@pwsan.com; Nayak, Rajendra;
>>> linux-omap@vger.kernel.org
>>> Subject: Re: On the APIs for Enabling and Disabling Wakeup 
>capability.
>>> 
>>> "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
>>> >

[HK] The errata is applicable to OMAP3430 only.
But this sequence applicable for omap4 as well. So for submitting the changes we need 
to have the HWMOD api to be changed to enaforce the Autodile set only after the smart idle.

>>> > 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.
>>> 
>> Few questions:
>> 1. Are you mentioning about the following patch:
>> 
>http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm
>.git;a=commit;h=865f0e0b1dd25899fe30eee5c8f1dba420eea177?
>
>No, this is a totally unrelated problem related to a specific init
>sequene.
>
>> Though this patch allows clearing of AutoIdle bit(signified by
>> HWMOD_INIT_NO_IDLE) while remaining in Idle state, it does not allow
>> the reverse, i.e. setting back the AutoIdle bit, while still 
>remaining
>> in Idle state.
>
>The use-case for setting the auto-idle bit while leaving the device in
>idle have not been described.
>
>> 2. Changing the hwmod flags (oh->flags) is acceptable in 
>run-time. Correct?
>
>For errata workarounds, in device/SoC init code yes.  In drivers, no.
>Drivers should not have any knowledge of hwmod internals.
>
>> 3. I believe, SysConfig settings have been a tricky area because of
>> different h/w-errata. Instead of looking into particular errata, as
>> and when they come in time to time and explore how to fit them in the
>> framework, would it not be more useful to provide a more generic
>> framework to operate on the SysConfig settings? Of course, as you
>> suggested, the preferred approach would be to absorb the changes in
>> the omap_device/hw-mod layer as much as possible. But unfortunately,
>> that may not be sufficient in all situations.
>
>For this kind of thing, I strongly prefer to better understand the
>specific errata that require the special settings.
>
>History suggests that having an API to modify sysconfig means it would
>get used not just for errata workarounds but also because "it doesn't
>work unless I do this."   We *really* need to better understand the
>reasons behind these special cases.
>

[HK] I agree that this can be hanled using hw->flags for omap3. 
Can you please point me the commit for the above errata fix? I am not successful in getting the exact commit.

There are few observation in the USBOTG with respect to offmode and sysconfig settings.
Still the investigations are in progress. Current mainline code for 3630 have a patch for the offmode as below.

Enable the force ilde and force standby before going to offmode.
Reset the sysconfig with smart standby and smartidle in restore path.
With the current API support I will not be in a position to implement the this workaround.

I think there are some more errata which needs the dynamic configuration of the sysconfig register like
Set the force idle when data transfer is complete and set back to smart idle/smart standby during data transfer.
I see the errata already in UART #2.15.

Can you please let me know how do we meet such requirement using the existing APIs?

~Hema

>Kevin
>

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Basak, Partha]

Kevin,

Thanks
Partha

> -----Original Message-----
> From: Kalliguddi, Hema
> Sent: Thursday, June 24, 2010 8:25 PM
> To: Kevin Hilman; Basak, Partha
> Cc: Cousson, Benoit; paul@pwsan.com; Nayak, Rajendra; linux-
> omap@vger.kernel.org; Gadiyar, Anand; Kamat, Nishant
> Subject: RE: On the APIs for Enabling and Disabling Wakeup capability.
> 
> Kevin,
> Replying on top of latest chin.
> 
> Thanks,
> Hema
> 
> >-----Original Message-----
> >From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >Sent: Thursday, June 24, 2010 2:01 AM
> >To: Basak, Partha
> >Cc: Kalliguddi, Hema; Cousson, Benoit; paul@pwsan.com; 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:
> >
> >> Benoit/Kevin,
> >>
> >>> -----Original Message-----
> >>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >>> Sent: Friday, June 18, 2010 8:29 PM
> >>> To: Kalliguddi, Hema
> >>> Cc: Cousson, Benoit; Basak, Partha; paul@pwsan.com; Nayak, Rajendra;
> >>> linux-omap@vger.kernel.org
> >>> Subject: Re: On the APIs for Enabling and Disabling Wakeup
> >capability.
> >>>
> >>> "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
> >>> >
> 
> [HK] The errata is applicable to OMAP3430 only.
> But this sequence applicable for omap4 as well. So for submitting the
> changes we need
> to have the HWMOD api to be changed to enaforce the Autodile set only
> after the smart idle.
> 
> >>> > 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.
> >>>
> >> Few questions:
> >> 1. Are you mentioning about the following patch:
> >>
> >http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm
> >.git;a=commit;h=865f0e0b1dd25899fe30eee5c8f1dba420eea177?
> >
> >No, this is a totally unrelated problem related to a specific init
> >sequene.
[Partha] Please send the commit ID
> >
> >> Though this patch allows clearing of AutoIdle bit(signified by
> >> HWMOD_INIT_NO_IDLE) while remaining in Idle state, it does not allow
> >> the reverse, i.e. setting back the AutoIdle bit, while still
> >remaining
> >> in Idle state.
> >
> >The use-case for setting the auto-idle bit while leaving the device in
> >idle have not been described.
> >
[Partha] My comment was more from a consistency of implementation standpoint. Once you clear the AutoIdle, there is no way to set it back before enabling the module. Anyhow, not clear what use-case you are trying to cater to here.

> >> 2. Changing the hwmod flags (oh->flags) is acceptable in
> >run-time. Correct?
> >
> >For errata workarounds, in device/SoC init code yes.  In drivers, no.
> >Drivers should not have any knowledge of hwmod internals.
> >
> >> 3. I believe, SysConfig settings have been a tricky area because of
> >> different h/w-errata. Instead of looking into particular errata, as
> >> and when they come in time to time and explore how to fit them in the
> >> framework, would it not be more useful to provide a more generic
> >> framework to operate on the SysConfig settings? Of course, as you
> >> suggested, the preferred approach would be to absorb the changes in
> >> the omap_device/hw-mod layer as much as possible. But unfortunately,
> >> that may not be sufficient in all situations.
> >
> >For this kind of thing, I strongly prefer to better understand the
> >specific errata that require the special settings.
> >
> >History suggests that having an API to modify sysconfig means it would
> >get used not just for errata workarounds but also because "it doesn't
> >work unless I do this."   We *really* need to better understand the
> >reasons behind these special cases.
> >
> 
[Partha] Refer to the details provided by Hema for the supporting information.
> [HK] I agree that this can be handled using hw->flags for omap3.
> Can you please point me the commit for the above errata fix? I am not
> successful in getting the exact commit.
> 
> There are few observation in the USBOTG with respect to offmode and
> sysconfig settings.
> Still the investigations are in progress. Current mainline code for 3630
> have a patch for the offmode as below.
> 
> Enable the force ilde and force standby before going to offmode.
> Reset the sysconfig with smart standby and smartidle in restore path.
> With the current API support I will not be in a position to implement the
> this workaround.
> 
> I think there are some more errata which needs the dynamic configuration
> of the sysconfig register like
> Set the force idle when data transfer is complete and set back to smart
> idle/smart standby during data transfer.
> I see the errata already in UART #2.15.
> 
> Can you please let me know how do we meet such requirement using the
> existing APIs?
> 
[Partha] The issue is not about providing control to configure AutoIdle alone. It is about exposing a wider control of SysConfig to the driver so that errata can be taken care of.

Also, I assume, as per your earlier suggestion, you would absorb setting and clearing of EnableWakeup inside hwmod_nable/idle functions. Correct?

> ~Hema
> 
> >Kevin
> >

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Kalliguddi, Hema]

 

>-----Original Message-----
>From: linux-omap-owner@vger.kernel.org 
>[mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kalliguddi, Hema
>Sent: Thursday, June 24, 2010 8:25 PM
>To: Kevin Hilman; Basak, Partha
>Cc: Cousson, Benoit; paul@pwsan.com; Nayak, Rajendra; 
>linux-omap@vger.kernel.org; Gadiyar, Anand; Kamat, Nishant
>Subject: RE: On the APIs for Enabling and Disabling Wakeup capability.
>
>Kevin,
>Replying on top of latest chin.
>
>Thanks,
>Hema
>
>>-----Original Message-----
>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>>Sent: Thursday, June 24, 2010 2:01 AM
>>To: Basak, Partha
>>Cc: Kalliguddi, Hema; Cousson, Benoit; paul@pwsan.com; 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:
>>
>>> Benoit/Kevin,
>>>
>>>> -----Original Message-----
>>>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>> Sent: Friday, June 18, 2010 8:29 PM
>>>> To: Kalliguddi, Hema
>>>> Cc: Cousson, Benoit; Basak, Partha; paul@pwsan.com; Nayak, 
>Rajendra;
>>>> linux-omap@vger.kernel.org
>>>> Subject: Re: On the APIs for Enabling and Disabling Wakeup 
>>capability.
>>>> 
>>>> "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
>>>> >
>
>[HK] The errata is applicable to OMAP3430 only.
>But this sequence applicable for omap4 as well. So for 
>submitting the changes we need 
>to have the HWMOD api to be changed to enaforce the Autodile 
>set only after the smart idle.
>
When can I expect the HWMOD API change which includes the auto idle setting only after
Smart idle setting and wakeup enable/disable settings?

Right now shall I proceed with setting Autoidle using omap_hwmod_set_slave_idlemode(), 
And omap_hwmod_enable_wakeup and omap_hwmod_disable_wakeup apis?

>>>> > 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.
>>>> 
>>> Few questions:
>>> 1. Are you mentioning about the following patch:
>>> 
>>http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm
>>.git;a=commit;h=865f0e0b1dd25899fe30eee5c8f1dba420eea177?
>>
>>No, this is a totally unrelated problem related to a specific init
>>sequene.
>>
>>> Though this patch allows clearing of AutoIdle bit(signified by
>>> HWMOD_INIT_NO_IDLE) while remaining in Idle state, it does not allow
>>> the reverse, i.e. setting back the AutoIdle bit, while still 
>>remaining
>>> in Idle state.
>>
>>The use-case for setting the auto-idle bit while leaving the device in
>>idle have not been described.
>>
>>> 2. Changing the hwmod flags (oh->flags) is acceptable in 
>>run-time. Correct?
>>
>>For errata workarounds, in device/SoC init code yes.  In drivers, no.
>>Drivers should not have any knowledge of hwmod internals.
>>
>>> 3. I believe, SysConfig settings have been a tricky area because of
>>> different h/w-errata. Instead of looking into particular errata, as
>>> and when they come in time to time and explore how to fit 
>them in the
>>> framework, would it not be more useful to provide a more generic
>>> framework to operate on the SysConfig settings? Of course, as you
>>> suggested, the preferred approach would be to absorb the changes in
>>> the omap_device/hw-mod layer as much as possible. But unfortunately,
>>> that may not be sufficient in all situations.
>>
>>For this kind of thing, I strongly prefer to better understand the
>>specific errata that require the special settings.
>>
>>History suggests that having an API to modify sysconfig means it would
>>get used not just for errata workarounds but also because "it doesn't
>>work unless I do this."   We *really* need to better understand the
>>reasons behind these special cases.
>>
>
>[HK] I agree that this can be hanled using hw->flags for omap3. 
>Can you please point me the commit for the above errata fix? I 
>am not successful in getting the exact commit.
>
>There are few observation in the USBOTG with respect to 
>offmode and sysconfig settings.
>Still the investigations are in progress. Current mainline 
>code for 3630 have a patch for the offmode as below.
>
>Enable the force ilde and force standby before going to offmode.
>Reset the sysconfig with smart standby and smartidle in restore path.
>With the current API support I will not be in a position to 
>implement the this workaround.
>
>I think there are some more errata which needs the dynamic 
>configuration of the sysconfig register like
>Set the force idle when data transfer is complete and set back 
>to smart idle/smart standby during data transfer.
>I see the errata already in UART #2.15.
>
>Can you please let me know how do we meet such requirement 
>using the existing APIs?

Did you get a chance to check this?
>
>~Hema
>
>>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
>

Re: On the APIs for Enabling and Disabling Wakeup capability.

[Kevin Hilman]

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

>>>>> > http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf
>>>>> >
>>
>>[HK] The errata is applicable to OMAP3430 only.  But this sequence
>>applicable for omap4 as well. So for submitting the changes we need to
>>have the HWMOD api to be changed to enaforce the Autodile set only
>>after the smart idle.
>
> When can I expect the HWMOD API change which includes the auto idle
> setting only after Smart idle setting and wakeup enable/disable
> settings?

Hi Hema,

If this is blocking you, rather than waiting for somone else to add this
feature, I suggest that you add the API you think would be needed with
proposed patches to the hwmod layer.  One for the idle settings, another
for wakeups.  In the changelog, describe (in detail) the reasons these
APIs would be used.

Kevin

RE: On the APIs for Enabling and Disabling Wakeup capability.

[Kalliguddi, Hema]

Kevin,

>-----Original Message-----
>From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>Sent: Friday, June 18, 2010 8:29 PM
>To: Kalliguddi, Hema
>Cc: Cousson, Benoit; Basak, Partha; paul@pwsan.com; Nayak, 
>Rajendra; linux-omap@vger.kernel.org
>Subject: Re: On the APIs for Enabling and Disabling Wakeup capability.
>
>"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.

The errata is applicable to OMAP3430 only.
But this sequence applicable for omap4 as well. So for submitting the changes we need 
to have the HWMOD api to be changed to enaforce the Autodile set only after the smart idle.

>
>> 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.
>

I agree that this can be hanled using hw->flags for omap3. 
Can you please point me the commit for the above errata fix? I am successful in getting the exact commit.

There are few observation in the USBOTG with respect to offmode and sysconfig settings.
Still the investigations are in progress. Current mainline code for 3630 have a patch for the offmode as below.

Enable the force ilde and force standby before going to offmode.
Reset the sysconfig with smart standby and smartidle in restore path.
With the current API support I will not be in a position to implement the this workaround.

I think there are some more errata which needs the dynamic configuration of the sysconfig register like
Set the force idle when data transfer is complete and set back to smart idle/smart standby during data transfer.
I see the errata already in UART #2.15.

Can you please let me know how do we meet such requirement using the existing APIs?

~Hema
>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

RE: On the APIs for Enabling and Disabling Wakeup capability.

[David Brownell]

> >> 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.

What's the relationship between these
and the sysfs attribute which manages
the per-device wakeup enable?


Should there be driver model calls, into which
these OMAP errata-oriented calls would hook?