From: Luc Verhaegen <libv@skynet.be>
To: u-boot@lists.denx.de
Subject: [U-Boot] [linux-sunxi] Re: [PATCH] video: add cfb console driver for sunxi
Date: Mon, 4 Aug 2014 19:28:46 +0200 [thread overview]
Message-ID: <20140804172846.GA14395@skynet.be> (raw)
In-Reply-To: <1407166296.4733.8.camel@localhost>
On Mon, Aug 04, 2014 at 05:31:36PM +0200, Henrik Nordstr?m wrote:
> m?n 2014-08-04 klockan 17:05 +0200 skrev Luc Verhaegen:
> > But... What do we do when u-boot sets up cfb, without setting up a
> > simplefb node in the dt. Or what do we do when a simplefb node is set
> > up, but no simplefb code is included in the kernel? Well, we then either
> > need to claim the clocks, and make sure that nothing else touches the
> > memory, or we need to cleanly disable the display engine. But which do
> > we choose, do we keep the u-boot output forever, or do we sync off when
> > the kernel starts?
>
> And what happens if we simply ignore it? Is there a risk of anything
> burning beyond software repair? If not, ignore it. There is no need to
> support all incompatible mixes even if it means some people will see
> strange fireworks on their screens when not following the software
> requirements.
>
> It's really no different from booting a kernel with wrong dt, or using a
> u-boot with wrong DRAM settings etc. An incompatible mix which is not
> meant to function properly.
>
> If you use a u-boot with this framebuffer support then you must also
> either use a kernel which supports being booted in such state, or make
> sure u-boot shuts things off before handing over to the kernel.
>
> If we can handle the situation gracefully in the kernel then fine, but
> it's by no means required, or even desired to spend any effort or even
> any serious thoughts on before compatible setups works.
>
> Regards
> Henrik
We can work around most situations gracefully in kernelspace. We should
for instance never set a bad mode, and never show random memory content,
as that is a total no-go. So some code will have to exist to cleanly
disable the display engine (we're in luck, we only need to poke the ahb
gating and some clocks).
But if we can overlook some of the above, we also should just consider
the memory lost until a kms driver kicks in, and ioremaps/whatevers it
for its own use.
How's this for the sunxi implementation of simplefb:
* u-boot lists used clocks, to allow some code in simplefb.c to grab all
clocks. This is necessary as the list of clocks might change with
changed cfb-console driver functionality.
* when the clocks get disabled, the existing display engine setup
becomes useless. the dt simplefb node has its status set to disabled.
The memory range info remains, none of the reserved ram is returned
to system. This needs to happen in both simplefb.c and in clk-sunxi.c.
* when the memory range gets mapped by the kms driver (currently, on
sunxi-3.4 i just use the full disp driver reserved range directly) in
a way that it will be released again at unload, the memory range info
remains. This ensures that future kms driver reloads can still grab
this memory.
* when however the memory range gets mapped to cma globally, the memory
range info is removed.
It makes sense to add the clock handling and the disabling of the
simple-framebuffer node in the actual simplefb driver. The memory
handling should be considered platform specific behaviour for now, but
perhaps dt reserved memory infrastructure can come to the rescue in
future.
Luc Verhaegen.
next prev parent reply other threads:[~2014-08-04 17:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-02 16:14 [U-Boot] [PATCH] video: add cfb console driver for sunxi Luc Verhaegen
2014-08-04 8:39 ` Hans de Goede
2014-08-04 15:05 ` Luc Verhaegen
2014-08-04 15:31 ` [U-Boot] [linux-sunxi] " Henrik Nordström
2014-08-04 16:53 ` Michal Suchanek
2014-08-04 21:26 ` Henrik Nordström
2014-08-04 17:28 ` Luc Verhaegen [this message]
2014-08-04 22:10 ` Henrik Nordström
2014-08-05 20:55 ` Maxime Ripard
2014-08-05 21:03 ` Maxime Ripard
2014-08-05 21:37 ` Michal Suchanek
2014-08-06 7:24 ` [U-Boot] [linux-sunxi] " Koen Kooi
2014-08-06 11:10 ` Hans de Goede
2014-08-06 12:21 ` [U-Boot] [linux-sunxi] " Maxime Ripard
2014-08-05 11:56 ` [U-Boot] " Hans de Goede
2014-08-05 20:47 ` [U-Boot] [linux-sunxi] " Maxime Ripard
2014-08-06 11:40 ` [U-Boot] " Luc Verhaegen
2014-08-07 9:28 ` Hans de Goede
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=20140804172846.GA14395@skynet.be \
--to=libv@skynet.be \
--cc=u-boot@lists.denx.de \
/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.