On Tue, Jan 08, 2013 at 07:31:30AM -0700, Jonathan Corbet wrote:
> On Tue, 08 Jan 2013 07:50:41 +0100
> Marek Szyprowski wrote:
>
> > > Couldn't this performance difference be due to the usage of GFP_DMA inside
> > > the VB2 code, like Federico's new patch series is proposing?
> > >
> > > If
On Tue, 08 Jan 2013 07:50:41 +0100
Marek Szyprowski wrote:
> > Couldn't this performance difference be due to the usage of GFP_DMA inside
> > the VB2 code, like Federico's new patch series is proposing?
> >
> > If not, why are there a so large performance penalty?
>
> Nope, this was caused
On Tue, 08 Jan 2013 07:50:41 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
Couldn't this performance difference be due to the usage of GFP_DMA inside
the VB2 code, like Federico's new patch series is proposing?
If not, why are there a so large performance penalty?
Nope, this
On Tue, Jan 08, 2013 at 07:31:30AM -0700, Jonathan Corbet wrote:
On Tue, 08 Jan 2013 07:50:41 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
Couldn't this performance difference be due to the usage of GFP_DMA inside
the VB2 code, like Federico's new patch series is proposing?
On 1/7/2013 9:15 PM, Mauro Carvalho Chehab wrote:
Em Mon, 7 Jan 2013 12:40:50 -0700
Jonathan Corbet escreveu:
> On Mon, 7 Jan 2013 00:09:47 +0100
> Alessandro Rubini wrote:
>
> > I don't expect you'll see serious performance differences on the PC. I
> > think ARM users will have better
Em Mon, 7 Jan 2013 12:40:50 -0700
Jonathan Corbet escreveu:
> On Mon, 7 Jan 2013 00:09:47 +0100
> Alessandro Rubini wrote:
>
> > I don't expect you'll see serious performance differences on the PC. I
> > think ARM users will have better benefits, due to the different cache
> > architecture.
On Mon, 7 Jan 2013 00:09:47 +0100
Alessandro Rubini wrote:
> I don't expect you'll see serious performance differences on the PC. I
> think ARM users will have better benefits, due to the different cache
> architecture. You told me Jon measured meaningful figures on a Marvel
> CPU.
It made the
On Mon, 7 Jan 2013 00:09:47 +0100
Alessandro Rubini rub...@gnudd.com wrote:
I don't expect you'll see serious performance differences on the PC. I
think ARM users will have better benefits, due to the different cache
architecture. You told me Jon measured meaningful figures on a Marvel
CPU.
Em Mon, 7 Jan 2013 12:40:50 -0700
Jonathan Corbet cor...@lwn.net escreveu:
On Mon, 7 Jan 2013 00:09:47 +0100
Alessandro Rubini rub...@gnudd.com wrote:
I don't expect you'll see serious performance differences on the PC. I
think ARM users will have better benefits, due to the different
On 1/7/2013 9:15 PM, Mauro Carvalho Chehab wrote:
Em Mon, 7 Jan 2013 12:40:50 -0700
Jonathan Corbet cor...@lwn.net escreveu:
On Mon, 7 Jan 2013 00:09:47 +0100
Alessandro Rubini rub...@gnudd.com wrote:
I don't expect you'll see serious performance differences on the PC. I
think ARM users
> The problem is that on the sta2x11 architecture only the first
> 512MB are available through the PCI bus, but the allocator can allocate
> memory
> for DMA above this limit. By using GFP_DMA flags the allocation take place
> under the 16MB so it works.
Still, you are not running the
> I have more information about DMA on the board that I'm using; probably, I
> can make dma-contig work with my device.
Ok, the driver STA2X11 now works with a patched dma-contig allocator. So, my
streaming allocator it is not mandatory.
I based my work on the previous work made by Windriver,
I have more information about DMA on the board that I'm using; probably, I
can make dma-contig work with my device.
Ok, the driver STA2X11 now works with a patched dma-contig allocator. So, my
streaming allocator it is not mandatory.
I based my work on the previous work made by Windriver,
The problem is that on the sta2x11 architecture only the first
512MB are available through the PCI bus, but the allocator can allocate
memory
for DMA above this limit. By using GFP_DMA flags the allocation take place
under the 16MB so it works.
Still, you are not running the upstream
On Thursday 03 January 2013 17:13:14 Federico Vaga wrote:
> > After all those discussions, I'm ok on adding this new driver, but please
> > add a summary of those discussions at the patch description. As I said,
> > the reason why this driver is needed is not obvious. So, it needs to be
> > very
On Thursday 03 January 2013 17:13:14 Federico Vaga wrote:
After all those discussions, I'm ok on adding this new driver, but please
add a summary of those discussions at the patch description. As I said,
the reason why this driver is needed is not obvious. So, it needs to be
very well
> After all those discussions, I'm ok on adding this new driver, but please
> add a summary of those discussions at the patch description. As I said,
> the reason why this driver is needed is not obvious. So, it needs to be
> very well described.
ack. I will ask more information to ST about the
After all those discussions, I'm ok on adding this new driver, but please
add a summary of those discussions at the patch description. As I said,
the reason why this driver is needed is not obvious. So, it needs to be
very well described.
ack. I will ask more information to ST about the board
Hi Federico,
Em Thu, 20 Dec 2012 16:37:50 +0100
Federico Vaga escreveu:
> > I can take a look at the dma coherent issues with that board, but I
> will
> > need some help as I don't have this hardware.
>
> I have the hardware, but I don't have the full knowledge of the
> boards. As I told
Hi Federico,
Em Thu, 20 Dec 2012 16:37:50 +0100
Federico Vaga federico.v...@gmail.com escreveu:
I can take a look at the dma coherent issues with that board, but I
will
need some help as I don't have this hardware.
I have the hardware, but I don't have the full knowledge of the
> I can take a look at the dma coherent issues with that board, but I
will
> need some help as I don't have this hardware.
I have the hardware, but I don't have the full knowledge of the
boards. As I told before, I asked to windriver which develop the
software for the whole board, but they
I can take a look at the dma coherent issues with that board, but I
will
need some help as I don't have this hardware.
I have the hardware, but I don't have the full knowledge of the
boards. As I told before, I asked to windriver which develop the
software for the whole board, but they
Hello,
I'm sorry for the delay, I've been terribly busy recently.
On 12/11/2012 2:54 PM, Federico Vaga wrote:
> This allocator is needed because some device (like STA2X11 VIP) cannot
> work
> with DMA sg or DMA coherent. Some other device (like the one used by
> Jonathan when he proposes
Hello,
I'm sorry for the delay, I've been terribly busy recently.
On 12/11/2012 2:54 PM, Federico Vaga wrote:
This allocator is needed because some device (like STA2X11 VIP) cannot
work
with DMA sg or DMA coherent. Some other device (like the one used by
Jonathan when he proposes
Sorry for the late answer to this.
> > This allocator is needed because some device (like STA2X11 VIP) cannot
> > work
> > with DMA sg or DMA coherent. Some other device (like the one used by
> > Jonathan when he proposes vb2-dma-nc allocator) can obtain much better
> > performance with DMA
Sorry for the late answer to this.
This allocator is needed because some device (like STA2X11 VIP) cannot
work
with DMA sg or DMA coherent. Some other device (like the one used by
Jonathan when he proposes vb2-dma-nc allocator) can obtain much better
performance with DMA streaming than
Em 05-12-2012 10:50, Federico Vaga escreveu:
On Tuesday 04 December 2012 14:04:22 Mauro Carvalho Chehab wrote:
Em 24-09-2012 09:44, Marek Szyprowski escreveu:
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
The DMA streaming allocator is similar to the DMA contig but it
On Tuesday 04 December 2012 14:04:22 Mauro Carvalho Chehab wrote:
> Em 24-09-2012 09:44, Marek Szyprowski escreveu:
> > Hello,
> >
> > On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
> >> The DMA streaming allocator is similar to the DMA contig but it use the
> >> DMA streaming
On Tuesday 04 December 2012 14:04:22 Mauro Carvalho Chehab wrote:
Em 24-09-2012 09:44, Marek Szyprowski escreveu:
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
The DMA streaming allocator is similar to the DMA contig but it use the
DMA streaming interface
Em 05-12-2012 10:50, Federico Vaga escreveu:
On Tuesday 04 December 2012 14:04:22 Mauro Carvalho Chehab wrote:
Em 24-09-2012 09:44, Marek Szyprowski escreveu:
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
The DMA streaming allocator is similar to the DMA contig but it
Em 24-09-2012 09:44, Marek Szyprowski escreveu:
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
The DMA streaming allocator is similar to the DMA contig but it use the
DMA streaming interface (dma_map_single, dma_unmap_single). The
allocator allocates buffers and
Em 24-09-2012 09:44, Marek Szyprowski escreveu:
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
The DMA streaming allocator is similar to the DMA contig but it use the
DMA streaming interface (dma_map_single, dma_unmap_single). The
allocator allocates buffers and
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
> The DMA streaming allocator is similar to the DMA contig but it use the
> DMA streaming interface (dma_map_single, dma_unmap_single). The
> allocator allocates buffers and immediately map the memory for DMA
> transfer. For each
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
The DMA streaming allocator is similar to the DMA contig but it use the
DMA streaming interface (dma_map_single, dma_unmap_single). The
allocator allocates buffers and immediately map the memory for DMA
transfer. For each
34 matches
Mail list logo
