smsc911x suspend/resume

smsc911x suspend/resume

[Mike Rapoport]

Hi all,
I'm trying to make suspend/resume work on OMAP3-based system and I'm
encountering issues with resume of SMSC 9220 chip.
After resume the interface is unusable unless I do 'ifconfig eth0 down'
and 'ifconfig eth0 up'.
I would expect that 'ping <some host>' would work right after resume
without need to bring the interface down and up, but probably I miss
something.
Any help would be appreciated.

-- 
Sincerely yours,
Mike.

Re: smsc911x suspend/resume

[Daniel Mack]

On Mon, Feb 08, 2010 at 11:42:27AM +0200, Mike Rapoport wrote:
> I'm trying to make suspend/resume work on OMAP3-based system and I'm
> encountering issues with resume of SMSC 9220 chip.
> After resume the interface is unusable unless I do 'ifconfig eth0 down'
> and 'ifconfig eth0 up'.
> I would expect that 'ping <some host>' would work right after resume
> without need to bring the interface down and up, but probably I miss
> something.
> Any help would be appreciated.

What happens to your supply voltages when going to suspend? When I
implemented the code for the smsc driver, I could only test scenarios
where AVDD remains stable during suspend. So the driver might need some
tweaks if that assumption is not true in your case. The SMSC datasheet
is quite comprehensive about this topic IIRC.

Also have a look at the Raumfeld device patches which use exactly this
chip and which can suspend and resume just fine. You'll need to check
out Eric's devel branch for that.

Daniel

Re: smsc911x suspend/resume

[Mike Rapoport]

Daniel Mack wrote:
> On Mon, Feb 08, 2010 at 11:42:27AM +0200, Mike Rapoport wrote:
>> I'm trying to make suspend/resume work on OMAP3-based system and I'm
>> encountering issues with resume of SMSC 9220 chip.
>> After resume the interface is unusable unless I do 'ifconfig eth0 down'
>> and 'ifconfig eth0 up'.
>> I would expect that 'ping <some host>' would work right after resume
>> without need to bring the interface down and up, but probably I miss
>> something.
>> Any help would be appreciated.
> 
> What happens to your supply voltages when going to suspend? When I
> implemented the code for the smsc driver, I could only test scenarios
> where AVDD remains stable during suspend. So the driver might need some
> tweaks if that assumption is not true in your case. The SMSC datasheet
> is quite comprehensive about this topic IIRC.

By AVDD you mean VDD33A?
Anyway, I have all the supplies except VDDVARIO shut down...
And the datasheet is indeed comprehensively describes chip power states
but I haven't found there anything about supplies required to stay on
during suspend...


> Also have a look at the Raumfeld device patches which use exactly this
> chip and which can suspend and resume just fine. You'll need to check
> out Eric's devel branch for that.
> 
> Daniel
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Sincerely yours,
Mike.

Re: smsc911x suspend/resume

[Daniel Mack]

On Mon, Feb 08, 2010 at 01:30:42PM +0200, Mike Rapoport wrote:
> Daniel Mack wrote:
> > What happens to your supply voltages when going to suspend? When I
> > implemented the code for the smsc driver, I could only test scenarios
> > where AVDD remains stable during suspend. So the driver might need some
> > tweaks if that assumption is not true in your case. The SMSC datasheet
> > is quite comprehensive about this topic IIRC.
> 
> By AVDD you mean VDD33A?

Yes.

> Anyway, I have all the supplies except VDDVARIO shut down...
> And the datasheet is indeed comprehensively describes chip power states
> but I haven't found there anything about supplies required to stay on
> during suspend...

In fact the datasheet doesn't really state that, and the chip seems
to expect the power domains to remain switched on during suspend, and
all power switching is done internally. Also the table in "7.4 Power
Consumption (Device and System Components)" describes it like that.

So it all comes down to the question of how low-power you need to be,
and whether you need wake-on-lan or not. What's currently implemented is
D1, but adding support for D2 should be easy.

Daniel

Re: smsc911x suspend/resume

[Mike Rapoport]

Daniel Mack wrote:
> On Mon, Feb 08, 2010 at 01:30:42PM +0200, Mike Rapoport wrote:
>> Daniel Mack wrote:
>>> What happens to your supply voltages when going to suspend? When I
>>> implemented the code for the smsc driver, I could only test scenarios
>>> where AVDD remains stable during suspend. So the driver might need some
>>> tweaks if that assumption is not true in your case. The SMSC datasheet
>>> is quite comprehensive about this topic IIRC.
>> By AVDD you mean VDD33A?
> 
> Yes.
> 
>> Anyway, I have all the supplies except VDDVARIO shut down...
>> And the datasheet is indeed comprehensively describes chip power states
>> but I haven't found there anything about supplies required to stay on
>> during suspend...
> 
> In fact the datasheet doesn't really state that, and the chip seems
> to expect the power domains to remain switched on during suspend, and
> all power switching is done internally. Also the table in "7.4 Power
> Consumption (Device and System Components)" describes it like that.
> 
> So it all comes down to the question of how low-power you need to be,
> and whether you need wake-on-lan or not. What's currently implemented is
> D1, but adding support for D2 should be easy.

I did some brute force save/restore of smsc9220 registers and it seems
to wake up now.
The question now is how to make it in a "generic" way ...
Thanks for the help anyway :)

> Daniel


-- 
Sincerely yours,
Mike.

Re: smsc911x suspend/resume

[Daniel Mack]

On Mon, Feb 08, 2010 at 04:42:25PM +0200, Mike Rapoport wrote:
> Daniel Mack wrote:
> > In fact the datasheet doesn't really state that, and the chip seems
> > to expect the power domains to remain switched on during suspend, and
> > all power switching is done internally. Also the table in "7.4 Power
> > Consumption (Device and System Components)" describes it like that.
> > 
> > So it all comes down to the question of how low-power you need to be,
> > and whether you need wake-on-lan or not. What's currently implemented is
> > D1, but adding support for D2 should be easy.
> 
> I did some brute force save/restore of smsc9220 registers and it seems
> to wake up now.
> The question now is how to make it in a "generic" way ...
> Thanks for the help anyway :)

Hmm, be careful about switching off power supplies that aren't supposed
to be switched off while others are still powered. You can easily
destroy hardware with that. Depending on how things are wired up
internally, voltages can leak from one unit block to the other. Maybe
Steve can can give a statement from official SMSC source about whether
it is safe to switch off VDD33A in this case.

Anyway, from what's written in the datasheet, I wouldn't dare just
blindly doing it.

Daniel

Re: smsc911x suspend/resume

[Mike Rapoport]

Daniel Mack wrote:
> On Mon, Feb 08, 2010 at 04:42:25PM +0200, Mike Rapoport wrote:
>> Daniel Mack wrote:
>>> In fact the datasheet doesn't really state that, and the chip seems
>>> to expect the power domains to remain switched on during suspend, and
>>> all power switching is done internally. Also the table in "7.4 Power
>>> Consumption (Device and System Components)" describes it like that.
>>>
>>> So it all comes down to the question of how low-power you need to be,
>>> and whether you need wake-on-lan or not. What's currently implemented is
>>> D1, but adding support for D2 should be easy.
>> I did some brute force save/restore of smsc9220 registers and it seems
>> to wake up now.
>> The question now is how to make it in a "generic" way ...
>> Thanks for the help anyway :)
> 
> Hmm, be careful about switching off power supplies that aren't supposed
> to be switched off while others are still powered. You can easily
> destroy hardware with that. Depending on how things are wired up
> internally, voltages can leak from one unit block to the other. Maybe
> Steve can can give a statement from official SMSC source about whether
> it is safe to switch off VDD33A in this case.
> 
> Anyway, from what's written in the datasheet, I wouldn't dare just
> blindly doing it.

I haven't dig too much in the datasheet, but I cannot remember anything
about keeping certain power supplies on during suspend. The only clue is
your comment in the driver that states
"/* This implementation assumes the devices remains powered on its VDDVARIO
  * pins during suspend. */"
And the platform I have either disables all supplies but VDDVARIO or keeps them
all up.
Anyway, I'll leave it running sleep/resume/ping cycle overnight to see in the
morning what have burned :)



> Daniel


-- 
Sincerely yours,
Mike.

Re: smsc911x suspend/resume

[Steve.Glendinning]

> Hmm, be careful about switching off power supplies that aren't supposed
> to be switched off while others are still powered. You can easily
> destroy hardware with that. Depending on how things are wired up
> internally, voltages can leak from one unit block to the other. Maybe
> Steve can can give a statement from official SMSC source about whether
> it is safe to switch off VDD33A in this case.

I've checked with the chip architects, no power planes should be 
externally
switched off in any suspend mode.

Steve

Re: smsc911x suspend/resume

[mike]

On Thu, Feb 11, 2010 at 06:26:32PM +0000, Steve.Glendinning@smsc.com wrote:
> > Hmm, be careful about switching off power supplies that aren't supposed
> > to be switched off while others are still powered. You can easily
> > destroy hardware with that. Depending on how things are wired up
> > internally, voltages can leak from one unit block to the other. Maybe
> > Steve can can give a statement from official SMSC source about whether
> > it is safe to switch off VDD33A in this case.
> 
> I've checked with the chip architects, no power planes should be 
> externally
> switched off in any suspend mode.

The question if they *can* be switched off. With the hardware I have,
most of 3.3V supplies are enabled/disabled with the same control. So, to
have maximal power saving in the system, I just pull this control to
disable 3.3V supplies, VDD33A among them. If smsc9220 can tolerate
switching VDD33A during suspend, I can send a patch that allows proper
wake-up with such conditions.

> Steve

Re: smsc911x suspend/resume

[Steve.Glendinning]

Hi Mike,

> >> I'm trying to make suspend/resume work on OMAP3-based system and I'm
> >> encountering issues with resume of SMSC 9220 chip.
> >> After resume the interface is unusable unless I do 'ifconfig eth0 
down'
> >> and 'ifconfig eth0 up'.
> >> I would expect that 'ping <some host>' would work right after resume
> >> without need to bring the interface down and up, but probably I miss
> >> something.
> >> Any help would be appreciated.
> > 
> > What happens to your supply voltages when going to suspend? When I
> > implemented the code for the smsc driver, I could only test scenarios
> > where AVDD remains stable during suspend. So the driver might need 
some
> > tweaks if that assumption is not true in your case. The SMSC datasheet
> > is quite comprehensive about this topic IIRC.
> 
> By AVDD you mean VDD33A?
> Anyway, I have all the supplies except VDDVARIO shut down...
> And the datasheet is indeed comprehensively describes chip power states
> but I haven't found there anything about supplies required to stay on
> during suspend...

I don't have the code in front of me (I'm travelling today) but IIRC
the driver doesn't place the LAN9220 in a specific power saving state,
so as far as the LAN9220 is concerned it's not actually suspended.

It's hard to do this in a "generic" way: some people expect their link
to stay up during suspend, some want suspend to completely power down
the ethernet chip, and some want to use one of several WoL modes. 

David: What's the "done thing" here for similar non-pci drivers?
Obviously "doesn't work after suspend" isn't the intended behaviour, so
there's definitely room for improvement!

> > Also have a look at the Raumfeld device patches which use exactly this
> > chip and which can suspend and resume just fine. You'll need to check
> > out Eric's devel branch for that.

Daniel: I haven't seen this, do you have a location for the git tree?

Thanks,
Steve

Re: smsc911x suspend/resume

[Daniel Mack]

On Mon, Feb 08, 2010 at 11:46:39AM +0000, Steve.Glendinning@smsc.com wrote:
> > Anyway, I have all the supplies except VDDVARIO shut down...
> > And the datasheet is indeed comprehensively describes chip power states
> > but I haven't found there anything about supplies required to stay on
> > during suspend...
> 
> I don't have the code in front of me (I'm travelling today) but IIRC
> the driver doesn't place the LAN9220 in a specific power saving state,
> so as far as the LAN9220 is concerned it's not actually suspended.

It does, I added that awhile back in b6907b0c7. But as I say, this is
currently hard-coded to D1, and if support for D2 is desired, we would
need to make that a platform data option.

> It's hard to do this in a "generic" way: some people expect their link
> to stay up during suspend, some want suspend to completely power down
> the ethernet chip, and some want to use one of several WoL modes. 
> 
> David: What's the "done thing" here for similar non-pci drivers?
> Obviously "doesn't work after suspend" isn't the intended behaviour, so
> there's definitely room for improvement!
> 
> > > Also have a look at the Raumfeld device patches which use exactly this
> > > chip and which can suspend and resume just fine. You'll need to check
> > > out Eric's devel branch for that.
> 
> Daniel: I haven't seen this, do you have a location for the git tree?

git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git

See the 'devel' branch. But there's actually nothing exciting in there,
it's just a simple platform support.

Daniel

Re: smsc911x suspend/resume

[Steve.Glendinning]

> > I don't have the code in front of me (I'm travelling today) but IIRC
> > the driver doesn't place the LAN9220 in a specific power saving state,
> > so as far as the LAN9220 is concerned it's not actually suspended.
> 
> It does, I added that awhile back in b6907b0c7. But as I say, this is
> currently hard-coded to D1, and if support for D2 is desired, we would
> need to make that a platform data option.

You're right, and I should remember as I reviewed it!

Steve

Re: smsc911x suspend/resume

[Mike Rapoport]

Steve.Glendinning@smsc.com wrote:
> Hi Mike,
> 
>>>> I'm trying to make suspend/resume work on OMAP3-based system and I'm
>>>> encountering issues with resume of SMSC 9220 chip.
>>>> After resume the interface is unusable unless I do 'ifconfig eth0 
> down'
>>>> and 'ifconfig eth0 up'.
>>>> I would expect that 'ping <some host>' would work right after resume
>>>> without need to bring the interface down and up, but probably I miss
>>>> something.
>>>> Any help would be appreciated.
>>> What happens to your supply voltages when going to suspend? When I
>>> implemented the code for the smsc driver, I could only test scenarios
>>> where AVDD remains stable during suspend. So the driver might need 
> some
>>> tweaks if that assumption is not true in your case. The SMSC datasheet
>>> is quite comprehensive about this topic IIRC.
>> By AVDD you mean VDD33A?
>> Anyway, I have all the supplies except VDDVARIO shut down...
>> And the datasheet is indeed comprehensively describes chip power states
>> but I haven't found there anything about supplies required to stay on
>> during suspend...
> 
> I don't have the code in front of me (I'm travelling today) but IIRC
> the driver doesn't place the LAN9220 in a specific power saving state,
> so as far as the LAN9220 is concerned it's not actually suspended.
> 
> It's hard to do this in a "generic" way: some people expect their link
> to stay up during suspend, some want suspend to completely power down
> the ethernet chip, and some want to use one of several WoL modes. 

Indeed a "generic" implementation may be tough task... Probably we can
add some platform_data flags for suspend modes and use them to decide
what low power mode should be selected?

> David: What's the "done thing" here for similar non-pci drivers?
> Obviously "doesn't work after suspend" isn't the intended behaviour, so
> there's definitely room for improvement!
> 
>>> Also have a look at the Raumfeld device patches which use exactly this
>>> chip and which can suspend and resume just fine. You'll need to check
>>> out Eric's devel branch for that.
> 
> Daniel: I haven't seen this, do you have a location for the git tree?
> 
> Thanks,
> Steve


-- 
Sincerely yours,
Mike.