From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Sonic Zhang <sonic.adi@gmail.com>
Cc: netdev <netdev@vger.kernel.org>,
adi-buildroot-devel@lists.sourceforge.net,
Sonic Zhang <sonic.zhang@analog.com>
Subject: Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.
Date: Mon, 19 Aug 2013 16:29:48 +0200 [thread overview]
Message-ID: <52122BDC.5030500@st.com> (raw)
In-Reply-To: <CAJxxZ0NFhMMKp2eB+b168=c6+JsmJE6-yva7ZOGKciK3e4b8Yg@mail.gmail.com>
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
>
>
next prev parent reply other threads:[~2013-08-19 14:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-15 7:37 [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative Sonic Zhang
2013-08-15 21:20 ` David Miller
2013-08-16 9:37 ` Sonic Zhang
2013-08-17 5:30 ` David Miller
2013-08-19 6:03 ` Giuseppe CAVALLARO
2013-08-19 7:31 ` Sonic Zhang
2013-08-19 7:45 ` Giuseppe CAVALLARO
2013-08-19 10:51 ` Sonic Zhang
2013-08-19 14:29 ` Giuseppe CAVALLARO [this message]
2013-08-22 8:40 ` Sonic Zhang
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=52122BDC.5030500@st.com \
--to=peppe.cavallaro@st.com \
--cc=adi-buildroot-devel@lists.sourceforge.net \
--cc=netdev@vger.kernel.org \
--cc=sonic.adi@gmail.com \
--cc=sonic.zhang@analog.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).