From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] mmaping with VIVT cache
Date: Wed, 15 Sep 2010 08:31:45 +0100 [thread overview]
Message-ID: <20100915073145.GA4478@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <AANLkTinKkoZsEEpM52yhp8yP5W9J_Ym-HfT3j+prDsUJ@mail.gmail.com>
On Wed, Sep 15, 2010 at 09:06:02AM +0800, Eric Miao wrote:
> On Wed, Sep 15, 2010 at 7:50 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Sep 13, 2010 at 12:58:41PM -0700, P F wrote:
> >> Hi,
> >>
> >> Please excuse the pseudonym.
> >>
> >> I have recently encountered a problem in the context of the UVC (webcam)
> >> driver. ?The driver maintainer, Laurent, suggested that we bring the
> >> thread to linux-arm-kernel for wider discussion. ?See here for reference:
> >> http://lists.berlios.de/pipermail/linux-uvc-devel/2010-August/005864.html
> >>
> >> The problem I encountered was this: using an ARM926EJ-S with OHCI USB host,
> >> I noticed intermittent graphical corruption of frames captured by several
> >> different webcams, both UVC and non-UVC.
> >>
> >> I was able to isolate the corruption down to one specific instance. ?In
> >> this instance, I collected three images:
> >> 1A.jpg - collected from host, prior to corruption
> >> 2A.jpg - collected from host, demonstrating corruption
> >> 2B.jpg - collected from inline USB analyzer, same image as 2A
> >>
> >> Images 1A and 2A are in sequence, i.e., 2A immediately follows 1A. ?2B is
> >> not corrupted, and a binary diff between 2A and 2B shows two 32-byte
> >> chunks have been changed. ?A binary diff between 2A and 1A shows that
> >> these same two chunks match. ?Therefore, it seems there is some
> >> contamination of the second image by the first.
> >>
> >> As I described in the linked message, I found a workaround for this issue
> >> by adding
> >> ? vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot)
> >> in the UVC driver's mmap() function, but Laurent explained that this was
> >> invalid.
> >>
> >> Does anybody have ideas for a proper fix? ?I can reproduce this corruption
> >> easily, and would be happy to test proposed patches.
> >
> > The fact is that mapping buffers as cacheable into userspace on non-
> > coherent architectures _will_ result in the cache contents getting in
> > the way of updates to the DMA'd buffer. ?It's a fundamental property
> > of such hardware implementations.
> >
>
> Maybe we can just detect if the buffer is mapped in alias, and modify the
> PTE, just as what we did to inconsistent write-combine? So to make this
> transparent to other consistent architectures?
All pages which are mapped into userspace have at least one alias.
next prev parent reply other threads:[~2010-09-15 7:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-13 19:58 [RFC] mmaping with VIVT cache P F
2010-09-14 23:50 ` Russell King - ARM Linux
2010-09-15 1:06 ` Eric Miao
2010-09-15 7:31 ` Russell King - ARM Linux [this message]
2010-09-15 7:37 ` Eric Miao
-- strict thread matches above, loose matches on Subject: below --
2010-09-16 0:25 P F
2010-09-16 23:05 ` Russell King - ARM Linux
2010-09-17 19:07 P F
2010-09-17 21:06 ` Russell King - ARM Linux
2010-09-20 10:38 ` Pawel Moll
2010-09-20 10:50 ` Russell King - ARM Linux
2010-09-20 11:31 ` Pawel Moll
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=20100915073145.GA4478@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).