power management problems in ehci-omap

power management problems in ehci-omap

[Andreas Kemnade]

Hi,

I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
pm problems. modprobe ehci-omap increases current by around 35mA and
also rmmod ehci-omap does not let it go down at all.

I expect that removing hardware does the same thing

Also suspend current increases by around 15mA if that module is loaded.
I tested with having everything disabled which is attached to that usb bus.

System was 
GTA04A5 (with dm3730 processor and usb3322 phy)

I know it has worked once, but I do not remember the version.

The kernel config used can be found here:
http://misc.andi.de1.cc/config-4.15.gz

Regards
Andreas
BTW: I am at the FOSDEM, will probably spend a lot of time in the
hw enablement devroom. So maybe ideas could be discussed directly.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Michael Nazzareno Trimarchi]

Hi

On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
> Hi,
>
> I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
> pm problems. modprobe ehci-omap increases current by around 35mA and
> also rmmod ehci-omap does not let it go down at all.
>
> I expect that removing hardware does the same thing
>
> Also suspend current increases by around 15mA if that module is loaded.
> I tested with having everything disabled which is attached to that usb bus.
>

Do you have an LTE connected to the usb?

Michael

> System was
> GTA04A5 (with dm3730 processor and usb3322 phy)
>
> I know it has worked once, but I do not remember the version.
>
> The kernel config used can be found here:
> http://misc.andi.de1.cc/config-4.15.gz
>
> Regards
> Andreas
> BTW: I am at the FOSDEM, will probably spend a lot of time in the
> hw enablement devroom. So maybe ideas could be discussed directly.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Andreas Kemnade]

On Sun, 4 Feb 2018 00:10:50 +0100
Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:

> Hi
> 
> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
> > Hi,
> >
> > I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
> > pm problems. modprobe ehci-omap increases current by around 35mA and
> > also rmmod ehci-omap does not let it go down at all.
> >
> > I expect that removing hardware does the same thing
nonsense sentence from me, was to tired. I would expect that removing the modules
properly powers down the device.
> >
> > Also suspend current increases by around 15mA if that module is loaded.
> > I tested with having everything disabled which is attached to that usb bus.
> >  
> 
> Do you have an LTE connected to the usb?
> 
Yes, there is a UMTS modem attached, but it was off during the tests.
It did not enumerate on the modem.

> Michael
> 
> > System was
> > GTA04A5 (with dm3730 processor and usb3322 phy)
> >
> > I know it has worked once, but I do not remember the version.
> >
> > The kernel config used can be found here:
> > http://misc.andi.de1.cc/config-4.15.gz
> >
Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Michael Nazzareno Trimarchi]

Hi Andreas

On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
> On Sun, 4 Feb 2018 00:10:50 +0100
> Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>
>> Hi
>>
>> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>> > Hi,
>> >
>> > I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
>> > pm problems. modprobe ehci-omap increases current by around 35mA and
>> > also rmmod ehci-omap does not let it go down at all.
>> >
>> > I expect that removing hardware does the same thing
> nonsense sentence from me, was to tired. I would expect that removing the modules
> properly powers down the device.
>> >
>> > Also suspend current increases by around 15mA if that module is loaded.
>> > I tested with having everything disabled which is attached to that usb bus.
>> >
>>
>> Do you have an LTE connected to the usb?
>>
> Yes, there is a UMTS modem attached, but it was off during the tests.
> It did not enumerate on the modem.
>

Just to understand if the suspend current drop was connected to the
suspend of lte modem on your side.
So you don't have anything connected on usb bus?

Michael

>> Michael
>>
>> > System was
>> > GTA04A5 (with dm3730 processor and usb3322 phy)
>> >
>> > I know it has worked once, but I do not remember the version.
>> >
>> > The kernel config used can be found here:
>> > http://misc.andi.de1.cc/config-4.15.gz
>> >
> Regards,
> Andreas



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Andreas Kemnade]

Hi,

On Sun, 4 Feb 2018 09:43:45 +0100
Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:

> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
> > On Sun, 4 Feb 2018 00:10:50 +0100
> > Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> >  
> >> Hi
> >>
> >> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:  
> >> > Hi,
> >> >
> >> > I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
> >> > pm problems. modprobe ehci-omap increases current by around 35mA and
> >> > also rmmod ehci-omap does not let it go down at all.
> >> >
> >> > I expect that removing hardware does the same thing  
> > nonsense sentence from me, was to tired. I would expect that removing the modules
> > properly powers down the device.  
> >> >
> >> > Also suspend current increases by around 15mA if that module is loaded.
> >> > I tested with having everything disabled which is attached to that usb bus.
> >> >  
> >>
> >> Do you have an LTE connected to the usb?
> >>  
> > Yes, there is a UMTS modem attached, but it was off during the tests.
> > It did not enumerate on the modem.
> >  
> 
> Just to understand if the suspend current drop was connected to the
> suspend of lte modem on your side.
> So you don't have anything connected on usb bus?
> 
Suspend current is increased when the ehci-omap module is loaded
in comparison to the state. I tested with the modem disabled, so there
is nothing on the bus. Increased suspend current is one thing,
current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.

I am testing with init=some_testscript.sh, so no userspace
is doing strange things. No module autoload or something.

Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Michael Nazzareno Trimarchi]

Hi Andreas

On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
> Hi,
>
> On Sun, 4 Feb 2018 09:43:45 +0100
> Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>
>> Hi Andreas
>>
>> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>> > On Sun, 4 Feb 2018 00:10:50 +0100
>> > Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>> >
>> >> Hi
>> >>
>> >> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>> >> > Hi,
>> >> >
>> >> > I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
>> >> > pm problems. modprobe ehci-omap increases current by around 35mA and
>> >> > also rmmod ehci-omap does not let it go down at all.
>> >> >
>> >> > I expect that removing hardware does the same thing
>> > nonsense sentence from me, was to tired. I would expect that removing the modules
>> > properly powers down the device.
>> >> >
>> >> > Also suspend current increases by around 15mA if that module is loaded.
>> >> > I tested with having everything disabled which is attached to that usb bus.
>> >> >
>> >>
>> >> Do you have an LTE connected to the usb?
>> >>
>> > Yes, there is a UMTS modem attached, but it was off during the tests.
>> > It did not enumerate on the modem.
>> >
>>
>> Just to understand if the suspend current drop was connected to the
>> suspend of lte modem on your side.
>> So you don't have anything connected on usb bus?
>>
> Suspend current is increased when the ehci-omap module is loaded
> in comparison to the state. I tested with the modem disabled, so there
> is nothing on the bus. Increased suspend current is one thing,
> current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
>
> I am testing with init=some_testscript.sh, so no userspace
> is doing strange things. No module autoload or something.
>

How many port are configured and how is the phy part connected to the
ehci controller?
Can you point me the schematic page?

michael


> Regards,
> Andreas



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[H. Nikolaus Schaller]

Hi Michael,

> Am 04.02.2018 um 11:55 schrieb Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>:
> 
> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>> Hi,
>> 
>> On Sun, 4 Feb 2018 09:43:45 +0100
>> Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>> 
>>> Hi Andreas
>>> 
>>> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>>>> On Sun, 4 Feb 2018 00:10:50 +0100
>>>> Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>>>> 
>>>>> Hi
>>>>> 
>>>>> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
>>>>>> pm problems. modprobe ehci-omap increases current by around 35mA and
>>>>>> also rmmod ehci-omap does not let it go down at all.
>>>>>> 
>>>>>> I expect that removing hardware does the same thing
>>>> nonsense sentence from me, was to tired. I would expect that removing the modules
>>>> properly powers down the device.
>>>>>> 
>>>>>> Also suspend current increases by around 15mA if that module is loaded.
>>>>>> I tested with having everything disabled which is attached to that usb bus.
>>>>>> 
>>>>> 
>>>>> Do you have an LTE connected to the usb?
>>>>> 
>>>> Yes, there is a UMTS modem attached, but it was off during the tests.
>>>> It did not enumerate on the modem.
>>>> 
>>> 
>>> Just to understand if the suspend current drop was connected to the
>>> suspend of lte modem on your side.
>>> So you don't have anything connected on usb bus?
>>> 
>> Suspend current is increased when the ehci-omap module is loaded
>> in comparison to the state. I tested with the modem disabled, so there
>> is nothing on the bus. Increased suspend current is one thing,
>> current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
>> 
>> I am testing with init=some_testscript.sh, so no userspace
>> is doing strange things. No module autoload or something.
>> 
> 
> How many port are configured and how is the phy part connected to the
> ehci controller?
> Can you point me the schematic page?

it is essentially a copy&paste from BeagleBoard XM.

Schematics of the GTA04 are here:

	http://projects.goldelico.com/p/gta04-main/downloads/48/

USB PHY is on page 9.

BR,
Nikolaus

> 
> michael
> 
> 
>> Regards,
>> Andreas
> 
> 
> 
> -- 
> | Michael Nazzareno Trimarchi                     Amarula Solutions BV |
> | COO  -  Founder                                      Cruquiuskade 47 |
> | +31(0)851119172                                 Amsterdam 1018 AM NL |
> |                  [`as] http://www.amarulasolutions.com               |
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel-S0jZdbWzriLCfDggNXIi3w@public.gmane.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Michael Nazzareno Trimarchi]

Hi

On Sun, Feb 4, 2018 at 12:07 PM, H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
> Hi Michael,
>
>> Am 04.02.2018 um 11:55 schrieb Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>:
>>
>> Hi Andreas
>>
>> On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>>> Hi,
>>>
>>> On Sun, 4 Feb 2018 09:43:45 +0100
>>> Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>>>
>>>> Hi Andreas
>>>>
>>>> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>>>>> On Sun, 4 Feb 2018 00:10:50 +0100
>>>>> Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
>>>>>>> pm problems. modprobe ehci-omap increases current by around 35mA and
>>>>>>> also rmmod ehci-omap does not let it go down at all.
>>>>>>>
>>>>>>> I expect that removing hardware does the same thing
>>>>> nonsense sentence from me, was to tired. I would expect that removing the modules
>>>>> properly powers down the device.
>>>>>>>
>>>>>>> Also suspend current increases by around 15mA if that module is loaded.
>>>>>>> I tested with having everything disabled which is attached to that usb bus.
>>>>>>>
>>>>>>
>>>>>> Do you have an LTE connected to the usb?
>>>>>>
>>>>> Yes, there is a UMTS modem attached, but it was off during the tests.
>>>>> It did not enumerate on the modem.
>>>>>
>>>>
>>>> Just to understand if the suspend current drop was connected to the
>>>> suspend of lte modem on your side.
>>>> So you don't have anything connected on usb bus?
>>>>
>>> Suspend current is increased when the ehci-omap module is loaded
>>> in comparison to the state. I tested with the modem disabled, so there
>>> is nothing on the bus. Increased suspend current is one thing,
>>> current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
>>>
>>> I am testing with init=some_testscript.sh, so no userspace
>>> is doing strange things. No module autoload or something.
>>>
>>
>> How many port are configured and how is the phy part connected to the
>> ehci controller?
>> Can you point me the schematic page?
>
> it is essentially a copy&paste from BeagleBoard XM.
>
> Schematics of the GTA04 are here:
>
>         http://projects.goldelico.com/p/gta04-main/downloads/48/
>
> USB PHY is on page 9.
>

I see. GPIO174 is controlled by you during boot or connected to the dts?
I don't find in mainline the connection to the physical and it's own
programming.
Can you check if the phy is in reset when module is remove?

Michael


> BR,
> Nikolaus
>
>>
>> michael
>>
>>
>>> Regards,
>>> Andreas
>>
>>
>>
>> --
>> | Michael Nazzareno Trimarchi                     Amarula Solutions BV |
>> | COO  -  Founder                                      Cruquiuskade 47 |
>> | +31(0)851119172                                 Amsterdam 1018 AM NL |
>> |                  [`as] http://www.amarulasolutions.com               |
>> _______________________________________________
>> http://projects.goldelico.com/p/gta04-kernel/
>> Letux-kernel mailing list
>> Letux-kernel-S0jZdbWzriLCfDggNXIi3w@public.gmane.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[H. Nikolaus Schaller]

Hi,
Andreas seems to be travelling back from FOSDEM so I jump in with best of my knowledge.

> Am 04.02.2018 um 12:34 schrieb Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>:
> 
> Hi
> 
> On Sun, Feb 4, 2018 at 12:07 PM, H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
>> Hi Michael,
>> 
>>> Am 04.02.2018 um 11:55 schrieb Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>:
>>> 
>>> Hi Andreas
>>> 
>>> On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>>>> Hi,
>>>> 
>>>> On Sun, 4 Feb 2018 09:43:45 +0100
>>>> Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>>>> 
>>>>> Hi Andreas
>>>>> 
>>>>> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>>>>>> On Sun, 4 Feb 2018 00:10:50 +0100
>>>>>> Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>>>>>> 
>>>>>>> Hi
>>>>>>> 
>>>>>>> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
>>>>>>>> pm problems. modprobe ehci-omap increases current by around 35mA and
>>>>>>>> also rmmod ehci-omap does not let it go down at all.
>>>>>>>> 
>>>>>>>> I expect that removing hardware does the same thing
>>>>>> nonsense sentence from me, was to tired. I would expect that removing the modules
>>>>>> properly powers down the device.
>>>>>>>> 
>>>>>>>> Also suspend current increases by around 15mA if that module is loaded.
>>>>>>>> I tested with having everything disabled which is attached to that usb bus.
>>>>>>>> 
>>>>>>> 
>>>>>>> Do you have an LTE connected to the usb?
>>>>>>> 
>>>>>> Yes, there is a UMTS modem attached, but it was off during the tests.
>>>>>> It did not enumerate on the modem.
>>>>>> 
>>>>> 
>>>>> Just to understand if the suspend current drop was connected to the
>>>>> suspend of lte modem on your side.
>>>>> So you don't have anything connected on usb bus?
>>>>> 
>>>> Suspend current is increased when the ehci-omap module is loaded
>>>> in comparison to the state. I tested with the modem disabled, so there
>>>> is nothing on the bus. Increased suspend current is one thing,
>>>> current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
>>>> 
>>>> I am testing with init=some_testscript.sh, so no userspace
>>>> is doing strange things. No module autoload or something.
>>>> 
>>> 
>>> How many port are configured and how is the phy part connected to the
>>> ehci controller?
>>> Can you point me the schematic page?
>> 
>> it is essentially a copy&paste from BeagleBoard XM.
>> 
>> Schematics of the GTA04 are here:
>> 
>>        http://projects.goldelico.com/p/gta04-main/downloads/48/
>> 
>> USB PHY is on page 9.
>> 
> 
> I see. GPIO174 is controlled by you during boot or connected to the dts?
> I don't find in mainline the connection to the physical and it's own
> programming.
> Can you check if the phy is in reset when module is remove?

The reset gpio is defined in the respective board-DTS:

https://elixir.free-electrons.com/linux/v4.15/source/arch/arm/boot/dts/omap3-beagle-xm.dts#L88
https://elixir.free-electrons.com/linux/v4.15/source/arch/arm/boot/dts/omap3-gta04.dtsi#L120

BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]

On Sun, 4 Feb 2018 11:55:02 +0100
Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:

> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
> > Hi,
> >
> > On Sun, 4 Feb 2018 09:43:45 +0100
> > Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> >  
> >> Hi Andreas
> >>
> >> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:  
> >> > On Sun, 4 Feb 2018 00:10:50 +0100
> >> > Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> >> >  
> >> >> Hi
> >> >>
> >> >> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas@kemnade.info> wrote:  
> >> >> > Hi,
> >> >> >
> >> >> > I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
> >> >> > pm problems. modprobe ehci-omap increases current by around 35mA and
> >> >> > also rmmod ehci-omap does not let it go down at all.
> >> >> >
> >> >> > I expect that removing hardware does the same thing  
> >> > nonsense sentence from me, was to tired. I would expect that removing the modules
> >> > properly powers down the device.  
> >> >> >
> >> >> > Also suspend current increases by around 15mA if that module is loaded.
> >> >> > I tested with having everything disabled which is attached to that usb bus.
> >> >> >  
> >> >>
> >> >> Do you have an LTE connected to the usb?
> >> >>  
> >> > Yes, there is a UMTS modem attached, but it was off during the tests.
> >> > It did not enumerate on the modem.
> >> >  
> >>
> >> Just to understand if the suspend current drop was connected to the
> >> suspend of lte modem on your side.
> >> So you don't have anything connected on usb bus?
> >>  
> > Suspend current is increased when the ehci-omap module is loaded
> > in comparison to the state. I tested with the modem disabled, so there
> > is nothing on the bus. Increased suspend current is one thing,
> > current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
> >
> > I am testing with init=some_testscript.sh, so no userspace
> > is doing strange things. No module autoload or something.
> >  

Ok, there is some heavy EBCAK involved. I just did an
echo rmmod
without a real rmmod. But the suspend thing is still valid.

Sorry for the confusion.

To avoid further confusion I have uploaded these two scripts
I have given to the kernel.
http://misc.andi.de1.cc/measure4.sh

output from that:
no modules: cur: 61047 delta: 61047
before: 423462
after: 421326
average 25632 uA over 300 seconds
 cur: 60333 delta: -714
+ehci-omap cur: 93712 delta: 33379
-ehci-omap cur: 60511 delta: -33201
before: 420792
after: 418656
average 25632 uA over 300 seconds


http://misc.andi.de1.cc/measure5.sh
output from that:

no modules: cur: 61225 delta: 61225
before: 427734
after: 425598
average 25717 uA over 299 seconds
 cur: 59797 delta: -1428
+ehci-omap cur: 93712 delta: 33915
before: 425242
after: 421860
average 40719 uA over 299 seconds

The 40mA is too high. We have had measurements below 30mA even with
modem enabled with some pre-dt setup (Kernel 3.7)

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: power management problems in ehci-omap

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

On Sun, 4 Feb 2018 09:43:45 +0100
Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:

> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:
> > On Sun, 4 Feb 2018 00:10:50 +0100
> > Michael Nazzareno Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> >  
> >> Hi
> >>
> >> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> wrote:  
> >> > Hi,
> >> >
> >> > I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze
> >> > pm problems. modprobe ehci-omap increases current by around 35mA and
> >> > also rmmod ehci-omap does not let it go down at all.
> >> >
> >> > I expect that removing hardware does the same thing  
> > nonsense sentence from me, was to tired. I would expect that removing the modules
> > properly powers down the device.  
> >> >
> >> > Also suspend current increases by around 15mA if that module is loaded.
> >> > I tested with having everything disabled which is attached to that usb bus.
> >> >  
> >>
> >> Do you have an LTE connected to the usb?
> >>  
> > Yes, there is a UMTS modem attached, but it was off during the tests.
> > It did not enumerate on the modem.
> >  
> 
> Just to understand if the suspend current drop was connected to the
> suspend of lte modem on your side.
> So you don't have anything connected on usb bus?
>
rechecked with a board with really nothing connected there
Same behaviour

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: power management problems in ehci-omap

[Tony Lindgren]

* Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 06:42]:
> rechecked with a board with really nothing connected there
> Same behaviour

I've just verified that my test board power consumption goes
back to normal after rmmod ehci-omap with v4.15.

For ehci PM, it might be a bit easier to do nowadays that
we have Linux generic wakeirq support if somebody wants to
take a look at it. The PHY lines could have wakeirq events
enabled for the pads, and there is an older series from
Rogeq that does not use wakeirqs at:

https://lkml.org/lkml/2013/7/10/355

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

On Tue, 6 Feb 2018 08:04:52 -0800
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:

> * Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 06:42]:
> > rechecked with a board with really nothing connected there
> > Same behaviour  
> 
> I've just verified that my test board power consumption goes
> back to normal after rmmod ehci-omap with v4.15.
> 
yes, for me too, I initially used a test script which does an
echo rmmod ehci-omap

without a real
rmmod ehci-omap

It just seems to be consistent with my observations in a fully booted
system (where many things can play a role). Sorry for that confusion.

But suspend current is a problem. I have repeated the measurement with
another board, so it is not a board problem. 

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

power management problems in ehci-omap

[Tony Lindgren]

* Andreas Kemnade <andreas@kemnade.info> [180206 16:56]:
> On Tue, 6 Feb 2018 08:04:52 -0800
> Tony Lindgren <tony@atomide.com> wrote:
> 
> > * Andreas Kemnade <andreas@kemnade.info> [180206 06:42]:
> > > rechecked with a board with really nothing connected there
> > > Same behaviour  
> > 
> > I've just verified that my test board power consumption goes
> > back to normal after rmmod ehci-omap with v4.15.
> > 
> yes, for me too, I initially used a test script which does an
> echo rmmod ehci-omap
> 
> without a real
> rmmod ehci-omap

Ah OK :)

> It just seems to be consistent with my observations in a fully booted
> system (where many things can play a role). Sorry for that confusion.

Try with a minimal set of modules first, then modprobe and rmmod one
at a time until you find the module breaking PM?

You probably know this already, but just in case it helps..

First idle the UARTs and enable off mode with something like:

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
	echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
	echo enabled > $uart/wakeup 2>&1
	echo auto > $uart/control 2>&1
done

echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode

Then if using omap3, the attached debug hack patch can be used to
see which devices are not idling:

> But suspend current is a problem. I have repeated the measurement with
> another board, so it is not a board problem. 

I also verified v4.15 behaves for suspend current even with
echi-omap loaded just in case.

Regards,

Tony

8< -------------------
From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 13 Dec 2017 16:36:45 -0800
Subject: [PATCH] NOT FOR MERGING: Test patch for dumping omap3 off idle
 blocking bits

Allows seeing the deeper idle state blockers in
/sys/kernel/debug/pm_debug/count. For example, when
off idle is working on beaglboard xm, this is what
i see:

# sleep 5; cat /sys/kernel/debug/pm_debug/count
...
0006ffff 48005020 (fa005020) cm_idlest_per blocking bits: 00010000
e7ffffbd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042
0000000d 48004a28 (fa004a28) cm_idlest3_core
---
 arch/arm/mach-omap2/pm-debug.c | 68 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -142,10 +142,78 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user)
 	return 0;
 }
 
+#include "iomap.h"
+
+struct dregs {
+	const char	*desc;
+	u32		phys;
+	void __iomem	*virt;
+	u32		mask;
+};
+
+#define PER_CM_BASE	0x48005000
+#define PER_CM_REG(name, offset, mask)				\
+	{ name, PER_CM_BASE + offset,				\
+	OMAP2_L4_IO_ADDRESS(PER_CM_BASE + offset), mask, }
+
+static struct dregs cm_per[] = {
+	PER_CM_REG("cm_idlest_per", 0x20, 0xfff80000), /* p 513 */
+	{ NULL, },
+};
+
+#define CORE_CM_BASE	0x48004a00
+#define CORE_CM_REG(name, offset, mask)				\
+	{ name, CORE_CM_BASE + offset,				\
+	OMAP2_L4_IO_ADDRESS(CORE_CM_BASE + offset), mask, }
+
+static struct dregs cm_core[] = {
+	CORE_CM_REG("cm_idlest1_core", 0x20, 0x9c800109), /* p 467 */
+	CORE_CM_REG("cm_idlest3_core", 0x28, 0xfffffffb),
+	{ NULL, },
+};
+
+void __dregs_dump(struct dregs *dregs, struct seq_file *s)
+{
+	for (; dregs->desc; dregs++) {
+		u32 val, blockers;
+
+		val = __raw_readl(dregs->virt);
+
+		seq_printf(s, "%08x %08x (%p) %s",
+			   val, dregs->phys, dregs->virt,
+			   dregs->desc);
+
+		if (dregs->mask) {
+			blockers = ~val;
+			blockers &= ~dregs->mask;
+
+			if (blockers)
+				seq_printf(s, " blocking bits: %08x",
+					   blockers);
+		}
+
+		seq_printf(s, "\n");
+	}
+}
+
+void cm_per_dump(struct seq_file *s)
+{
+	__dregs_dump(cm_per, s);
+}
+
+void cm_core_dump(struct seq_file *s)
+{
+	__dregs_dump(cm_core, s);
+}
+
 static int pm_dbg_show_counters(struct seq_file *s, void *unused)
 {
 	pwrdm_for_each(pwrdm_dbg_show_counter, s);
 	clkdm_for_each(clkdm_dbg_show_counter, s);
+	if (cpu_is_omap34xx()) {
+		cm_per_dump(s);
+		cm_core_dump(s);
+	}
 
 	return 0;
 }

Re: power management problems in ehci-omap

[Tony Lindgren]

* Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 16:56]:
> On Tue, 6 Feb 2018 08:04:52 -0800
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> 
> > * Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 06:42]:
> > > rechecked with a board with really nothing connected there
> > > Same behaviour  
> > 
> > I've just verified that my test board power consumption goes
> > back to normal after rmmod ehci-omap with v4.15.
> > 
> yes, for me too, I initially used a test script which does an
> echo rmmod ehci-omap
> 
> without a real
> rmmod ehci-omap

Ah OK :)

> It just seems to be consistent with my observations in a fully booted
> system (where many things can play a role). Sorry for that confusion.

Try with a minimal set of modules first, then modprobe and rmmod one
at a time until you find the module breaking PM?

You probably know this already, but just in case it helps..

First idle the UARTs and enable off mode with something like:

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
	echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
	echo enabled > $uart/wakeup 2>&1
	echo auto > $uart/control 2>&1
done

echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode

Then if using omap3, the attached debug hack patch can be used to
see which devices are not idling:

> But suspend current is a problem. I have repeated the measurement with
> another board, so it is not a board problem. 

I also verified v4.15 behaves for suspend current even with
echi-omap loaded just in case.

Regards,

Tony

8< -------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Wed, 13 Dec 2017 16:36:45 -0800
Subject: [PATCH] NOT FOR MERGING: Test patch for dumping omap3 off idle
 blocking bits

Allows seeing the deeper idle state blockers in
/sys/kernel/debug/pm_debug/count. For example, when
off idle is working on beaglboard xm, this is what
i see:

# sleep 5; cat /sys/kernel/debug/pm_debug/count
...
0006ffff 48005020 (fa005020) cm_idlest_per blocking bits: 00010000
e7ffffbd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042
0000000d 48004a28 (fa004a28) cm_idlest3_core
---
 arch/arm/mach-omap2/pm-debug.c | 68 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -142,10 +142,78 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user)
 	return 0;
 }
 
+#include "iomap.h"
+
+struct dregs {
+	const char	*desc;
+	u32		phys;
+	void __iomem	*virt;
+	u32		mask;
+};
+
+#define PER_CM_BASE	0x48005000
+#define PER_CM_REG(name, offset, mask)				\
+	{ name, PER_CM_BASE + offset,				\
+	OMAP2_L4_IO_ADDRESS(PER_CM_BASE + offset), mask, }
+
+static struct dregs cm_per[] = {
+	PER_CM_REG("cm_idlest_per", 0x20, 0xfff80000), /* p 513 */
+	{ NULL, },
+};
+
+#define CORE_CM_BASE	0x48004a00
+#define CORE_CM_REG(name, offset, mask)				\
+	{ name, CORE_CM_BASE + offset,				\
+	OMAP2_L4_IO_ADDRESS(CORE_CM_BASE + offset), mask, }
+
+static struct dregs cm_core[] = {
+	CORE_CM_REG("cm_idlest1_core", 0x20, 0x9c800109), /* p 467 */
+	CORE_CM_REG("cm_idlest3_core", 0x28, 0xfffffffb),
+	{ NULL, },
+};
+
+void __dregs_dump(struct dregs *dregs, struct seq_file *s)
+{
+	for (; dregs->desc; dregs++) {
+		u32 val, blockers;
+
+		val = __raw_readl(dregs->virt);
+
+		seq_printf(s, "%08x %08x (%p) %s",
+			   val, dregs->phys, dregs->virt,
+			   dregs->desc);
+
+		if (dregs->mask) {
+			blockers = ~val;
+			blockers &= ~dregs->mask;
+
+			if (blockers)
+				seq_printf(s, " blocking bits: %08x",
+					   blockers);
+		}
+
+		seq_printf(s, "\n");
+	}
+}
+
+void cm_per_dump(struct seq_file *s)
+{
+	__dregs_dump(cm_per, s);
+}
+
+void cm_core_dump(struct seq_file *s)
+{
+	__dregs_dump(cm_core, s);
+}
+
 static int pm_dbg_show_counters(struct seq_file *s, void *unused)
 {
 	pwrdm_for_each(pwrdm_dbg_show_counter, s);
 	clkdm_for_each(clkdm_dbg_show_counter, s);
+	if (cpu_is_omap34xx()) {
+		cm_per_dump(s);
+		cm_core_dump(s);
+	}
 
 	return 0;
 }
-- 
2.16.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

power management problems in ehci-omap

[Andreas Kemnade]

On Tue, 6 Feb 2018 09:17:37 -0800
Tony Lindgren <tony@atomide.com> wrote:

> * Andreas Kemnade <andreas@kemnade.info> [180206 16:56]:
> > On Tue, 6 Feb 2018 08:04:52 -0800
> > Tony Lindgren <tony@atomide.com> wrote:
> >   
> > > * Andreas Kemnade <andreas@kemnade.info> [180206 06:42]:  
> > > > rechecked with a board with really nothing connected there
> > > > Same behaviour    
> > > 
> > > I've just verified that my test board power consumption goes
> > > back to normal after rmmod ehci-omap with v4.15.
> > >   
> > yes, for me too, I initially used a test script which does an
> > echo rmmod ehci-omap
> > 
> > without a real
> > rmmod ehci-omap  
> 
> Ah OK :)
> 
> > It just seems to be consistent with my observations in a fully booted
> > system (where many things can play a role). Sorry for that confusion.  
> 
> Try with a minimal set of modules first, then modprobe and rmmod one
> at a time until you find the module breaking PM?
> 
Yes, that is basically what I do with this script:

https://misc.andi.de1.cc/measure4.sh

and

https://misc.andi.de1.cc/measure5.sh

I start from a bare kernel, check currents, load ehci-omap (I have also
debugged many other pm things that way)
check currents again. 
But since my rough observations with a fully loaded system
seem to match with the 
echo rmmod behaviour, I did not notice my mistake.

> You probably know this already, but just in case it helps..
> 
> First idle the UARTs and enable off mode with something like:
> 
> uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
> for uart in $uarts; do
> 	echo 3000 > $uart/autosuspend_delay_ms 2>&1
> done
> 
> uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> for uart in $uarts; do
> 	echo enabled > $uart/wakeup 2>&1
> 	echo auto > $uart/control 2>&1
> done
> 

hmm, this looks a bit like runtime suspend.

I mean suspend aka echo mem >/sys/power/state

> echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode
> 
In earlier times this just caused trouble and a little lower current,
maybe it is time to check again.

> Then if using omap3, the attached debug hack patch can be used to
> see which devices are not idling:
> 
Yes, I will try out. It it about detecting whether the soc itself went
into low power mode. But it does not check e.g. whether the phy is put
into low power mode correctly. So ehci-usb in soc might be powered off
and phy is still on.

When I go to suspend, I get this message:
"Successfully put all powerdomains to target state"

@Nikolaus: Can you check IR at the end of the suspend time in
https://misc.andi.de1.cc/measure5.sh
the second suspend compared with the first whether the phy (the USB
2233) stays on. 

Regards,
Andreas

Re: power management problems in ehci-omap

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

On Tue, 6 Feb 2018 09:17:37 -0800
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:

> * Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 16:56]:
> > On Tue, 6 Feb 2018 08:04:52 -0800
> > Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> >   
> > > * Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 06:42]:  
> > > > rechecked with a board with really nothing connected there
> > > > Same behaviour    
> > > 
> > > I've just verified that my test board power consumption goes
> > > back to normal after rmmod ehci-omap with v4.15.
> > >   
> > yes, for me too, I initially used a test script which does an
> > echo rmmod ehci-omap
> > 
> > without a real
> > rmmod ehci-omap  
> 
> Ah OK :)
> 
> > It just seems to be consistent with my observations in a fully booted
> > system (where many things can play a role). Sorry for that confusion.  
> 
> Try with a minimal set of modules first, then modprobe and rmmod one
> at a time until you find the module breaking PM?
> 
Yes, that is basically what I do with this script:

https://misc.andi.de1.cc/measure4.sh

and

https://misc.andi.de1.cc/measure5.sh

I start from a bare kernel, check currents, load ehci-omap (I have also
debugged many other pm things that way)
check currents again. 
But since my rough observations with a fully loaded system
seem to match with the 
echo rmmod behaviour, I did not notice my mistake.

> You probably know this already, but just in case it helps..
> 
> First idle the UARTs and enable off mode with something like:
> 
> uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
> for uart in $uarts; do
> 	echo 3000 > $uart/autosuspend_delay_ms 2>&1
> done
> 
> uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> for uart in $uarts; do
> 	echo enabled > $uart/wakeup 2>&1
> 	echo auto > $uart/control 2>&1
> done
> 

hmm, this looks a bit like runtime suspend.

I mean suspend aka echo mem >/sys/power/state

> echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode
> 
In earlier times this just caused trouble and a little lower current,
maybe it is time to check again.

> Then if using omap3, the attached debug hack patch can be used to
> see which devices are not idling:
> 
Yes, I will try out. It it about detecting whether the soc itself went
into low power mode. But it does not check e.g. whether the phy is put
into low power mode correctly. So ehci-usb in soc might be powered off
and phy is still on.

When I go to suspend, I get this message:
"Successfully put all powerdomains to target state"

@Nikolaus: Can you check IR at the end of the suspend time in
https://misc.andi.de1.cc/measure5.sh
the second suspend compared with the first whether the phy (the USB
2233) stays on. 

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

power management problems in ehci-omap

[Tony Lindgren]

* Andreas Kemnade <andreas@kemnade.info> [180206 18:04]:
> On Tue, 6 Feb 2018 09:17:37 -0800
> Tony Lindgren <tony@atomide.com> wrote:
> > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> > for uart in $uarts; do
> > 	echo enabled > $uart/wakeup 2>&1
> > 	echo auto > $uart/control 2>&1
> > done
> > 
> 
> hmm, this looks a bit like runtime suspend.

Not only that, it enables wakeup for UART also for suspend :)

That is if your dts has it configured with interrupts-extended
for the console UART like omap3-beagle-xm.dts has for example.
Seems like the gta04 dts don't have these.. And you also want
to have chosen with stdout-path = &uart3 or whatever the debug
UART is for earlycon to work.

> I mean suspend aka echo mem >/sys/power/state
> 
> > echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode

And the above will enable SoC and PMIC off modes, which will also
take the suspend power to some much much lower value :) You need
to configure the PMIC too depending if the oscillator can be turned
off, in that case set "ti,twl4030-power-idle-osc-off". That too
seems to be missing in gta04 dts files..

Regards,

Tony
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Tony Lindgren]

* Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 18:04]:
> On Tue, 6 Feb 2018 09:17:37 -0800
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> > for uart in $uarts; do
> > 	echo enabled > $uart/wakeup 2>&1
> > 	echo auto > $uart/control 2>&1
> > done
> > 
> 
> hmm, this looks a bit like runtime suspend.

Not only that, it enables wakeup for UART also for suspend :)

That is if your dts has it configured with interrupts-extended
for the console UART like omap3-beagle-xm.dts has for example.
Seems like the gta04 dts don't have these.. And you also want
to have chosen with stdout-path = &uart3 or whatever the debug
UART is for earlycon to work.

> I mean suspend aka echo mem >/sys/power/state
> 
> > echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode

And the above will enable SoC and PMIC off modes, which will also
take the suspend power to some much much lower value :) You need
to configure the PMIC too depending if the oscillator can be turned
off, in that case set "ti,twl4030-power-idle-osc-off". That too
seems to be missing in gta04 dts files..

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

power management problems in ehci-omap

[Andreas Kemnade]

On Tue, 6 Feb 2018 10:16:23 -0800
Tony Lindgren <tony@atomide.com> wrote:

> * Andreas Kemnade <andreas@kemnade.info> [180206 18:04]:
> > On Tue, 6 Feb 2018 09:17:37 -0800
> > Tony Lindgren <tony@atomide.com> wrote:  
> > > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> > > for uart in $uarts; do
> > > 	echo enabled > $uart/wakeup 2>&1
> > > 	echo auto > $uart/control 2>&1
> > > done
> > >   
> > 
> > hmm, this looks a bit like runtime suspend.  
> 
> Not only that, it enables wakeup for UART also for suspend :)
> 
We are using the rtc for wakeup and measure discharge of battery
for a time frame of about 300 seconds.

> That is if your dts has it configured with interrupts-extended
> for the console UART like omap3-beagle-xm.dts has for example.
> Seems like the gta04 dts don't have these.. And you also want
> to have chosen with stdout-path = &uart3 or whatever the debug
> UART is for earlycon to work.
> 
> > I mean suspend aka echo mem >/sys/power/state
> >   
> > > echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode  
> 
> And the above will enable SoC and PMIC off modes, which will also
> take the suspend power to some much much lower value :) You need
> to configure the PMIC too depending if the oscillator can be turned
> off, in that case set "ti,twl4030-power-idle-osc-off". That too
> seems to be missing in gta04 dts files..
> 
It was in our tree. It can be enabled for the gta04a5. We have even done
that. But then suspend while charging breaks. I have no idea how to do a
proper if-not-charging-power-idle-osc-off patch... 

Yes there are other places where we can optimize suspend current. But
lets first find out why ehci-omap seems to cause trouble here.
So we are looking for around 15mA of additional suspend current when the
module is loaded. 
Shouldn't the reset line of the phy (usb-nop-xceiv) be set to low when
going to suspend? I do not see code how to do it. I guess that is the
reason.

BTW:
root@letux:~# cat /sys/bus/platform/devices/48064800.ehci/power/runtime_status 
active

Regards,
Andreas

Re: power management problems in ehci-omap

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

On Tue, 6 Feb 2018 10:16:23 -0800
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:

> * Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 18:04]:
> > On Tue, 6 Feb 2018 09:17:37 -0800
> > Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:  
> > > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> > > for uart in $uarts; do
> > > 	echo enabled > $uart/wakeup 2>&1
> > > 	echo auto > $uart/control 2>&1
> > > done
> > >   
> > 
> > hmm, this looks a bit like runtime suspend.  
> 
> Not only that, it enables wakeup for UART also for suspend :)
> 
We are using the rtc for wakeup and measure discharge of battery
for a time frame of about 300 seconds.

> That is if your dts has it configured with interrupts-extended
> for the console UART like omap3-beagle-xm.dts has for example.
> Seems like the gta04 dts don't have these.. And you also want
> to have chosen with stdout-path = &uart3 or whatever the debug
> UART is for earlycon to work.
> 
> > I mean suspend aka echo mem >/sys/power/state
> >   
> > > echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode  
> 
> And the above will enable SoC and PMIC off modes, which will also
> take the suspend power to some much much lower value :) You need
> to configure the PMIC too depending if the oscillator can be turned
> off, in that case set "ti,twl4030-power-idle-osc-off". That too
> seems to be missing in gta04 dts files..
> 
It was in our tree. It can be enabled for the gta04a5. We have even done
that. But then suspend while charging breaks. I have no idea how to do a
proper if-not-charging-power-idle-osc-off patch... 

Yes there are other places where we can optimize suspend current. But
lets first find out why ehci-omap seems to cause trouble here.
So we are looking for around 15mA of additional suspend current when the
module is loaded. 
Shouldn't the reset line of the phy (usb-nop-xceiv) be set to low when
going to suspend? I do not see code how to do it. I guess that is the
reason.

BTW:
root@letux:~# cat /sys/bus/platform/devices/48064800.ehci/power/runtime_status 
active

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

power management problems in ehci-omap

[Roger Quadros]

Hi,

On 06/02/18 20:40, Andreas Kemnade wrote:
> On Tue, 6 Feb 2018 10:16:23 -0800
> Tony Lindgren <tony@atomide.com> wrote:
> 
>> * Andreas Kemnade <andreas@kemnade.info> [180206 18:04]:
>>> On Tue, 6 Feb 2018 09:17:37 -0800
>>> Tony Lindgren <tony@atomide.com> wrote:  
>>>> uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
>>>> for uart in $uarts; do
>>>> 	echo enabled > $uart/wakeup 2>&1
>>>> 	echo auto > $uart/control 2>&1
>>>> done
>>>>   
>>>
>>> hmm, this looks a bit like runtime suspend.  
>>
>> Not only that, it enables wakeup for UART also for suspend :)
>>
> We are using the rtc for wakeup and measure discharge of battery
> for a time frame of about 300 seconds.
> 
>> That is if your dts has it configured with interrupts-extended
>> for the console UART like omap3-beagle-xm.dts has for example.
>> Seems like the gta04 dts don't have these.. And you also want
>> to have chosen with stdout-path = &uart3 or whatever the debug
>> UART is for earlycon to work.
>>
>>> I mean suspend aka echo mem >/sys/power/state
>>>   
>>>> echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode  
>>
>> And the above will enable SoC and PMIC off modes, which will also
>> take the suspend power to some much much lower value :) You need
>> to configure the PMIC too depending if the oscillator can be turned
>> off, in that case set "ti,twl4030-power-idle-osc-off". That too
>> seems to be missing in gta04 dts files..
>>
> It was in our tree. It can be enabled for the gta04a5. We have even done
> that. But then suspend while charging breaks. I have no idea how to do a
> proper if-not-charging-power-idle-osc-off patch... 
> 
> Yes there are other places where we can optimize suspend current. But
> lets first find out why ehci-omap seems to cause trouble here.
> So we are looking for around 15mA of additional suspend current when the
> module is loaded. 
> Shouldn't the reset line of the phy (usb-nop-xceiv) be set to low when
> going to suspend? I do not see code how to do it. I guess that is the
> reason.
> 
> BTW:
> root@letux:~# cat /sys/bus/platform/devices/48064800.ehci/power/runtime_status 
> active


PM handling is not yet there in the ehci-omap driver.

> static struct platform_driver ehci_hcd_omap_driver = {
>         .probe                  = ehci_hcd_omap_probe,
>         .remove                 = ehci_hcd_omap_remove,
>         .shutdown               = usb_hcd_platform_shutdown,
>         /*.suspend              = ehci_hcd_omap_suspend, */
>         /*.resume               = ehci_hcd_omap_resume, */
>         .driver = {
>                 .name           = hcd_name,
>                 .of_match_table = omap_ehci_dt_ids,
>         }
> };

There is also some co-relation with the parent driver
drivers/mfd/omap-usb-host.c

Getting low power on system suspend should be easy as we most probably don't
need wakeup to work in this case. This should fix the increased power during
system suspend.

To fix active power consumption we need to implement runtime PM.
However, for runtime suspend case we do need remote-wakeup to work else we
won't be able to detect any new USB devices after the host runtime suspends.
For this we need to remux one of the PHY lines into a GPIO to capture the wake event.
This is where the generic wakeirq support comes in.

Re: power management problems in ehci-omap

[Roger Quadros]

Hi,

On 06/02/18 20:40, Andreas Kemnade wrote:
> On Tue, 6 Feb 2018 10:16:23 -0800
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> 
>> * Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 18:04]:
>>> On Tue, 6 Feb 2018 09:17:37 -0800
>>> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:  
>>>> uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
>>>> for uart in $uarts; do
>>>> 	echo enabled > $uart/wakeup 2>&1
>>>> 	echo auto > $uart/control 2>&1
>>>> done
>>>>   
>>>
>>> hmm, this looks a bit like runtime suspend.  
>>
>> Not only that, it enables wakeup for UART also for suspend :)
>>
> We are using the rtc for wakeup and measure discharge of battery
> for a time frame of about 300 seconds.
> 
>> That is if your dts has it configured with interrupts-extended
>> for the console UART like omap3-beagle-xm.dts has for example.
>> Seems like the gta04 dts don't have these.. And you also want
>> to have chosen with stdout-path = &uart3 or whatever the debug
>> UART is for earlycon to work.
>>
>>> I mean suspend aka echo mem >/sys/power/state
>>>   
>>>> echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode  
>>
>> And the above will enable SoC and PMIC off modes, which will also
>> take the suspend power to some much much lower value :) You need
>> to configure the PMIC too depending if the oscillator can be turned
>> off, in that case set "ti,twl4030-power-idle-osc-off". That too
>> seems to be missing in gta04 dts files..
>>
> It was in our tree. It can be enabled for the gta04a5. We have even done
> that. But then suspend while charging breaks. I have no idea how to do a
> proper if-not-charging-power-idle-osc-off patch... 
> 
> Yes there are other places where we can optimize suspend current. But
> lets first find out why ehci-omap seems to cause trouble here.
> So we are looking for around 15mA of additional suspend current when the
> module is loaded. 
> Shouldn't the reset line of the phy (usb-nop-xceiv) be set to low when
> going to suspend? I do not see code how to do it. I guess that is the
> reason.
> 
> BTW:
> root@letux:~# cat /sys/bus/platform/devices/48064800.ehci/power/runtime_status 
> active


PM handling is not yet there in the ehci-omap driver.

> static struct platform_driver ehci_hcd_omap_driver = {
>         .probe                  = ehci_hcd_omap_probe,
>         .remove                 = ehci_hcd_omap_remove,
>         .shutdown               = usb_hcd_platform_shutdown,
>         /*.suspend              = ehci_hcd_omap_suspend, */
>         /*.resume               = ehci_hcd_omap_resume, */
>         .driver = {
>                 .name           = hcd_name,
>                 .of_match_table = omap_ehci_dt_ids,
>         }
> };

There is also some co-relation with the parent driver
drivers/mfd/omap-usb-host.c

Getting low power on system suspend should be easy as we most probably don't
need wakeup to work in this case. This should fix the increased power during
system suspend.

To fix active power consumption we need to implement runtime PM.
However, for runtime suspend case we do need remote-wakeup to work else we
won't be able to detect any new USB devices after the host runtime suspends.
For this we need to remux one of the PHY lines into a GPIO to capture the wake event.
This is where the generic wakeirq support comes in.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html