linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: PIPT cache handling on s5pv210 chip
Date: Mon, 17 May 2010 05:03:25 +0100	[thread overview]
Message-ID: <20100517040325.GX6684@trinity.fluff.org> (raw)
In-Reply-To: <00ca01caf359$643defa0$2cb9cee0$%kim@samsung.com>

On Fri, May 14, 2010 at 08:34:14PM +0900, Kukjin Kim wrote:
> Russell King wrote:
> > 
> > On Fri, May 14, 2010 at 07:36:47PM +0900, Kukjin Kim wrote:
> > > In case of __vmalloc() with non-cacheable option, there may come some
> > > malfunctions related to cache.
> > 
> > Practically, you are not allowed on ARMv6 or ARMv7 to create mappings
> > which alias with differing memory types; that is 100% outlawed by the
> > architecture spec, and there is NO mitigation for this.

Unfortunately, just because something is outlawed doesn't mean that people
will try and do it.
 
> > It means that it is _illegal_ to use __vmalloc() with anything but a
> > memory-like mapping protection.
> > 
> > There is mitigation for having different cacheability, but this is just
> > a work-around while OSes like Linux work to remove the creation of
> > aliases with differing cacheability attributes.  There's no guarantee
> > that later ARMv7 or future CPUs will continue to operate predictably.
> > 
> > The same applies for ioremap() being used on SDRAM - and those who look
> > at what's in my tree will notice that ioremap() has recently been made
> > to fail when used on SDRAM for this very reason.
> 
> In case a driver starts the Memory_To_Peripheral DMA operation with the
> memory area allotted by __vmalloc(,,no-cacheable), the driver can face some
> problems caused by cache victims.

This would seem to indicate either the driver needs to allocate the
memory differently, or that it is not following the correct procedure
to hande the memory area to the hardware or that there it is a problem
with how the L2 cache has been integrated into the kernel.

I'm not sure what kernel this is based on, or what drivers are being
affected by this as I suspect this is from one of the for-vendor branches
that tends to pop-up because something needs to be shipped ASAP.
 
> > Therefore, the above hack isn't going near mainline.
> 
> Nevertheless, I think so too.

This is the kind of thing that makes me want to go and find the
perpitrators and uise the ogg-cavetech-super-pointy-stick on them.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

      parent reply	other threads:[~2010-05-17  4:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-14  3:49 PIPT cache handling on s5pv210 chip Kyungmin Park
2010-05-14  9:11 ` Russell King - ARM Linux
2010-05-14 10:36 ` Kukjin Kim
2010-05-14 10:48   ` Russell King - ARM Linux
2010-05-14 11:34     ` Kukjin Kim
2010-05-14 11:53       ` Russell King - ARM Linux
2010-05-17  4:03       ` Ben Dooks [this message]

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=20100517040325.GX6684@trinity.fluff.org \
    --to=ben-linux@fluff.org \
    --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).