Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1546307 > unrolled thread

[PATCH v2] stmmac: CSR clock configuration fix

Started byJoao Pinto <Joao.Pinto@synopsys.com>
First post2016-12-22 13:40 +0100
Last post2016-12-22 17:30 +0100
Articles 8 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH v2] stmmac: CSR clock configuration fix Joao Pinto <Joao.Pinto@synopsys.com> - 2016-12-22 13:40 +0100
    Re: [PATCH v2] stmmac: CSR clock configuration fix Phil Reid <preid@electromag.com.au> - 2016-12-22 16:50 +0100
      Re: [PATCH v2] stmmac: CSR clock configuration fix Joao Pinto <Joao.Pinto@synopsys.com> - 2016-12-22 16:50 +0100
        Re: [PATCH v2] stmmac: CSR clock configuration fix Phil Reid <preid@electromag.com.au> - 2016-12-22 18:00 +0100
          Re: [PATCH v2] stmmac: CSR clock configuration fix Joao Pinto <Joao.Pinto@synopsys.com> - 2016-12-22 18:10 +0100
            Re: [PATCH v2] stmmac: CSR clock configuration fix Phil Reid <preid@electromag.com.au> - 2016-12-23 02:10 +0100
              Re: [PATCH v2] stmmac: CSR clock configuration fix Joao Pinto <Joao.Pinto@synopsys.com> - 2016-12-23 11:10 +0100
    Re: [PATCH v2] stmmac: CSR clock configuration fix David Miller <davem@davemloft.net> - 2016-12-22 17:30 +0100

#1546307 — [PATCH v2] stmmac: CSR clock configuration fix

FromJoao Pinto <Joao.Pinto@synopsys.com>
Date2016-12-22 13:40 +0100
Subject[PATCH v2] stmmac: CSR clock configuration fix
Message-ID<sRaP8-140-33@gated-at.bofh.it>
When testing stmmac with my QoS reference design I checked a problem in the
CSR clock configuration that was impossibilitating the phy discovery, since
every read operation returned 0x0000ffff. This patch fixes the issue.

Signed-off-by: Joao Pinto <jpinto@synopsys.com>
---
changes v1->v2 (David Miller)
- DWMAC100 and DWMAC1000 csr clocks masks should also be fixed for the patch
to make sense

 drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c    | 8 ++++----
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index b21d03f..94223c8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -539,7 +539,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
 	mac->mii.reg_shift = 6;
 	mac->mii.reg_mask = 0x000007C0;
 	mac->mii.clk_csr_shift = 2;
-	mac->mii.clk_csr_mask = 0xF;
+	mac->mii.clk_csr_mask = GENMASK(4, 2);
 
 	/* Get and dump the chip ID */
 	*synopsys_id = stmmac_get_synopsys_id(hwid);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index a1d582f..8a40e69 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -197,7 +197,7 @@ struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id)
 	mac->mii.reg_shift = 6;
 	mac->mii.reg_mask = 0x000007C0;
 	mac->mii.clk_csr_shift = 2;
-	mac->mii.clk_csr_mask = 0xF;
+	mac->mii.clk_csr_mask = GENMASK(4, 2);
 
 	/* Synopsys Id is not available on old chips */
 	*synopsys_id = 0;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 23322fd..fda01f7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -81,8 +81,8 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
 	value |= (phyaddr << priv->hw->mii.addr_shift)
 		& priv->hw->mii.addr_mask;
 	value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
-	value |= (priv->clk_csr & priv->hw->mii.clk_csr_mask)
-		<< priv->hw->mii.clk_csr_shift;
+	value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
+		& priv->hw->mii.clk_csr_mask;
 	if (priv->plat->has_gmac4)
 		value |= MII_GMAC4_READ;
 
@@ -122,8 +122,8 @@ static int stmmac_mdio_write(struct mii_bus *bus, int phyaddr, int phyreg,
 		& priv->hw->mii.addr_mask;
 	value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
 
-	value |= ((priv->clk_csr & priv->hw->mii.clk_csr_mask)
-		<< priv->hw->mii.clk_csr_shift);
+	value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
+		& priv->hw->mii.clk_csr_mask;
 	if (priv->plat->has_gmac4)
 		value |= MII_GMAC4_WRITE;
 
-- 
2.9.3

[toc] | [next] | [standalone]

#1546426

FromPhil Reid <preid@electromag.com.au>
Date2016-12-22 16:50 +0100
Message-ID<sRdMZ-2Q5-9@gated-at.bofh.it>
In reply to#1546307
G'day Joao,

On 22/12/2016 20:38, Joao Pinto wrote:
> When testing stmmac with my QoS reference design I checked a problem in the
> CSR clock configuration that was impossibilitating the phy discovery, since
> every read operation returned 0x0000ffff. This patch fixes the issue.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> ---
> changes v1->v2 (David Miller)
> - DWMAC100 and DWMAC1000 csr clocks masks should also be fixed for the patch
> to make sense
>
>  drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c  | 2 +-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c    | 8 ++++----
>  3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> index b21d03f..94223c8 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> @@ -539,7 +539,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
>  	mac->mii.reg_shift = 6;
>  	mac->mii.reg_mask = 0x000007C0;
>  	mac->mii.clk_csr_shift = 2;
> -	mac->mii.clk_csr_mask = 0xF;
> +	mac->mii.clk_csr_mask = GENMASK(4, 2);

Should this not be GENMASK(5,2)

>
>  	/* Get and dump the chip ID */
>  	*synopsys_id = stmmac_get_synopsys_id(hwid);
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
> index a1d582f..8a40e69 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
> @@ -197,7 +197,7 @@ struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id)
>  	mac->mii.reg_shift = 6;
>  	mac->mii.reg_mask = 0x000007C0;
>  	mac->mii.clk_csr_shift = 2;
> -	mac->mii.clk_csr_mask = 0xF;
> +	mac->mii.clk_csr_mask = GENMASK(4, 2);
same as above?

>
>  	/* Synopsys Id is not available on old chips */
>  	*synopsys_id = 0;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> index 23322fd..fda01f7 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> @@ -81,8 +81,8 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
>  	value |= (phyaddr << priv->hw->mii.addr_shift)
>  		& priv->hw->mii.addr_mask;
>  	value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
> -	value |= (priv->clk_csr & priv->hw->mii.clk_csr_mask)
> -		<< priv->hw->mii.clk_csr_shift;
> +	value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
> +		& priv->hw->mii.clk_csr_mask;
>  	if (priv->plat->has_gmac4)
>  		value |= MII_GMAC4_READ;
>
> @@ -122,8 +122,8 @@ static int stmmac_mdio_write(struct mii_bus *bus, int phyaddr, int phyreg,
>  		& priv->hw->mii.addr_mask;
>  	value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
>
> -	value |= ((priv->clk_csr & priv->hw->mii.clk_csr_mask)
> -		<< priv->hw->mii.clk_csr_shift);
> +	value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
> +		& priv->hw->mii.clk_csr_mask;
>  	if (priv->plat->has_gmac4)
>  		value |= MII_GMAC4_WRITE;
>
>


-- 
Regards
Phil Reid

[toc] | [prev] | [next] | [standalone]

#1546427

FromJoao Pinto <Joao.Pinto@synopsys.com>
Date2016-12-22 16:50 +0100
Message-ID<sRdMZ-2Q5-7@gated-at.bofh.it>
In reply to#1546426
Hello Phil,

Às 3:42 PM de 12/22/2016, Phil Reid escreveu:
> G'day Joao,
> 
> On 22/12/2016 20:38, Joao Pinto wrote:
>> When testing stmmac with my QoS reference design I checked a problem in the
>> CSR clock configuration that was impossibilitating the phy discovery, since
>> every read operation returned 0x0000ffff. This patch fixes the issue.
>>
>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>> ---
>> changes v1->v2 (David Miller)
>> - DWMAC100 and DWMAC1000 csr clocks masks should also be fixed for the patch
>> to make sense
>>
>>  drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
>>  drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c  | 2 +-
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c    | 8 ++++----
>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>> index b21d03f..94223c8 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>> @@ -539,7 +539,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
>> *ioaddr, int mcbins,
>>      mac->mii.reg_shift = 6;
>>      mac->mii.reg_mask = 0x000007C0;
>>      mac->mii.clk_csr_shift = 2;
>> -    mac->mii.clk_csr_mask = 0xF;
>> +    mac->mii.clk_csr_mask = GENMASK(4, 2);
> 
> Should this not be GENMASK(5,2)

According to Universal MAC databook (valid for MAC100 and MAC1000), we have:

Bits: 4:2
000 60-100 MHz clk_csr_i/42
001 100-150 MHz clk_csr_i/62
010 20-35 MHz clk_csr_i/16
011 35-60 MHz clk_csr_i/26
100 150-250 MHz clk_csr_i/102
101 250-300 MHz clk_csr_i/124
110, 111 Reserved

So only bits 2, 3 and 4 should be masked.

Thanks.

> 
>>
>>      /* Get and dump the chip ID */
>>      *synopsys_id = stmmac_get_synopsys_id(hwid);
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
>> index a1d582f..8a40e69 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
>> @@ -197,7 +197,7 @@ struct mac_device_info *dwmac100_setup(void __iomem
>> *ioaddr, int *synopsys_id)
>>      mac->mii.reg_shift = 6;
>>      mac->mii.reg_mask = 0x000007C0;
>>      mac->mii.clk_csr_shift = 2;
>> -    mac->mii.clk_csr_mask = 0xF;
>> +    mac->mii.clk_csr_mask = GENMASK(4, 2);
> same as above?
> 
>>
>>      /* Synopsys Id is not available on old chips */
>>      *synopsys_id = 0;
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> index 23322fd..fda01f7 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> @@ -81,8 +81,8 @@ static int stmmac_mdio_read(struct mii_bus *bus, int
>> phyaddr, int phyreg)
>>      value |= (phyaddr << priv->hw->mii.addr_shift)
>>          & priv->hw->mii.addr_mask;
>>      value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
>> -    value |= (priv->clk_csr & priv->hw->mii.clk_csr_mask)
>> -        << priv->hw->mii.clk_csr_shift;
>> +    value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
>> +        & priv->hw->mii.clk_csr_mask;
>>      if (priv->plat->has_gmac4)
>>          value |= MII_GMAC4_READ;
>>
>> @@ -122,8 +122,8 @@ static int stmmac_mdio_write(struct mii_bus *bus, int
>> phyaddr, int phyreg,
>>          & priv->hw->mii.addr_mask;
>>      value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
>>
>> -    value |= ((priv->clk_csr & priv->hw->mii.clk_csr_mask)
>> -        << priv->hw->mii.clk_csr_shift);
>> +    value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
>> +        & priv->hw->mii.clk_csr_mask;
>>      if (priv->plat->has_gmac4)
>>          value |= MII_GMAC4_WRITE;
>>
>>
> 
>

[toc] | [prev] | [next] | [standalone]

#1546490

FromPhil Reid <preid@electromag.com.au>
Date2016-12-22 18:00 +0100
Message-ID<sReSJ-3uM-13@gated-at.bofh.it>
In reply to#1546427
On 22/12/2016 23:47, Joao Pinto wrote:
>
> Hello Phil,
>
> Às 3:42 PM de 12/22/2016, Phil Reid escreveu:
>> G'day Joao,
>>
>> On 22/12/2016 20:38, Joao Pinto wrote:
>>> When testing stmmac with my QoS reference design I checked a problem in the
>>> CSR clock configuration that was impossibilitating the phy discovery, since
>>> every read operation returned 0x0000ffff. This patch fixes the issue.
>>>
>>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>>> ---
>>> changes v1->v2 (David Miller)
>>> - DWMAC100 and DWMAC1000 csr clocks masks should also be fixed for the patch
>>> to make sense
>>>
>>>  drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
>>>  drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c  | 2 +-
>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c    | 8 ++++----
>>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>> index b21d03f..94223c8 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>> @@ -539,7 +539,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
>>> *ioaddr, int mcbins,
>>>      mac->mii.reg_shift = 6;
>>>      mac->mii.reg_mask = 0x000007C0;
>>>      mac->mii.clk_csr_shift = 2;
>>> -    mac->mii.clk_csr_mask = 0xF;
>>> +    mac->mii.clk_csr_mask = GENMASK(4, 2);
>>
>> Should this not be GENMASK(5,2)
>
> According to Universal MAC databook (valid for MAC100 and MAC1000), we have:
>
> Bits: 4:2
> 000 60-100 MHz clk_csr_i/42
> 001 100-150 MHz clk_csr_i/62
> 010 20-35 MHz clk_csr_i/16
> 011 35-60 MHz clk_csr_i/26
> 100 150-250 MHz clk_csr_i/102
> 101 250-300 MHz clk_csr_i/124
> 110, 111 Reserved
>
> So only bits 2, 3 and 4 should be masked.
>
> Thanks.
>
But this is a change in behaviour from what was there isn't.
Previous mask was 4 bits. now it's 3.

And for example the altera socfgpa implementation in the cyclone V has valid values
for values 0x8-0xf, using bit 5:2.





-- 
Regards
Phil Reid

[toc] | [prev] | [next] | [standalone]

#1546497

FromJoao Pinto <Joao.Pinto@synopsys.com>
Date2016-12-22 18:10 +0100
Message-ID<sRf2p-3NJ-5@gated-at.bofh.it>
In reply to#1546490
Às 4:57 PM de 12/22/2016, Phil Reid escreveu:
> On 22/12/2016 23:47, Joao Pinto wrote:
>>
>> Hello Phil,
>>
>> Às 3:42 PM de 12/22/2016, Phil Reid escreveu:
>>> G'day Joao,
>>>
>>> On 22/12/2016 20:38, Joao Pinto wrote:
>>>> When testing stmmac with my QoS reference design I checked a problem in the
>>>> CSR clock configuration that was impossibilitating the phy discovery, since
>>>> every read operation returned 0x0000ffff. This patch fixes the issue.
>>>>
>>>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>>>> ---
>>>> changes v1->v2 (David Miller)
>>>> - DWMAC100 and DWMAC1000 csr clocks masks should also be fixed for the patch
>>>> to make sense
>>>>
>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c  | 2 +-
>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c    | 8 ++++----
>>>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>> index b21d03f..94223c8 100644
>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>> @@ -539,7 +539,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
>>>> *ioaddr, int mcbins,
>>>>      mac->mii.reg_shift = 6;
>>>>      mac->mii.reg_mask = 0x000007C0;
>>>>      mac->mii.clk_csr_shift = 2;
>>>> -    mac->mii.clk_csr_mask = 0xF;
>>>> +    mac->mii.clk_csr_mask = GENMASK(4, 2);
>>>
>>> Should this not be GENMASK(5,2)
>>
>> According to Universal MAC databook (valid for MAC100 and MAC1000), we have:
>>
>> Bits: 4:2
>> 000 60-100 MHz clk_csr_i/42
>> 001 100-150 MHz clk_csr_i/62
>> 010 20-35 MHz clk_csr_i/16
>> 011 35-60 MHz clk_csr_i/26
>> 100 150-250 MHz clk_csr_i/102
>> 101 250-300 MHz clk_csr_i/124
>> 110, 111 Reserved
>>
>> So only bits 2, 3 and 4 should be masked.
>>
>> Thanks.
>>
> But this is a change in behaviour from what was there isn't.
> Previous mask was 4 bits. now it's 3.
> 
> And for example the altera socfgpa implementation in the cyclone V has valid values
> for values 0x8-0xf, using bit 5:2.

According to the databook, bit 5 is reserved and RO. When reserved, it is
possible to customize. Is that the case? If there is hardware using the 5th bit
we can put it GENMASK(5, 2) with no problem.

> 
> 
> 
> 
>

[toc] | [prev] | [next] | [standalone]

#1546684

FromPhil Reid <preid@electromag.com.au>
Date2016-12-23 02:10 +0100
Message-ID<sRmwW-5f-3@gated-at.bofh.it>
In reply to#1546497
G'day Joao,
On 23/12/2016 01:06, Joao Pinto wrote:
> Às 4:57 PM de 12/22/2016, Phil Reid escreveu:
>> On 22/12/2016 23:47, Joao Pinto wrote:
>>>
>>> Hello Phil,
>>>
>>> Às 3:42 PM de 12/22/2016, Phil Reid escreveu:
>>>> G'day Joao,
>>>>
>>>> On 22/12/2016 20:38, Joao Pinto wrote:
>>>>> When testing stmmac with my QoS reference design I checked a problem in the
>>>>> CSR clock configuration that was impossibilitating the phy discovery, since
>>>>> every read operation returned 0x0000ffff. This patch fixes the issue.
>>>>>
>>>>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>>>>> ---
>>>>> changes v1->v2 (David Miller)
>>>>> - DWMAC100 and DWMAC1000 csr clocks masks should also be fixed for the patch
>>>>> to make sense
>>>>>
>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c  | 2 +-
>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c    | 8 ++++----
>>>>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>>> index b21d03f..94223c8 100644
>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>>> @@ -539,7 +539,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
>>>>> *ioaddr, int mcbins,
>>>>>      mac->mii.reg_shift = 6;
>>>>>      mac->mii.reg_mask = 0x000007C0;
>>>>>      mac->mii.clk_csr_shift = 2;
>>>>> -    mac->mii.clk_csr_mask = 0xF;
>>>>> +    mac->mii.clk_csr_mask = GENMASK(4, 2);
>>>>
>>>> Should this not be GENMASK(5,2)
>>>
>>> According to Universal MAC databook (valid for MAC100 and MAC1000), we have:
>>>
>>> Bits: 4:2
>>> 000 60-100 MHz clk_csr_i/42
>>> 001 100-150 MHz clk_csr_i/62
>>> 010 20-35 MHz clk_csr_i/16
>>> 011 35-60 MHz clk_csr_i/26
>>> 100 150-250 MHz clk_csr_i/102
>>> 101 250-300 MHz clk_csr_i/124
>>> 110, 111 Reserved
>>>
>>> So only bits 2, 3 and 4 should be masked.
>>>
>>> Thanks.
>>>
>> But this is a change in behaviour from what was there isn't.
>> Previous mask was 4 bits. now it's 3.
>>
>> And for example the altera socfgpa implementation in the cyclone V has valid values
>> for values 0x8-0xf, using bit 5:2.
>
> According to the databook, bit 5 is reserved and RO. When reserved, it is
> possible to customize. Is that the case? If there is hardware using the 5th bit
> we can put it GENMASK(5, 2) with no problem.
>
I've also checked the Aria 10 documentation and bit 5 is also RW.
The following options are documented and supported
     1000: CSR clock/4
     1001: CSR clock/6
     1010: CSR clock/8
     1011: CSR clock/10
     1100: CSR clock/12
     1101: CSR clock/14
     1110: CSR clock/16
     1111: CSR clock/18
They do mention that these values will probably be outside the IEEE 802.3 specified range.

But there's at least a couple of cores out there where GENMASK(5,2) is valid.
Can't say if anyone is using that setting thou.


-- 
Regards
Phil Reid

[toc] | [prev] | [next] | [standalone]

#1546800

FromJoao Pinto <Joao.Pinto@synopsys.com>
Date2016-12-23 11:10 +0100
Message-ID<sRuXv-5wu-11@gated-at.bofh.it>
In reply to#1546684
Hello Phil,

Às 1:09 AM de 12/23/2016, Phil Reid escreveu:
> G'day Joao,
> On 23/12/2016 01:06, Joao Pinto wrote:
>> Às 4:57 PM de 12/22/2016, Phil Reid escreveu:
>>> On 22/12/2016 23:47, Joao Pinto wrote:
>>>>
>>>> Hello Phil,
>>>>
>>>> Às 3:42 PM de 12/22/2016, Phil Reid escreveu:
>>>>> G'day Joao,
>>>>>
>>>>> On 22/12/2016 20:38, Joao Pinto wrote:
>>>>>> When testing stmmac with my QoS reference design I checked a problem in the
>>>>>> CSR clock configuration that was impossibilitating the phy discovery, since
>>>>>> every read operation returned 0x0000ffff. This patch fixes the issue.
>>>>>>
>>>>>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>>>>>> ---
>>>>>> changes v1->v2 (David Miller)
>>>>>> - DWMAC100 and DWMAC1000 csr clocks masks should also be fixed for the patch
>>>>>> to make sense
>>>>>>
>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c  | 2 +-
>>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c    | 8 ++++----
>>>>>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>>>> index b21d03f..94223c8 100644
>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>>>>>> @@ -539,7 +539,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
>>>>>> *ioaddr, int mcbins,
>>>>>>      mac->mii.reg_shift = 6;
>>>>>>      mac->mii.reg_mask = 0x000007C0;
>>>>>>      mac->mii.clk_csr_shift = 2;
>>>>>> -    mac->mii.clk_csr_mask = 0xF;
>>>>>> +    mac->mii.clk_csr_mask = GENMASK(4, 2);
>>>>>
>>>>> Should this not be GENMASK(5,2)
>>>>
>>>> According to Universal MAC databook (valid for MAC100 and MAC1000), we have:
>>>>
>>>> Bits: 4:2
>>>> 000 60-100 MHz clk_csr_i/42
>>>> 001 100-150 MHz clk_csr_i/62
>>>> 010 20-35 MHz clk_csr_i/16
>>>> 011 35-60 MHz clk_csr_i/26
>>>> 100 150-250 MHz clk_csr_i/102
>>>> 101 250-300 MHz clk_csr_i/124
>>>> 110, 111 Reserved
>>>>
>>>> So only bits 2, 3 and 4 should be masked.
>>>>
>>>> Thanks.
>>>>
>>> But this is a change in behaviour from what was there isn't.
>>> Previous mask was 4 bits. now it's 3.
>>>
>>> And for example the altera socfgpa implementation in the cyclone V has valid
>>> values
>>> for values 0x8-0xf, using bit 5:2.
>>
>> According to the databook, bit 5 is reserved and RO. When reserved, it is
>> possible to customize. Is that the case? If there is hardware using the 5th bit
>> we can put it GENMASK(5, 2) with no problem.
>>
> I've also checked the Aria 10 documentation and bit 5 is also RW.
> The following options are documented and supported
>     1000: CSR clock/4
>     1001: CSR clock/6
>     1010: CSR clock/8
>     1011: CSR clock/10
>     1100: CSR clock/12
>     1101: CSR clock/14
>     1110: CSR clock/16
>     1111: CSR clock/18
> They do mention that these values will probably be outside the IEEE 802.3
> specified range.
> 
> But there's at least a couple of cores out there where GENMASK(5,2) is valid.
> Can't say if anyone is using that setting thou.

Thanks for checking it! Ok, it seems like they are using the reserved bit 5. No
problem, I am going to change the patch and put the mask from 2 to 5. Thanks for
your help!

Joao

> 
>

[toc] | [prev] | [next] | [standalone]

#1546463

FromDavid Miller <davem@davemloft.net>
Date2016-12-22 17:30 +0100
Message-ID<sRepH-3kK-17@gated-at.bofh.it>
In reply to#1546307
From: Joao Pinto <Joao.Pinto@synopsys.com>
Date: Thu, 22 Dec 2016 12:38:00 +0000

> When testing stmmac with my QoS reference design I checked a problem in the
> CSR clock configuration that was impossibilitating the phy discovery, since
> every read operation returned 0x0000ffff. This patch fixes the issue.
> 
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>

Applied.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web