Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: wlf <wulf@rock-chips.com>
To: Doug Anderson <dianders@google.com>
Cc: "William Wu" <william.wu@rock-chips.com>,
	hminas@synopsys.com, felipe.balbi@linux.intel.com,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Sergei Shtylyov" <sergei.shtylyov@cogentembedded.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Frank Wang" <frank.wang@rock-chips.com>,
	黄涛 <huangtao@rock-chips.com>,
	"daniel.meng" <daniel.meng@rock-chips.com>,
	"John Youn" <John.Youn@synopsys.com>, 王征增 <wzz@rock-chips.com>,
	zsq@rock-chips.com, 許嘉銘 <Allen.Hsu@quantatw.com>,
	"Stan Tsui" <StanTsui@aopen.com>,
	"Spruce Wu (吳建勳)" <Spruce.Wu@quantatw.com>
Subject: Re: [PATCH v3 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in
Date: Fri, 11 May 2018 17:26:59 +0800	[thread overview]
Message-ID: <3768eb42-98c4-5bd0-a796-5ba36d03cd35@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=Xsa9MAw==_Oi28B69oqZehwL2JTwEzjKAnH5PS5wKC_A@mail.gmail.com>

Dear Doug,


在 2018年05月11日 04:59, Doug Anderson 写道:
> Hi,
>
> On Wed, May 9, 2018 at 1:55 AM, wlf <wulf@rock-chips.com> wrote:
>>>>>> +       } else if (hsotg->params.host_dma) {
>>>>> Are you sure this is "else if"?  Can't you have descriptor DMA enabled
>>>>> in the controller and still need to do a normal DMA transfer if you
>>>>> plug in a hub?  Seems like this should be just "if".
>>>> Sorry, I don't understand the case "have descriptor DMA enabled in the
>>>> controller and still need to do a normal DMA transfer". But maybe it
>>>> still
>>>> has another problem if just use "if" here, because it will create kmem
>>>> caches for Slave mode which actually doesn't need aligned DMA buf.
>>> So right now your code looks like:
>>>
>>> if (hsotg->params.dma_desc_enable ||
>>>       hsotg->params.dma_desc_fs_enable) {
>>>       ...
>>>       ...
>>> } else if (hsotg->params.host_dma) {
>>>      ...
>>> }
>>>
>>>
>>> I've never played much with "descriptor DMA" on dwc2 because every
>>> time I enabled it (last I tried was years ago) a whole bunch of
>>> peripherals stopped working and I didn't dig (I just left it off).
>>> Thus, I'm no expert on descriptor DMA.  ...that being said, my
>>> understanding is that if you enable descriptor DMA in the controller
>>> then it will enable a smarter DMA mode for some of the transfers.
>>> IIRC Descriptor DMA mode specifically can't handle splits.  Is my
>>> memory correct there?  Presumably that means that when you enable
>>> descriptor DMA in the controller the driver will automatically fall
>>> back to normal Address DMA mode if things get too complicated.  When
>>> it falls back to Address DMA mode, presumably dwc2_hcd_init() won't
>>> get called again.  That means that any data structures that are needed
>>> for Address DMA need to be allocated in dwc2_hcd_init() even if
>>> descriptor DMA is enabled because we might need to fall back to
>>> Address DMA.
>>>
>>> Thus, I'm suggesting changing the code to:
>>>
>>> if (hsotg->params.dma_desc_enable ||
>>>       hsotg->params.dma_desc_fs_enable) {
>>>       ...
>>>       ...
>>> }
>>>
>>> if (hsotg->params.host_dma) {
>>>      ...
>>> }
>>>
>>>
>>> ...as I said, I'm no expert and I could just be confused.  If
>>> something I say seems wrong please correct me.
>> Ah, I got it. Thanks for your detailed explanation. Although I don't know if
>> it's possible that dwc2 driver automatically fall back to normal Address DMA
>> mode when desc DMA work abnormally with split, I agree with your suggestion.
>> I'll fix it in V4 patch.
> Hmm, I guess you're right.  I did a quick search and I can't find any
> evidence of a fallback like this.  Maybe I dreamed that.  I found some
> old comment in the commit history that said:
I think you're right. I find that it's possible to fall back to Address 
DMA mode if desc DMA initialization failure. The error case is:in 
dwc2_hcd_init(),  if it fails to create dwc2 generic desc cache or dwc2 
hs isoc desc cache, then it will disable desc DMA and fall back to 
Address DMA mode.
>
> /*
>   * Disable descriptor dma mode by default as the HW can support
>   * it, but does not support it for SPLIT transactions.
>   * Disable it for FS devices as well.
>   */
>
> ...and it looks there's currently nobody using descriptor DMA anyway
> (assuming I read the code correctly).  It does seem like people were
> ever going to turn it on then it would have to be dynamic as I was
> dreaming it was...
Yes, the dwc2 desc DMA mode can't support split transaction. So few 
people use desc DMA mode for OTG Host mode. BTW, I find that the latest 
code enable desc DMA mode by default for the OTG peripheral mode if the 
dwc2 hardware support desc DMA.
>

  reply	other threads:[~2018-05-11  9:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-08  3:07 [PATCH v3 0/2] usb: dwc2: fix isoc split in transfer issue William Wu
2018-05-08  3:07 ` [PATCH v3 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in William Wu
2018-05-08  5:11   ` Doug Anderson
2018-05-08  7:43     ` wlf
2018-05-08 15:29       ` Doug Anderson
2018-05-09  8:55         ` wlf
2018-05-10 20:59           ` Doug Anderson
2018-05-11  9:26             ` wlf [this message]
2018-05-08  3:07 ` [PATCH v3 2/2] usb: dwc2: fix isoc split in transfer with no data William Wu
2018-05-08  5:13   ` Doug Anderson
2018-05-08  7:01     ` wlf

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=3768eb42-98c4-5bd0-a796-5ba36d03cd35@rock-chips.com \
    --to=wulf@rock-chips.com \
    --cc=Allen.Hsu@quantatw.com \
    --cc=John.Youn@synopsys.com \
    --cc=Spruce.Wu@quantatw.com \
    --cc=StanTsui@aopen.com \
    --cc=daniel.meng@rock-chips.com \
    --cc=dianders@google.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=frank.wang@rock-chips.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=hminas@synopsys.com \
    --cc=huangtao@rock-chips.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=william.wu@rock-chips.com \
    --cc=wzz@rock-chips.com \
    --cc=zsq@rock-chips.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