[PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[Sonic Zhang]

From: Sonic Zhang <sonic.zhang@analog.com>

Some synopsys ip implementation doesn't support DMA store and forward mode,
such as BF60x. So, define force_sf_dma_mode negative to use DMA thresholds only.

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f2ccb36..b0e003a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1157,7 +1157,9 @@ static void free_dma_desc_resources(struct stmmac_priv *priv)
  */
 static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
 {
-	if (likely(priv->plat->force_sf_dma_mode ||
+	if (priv->plat->force_sf_dma_mode < 0)
+		priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
+	else if (likely(priv->plat->force_sf_dma_mode > 0 ||
 		   ((priv->plat->tx_coe) && (!priv->no_csum_insertion)))) {
 		/*
 		 * In case of GMAC, SF mode can be enabled
-- 
1.8.2.3

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[David Miller]

From: Sonic Zhang <sonic.adi@gmail.com>
Date: Thu, 15 Aug 2013 15:37:36 +0800

> @@ -1157,7 +1157,9 @@ static void free_dma_desc_resources(struct stmmac_priv *priv)
>   */
>  static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
>  {
> -	if (likely(priv->plat->force_sf_dma_mode ||
> +	if (priv->plat->force_sf_dma_mode < 0)
> +		priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
> +	else if (likely(priv->plat->force_sf_dma_mode > 0 ||
>  		   ((priv->plat->tx_coe) && (!priv->no_csum_insertion)))) {

You need to properly re-indent the last line here so that
the openning parenthesis lines up with the first column
after the openning parenthesis on the "else if" line.

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[Sonic Zhang]

Hi David,

On Fri, Aug 16, 2013 at 5:20 AM, David Miller <davem@davemloft.net> wrote:
> From: Sonic Zhang <sonic.adi@gmail.com>
> Date: Thu, 15 Aug 2013 15:37:36 +0800
>
>> @@ -1157,7 +1157,9 @@ static void free_dma_desc_resources(struct stmmac_priv *priv)
>>   */
>>  static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
>>  {
>> -     if (likely(priv->plat->force_sf_dma_mode ||
>> +     if (priv->plat->force_sf_dma_mode < 0)
>> +             priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
>> +     else if (likely(priv->plat->force_sf_dma_mode > 0 ||
>>                  ((priv->plat->tx_coe) && (!priv->no_csum_insertion)))) {
>
> You need to properly re-indent the last line here so that
> the openning parenthesis lines up with the first column
> after the openning parenthesis on the "else if" line.

The last line is the original source code in master branch of the
Linus's kernel git tree. Do you mean I should fix the ident issue in
this patch as well?


Regards,

Sonic

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[David Miller]

From: Sonic Zhang <sonic.adi@gmail.com>
Date: Fri, 16 Aug 2013 17:37:42 +0800

> Hi David,
> 
> On Fri, Aug 16, 2013 at 5:20 AM, David Miller <davem@davemloft.net> wrote:
>> From: Sonic Zhang <sonic.adi@gmail.com>
>> Date: Thu, 15 Aug 2013 15:37:36 +0800
>>
>>> @@ -1157,7 +1157,9 @@ static void free_dma_desc_resources(struct stmmac_priv *priv)
>>>   */
>>>  static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
>>>  {
>>> -     if (likely(priv->plat->force_sf_dma_mode ||
>>> +     if (priv->plat->force_sf_dma_mode < 0)
>>> +             priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
>>> +     else if (likely(priv->plat->force_sf_dma_mode > 0 ||
>>>                  ((priv->plat->tx_coe) && (!priv->no_csum_insertion)))) {
>>
>> You need to properly re-indent the last line here so that
>> the openning parenthesis lines up with the first column
>> after the openning parenthesis on the "else if" line.
> 
> The last line is the original source code in master branch of the
> Linus's kernel git tree. Do you mean I should fix the ident issue in
> this patch as well?

I'm saying that, in your patch, the second line in

+     else if (likely(priv->plat->force_sf_dma_mode > 0 ||
                 ((priv->plat->tx_coe) && (!priv->no_csum_insertion)))) {

need to be reindented because you're moving the openning parenthesis
to the left by several columns, therefore the second line needs to move
the same amount.

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[Giuseppe CAVALLARO]

Hello Sonic

On 8/15/2013 9:37 AM, Sonic Zhang wrote:
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> Some synopsys ip implementation doesn't support DMA store and forward mode,
> such as BF60x. So, define force_sf_dma_mode negative to use DMA thresholds only.

I think that you should not pass the force_sf_dma_mode platform field
at all (and it doesn't make sense to force it as negative).
To use the threshold you should reset tx_coe. In fact, your HW cannot
perform the Hw csum if SF is not available.
Note that, the HW cap register (if available) can override (set/reset)
  tx_coe.

I tested, long time ago, this scenario on old mac w/o HW cap register
and w/o SF.

let me know if it is ok

I have just noticed that the no_csum_insertion could be removed and I'll
provide a patch for it.

peppe

>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> ---
>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index f2ccb36..b0e003a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1157,7 +1157,9 @@ static void free_dma_desc_resources(struct stmmac_priv *priv)
>    */
>   static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
>   {
> -	if (likely(priv->plat->force_sf_dma_mode ||
> +	if (priv->plat->force_sf_dma_mode < 0)
> +		priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
> +	else if (likely(priv->plat->force_sf_dma_mode > 0 ||
>   		   ((priv->plat->tx_coe) && (!priv->no_csum_insertion)))) {
>   		/*
>   		 * In case of GMAC, SF mode can be enabled
>

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[Sonic Zhang]

Hi Giuseppe,

On Mon, Aug 19, 2013 at 2:03 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> Hello Sonic
>
>
> On 8/15/2013 9:37 AM, Sonic Zhang wrote:
>>
>> From: Sonic Zhang <sonic.zhang@analog.com>
>>
>> Some synopsys ip implementation doesn't support DMA store and forward
>> mode,
>> such as BF60x. So, define force_sf_dma_mode negative to use DMA thresholds
>> only.
>
>
> I think that you should not pass the force_sf_dma_mode platform field
> at all (and it doesn't make sense to force it as negative).
> To use the threshold you should reset tx_coe. In fact, your HW cannot
> perform the Hw csum if SF is not available.
> Note that, the HW cap register (if available) can override (set/reset)
>  tx_coe.

Even if I reset tx_coe, the SF mode is still set to RX DMA in current
stmmac_dma_operation_mode(). SF mode is not supported in both RX DMA
and TX DMA in Blackfin MAC.


>
> I tested, long time ago, this scenario on old mac w/o HW cap register
> and w/o SF.

Blackfin synopsys MAC IP has the HW cap register with tx_coe set to 1,
but the HW tx_coe doesn't really work. I have the other patch to
disable HW tx_coe in board file and override the HW cap register.

Regards,

Sonic

>
> let me know if it is ok
>
> I have just noticed that the no_csum_insertion could be removed and I'll
> provide a patch for it.
>

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[Giuseppe CAVALLARO]

On 8/19/2013 9:31 AM, Sonic Zhang wrote:
> Hi Giuseppe,
>
> On Mon, Aug 19, 2013 at 2:03 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@st.com> wrote:
>> Hello Sonic
>>
>>
>> On 8/15/2013 9:37 AM, Sonic Zhang wrote:
>>>
>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>
>>> Some synopsys ip implementation doesn't support DMA store and forward
>>> mode,
>>> such as BF60x. So, define force_sf_dma_mode negative to use DMA thresholds
>>> only.
>>
>>
>> I think that you should not pass the force_sf_dma_mode platform field
>> at all (and it doesn't make sense to force it as negative).
>> To use the threshold you should reset tx_coe. In fact, your HW cannot
>> perform the Hw csum if SF is not available.
>> Note that, the HW cap register (if available) can override (set/reset)
>>   tx_coe.
>
> Even if I reset tx_coe, the SF mode is still set to RX DMA in current
> stmmac_dma_operation_mode(). SF mode is not supported in both RX DMA
> and TX DMA in Blackfin MAC.

yes this is true. the SF is always set for the RX path because I have
never had and known HW w/o RX csum (since the 209).

So I think the code could be improved to disable/enable the SF also for
the RX path.

>>
>> I tested, long time ago, this scenario on old mac w/o HW cap register
>> and w/o SF.
>
> Blackfin synopsys MAC IP has the HW cap register with tx_coe set to 1,
> but the HW tx_coe doesn't really work. I have the other patch to
> disable HW tx_coe in board file and override the HW cap register.

AFAIK the HW shouldn't be able to perform the csum in HW w/o SF.

Maybe, an easy way could be to use a new field to force the threshold
mode. This should also remove the csum in HW (IMO) and program the
DMA operation register.

Regards
Peppe

>
> Regards,
>
> Sonic
>
>>
>> let me know if it is ok
>>
>> I have just noticed that the no_csum_insertion could be removed and I'll
>> provide a patch for it.
>>
>
>

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[Sonic Zhang]

Hi Giuseppe,

On Mon, Aug 19, 2013 at 3:45 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> On 8/19/2013 9:31 AM, Sonic Zhang wrote:
>>
>> Hi Giuseppe,
>>
>> On Mon, Aug 19, 2013 at 2:03 PM, Giuseppe CAVALLARO
>> <peppe.cavallaro@st.com> wrote:
>>>
>>> Hello Sonic
>>>
>>>
>>> On 8/15/2013 9:37 AM, Sonic Zhang wrote:
>>>>
>>>>
>>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>>
>>>> Some synopsys ip implementation doesn't support DMA store and forward
>>>> mode,
>>>> such as BF60x. So, define force_sf_dma_mode negative to use DMA
>>>> thresholds
>>>> only.
>>>
>>>
>>>
>>> I think that you should not pass the force_sf_dma_mode platform field
>>> at all (and it doesn't make sense to force it as negative).
>>> To use the threshold you should reset tx_coe. In fact, your HW cannot
>>> perform the Hw csum if SF is not available.
>>> Note that, the HW cap register (if available) can override (set/reset)
>>>   tx_coe.
>>
>>
>> Even if I reset tx_coe, the SF mode is still set to RX DMA in current
>> stmmac_dma_operation_mode(). SF mode is not supported in both RX DMA
>> and TX DMA in Blackfin MAC.
>
>
> yes this is true. the SF is always set for the RX path because I have
> never had and known HW w/o RX csum (since the 209).
>
> So I think the code could be improved to disable/enable the SF also for
> the RX path.
>
>
>>>
>>> I tested, long time ago, this scenario on old mac w/o HW cap register
>>> and w/o SF.
>>
>>
>> Blackfin synopsys MAC IP has the HW cap register with tx_coe set to 1,
>> but the HW tx_coe doesn't really work. I have the other patch to
>> disable HW tx_coe in board file and override the HW cap register.
>
>
> AFAIK the HW shouldn't be able to perform the csum in HW w/o SF.
>
> Maybe, an easy way could be to use a new field to force the threshold
> mode. This should also remove the csum in HW (IMO) and program the
> DMA operation register.
>

The problem is that HW RX csum works perfectly on Blackfin MAC
although the SF mode is not supported in RX DMA. I may need 2 platform
fields to force RX DMA threshold and disable HW tx_coe. One field
doesn't cover both cases well.

Which 2 fields do you prefer?

Thanks

Sonic

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[Giuseppe CAVALLARO]

On 8/19/2013 12:51 PM, Sonic Zhang wrote:
> Hi Giuseppe,
>
> On Mon, Aug 19, 2013 at 3:45 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@st.com> wrote:
>> On 8/19/2013 9:31 AM, Sonic Zhang wrote:
>>>
>>> Hi Giuseppe,
>>>
>>> On Mon, Aug 19, 2013 at 2:03 PM, Giuseppe CAVALLARO
>>> <peppe.cavallaro@st.com> wrote:
>>>>
>>>> Hello Sonic
>>>>
>>>>
>>>> On 8/15/2013 9:37 AM, Sonic Zhang wrote:
>>>>>
>>>>>
>>>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>>>
>>>>> Some synopsys ip implementation doesn't support DMA store and forward
>>>>> mode,
>>>>> such as BF60x. So, define force_sf_dma_mode negative to use DMA
>>>>> thresholds
>>>>> only.
>>>>
>>>>
>>>>
>>>> I think that you should not pass the force_sf_dma_mode platform field
>>>> at all (and it doesn't make sense to force it as negative).
>>>> To use the threshold you should reset tx_coe. In fact, your HW cannot
>>>> perform the Hw csum if SF is not available.
>>>> Note that, the HW cap register (if available) can override (set/reset)
>>>>    tx_coe.
>>>
>>>
>>> Even if I reset tx_coe, the SF mode is still set to RX DMA in current
>>> stmmac_dma_operation_mode(). SF mode is not supported in both RX DMA
>>> and TX DMA in Blackfin MAC.
>>
>>
>> yes this is true. the SF is always set for the RX path because I have
>> never had and known HW w/o RX csum (since the 209).
>>
>> So I think the code could be improved to disable/enable the SF also for
>> the RX path.
>>
>>
>>>>
>>>> I tested, long time ago, this scenario on old mac w/o HW cap register
>>>> and w/o SF.
>>>
>>>
>>> Blackfin synopsys MAC IP has the HW cap register with tx_coe set to 1,
>>> but the HW tx_coe doesn't really work. I have the other patch to
>>> disable HW tx_coe in board file and override the HW cap register.
>>
>>
>> AFAIK the HW shouldn't be able to perform the csum in HW w/o SF.
>>
>> Maybe, an easy way could be to use a new field to force the threshold
>> mode. This should also remove the csum in HW (IMO) and program the
>> DMA operation register.
>>
>
> The problem is that HW RX csum works perfectly on Blackfin MAC
> although the SF mode is not supported in RX DMA.

hmm maybe we should ask SYNP. I'll try.

> I may need 2 platform
> fields to force RX DMA threshold and disable HW tx_coe. One field
> doesn't cover both cases well.

concerning tx_coe, I had added it to inform the stmmac that the HW
was (or not) able to do the csum in hw. This was true on chip w/o
the HW cap register. If you have the HW cap reg so let me assume
there is another problem. For example, I worked (time ago) on an HW
where the cap reg declared that the mac was able to perform the csum
in hw but, after debugging it, I discovered that the problem was on
SG. I mean, the HW was able to do the csum in HW but had problems on
fragmented frame (I mean, frames that were split in one more
descriptor).

I will send you the patch I used to fix that... maybe you are in the
same scenario.

Concerning the threshold, just to avoid to complicate the code, we could
keep force_sf_dma_mode and add force_thresh_dma_mode that force both
rx and tx. I do not want to remove the force_sf_dma_mode that is also
used on some platforms (AFAIK).
Do not forget to update the stmmac.txt and devicetree support
What do you think?
I also think that the patch should be prepared on top of net-next.

Peppe
>
> Which 2 fields do you prefer?
>
> Thanks
>
> Sonic
>
>

Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.

[Sonic Zhang]

Hi Peppe,

On Mon, Aug 19, 2013 at 10:29 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> On 8/19/2013 12:51 PM, Sonic Zhang wrote:
>>
>> Hi Giuseppe,
>>
>> On Mon, Aug 19, 2013 at 3:45 PM, Giuseppe CAVALLARO
>> <peppe.cavallaro@st.com> wrote:
>>>
>>> On 8/19/2013 9:31 AM, Sonic Zhang wrote:
>>>>
>>>>
>>>> Hi Giuseppe,
>>>>
>>>> On Mon, Aug 19, 2013 at 2:03 PM, Giuseppe CAVALLARO
>>>> <peppe.cavallaro@st.com> wrote:
>>>>>
>>>>>
>>>>> Hello Sonic
>>>>>
>>>>>
>>>>> On 8/15/2013 9:37 AM, Sonic Zhang wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>>>>
>>>>>> Some synopsys ip implementation doesn't support DMA store and forward
>>>>>> mode,
>>>>>> such as BF60x. So, define force_sf_dma_mode negative to use DMA
>>>>>> thresholds
>>>>>> only.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I think that you should not pass the force_sf_dma_mode platform field
>>>>> at all (and it doesn't make sense to force it as negative).
>>>>> To use the threshold you should reset tx_coe. In fact, your HW cannot
>>>>> perform the Hw csum if SF is not available.
>>>>> Note that, the HW cap register (if available) can override (set/reset)
>>>>>    tx_coe.
>>>>
>>>>
>>>>
>>>> Even if I reset tx_coe, the SF mode is still set to RX DMA in current
>>>> stmmac_dma_operation_mode(). SF mode is not supported in both RX DMA
>>>> and TX DMA in Blackfin MAC.
>>>
>>>
>>>
>>> yes this is true. the SF is always set for the RX path because I have
>>> never had and known HW w/o RX csum (since the 209).
>>>
>>> So I think the code could be improved to disable/enable the SF also for
>>> the RX path.
>>>
>>>
>>>>>
>>>>> I tested, long time ago, this scenario on old mac w/o HW cap register
>>>>> and w/o SF.
>>>>
>>>>
>>>>
>>>> Blackfin synopsys MAC IP has the HW cap register with tx_coe set to 1,
>>>> but the HW tx_coe doesn't really work. I have the other patch to
>>>> disable HW tx_coe in board file and override the HW cap register.
>>>
>>>
>>>
>>> AFAIK the HW shouldn't be able to perform the csum in HW w/o SF.
>>>
>>> Maybe, an easy way could be to use a new field to force the threshold
>>> mode. This should also remove the csum in HW (IMO) and program the
>>> DMA operation register.
>>>
>>
>> The problem is that HW RX csum works perfectly on Blackfin MAC
>> although the SF mode is not supported in RX DMA.
>
>
> hmm maybe we should ask SYNP. I'll try.
>
>
>> I may need 2 platform
>> fields to force RX DMA threshold and disable HW tx_coe. One field
>> doesn't cover both cases well.
>
>
> concerning tx_coe, I had added it to inform the stmmac that the HW
> was (or not) able to do the csum in hw. This was true on chip w/o
> the HW cap register. If you have the HW cap reg so let me assume
> there is another problem. For example, I worked (time ago) on an HW
> where the cap reg declared that the mac was able to perform the csum
> in hw but, after debugging it, I discovered that the problem was on
> SG. I mean, the HW was able to do the csum in HW but had problems on
> fragmented frame (I mean, frames that were split in one more
> descriptor).
>
> I will send you the patch I used to fix that... maybe you are in the
> same scenario.
>
> Concerning the threshold, just to avoid to complicate the code, we could
> keep force_sf_dma_mode and add force_thresh_dma_mode that force both
> rx and tx. I do not want to remove the force_sf_dma_mode that is also
> used on some platforms (AFAIK).
> Do not forget to update the stmmac.txt and devicetree support
> What do you think?
> I also think that the patch should be prepared on top of net-next.

OK, I will use the new flag and update document and device tree as well.
When can you send me your fragmented frame patch?

Regards,

Sonic