From: Alan Stern on
On Thu, 8 Apr 2010, Daniel Mack wrote:

> > > AFAIK, the driver shouldn't have to worry about this at all. When the
> > > buffer gets DMA-mapped for the controller, the DMA mapping code should
> > > see that the device has a 32-bit DMA mask and either bounce or IOMMU-map
> > > the memory so that it appears below 4GB.
> >
> > That's true. It would of course be more efficient for the buffer to be
> > allocated below 4 GB, but it should work okay either way. Daniel, do
> > you have any idea why it fails?
>
> No, and I can't do real tests as I lack a 64bit machine. I'll do some
> more investigation later today, but for now the only explanation I have
> is that not the remapped DMA buffer is used eventually by the EHCI code
> but the physical address of the original buffer.
>
> It would of course be best to fix the whole problem at this level, if
> possible.

It definitely needs to be fixed at this level. But I still think it's
appropriate to have new USB core functions for allocating and
deallocating I/O memory. The additional price is small compared to
constantly bouncing the buffers.

Pedro, in the hope of tracking down the problem, can you apply this
patch and see what output it produces in the system log when the
"interference" happens? (Warning: It will produce quite a lot of
output whenever you send data to the audio device -- between 500 and
1000 lines per second.)

Alan Stern



Index: 2.6.33/drivers/usb/core/hcd.c
===================================================================
--- 2.6.33.orig/drivers/usb/core/hcd.c
+++ 2.6.33/drivers/usb/core/hcd.c
@@ -1395,6 +1395,10 @@ int usb_hcd_submit_urb (struct urb *urb,
usbmon_urb_submit_error(&hcd->self, urb, status);
goto error;
}
+ if (usb_endpoint_is_isoc_out(&urb->ep->desc))
+ dev_info(&urb->dev->dev, "Iso xfer %p dma %llx\n",
+ urb->transfer_buffer,
+ (unsigned long long) urb->transfer_dma);

if (is_root_hub(urb->dev))
status = rh_urb_enqueue(hcd, urb);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pedro Ribeiro on
On 8 April 2010 17:57, Alan Stern <stern(a)rowland.harvard.edu> wrote:
> On Thu, 8 Apr 2010, Daniel Mack wrote:
>
>> > > AFAIK, the driver shouldn't have to worry about this at all. When the
>> > > buffer gets DMA-mapped for the controller, the DMA mapping code should
>> > > see that the device has a 32-bit DMA mask and either bounce or IOMMU-map
>> > > the memory so that it appears below 4GB.
>> >
>> > That's true. �It would of course be more efficient for the buffer to be
>> > allocated below 4 GB, but it should work okay either way. �Daniel, do
>> > you have any idea why it fails?
>>
>> No, and I can't do real tests as I lack a 64bit machine. I'll do some
>> more investigation later today, but for now the only explanation I have
>> is that not the remapped DMA buffer is used eventually by the EHCI code
>> but the physical address of the original buffer.
>>
>> It would of course be best to fix the whole problem at this level, if
>> possible.
>
> It definitely needs to be fixed at this level. �But I still think it's
> appropriate to have new USB core functions for allocating and
> deallocating I/O memory. �The additional price is small compared to
> constantly bouncing the buffers.
>
> Pedro, in the hope of tracking down the problem, can you apply this
> patch and see what output it produces in the system log when the
> "interference" happens? �(Warning: It will produce quite a lot of
> output whenever you send data to the audio device -- between 500 and
> 1000 lines per second.)
>
> Alan Stern
>
>
>
> Index: 2.6.33/drivers/usb/core/hcd.c
> ===================================================================
> --- 2.6.33.orig/drivers/usb/core/hcd.c
> +++ 2.6.33/drivers/usb/core/hcd.c
> @@ -1395,6 +1395,10 @@ int usb_hcd_submit_urb (struct urb *urb,
> � � � � � � � �usbmon_urb_submit_error(&hcd->self, urb, status);
> � � � � � � � �goto error;
> � � � �}
> + � � � if (usb_endpoint_is_isoc_out(&urb->ep->desc))
> + � � � � � � � dev_info(&urb->dev->dev, "Iso xfer %p dma %llx\n",
> + � � � � � � � � � � � � � � � urb->transfer_buffer,
> + � � � � � � � � � � � � � � � (unsigned long long) urb->transfer_dma);
>
> � � � �if (is_root_hub(urb->dev))
> � � � � � � � �status = rh_urb_enqueue(hcd, urb);
>
>

I'll do it tonight and send you the results tomorrow morning. Do you
want CONFIG_USB_DEBUG enabled or disabled?

Pedro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Thu, 8 Apr 2010, Pedro Ribeiro wrote:

> > Pedro, in the hope of tracking down the problem, can you apply this
> > patch and see what output it produces in the system log when the
> > "interference" happens? �(Warning: It will produce quite a lot of
> > output whenever you send data to the audio device -- between 500 and
> > 1000 lines per second.)

> I'll do it tonight and send you the results tomorrow morning. Do you
> want CONFIG_USB_DEBUG enabled or disabled?

It doesn't matter.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on
Am Donnerstag, 8. April 2010 18:59:38 schrieb Alan Stern:
> On Thu, 8 Apr 2010, Oliver Neukum wrote:
>
> > Am Mittwoch, 7. April 2010 17:46:17 schrieb Alan Stern:
> > > Or alternatively, instead of allocating regular memory the routine
> > > could simply fail. Then the caller would be responsible for checking
> > > and using regular memory instead of dma-consistent memory. Of course,
> > > that would put an even larger burden on the caller than just forcing it
> > > to keep track of what flag to use.
> >
> > Then it would be sensible to pass it a filled URB, modify it or return
> > an error code.
>
> That would work, but it doesn't match the way existing drivers use the
> interface. For example, the audio driver allocates a 16-byte coherent
> buffer and then uses four bytes from it for each of four different
> URBs.

That will not work with any fallback that does not yield a coherent buffer.

Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Thu, 8 Apr 2010, Oliver Neukum wrote:

> Am Donnerstag, 8. April 2010 18:59:38 schrieb Alan Stern:
> > On Thu, 8 Apr 2010, Oliver Neukum wrote:
> >
> > > Am Mittwoch, 7. April 2010 17:46:17 schrieb Alan Stern:
> > > > Or alternatively, instead of allocating regular memory the routine
> > > > could simply fail. Then the caller would be responsible for checking
> > > > and using regular memory instead of dma-consistent memory. Of course,
> > > > that would put an even larger burden on the caller than just forcing it
> > > > to keep track of what flag to use.
> > >
> > > Then it would be sensible to pass it a filled URB, modify it or return
> > > an error code.
> >
> > That would work, but it doesn't match the way existing drivers use the
> > interface. For example, the audio driver allocates a 16-byte coherent
> > buffer and then uses four bytes from it for each of four different
> > URBs.
>
> That will not work with any fallback that does not yield a coherent buffer.

What you mean isn't entirely clear. But it certainly does work in
various circumstances that don't yield coherent buffers. For example,
it works if the controller uses PIO instead of DMA. It also works if
the controller uses DMA and the URBs have to be bounced.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/