[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130106230947.GA17979@mail.gnudd.com>
Date: Mon, 7 Jan 2013 00:09:47 +0100
From: Alessandro Rubini <rubini@...dd.com>
To: federico.vaga@...il.com
Cc: mchehab@...hat.com, m.szyprowski@...sung.com,
mchehab@...radead.org, pawel@...iak.com, hans.verkuil@...co.com,
giancarlo.asnaghi@...com, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org, corbet@....net,
s.nawrocki@...sung.com
Subject: Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory
allocator
> 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 allocator. IIUC, you added a
"gfp_t" field in the platform data or somewhere, so the sta2x11 can
request GFP_DMA to be OR'd, while other users remain unaffected. Will
you please submit the patch to achieve that?
> I cannot do performance test at the moment because I don't have the time, so I
> cannot personally justify the presence of a new allocator.
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.
> I will propose V4 patches soon.
thanks
/alessandro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists