All of lore.kernel.org
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/6] ARM: integrator: multiplatform advancements
Date: Fri, 14 Feb 2014 13:47:56 +0000	[thread overview]
Message-ID: <20140214134756.GI30257@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1392373771-17303-1-git-send-email-linus.walleij@linaro.org>

On Fri, Feb 14, 2014 at 11:29:25AM +0100, Linus Walleij wrote:
> The *real* solution, one might argue is to convert the CLCD
> driver to DRM and add device tree bindings, but it appears that
> this is an orthogonal goal that has been attempted by other with
> mixed results.

What mixed results?  You know, I find it rather sick that people run
around trying to do this to a driver that I authored and maintain
without one comment to me about it.  It sometimes feels like people
think I don't exist anymore.

The biggest complaint I've heard against DRM is the amount of code
required.  That's partly because we haven't - until now - had a good
way to separate the "connectors" as stand-alone implementations separate
from the core DRM drivers.  I'm hopeful that by 3.15, we will see some
implementations (imx-drm and armada) start making use of this.

Also, remember that DRM is Direct Rendering Manager, which incorporates
Kernel Mode Setting.  It's the KMS part which is most relevant to things
like CLCD since it has no GPU.  However, the non-KMS bits also are when
you have something like a Mali GPU or other GPU.

We /really/ need these GPUs to move over to DRM - any ARM platform using
a GPU today is inherently insecure since they all have been coded to push
physical addresses around everywhere, which basically means userspace can
use the GPU to access parts of the system such as overwriting bits of the
kernel.

It's useless write-protecting the vectors page and/or the kernel text in
a vain attempt to provide additional security if the GPU can be used from
userspace to write to that RAM.

Having everything under DRM eliminates that problem because userspace only
gets to deal with handles to the various buffers rather than physical
addresses, which ensures that you can't specify an address for a buffer
you don't own.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

  parent reply	other threads:[~2014-02-14 13:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-14 10:29 [PATCH 0/6] ARM: integrator: multiplatform advancements Linus Walleij
2014-02-14 10:29 ` [PATCH 1/6] ARM: integrator: localize the lm.h header Linus Walleij
2014-02-14 10:29 ` [PATCH 2/6] ARM: integrator: localize the impd1.h header Linus Walleij
2014-02-14 10:29 ` [PATCH 3/6] ARM: integrator: merge platform.h to hardware.h Linus Walleij
2014-02-14 10:29 ` [PATCH 4/6] ARM: integrator: localize the hardware.h header Linus Walleij
2014-02-14 10:29 ` [PATCH 5/6] ARM: integrator: register sched_clock directly Linus Walleij
2014-02-14 10:29 ` [PATCH 6/6] RFC: ARM: integrator: get rid of <mach/memory.h> Linus Walleij
2014-02-14 12:02   ` Arnd Bergmann
2014-02-14 13:47 ` Russell King - ARM Linux [this message]
2014-02-24  9:37   ` [PATCH 0/6] ARM: integrator: multiplatform advancements Linus Walleij
2014-03-05 16:19     ` 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=20140214134756.GI30257@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.