From: Albert Herranz <albert_herranz@yahoo.es>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag
Date: Tue, 02 Mar 2010 18:02:31 +0100 [thread overview]
Message-ID: <4B8D44A7.7030302@yahoo.es> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1003021034190.1730-100000@iolanthe.rowland.org>
Alan Stern wrote:
> On Mon, 1 Mar 2010, Albert Herranz wrote:
>
>>> If transfer_buffer_length is 0 then do nothing.
>>> Otherwise if num_sgs > 0 then do nothing.
>>> Otherwise if URB_NO_TRANSFER_DMA_MAP and transfer_dma
>>> are both set (this avoids your HCD_NO_COHERENT_MEM
>>> case) then do nothing.
>>>
>> I see. This case would include the PIO case too (for which dma_handle
>> is set to all 1s).
>
> The test above should be transfer_dma != ~0, not transfer_dma != 0,
> since ~0 means the DMA address isn't set. In fact I forgot to
> include the PIO case; it should be handled by changing the remaining
> tests as follows:
>
> Otherwise if hcd->self.uses_dma is set then
> If this URB doesn't require PIO then call dma_map_single
> Otherwise if HCD_LOCAL_MEM is set then call hcd_alloc_coherent
> Otherwise do nothing (PIO case).
>
> Currently "this URB doesn't require PIO" is always true, but in the
> future it won't be.
>
Can this be currently tested?
Should I make provisions for this check now too?
>> So this assumes that transfer_dma should be set initially to 0 when
>> allocating USB buffers for HCD_NO_COHERENT_MEM.
>
> No, it should be set to ~0, the same as when buffers are allocated for
> a PIO-based controller.
>
This logic now resembles more the one in my v2 proposal although with different formal checks.
I think I'll code and post another iteration of the 8/9 patch with your proposed checks and then we can continue further discussion on it.
I'll try to add explanatory comments for each check.
> Alan Stern
>
Thanks a lot for your input,
Albert
WARNING: multiple messages have this Message-ID (diff)
From: albert_herranz@yahoo.es (Albert Herranz)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag
Date: Tue, 02 Mar 2010 18:02:31 +0100 [thread overview]
Message-ID: <4B8D44A7.7030302@yahoo.es> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1003021034190.1730-100000@iolanthe.rowland.org>
Alan Stern wrote:
> On Mon, 1 Mar 2010, Albert Herranz wrote:
>
>>> If transfer_buffer_length is 0 then do nothing.
>>> Otherwise if num_sgs > 0 then do nothing.
>>> Otherwise if URB_NO_TRANSFER_DMA_MAP and transfer_dma
>>> are both set (this avoids your HCD_NO_COHERENT_MEM
>>> case) then do nothing.
>>>
>> I see. This case would include the PIO case too (for which dma_handle
>> is set to all 1s).
>
> The test above should be transfer_dma != ~0, not transfer_dma != 0,
> since ~0 means the DMA address isn't set. In fact I forgot to
> include the PIO case; it should be handled by changing the remaining
> tests as follows:
>
> Otherwise if hcd->self.uses_dma is set then
> If this URB doesn't require PIO then call dma_map_single
> Otherwise if HCD_LOCAL_MEM is set then call hcd_alloc_coherent
> Otherwise do nothing (PIO case).
>
> Currently "this URB doesn't require PIO" is always true, but in the
> future it won't be.
>
Can this be currently tested?
Should I make provisions for this check now too?
>> So this assumes that transfer_dma should be set initially to 0 when
>> allocating USB buffers for HCD_NO_COHERENT_MEM.
>
> No, it should be set to ~0, the same as when buffers are allocated for
> a PIO-based controller.
>
This logic now resembles more the one in my v2 proposal although with different formal checks.
I think I'll code and post another iteration of the 8/9 patch with your proposed checks and then we can continue further discussion on it.
I'll try to add explanatory comments for each check.
> Alan Stern
>
Thanks a lot for your input,
Albert
next prev parent reply other threads:[~2010-03-02 17:02 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-28 14:07 [RFC PATCH v2 0/9] wii: add usb 2.0 support Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 1/9] powerpc: add per-device dma coherent support Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 2/9] wii: have generic dma coherent Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 3/9] dma-coherent: fix bitmap access races Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 4/9] add generic dmabounce support Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:20 ` Russell King - ARM Linux
2010-02-28 14:20 ` Russell King - ARM Linux
2010-02-28 16:37 ` Albert Herranz
2010-02-28 16:37 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 5/9] arm: use " Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 6/9] powerpc: add optional per-device " Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:08 ` [RFC PATCH v2 7/9] wii: add mem2 dma mapping ops Albert Herranz
2010-02-28 14:08 ` Albert Herranz
2010-02-28 14:08 ` [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag Albert Herranz
2010-02-28 14:08 ` Albert Herranz
2010-03-01 14:49 ` Alan Stern
2010-03-01 14:49 ` Alan Stern
2010-03-01 18:38 ` Albert Herranz
2010-03-01 18:38 ` Albert Herranz
2010-03-01 19:23 ` Alan Stern
2010-03-01 19:23 ` Alan Stern
2010-03-01 20:11 ` Albert Herranz
2010-03-01 20:11 ` Albert Herranz
2010-03-01 20:45 ` Alan Stern
2010-03-01 20:45 ` Alan Stern
2010-03-01 22:55 ` Albert Herranz
2010-03-01 22:55 ` Albert Herranz
2010-03-02 15:50 ` Alan Stern
2010-03-02 15:50 ` Alan Stern
2010-03-02 17:02 ` Albert Herranz [this message]
2010-03-02 17:02 ` Albert Herranz
2010-03-02 17:43 ` Alan Stern
2010-03-02 17:43 ` Alan Stern
2010-02-28 14:08 ` [RFC PATCH v2 9/9] wii: hollywood ehci controller support Albert Herranz
2010-02-28 14:08 ` Albert Herranz
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=4B8D44A7.7030302@yahoo.es \
--to=albert_herranz@yahoo.es \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=stern@rowland.harvard.edu \
/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.