On Wed, 24 Jun 2009 10:20:01 +0800
David Brownell <david-b@xxxxxxxxxxx> wrote:
> On Friday 12 June 2009, Alek Du wrote:
> > --- a/drivers/usb/core/buffer.c
> > +++ b/drivers/usb/core/buffer.c
> > @@ -115,6 +115,11 @@ void *hcd_buffer_alloc(
> > return kmalloc(size, mem_flags);
> > }
> >
> > + /* we won't use internal SRAM as data payload, we can't get
> > + any benefits from it */
>
> That comment is misleading. What you're really trying to do is
> work with *TWO* pools of DMA-coherent memory ... reserving the
> (on-chip) SRAM for driver-internal use.
>
> So please re-name that flag. It's not "has_sram" that matters;
> it's maybe more like "ignore_local_mem".
David,
This flag is defined and used in [PATCH 2/4 v3] EHCI: Support Intel Moorestown MPH and OTG host.
There the has_sram is "really" the meaning of has sram. :-).
Maybe I need to add a new flag as sram_no_payload to use here.
> For reference ... some of the other implementations of USB
> controllers with private SRAM *require* that it be used for
> data payloads as well as descriptors; their DMA engines do
> not have access to other memory. Such a controller most
> certainly "has_sram". Yet setting this flag would be very
> wrong, and would prevent USB from working.
>
The has_sram flag is introduced by [PATCH 2/4 v3], so other HCDs won't set it.
But you are right, it is misleading, I will add a new flag for this case.
Thanks,
Alek
>
> > + if (hcd->has_sram)
> > + return dma_alloc_coherent(NULL, size, dma, mem_flags);
> > +
> > for (i = 0; i < HCD_BUFFER_POOLS; i++) {
> > if (size <= pool_max [i])
> > return dma_pool_alloc(hcd->pool [i], mem_flags, dma);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
