linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: stuart.menefy@st.com (Stuart Menefy)
To: linux-arm-kernel@lists.infradead.org
Subject: [regression] in linux-next: sh_mobile_ceu_camera broken by	"ARM: Prohibit ioremap() on kernel managed RAM"
Date: Tue, 10 Aug 2010 15:07:09 +0100	[thread overview]
Message-ID: <4C615D0D.2080600@st.com> (raw)
In-Reply-To: <20100808220035.GD23623@n2100.arm.linux.org.uk>

On 08/08/10 23:00, Russell King - ARM Linux wrote:
> On Sun, Aug 08, 2010 at 05:45:26PM +0200, Arnd Hannemann wrote:
>> Hi Russell,
>>
>> your commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8
>> ARM: Prohibit ioremap() on kernel managed RAM
>>
>> lets drivers/base/dma-coherent.c::dma_declare_coherent_memory()
>> fail for the sh_mobile_ceu_camera driver (see backtrace below).
>> I think, other configurations (i.MX31 users of the mx3_camera driver:
>> pcm037 and mx31moboard) will have the same problem.
>>
>> Since I have no idea how to fix this, I post this regression report here...
> 
> Me neither!  However, reverting the commit isn't the answer.
> 
> ARM shmobile platforms are ARM architecture V6 or V7, both of which have
> the architectural restriction that multiple mappings of the same physical
> address space must have the same memory type and cache attributes.  We
> know that some ARMv7 systems do bad things when multiple different
> mappings exist - and as they're using ARM's own Cortex CPU designs, and
> I doubt shmobile is any different in that...
> 
> So, basically going forward with the advent of VIPT caches on ARM, any
> kernel interface which allows system RAM to be remapped with different
> attributes from the lowmem mapping is bad news - that means (eg) using
> vmap() with a non-PGPROT_KERNEL pgprot has become illegal.  Certainly
> using ioremap() on mapped system RAM on VIPT has become illegal, and
> that's what has now been prevented.
> 
> It's actually a restriction which x86 gained some time ago, which I
> stupidly continued to permit on ARM.  Now that our hardware has gained
> the same restriction, we're now going to be into the same learning
> curve...

Doesn't dma_alloc_coherent() suffer from the same problems? Pages are
allocated using alloc_pages, and in the non-coherent case will be
mapped uncached into consistent mapping region, creating a second
mapping with different attributes.

Stuart

  reply	other threads:[~2010-08-10 14:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-08 15:45 [regression] in linux-next: sh_mobile_ceu_camera broken by "ARM: Prohibit ioremap() on kernel managed RAM" Arnd Hannemann
2010-08-08 22:00 ` Russell King - ARM Linux
2010-08-10 14:07   ` Stuart Menefy [this message]
2010-08-10 16:36     ` Russell King - ARM Linux
2010-08-10  8:45 ` Philippe Rétornaz
2010-08-10  9:27   ` Russell King - ARM Linux
2010-08-10 19:55     ` Guennadi Liakhovetski
2010-08-10 21:26       ` Russell King - ARM Linux
2010-08-13 10:52         ` hisao munakata
2010-08-18 19:23         ` Guennadi Liakhovetski
2010-08-18 19:41           ` Russell King - ARM Linux
2010-08-18 20:31             ` Guennadi Liakhovetski
2010-08-18 21:44               ` Russell King - ARM Linux
2010-08-18 21:47               ` Russell King - ARM Linux

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=4C615D0D.2080600@st.com \
    --to=stuart.menefy@st.com \
    --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).