netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
	srinivas.kandagatla@st.com, deepak.sikri@st.com,
	spear-devel@list.st.com, shiraz.hashim@st.com,
	viresh.kumar@st.com, bhutchings@solarflare.com
Subject: Re: [PATCH 09/10] stmmac: MDC clock dynamically based on the csr clock input
Date: Mon, 02 Apr 2012 13:17:22 +0200	[thread overview]
Message-ID: <4F798AC2.4090909@st.com> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6EB8@saturn3.aculab.com>

On 3/23/2012 10:53 AM, David Laight wrote:
>  
> 
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org 
>> [mailto:netdev-owner@vger.kernel.org] On Behalf Of Giuseppe CAVALLARO
>> Sent: 23 March 2012 09:09
>> To: netdev@vger.kernel.org
>> Cc: davem@davemloft.net; srinivas.kandagatla@st.com; 
>> deepak.sikri@st.com; spear-devel@list.st.com; 
>> shiraz.hashim@st.com; viresh.kumar@st.com; 
>> bhutchings@solarflare.com; Giuseppe Cavallaro
>> Subject: [PATCH 09/10] stmmac: MDC clock dynamically based on 
>> the csr clock input
>>
>> If a specific clk_csr value is passed from the platform
>> this means that the CSR Clock Range selection cannot be
>> changed at run-time and it is fixed (as reported in the driver
>> documentation). Viceversa the driver will try to set the MDC
>> clock dynamically according to the actual clock input.
>>
>> Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
>> Reviewed-by: Francesco Virlinzi <francesco.virlinzi@st.com>
>> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> ---
>>  Documentation/networking/stmmac.txt               |    2 +-
>>  drivers/net/ethernet/stmicro/stmmac/common.h      |   10 +++++
>>  drivers/net/ethernet/stmicro/stmmac/stmmac.h      |    1 +
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |   40 
>> +++++++++++++++++++++
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |    4 +-
>>  5 files changed, 54 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/networking/stmmac.txt 
>> b/Documentation/networking/stmmac.txt
>> index eacb640..ab1e8d7 100644
>> --- a/Documentation/networking/stmmac.txt
>> +++ b/Documentation/networking/stmmac.txt
>> @@ -137,7 +137,7 @@ Where:
>>   o pbl: the Programmable Burst Length is maximum number of beats to
>>         be transferred in one DMA transaction.
>>         GMAC also enables the 4xPBL by default.
>> - o clk_csr: CSR Clock range selection.
>> + o clk_csr: fixed CSR Clock range selection.
>>   o has_gmac: uses the GMAC core.
>>   o enh_desc: if sets the MAC will use the enhanced 
>> descriptor structure.
>>   o tx_coe: core is able to perform the tx csum in HW.
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>> index f4df1eb..312e3f1 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>> @@ -97,6 +97,16 @@ struct stmmac_extra_stats {
>>  	unsigned long normal_irq_n;
>>  };
>>  
>> +/* CSR Frequency Access Defines*/
>> +#define CSR_F_35M	35000000
>> +#define CSR_F_60M	60000000
>> +#define CSR_F_100M	100000000
>> +#define CSR_F_150M	150000000
>> +#define CSR_F_250M	50000000
>> +#define CSR_F_300M	300000000
> 
> The value of CSR_F_250M looks like a typo.

yes you are right, I'll fix it and re-send the all patches.

> These defines look rather pointless to me though!
> 
> Another patch has:
>> -----------------------------------------
>> 	Selection	MDC Clock
>> -----------------------------------------
>> 	1000 		clk_csr_i/4
>> 	1001 		clk_csr_i/6
>> 	1010 		clk_csr_i/8
>> 	1011 		clk_csr_i/10
>> 	1100 		clk_csr_i/12
>> 	1101	 	clk_csr_i/14
>> 	1110 		clk_csr_i/16
>> 	1111 		clk_csr_i/18
> I detect a pattern ...

On this mac, the MDC clock can be set by user in several ways.
if the bit Reg4 bit 5 is 0 so the clock divisor will be driven according
to a fixed range of frq (CSR_F_35M & CO).
If the bit 5 is set then "custom" divisors can be used.
I know it's quite tricky but these patches (from SPEAr) that I reviewed,
indeed, added an useful fix to  dynamically set the MDC clock according
to the actual clock source. This also helped somebody on custom boards.

Peppe

> 
> 	David
> 
> 
> 
> 

  reply	other threads:[~2012-04-02 11:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-23  9:08 [PATCH 00/10] stmmac update: March 2012 Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 01/10] stmmac: Allow stmmac to work with other PHY buses(v3) Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 02/10] stmmac: Define CSUM offload engine Types Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 03/10] stmmac: sanitize the rx coe and add the type-1 csum Giuseppe CAVALLARO
2012-03-24  9:21   ` deepaksi
2012-04-02 11:07     ` Giuseppe CAVALLARO
2012-04-02 16:18       ` deepaksi
2012-04-03  6:49         ` Giuseppe CAVALLARO
2012-04-03  7:56           ` deepaksi
2012-04-03 13:03             ` Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 04/10] stmmac: Define MDC clock selection macros Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 05/10] stmmac: re-work the internal GMAC DMA platf parameters Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 06/10] stmmac: Replace infinite loops by timeouts in mdio r/w Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 07/10] stmmac: add clk management support Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 08/10] stmmac: extend CSR Clock Range programming Giuseppe CAVALLARO
2012-03-23  9:08 ` [PATCH 09/10] stmmac: MDC clock dynamically based on the csr clock input Giuseppe CAVALLARO
2012-03-23  9:53   ` David Laight
2012-04-02 11:17     ` Giuseppe CAVALLARO [this message]
2012-03-23  9:08 ` [PATCH 10/10] stmmac: update the driver version March 2012 Giuseppe CAVALLARO
  -- strict thread matches above, loose matches on Subject: below --
2012-04-04 14:33 [PATCH 00/10] stmmac update: March 2012 (v2) Giuseppe CAVALLARO
2012-04-04 14:33 ` [PATCH 09/10] stmmac: MDC clock dynamically based on the csr clock input Giuseppe CAVALLARO

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=4F798AC2.4090909@st.com \
    --to=peppe.cavallaro@st.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=deepak.sikri@st.com \
    --cc=netdev@vger.kernel.org \
    --cc=shiraz.hashim@st.com \
    --cc=spear-devel@list.st.com \
    --cc=srinivas.kandagatla@st.com \
    --cc=viresh.kumar@st.com \
    /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).