From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
dri-devel <dri-devel@lists.freedesktop.org>,
Hans de Goede <hdegoede@redhat.com>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [RFC] drm: implement generic firmware eviction
Date: Tue, 30 Aug 2016 23:00:31 +0200 [thread overview]
Message-ID: <20160830210031.GJ18605@lukather> (raw)
In-Reply-To: <CANq1E4Shy1+rQsshWxeFRhFvuAg1sB3ffnVT7hoMZSjZAR=yuQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1101 bytes --]
Hi David,
On Tue, Aug 30, 2016 at 09:30:44PM +0200, David Herrmann wrote:
> Hi Rob
> IOW the device handover code somehow needs to know who was responsible
> for the instantiation of the simple-framebuffer device, so it can tell
> them to remove it again. On x86 there is only one place where those
> can be instantiated. But on OF-based systems, it can be dynamically
> instantiated in many places right now.
I don't think that's true. There's the assumption that the bootloader
will have set up the framebuffer and Linux just takes over. Even on
ARM, you'll need to at least reserve the memory, grab the clocks and
so on, and it needs to happen way before you can load overlays (for
the buffer even way before the simple-framebuffer driver is probed).
I don't see how we could use overlays with simple-framebuffer, unless
we apply those overlays before linux starts, but then Linux basically
doesn't care if it was an overlay or not, it's treated as a single DT.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-08-30 21:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-26 0:00 [RFC] drm: implement generic firmware eviction David Herrmann
2016-08-26 7:57 ` Hans de Goede
2016-08-26 8:01 ` David Herrmann
2016-08-26 8:43 ` Hans de Goede
2016-08-26 8:58 ` Maxime Ripard
2016-08-26 9:02 ` Hans de Goede
2016-08-26 12:52 ` Maxime Ripard
2016-08-26 12:58 ` Hans de Goede
2016-08-26 13:33 ` Maxime Ripard
2016-08-26 9:39 ` Jani Nikula
[not found] ` <20160826000056.12806-1-dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-08-26 5:59 ` Daniel Vetter
2016-08-26 12:36 ` Rob Herring
2016-08-30 19:30 ` David Herrmann
2016-08-30 20:58 ` Rob Herring
2016-08-30 21:12 ` David Herrmann
[not found] ` <CANq1E4Twr6Uy2QnowV_WP8yz9QymkchnFS1GwFf_FBRcYF6oOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-30 23:01 ` Rob Herring
[not found] ` <CAL_JsqJuyPW-kPBbiaq2hRyMN0CBY5UXiUOxHR7GYkjDQodAfA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-31 6:59 ` David Herrmann
2016-08-30 21:00 ` Maxime Ripard [this message]
2016-08-26 13:27 ` Maxime Ripard
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=20160830210031.GJ18605@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=daniel.vetter@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=robh+dt@kernel.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).