[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eb63b7c2-9485-4b11-bf73-4d38a2365f19@quicinc.com>
Date: Mon, 1 Jul 2024 12:18:19 -0700
From: Sagar Cheluvegowda <quic_scheluve@...cinc.com>
To: Andrew Halaney <ahalaney@...hat.com>
CC: Vinod Koul <vkoul@...nel.org>,
Alexandre Torgue
<alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
"David S.
Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
"Jakub
Kicinski" <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin
<mcoquelin.stm32@...il.com>,
Russell King <linux@...linux.org.uk>, "Rob
Herring" <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
"Conor
Dooley" <conor+dt@...nel.org>,
Bhupesh Sharma <bhupesh.sharma@...aro.org>, <kernel@...cinc.com>,
Andrew Lunn <andrew@...n.ch>, <linux-arm-msm@...r.kernel.org>,
<netdev@...r.kernel.org>, <linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
<devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] net: stmmac: Bring down the clocks to lower
frequencies when mac link goes down
On 6/28/2024 2:50 PM, Sagar Cheluvegowda wrote:
>
>
> On 6/26/2024 7:58 AM, Andrew Halaney wrote:
>> On Tue, Jun 25, 2024 at 04:49:30PM GMT, Sagar Cheluvegowda wrote:
>>> When mac link goes down we don't need to mainitain the clocks to operate
>>> at higher frequencies, as an optimized solution to save power when
>>> the link goes down we are trying to bring down the clocks to the
>>> frequencies corresponding to the lowest speed possible.
>>>
>>> Signed-off-by: Sagar Cheluvegowda <quic_scheluve@...cinc.com>
>>> ---
>>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> index ec7c61ee44d4..f0166f0bc25f 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -996,6 +996,9 @@ static void stmmac_mac_link_down(struct phylink_config *config,
>>> {
>>> struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
>>>
>>> + if (priv->plat->fix_mac_speed)
>>> + priv->plat->fix_mac_speed(priv->plat->bsp_priv, SPEED_10, mode);
>>> +
The above fix_mac_speed needs to be removed, i lately realized this mistake.
>>> stmmac_mac_set(priv, priv->ioaddr, false);
>>> priv->eee_active = false;
>>> priv->tx_lpi_enabled = false;
>>> @@ -1004,6 +1007,11 @@ static void stmmac_mac_link_down(struct phylink_config *config,
>>>
>>> if (priv->dma_cap.fpesel)
>>> stmmac_fpe_link_state_handle(priv, false);
>>> +
>>> + stmmac_set_icc_bw(priv, SPEED_10);
>>> +
>>> + if (priv->plat->fix_mac_speed)
>>> + priv->plat->fix_mac_speed(priv->plat->bsp_priv, SPEED_10, mode);
>>
>>
>> I think you're doing this at the beginning and end of
>> stmmac_mac_link_down(), is that intentional?
>>
>>
>
> I realised that bringing down the clock to 10Mbps should be the last operation
> of the link down process, the reason being if we bring down the clocks first it will
> deprive essential internal clocks to DMA/MTL modules which are required for
> Cleanup operations this might cause excessive delays in stopping DMA
> or flusing MTL queues.
>
>>
Powered by blists - more mailing lists