Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752498AbdGGWjH (ORCPT ); Fri, 7 Jul 2017 18:39:07 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:49344 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbdGGWjF (ORCPT ); Fri, 7 Jul 2017 18:39:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org D24906084D Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Fri, 7 Jul 2017 15:39:02 -0700 From: Stephen Boyd To: Rob Clark Cc: Russell King - ARM Linux , Viresh Kumar , Greg Kroah-Hartman , Rafael Wysocki , Vincent Guittot , Rob Herring , Linux Kernel Mailing List , Mark Brown , Rajendra Nayak , Shiraz Hashim , "linux-arm-kernel@lists.infradead.org" Subject: Re: [RFC 0/5] drivers: Add boot constraints core Message-ID: <20170707223902.GI22780@codeaurora.org> References: <20170629124908.GV4902@n2100.armlinux.org.uk> <20170629145808.GQ29665@vireshk-i7> <20170629154353.GX4902@n2100.armlinux.org.uk> <20170629210002.GB22780@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2251 Lines: 45 On 07/05, Rob Clark wrote: > On Thu, Jun 29, 2017 at 5:00 PM, Stephen Boyd wrote: > > On 06/29, Russell King - ARM Linux wrote: > >> > >> As far as the memory being used goes, they probably locate the frame > >> buffer well away from the kernel or any area that the kernel is likely > >> to use during decompression. > >> > >> It's probably also marked as a reserved memory region in DT to avoid > >> the kernel touching it during boot, or _maybe_ they just locate it > >> somewhere in memory that they've tested that the kernel doesn't touch > >> until after their kernel has initialised the LCD controller (thereby > >> avoiding the memory being permanently consumed.) > >> > > > > Yes. The display controller is typically pointed to a memory > > carveout that we treat as reserved in the kernel. I'm fairly > > certain that we avoid the "permanently consumed" problem by > > making it a carveout for the display controller, so that when the > > display controller probes it can take ownership of the memory > > from the bootloader. > > > > For aarch64/arm64 booting with EFI, the bootloader passes info about > memory layout to the kernel (including the fact that the framebuffer > is carved out) so kernel doesn't clobber the scanout buffer. The > non-EFI case, the bootloader should (not that lk does) patch up the > fdt reserved memory node w/ correct address/size. I think > lk+downstream just relies on luck. > Downstream+lk seems to be doing a carveout with reserved-memory in DT[1]. The bootloader isn't updating the DT to indicate this, instead we rely on an agreement between bootloader and kernel's DT file to have the carveout. Once the display driver configures things enough to allocate another display buffer it actually frees the memory back to the system[2]. Most of the code for this splash screen stuff is in that mdss_mdp_splash_logo.c file. [1] https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/msm8996.dtsi?h=rel/msm-4.4#n231 [2] https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/drivers/video/fbdev/msm/mdss_mdp_splash_logo.c?h=rel/msm-4.4#n252 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project