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: Mon, 01 Mar 2010 19:38:19 +0100 [thread overview]
Message-ID: <4B8C099B.30504@yahoo.es> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1003010943480.1645-100000@iolanthe.rowland.org>
Alan Stern wrote:
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -1260,6 +1260,34 @@ static void hcd_free_coherent(struct usb_bus *bus, dma_addr_t *dma_handle,
>> *dma_handle = 0;
>> }
>>
>> +static int urb_needs_setup_dma_map(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->setup_dma == ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_setup_dma_unmap(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->setup_dma && urb->setup_dma != ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_transfer_dma_map(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->transfer_dma == ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_transfer_dma_unmap(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->transfer_dma && urb->transfer_dma != ~(dma_addr_t)0);
>> +}
>> +
>
> These functions would be a lot easier to understand if they were
> expanded into multiple test and return statements, rather than
> squeezing all the Boolean manipulations into single expressions. (Not
> to mention the fact that other developement is going to make them even
> more complicated than they are now...)
>
Yes, agreed. I'll enhance that, thanks.
> Also, I can't help thinking that the corresponding *_map() and
> *_unmap() routines are so similar, it ought to be possible to combine
> them. The only difference is a check for a NULL DMA address, and it's
> not clear to me why it is present. It's also not clear why the test
> for a DMA address of all ones is present. Maybe they both can be
> removed.
>
I think too that I can simplify that logic.
I added those checks in a defensive way seeking robustness while I familiarize with the USB stack innards. So far, those cases are just avoiding mappings when urb_needs_transfer_dma_map()/urb_needs_transfer_dma_unmap() are called with urb->transfer_buffer == 0 and urb->transfer_dma == 0.
I guess that those cases are related to scatterlist-based urb requests.
What should be the correct way to check if a urb has already been scatter/gather-mapped?
The final logic would be something like:
- map if URB_NO_TRANSFER_DMA_MAP is cleared
- otherwise (URB_TRANSFER_NO_DMA_MAP is set so) map if HCD_NO_COHERENT_MEM is set _and_ it's not a scatter/gather request (as that should have been mapped already by usb_buffer_map_sg())
Am I on the right path?
> Alan Stern
>
Thanks,
Albert
next prev parent reply other threads:[~2010-03-01 18:38 UTC|newest]
Thread overview: 21+ 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 ` [RFC PATCH v2 1/9] powerpc: add per-device dma coherent support Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 2/9] wii: have generic dma coherent 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 ` [RFC PATCH v2 4/9] add generic dmabounce support Albert Herranz
2010-02-28 14:20 ` Russell King - ARM Linux
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 ` [RFC PATCH v2 6/9] powerpc: add optional per-device " 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 ` [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag Albert Herranz
2010-03-01 14:49 ` Alan Stern
2010-03-01 18:38 ` Albert Herranz [this message]
2010-03-01 19:23 ` Alan Stern
2010-03-01 20:11 ` Albert Herranz
2010-03-01 20:45 ` Alan Stern
2010-03-01 22:55 ` Albert Herranz
2010-03-02 15:50 ` Alan Stern
2010-03-02 17:02 ` Albert Herranz
2010-03-02 17:43 ` Alan Stern
2010-02-28 14:08 ` [RFC PATCH v2 9/9] wii: hollywood ehci controller support 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=4B8C099B.30504@yahoo.es \
--to=albert_herranz@yahoo.es \
--cc=linux-arm-kernel@lists.infradead.org \
/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).