All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@google.com>
To: wlf <wulf@rock-chips.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>,
	"Martin Tsai" <Martin.Tsai@quantatw.com>,
	"Kevin Hsueh" <Kevin.Shai@quantatw.com>,
	"Mon-Jer Wu (吳孟哲)" <Mon-Jer.Wu@quantatw.com>,
	"Claud Chang (張恭築)" <Claud.Chang@quantatw.com>,
	"San Lin (林建菱)" <San.Lin@quantatw.com>,
	"Ren Kuo" <Ren.Kuo@quantatw.com>,
	"David H.T. Wang" <davidhtwang@aopen.com>,
	"Fong Lin" <fonglin@aopen.com>,
	"Steven Cheng" <stevencheng@aopen.com>,
	"Tom Chen" <tomchen@aopen.com>, "Don Chang" <donchang@aopen.com>,
	milesschofield@aopen.com
Subject: Re: [PATCH v3 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in
Date: Thu, 10 May 2018 13:59:13 -0700	[thread overview]
Message-ID: <CAD=FV=Xsa9MAw==_Oi28B69oqZehwL2JTwEzjKAnH5PS5wKC_A@mail.gmail.com> (raw)
In-Reply-To: <196bd304-3c6b-91b6-1743-50d6d13fc5a5@rock-chips.com>

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:

/*
 * 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...

-Doug

WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@google.com>
To: wlf <wulf@rock-chips.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>,
	"Martin Tsai" <Martin.Tsai@quantatw.com>,
	"Kevin Hsueh" <Kevin.Shai@quantatw.com>,
	"Mon-Jer Wu (吳孟哲)" <Mon-Jer.Wu@quantatw.com>,
	"Claud Chang (張恭築)" <Claud.Chang@quantatw.com>,
	"San Lin (林建菱)" <San.Lin@quantatw.com>,
	"Ren Kuo" <Ren.Kuo@quantatw.com>,
	"David H.T. Wang" <davidhtwang@aopen.com>,
	"Fong Lin" <fonglin@aopen.com>,
	"Steven Cheng" <stevencheng@aopen.com>,
	"Tom Chen" <tomchen@aopen.com>, "Don Chang" <donchang@aopen.com>,
	milesschofield@aopen.com
Subject: [v3,1/2] usb: dwc2: alloc dma aligned buffer for isoc split in
Date: Thu, 10 May 2018 13:59:13 -0700	[thread overview]
Message-ID: <CAD=FV=Xsa9MAw==_Oi28B69oqZehwL2JTwEzjKAnH5PS5wKC_A@mail.gmail.com> (raw)

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:

/*
 * 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...

-Doug
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@google.com>
To: wlf <wulf@rock-chips.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: Thu, 10 May 2018 13:59:13 -0700	[thread overview]
Message-ID: <CAD=FV=Xsa9MAw==_Oi28B69oqZehwL2JTwEzjKAnH5PS5wKC_A@mail.gmail.com> (raw)
In-Reply-To: <196bd304-3c6b-91b6-1743-50d6d13fc5a5@rock-chips.com>

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:

/*
 * 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...

-Doug

  reply	other threads:[~2018-05-10 20:59 UTC|newest]

Thread overview: 29+ 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  3:07   ` [v3,1/2] " William Wu
2018-05-08  5:11   ` [PATCH v3 1/2] " Doug Anderson
2018-05-08  5:11     ` Doug Anderson
2018-05-08  5:11     ` [v3,1/2] " Doug Anderson
2018-05-08  7:43     ` [PATCH v3 1/2] " wlf
2018-05-08  7:43       ` wlf
2018-05-08  7:43       ` [v3,1/2] " William Wu
2018-05-08 15:29       ` [PATCH v3 1/2] " Doug Anderson
2018-05-08 15:29         ` Doug Anderson
2018-05-08 15:29         ` [v3,1/2] " Doug Anderson
2018-05-09  8:55         ` [PATCH v3 1/2] " wlf
2018-05-09  8:55           ` wlf
2018-05-09  8:55           ` [v3,1/2] " William Wu
2018-05-10 20:59           ` Doug Anderson [this message]
2018-05-10 20:59             ` [PATCH v3 1/2] " Doug Anderson
2018-05-10 20:59             ` [v3,1/2] " Doug Anderson
2018-05-11  9:26             ` [PATCH v3 1/2] " wlf
2018-05-11  9:26               ` wlf
2018-05-11  9:26               ` [v3,1/2] " William Wu
2018-05-08  3:07 ` [PATCH v3 2/2] usb: dwc2: fix isoc split in transfer with no data William Wu
2018-05-08  3:07   ` [v3,2/2] " William Wu
2018-05-08  5:13   ` [PATCH v3 2/2] " Doug Anderson
2018-05-08  5:13     ` Doug Anderson
2018-05-08  5:13     ` [v3,2/2] " Doug Anderson
2018-05-08  7:01     ` [PATCH v3 2/2] " wlf
2018-05-08  7:01       ` wlf
2018-05-08  7:01       ` [v3,2/2] " William Wu

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='CAD=FV=Xsa9MAw==_Oi28B69oqZehwL2JTwEzjKAnH5PS5wKC_A@mail.gmail.com' \
    --to=dianders@google.com \
    --cc=Allen.Hsu@quantatw.com \
    --cc=Claud.Chang@quantatw.com \
    --cc=John.Youn@synopsys.com \
    --cc=Kevin.Shai@quantatw.com \
    --cc=Martin.Tsai@quantatw.com \
    --cc=Mon-Jer.Wu@quantatw.com \
    --cc=Ren.Kuo@quantatw.com \
    --cc=San.Lin@quantatw.com \
    --cc=Spruce.Wu@quantatw.com \
    --cc=StanTsui@aopen.com \
    --cc=daniel.meng@rock-chips.com \
    --cc=davidhtwang@aopen.com \
    --cc=donchang@aopen.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=fonglin@aopen.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=milesschofield@aopen.com \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=stevencheng@aopen.com \
    --cc=tomchen@aopen.com \
    --cc=william.wu@rock-chips.com \
    --cc=wulf@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.