linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] CMA and ARM DMA-mapping updates for v3.5
Date: Fri, 1 Jun 2012 16:06:21 +0100	[thread overview]
Message-ID: <20120601150621.GA9525@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <015e01cd3daa$6d910e50$48b32af0$%szyprowski@samsung.com>

On Tue, May 29, 2012 at 04:50:45PM +0200, Marek Szyprowski wrote:
> Hello,
> 
> On Tuesday, May 29, 2012 2:30 PM Russell King - ARM Linux wrote:
> 
> > I notice we have new warnings as a result of CMA being merged, though
> > thankfully they're just in Kconfig:
> > 
> > warning: (ARM) selects CMA which has unmet direct dependencies (HAVE_DMA_CONTIGUOUS &&
> > HAVE_MEMBLOCK && EXPERIMENTAL)
> > 
> > This seems totally weird: you're mandating that ARM must have CMA
> > selected, but it's an experimental feature?  So you're implying that
> > the entire ARM kernel becomes totally experimental for the next
> > release cycle?
> > 
> > I think this needs fixing.
> 
> No, that wasn't my intention. I will provide a patch which removes unconditional dependency
> on CMA - it will let one to disable CMA and use old allocation method if needed, but this 
> requires a few more changes in the dma-mapping implementation. I wasn't aware of the 
> consequences and no one has complained about this since v15 of CMA patches (Aug 2011).

I've just been looking at the automatic build and boot logs, and CMA looks
like it has the potential to cause regressions:

Linux version 3.4.0+ (rmk at rmk-PC.arm.linux.org.uk) (gcc version 4.3.5 (GCC) ) #1 PREEMPT Fri Jun 1 02:01:58 BST 2012
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP LDP board
vmalloc area is too big, limiting to 976MB
Reserving 2097152 bytes SDRAM for VRAM
cma: CMA: failed to reserve 16 MiB
...
Kernel command line: console=ttyO2,115200n8 noinitrd vmalloc=1G mem=128M root=/dev/mmcblk0p2 rw ip=none rootdelay=2 video=omap24xxfb:rotation=270
...
NET: Registered protocol family 16
initlevel:2=postcore, 16 registered initcalls
DMA: failed to allocate 256 KiB pool for atomic coherent allocation

I don't see any other failures, but that doesn't look good...

Note that that command line has worked perfectly well up until now.

  reply	other threads:[~2012-06-01 15:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-22  7:40 [GIT PULL] CMA and ARM DMA-mapping updates for v3.5 Marek Szyprowski
2012-05-22  8:27 ` [Linaro-mm-sig] " Barry Song
2012-05-29 12:29 ` Russell King - ARM Linux
2012-05-29 14:50   ` Marek Szyprowski
2012-06-01 15:06     ` Russell King - ARM Linux [this message]
2012-05-30  8:59   ` [PATCH] ARM: dma-mapping: remove unconditional dependency on CMA Marek Szyprowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120601150621.GA9525@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).