On Sun, 3 Jul 2011, Per Forlin wrote:
> On 2 July 2011 21:37, Arnd Bergmann wrote:
> > On Saturday 02 July 2011 14:29:38 Russell King - ARM Linux wrote:
> >> One other thing to be considered here is whether this idea should be
> >> limited to just MMC or whether it should be extended further, to
On 2 July 2011 21:37, Arnd Bergmann wrote:
> On Saturday 02 July 2011 14:29:38 Russell King - ARM Linux wrote:
>> One other thing to be considered here is whether this idea should be
>> limited to just MMC or whether it should be extended further, to
>> move the DMA mapping stuff out of the hot pa
On Saturday 02 July 2011 14:29:38 Russell King - ARM Linux wrote:
> One other thing to be considered here is whether this idea should be
> limited to just MMC or whether it should be extended further, to
> move the DMA mapping stuff out of the hot path for other block devices
> too.
>
> There are
On Fri, Jul 01, 2011 at 06:44:43PM +0200, Arnd Bergmann wrote:
> On Thursday 30 June 2011, Russell King - ARM Linux wrote:
> > We've been here before - with PCMCIA's card insertion code, where you
> > have to go through a sequence of events (insert, power up, reset, etc).
> > The PCMCIA code used t
On Thursday 30 June 2011, Russell King - ARM Linux wrote:
> We've been here before - with PCMCIA's card insertion code, where you
> have to go through a sequence of events (insert, power up, reset, etc).
> The PCMCIA code used to have a collection of small functions to do
> each step, one chained a
On Tue, Jun 28, 2011 at 10:11 AM, Per Forlin wrote:
> This is done by making the issue_rw_rq() non-blocking.
> The increase in throughput is proportional to the time it takes to
> prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
> a request and how fast the memory is. The faste
On Thu, Jun 30, 2011 at 03:12:46PM +0200, Arnd Bergmann wrote:
> I think this looks good enough to merge into the linux-mmc tree, the code is
> clean and the benefits are clear.
>
> Acked-by: Arnd Bergmann
>
> One logical follow-up as both a cleanup and performance optimization would be
> to get
On Tuesday 28 June 2011, Per Forlin wrote:
> How significant is the cache maintenance over head?
> It depends, the eMMC are much faster now
> compared to a few years ago and cache maintenance cost more due to
> multiple cache levels and speculative cache pre-fetch. In relation the
> cost for handli
On Thu, Jun 30, 2011 at 6:06 PM, Poddar, Sourav wrote:
> On Tue, Jun 28, 2011 at 1:41 PM, Per Forlin wrote:
>> How significant is the cache maintenance over head?
>> It depends, the eMMC are much faster now
>> compared to a few years ago and cache maintenance cost more due to
>> multiple cache le
On Tue, Jun 28, 2011 at 1:41 PM, Per Forlin wrote:
> How significant is the cache maintenance over head?
> It depends, the eMMC are much faster now
> compared to a few years ago and cache maintenance cost more due to
> multiple cache levels and speculative cache pre-fetch. In relation the
> cost f
This patches are tested on samsung exynos4 platform.
Acked-by: Kyungmin Park
On Tue, Jun 28, 2011 at 5:11 PM, Per Forlin wrote:
> How significant is the cache maintenance over head?
> It depends, the eMMC are much faster now
> compared to a few years ago and cache maintenance cost more due to
>
How significant is the cache maintenance over head?
It depends, the eMMC are much faster now
compared to a few years ago and cache maintenance cost more due to
multiple cache levels and speculative cache pre-fetch. In relation the
cost for handling the caches have increased and is now a bottle neck
12 matches
Mail list logo
