linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Michael Chan <mchan@broadcom.com>,
	"open list:BROADCOM ETHERNET PHY DRIVERS" 
	<bcm-kernel-feedback-list@broadcom.com>,
	open list <linux-kernel@vger.kernel.org>,
	michael@walle.cc
Subject: Re: [PATCH net-next v2 3/3] net: phy: broadcom: Allow BCM54210E to configure APD
Date: Fri, 5 Mar 2021 03:08:45 +0200	[thread overview]
Message-ID: <20210305010845.blqccudijh6ezm6a@skbuf> (raw)
In-Reply-To: <99e28317-e93d-88fa-f43f-d1d072b61292@gmail.com>

On Tue, Mar 02, 2021 at 07:37:34PM -0800, Florian Fainelli wrote:
> Took a while but for the 54210E reference board here are the numbers,
> your mileage will vary depending on the supplies, regulator efficiency
> and PCB design around the PHY obviously:
> 
> BMCR.PDOWN:			86.12 mW
> auto-power down:		77.84 mW

Quite curious that the APD power is lower than the normal BMCR.PDOWN
value. As far as my understanding goes, when in APD mode, the PHY even
wakes up from time to time to send pulses to the link partner?

> auto-power-down, DLL disabled:  30.83 mW

The jump from simple APD to APD with DLL disabled is pretty big.
Correct me if I'm wrong, but there's an intermediary step which was not
measured, where the CLK125 is disabled but the internal DLL (Delay
Locked Loop?) is still enabled. I think powering off the internal DLL
also implies powering off the CLK125 pin, at least that's how the PHY
driver treats things at the moment. But we don't know if the huge
reduction in power is due just to CLK125 or the DLL (it's more likely
it's due to both, in equal amounts).

Anyway, it's great to have some results which tell us exactly what is
worthwhile and what isn't. In other news, I've added the BCM5464 to the
list of PHYs with APD and I didn't see any issues thus far.

> IDDQ-low power:			 9.85 mW (requires a RESETn toggle)
> IDDQ with soft recovery:	10.75 mW
> 
> Interestingly, the 50212E that I am using requires writing the PDOWN bit
> and only that bit (not a RMW) in order to get in a correct state, both
> LEDs keep flashing when that happens, fixes coming.
> 
> When net-next opens back up I will submit patches to support IDDQ with
> soft recovery since that is clearly much better than the standard power
> down and it does not require a RESETn toggle.

Iddq must be the quiescent supply current, isn't it (but in that case,
I'm a bit confused to not see a value in mA)? Is it an actual operating
mode (I don't see anything about that mentioned in the BCM5464 sheet)
and if it is, what is there exactly to support?

  reply	other threads:[~2021-03-05  1:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-13  3:46 [PATCH net-next v2 0/3] net: phy: broadcom: Cleanups and APD Florian Fainelli
2021-02-13  3:46 ` [PATCH net-next v2 1/3] net: phy: broadcom: Avoid forward for bcm54xx_config_clock_delay() Florian Fainelli
2021-02-13 10:31   ` Vladimir Oltean
2021-02-13  3:46 ` [PATCH net-next v2 2/3] net: phy: broadcom: Remove unused flags Florian Fainelli
2021-02-13 10:33   ` Vladimir Oltean
2021-02-13  3:46 ` [PATCH net-next v2 3/3] net: phy: broadcom: Allow BCM54210E to configure APD Florian Fainelli
2021-02-13 10:42   ` Vladimir Oltean
2021-02-15  4:29     ` Florian Fainelli
2021-03-03  3:37       ` Florian Fainelli
2021-03-05  1:08         ` Vladimir Oltean [this message]
2021-03-06  4:26           ` Florian Fainelli
2021-02-15 23:20 ` [PATCH net-next v2 0/3] net: phy: broadcom: Cleanups and APD patchwork-bot+netdevbpf

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20210305010845.blqccudijh6ezm6a@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mchan@broadcom.com \
    --cc=michael@walle.cc \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

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

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