On Tue, Sep 21, 2010 at 10:41 PM, Kumar Gala wrote:
>
> On Sep 21, 2010, at 5:34 PM, Timur Tabi wrote:
>
>> On Tue, Sep 21, 2010 at 5:17 PM, Scott Wood wrote:
>>
>>> It needs to be the actual device that is performing the DMA -- the
>>> platform may need to do things such as IOMMU manipulation wh
On Sep 21, 2010, at 5:34 PM, Timur Tabi wrote:
> On Tue, Sep 21, 2010 at 5:17 PM, Scott Wood wrote:
>
>> It needs to be the actual device that is performing the DMA -- the
>> platform may need to do things such as IOMMU manipulation where
>> knowing the device matters.
>
> Ok, this all makes s
On Tue, Sep 21, 2010 at 5:17 PM, Scott Wood wrote:
> It needs to be the actual device that is performing the DMA -- the
> platform may need to do things such as IOMMU manipulation where
> knowing the device matters.
Ok, this all makes sense. So it appears that the patch is valid, at
least in th
On Tue, 21 Sep 2010 17:08:54 -0500
Timur Tabi wrote:
> On Tue, Sep 21, 2010 at 5:05 PM, Dan Malek wrote:
>
> > The DMA descriptors are accessed using DMA by the
> > controller itself.
>
> Yes and no. Technically, it is DMA, but it's not something that
> SWIOTLB could ever know about. We just
On Sep 21, 2010, at 2:49 PM, Scott Wood wrote:
On Tue, 21 Sep 2010 16:43:12 -0500
Timur Tabi wrote:
Since we don't DMA the descriptors themselves, I just don't see how
this patch does anything.
Look in dmaengine.c, there are calls to dma_map_single() and
dma_map_page(), using what I assum
On Tue, Sep 21, 2010 at 5:05 PM, Dan Malek wrote:
> The DMA descriptors are accessed using DMA by the
> controller itself.
Yes and no. Technically, it is DMA, but it's not something that
SWIOTLB could ever know about. We just pass the physical address to
the DMA controller, and it does a memor
On Tue, Sep 21, 2010 at 4:49 PM, Scott Wood wrote:
> Look in dmaengine.c, there are calls to dma_map_single() and
> dma_map_page(), using what I assume is that same device pointer --
> unless there's confusion between the channel and the controller.
You're right. I missed this line in the drive
On Tue, 21 Sep 2010 16:43:12 -0500
Timur Tabi wrote:
> On Tue, Sep 21, 2010 at 4:34 PM, Scott Wood wrote:
>
> > This doesn't control allocation (it probably should with
> > dma_alloc_coherent, though I don't see it in the code), it controls
> > whether swiotlb will create a bounce buffer -- def
On Tue, Sep 21, 2010 at 4:34 PM, Scott Wood wrote:
> This doesn't control allocation (it probably should with
> dma_alloc_coherent, though I don't see it in the code), it controls
> whether swiotlb will create a bounce buffer -- defeating the point of
> using DMA to accelerate a memcpy.
But it w
On Tue, 21 Sep 2010 16:24:10 -0500
Timur Tabi wrote:
> On Tue, Sep 21, 2010 at 7:55 AM, Kumar Gala wrote:
> >
> > On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
> >
> >> Signed-off-by: Li Yang
> >> ---
> >
> > We really should have a sentence about how or why this works to address
> > 36-bit addr
On Tue, Sep 21, 2010 at 7:55 AM, Kumar Gala wrote:
>
> On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
>
>> Signed-off-by: Li Yang
>> ---
>
> We really should have a sentence about how or why this works to address
> 36-bit addressing.
For example, I would like to know which memory is going to be
al
On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
> Signed-off-by: Li Yang
> ---
We really should have a sentence about how or why this works to address 36-bit
addressing.
> drivers/dma/fsldma.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/d
12 matches
Mail list logo
