From mboxrd@z Thu Jan 1 00:00:00 1970 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= Date: Tue, 05 Aug 2014 00:10:30 +0200 Subject: [U-Boot] [linux-sunxi] Re: [PATCH] video: add cfb console driver for sunxi In-Reply-To: <20140804172846.GA14395@skynet.be> References: <1406996097-23167-1-git-send-email-libv@skynet.be> <53DF46B1.60107@redhat.com> <20140804150500.GA13286@skynet.be> <1407166296.4733.8.camel@localhost> <20140804172846.GA14395@skynet.be> Message-ID: <1407190230.4733.77.camel@localhost> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de m?n 2014-08-04 klockan 19:28 +0200 skrev Luc Verhaegen: > 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). I seriously don't worry about display mode corruption or showing random memory if people boot configurations/combinations which are not supported. > 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. If it in any way hinders development of the KMS driver then yes. > 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. Is this list of clocks in any way different from what KMS needs to use? > * 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. Disabled by whom? > * 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. Why do a KMS reload need to be able to grab the same memory again? The display is shut off when the KMS driver is unloaded, right? Or this only temporary? > * 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. Maybe, but people who need framebuffer in u-boot likley need it in kernel as well I would think, so I do not worry much about releasing the memory back to kernel for general purpose use if it has been reserved by u-boot. If you really have no use of the display then don't enable it in the first place (or make sure it's shut off). Including any memory reservations. Similar to PC BIOS settings for reserved (shared) memory on many IGP devices. You don't normally change such settings in kernel. If you want a different memory layout then shut down, change BIOS settings and boot again. Not a problem imho. (shut down, change u-boot & DT settings, boot again). Regards Henrik