On Sun, 1 Jul 2007, David Brownell wrote:
> As I understand it the actual mechanism is more like: platforms
> always set up a chunk of memory as uncached, and always map that
> through the IOMMU. Call that the DMA-{coherent,consistent} region.
>
> Utilities like dma_alloc_coherent() -- and henc
On Sun, 1 Jul 2007 21:02:11 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
> As I understand it the actual mechanism is more like: platforms
> always set up a chunk of memory as uncached, and always map that
> through the IOMMU. Call that the DMA-{coherent,consistent} region.
>
> Utilities li
On Wednesday 06 June 2007, Oliver Neukum wrote:
> Am Mittwoch, 6. Juni 2007 schrieb Pete Zaitcev:
> > The consistent allocation was intended to things like mailboxes,
> > where it is more advantageous to load a couple of words from uncached
> > memory than to call an API which invalidates or fl
On Mon, Jun 04, 2007 at 10:38:44AM +0200, Marcel Holtmann wrote:
> Hi,
>
> after the discussion with Oliver at the LinuxTag last week, I started to
> re-write the hci_usb driver to remove this ugly cruft around the URB
> management in the driver. The basic driver (without ISOC support) is
> workin
On Tue, Jun 05, 2007 at 02:43:55PM +0200, Marcel Holtmann wrote:
> Hi Oliver,
>
> > > > > an alternate way would be to extend the usb_kill_anchored_urbs() with
> > > > > its own complete handler that gets called for every anchored URB. This
> > > > > would make it possible to cleanup the allocated
Am Mittwoch, 6. Juni 2007 schrieb Pete Zaitcev:
> On Wed, 6 Jun 2007 11:16:51 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > So what exactly is the problem? Is the documentation wrong?
>
> In the vast majority of cases, streaming transfer is more appropriate,
In which regard exactly? Coul
On Wed, 6 Jun 2007 11:16:51 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> So what exactly is the problem? Is the documentation wrong?
In the vast majority of cases, streaming transfer is more appropriate,
which is what you receive if you let HCD to establish and tear down
mappings. The consis
Am Dienstag, 5. Juni 2007 schrieb Pete Zaitcev:
> On Mon, 04 Jun 2007 10:38:44 +0200, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
>
> > static void urb_destroy(struct kref *kref)
> > {
> > struct urb *urb = to_urb(kref);
> > +
> > + if (urb->transfer_flags & URB_FREE_BUFFER)
> > +
Am Dienstag, 5. Juni 2007 schrieb Pete Zaitcev:
> On Tue, 5 Jun 2007 15:29:12 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > Perhaps you need to have two flags, for freeing unconditionally
> > and on condition of no errors having happened.
> > If you free unconditionally handling errors, eg
Hi Pete,
> > The usb_buffer_alloc() and usb_buffer_free() usage was taken from the
> > skeleton example driver. No idea if that is a good idea or not. I was
> > under the impression that using the provided helper function that take
> > care of DMA is a good thing.
>
> Just as I suspected.
>
> Yo
On Tue, 05 Jun 2007 17:26:24 +0200, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> The usb_buffer_alloc() and usb_buffer_free() usage was taken from the
> skeleton example driver. No idea if that is a good idea or not. I was
> under the impression that using the provided helper function that take
>
Hi Pete,
> > Perhaps you need to have two flags, for freeing unconditionally
> > and on condition of no errors having happened.
> > If you free unconditionally handling errors, eg. clearing a stall becomes
> > hard.
>
> This assertion makes no sense to me. URBs are not "freed" or "put" by
> magic
Hi Pete,
> > static void urb_destroy(struct kref *kref)
> > {
> > struct urb *urb = to_urb(kref);
> > +
> > + if (urb->transfer_flags & URB_FREE_BUFFER)
> > + usb_buffer_free(urb->dev, urb->transfer_buffer_length,
> > + urb->transfer_buffer, urb->transfe
On Mon, 04 Jun 2007 10:38:44 +0200, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> static void urb_destroy(struct kref *kref)
> {
> struct urb *urb = to_urb(kref);
> +
> + if (urb->transfer_flags & URB_FREE_BUFFER)
> + usb_buffer_free(urb->dev, urb->transfer_buffer_length,
>
On Tue, 5 Jun 2007 15:29:12 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Perhaps you need to have two flags, for freeing unconditionally
> and on condition of no errors having happened.
> If you free unconditionally handling errors, eg. clearing a stall becomes
> hard.
This assertion makes n
Am Dienstag, 5. Juni 2007 14:43 schrieb Marcel Holtmann:
Hello,
> > > To avoid confusion we could rename it to usb_release_t or something
> > > similar.
> >
> > One usage is a bit weak to add common code.
>
> this is why I wanna have a general solution for one-shot buffers.
I understand and co
Hi Oliver,
> > > > an alternate way would be to extend the usb_kill_anchored_urbs() with
> > > > its own complete handler that gets called for every anchored URB. This
> > > > would make it possible to cleanup the allocated buffers. I attached a
> > > > patch for that, too.
> > >
> > > No, that w
Am Montag, 4. Juni 2007 16:44 schrieb Marcel Holtmann:
> Hi Oliver,
Hello,
> > > an alternate way would be to extend the usb_kill_anchored_urbs() with
> > > its own complete handler that gets called for every anchored URB. This
> > > would make it possible to cleanup the allocated buffers. I atta
Hi Oliver,
> > an alternate way would be to extend the usb_kill_anchored_urbs() with
> > its own complete handler that gets called for every anchored URB. This
> > would make it possible to cleanup the allocated buffers. I attached a
> > patch for that, too.
>
> No, that would mean an URB could h
Am Montag, 4. Juni 2007 13:58 schrieb Marcel Holtmann:
> an alternate way would be to extend the usb_kill_anchored_urbs() with
> its own complete handler that gets called for every anchored URB. This
> would make it possible to cleanup the allocated buffers. I attached a
> patch for that, too.
No
Hi,
> after the discussion with Oliver at the LinuxTag last week, I started to
> re-write the hci_usb driver to remove this ugly cruft around the URB
> management in the driver. The basic driver (without ISOC support) is
> working perfectly fine and thanks to the reference count of the URB and
> t
21 matches
Mail list logo
