From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Date: Thu, 25 Feb 2016 13:43:46 +0000 Subject: Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree Message-Id: List-Id: References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org> <1454594660-7532-12-git-send-email-linus.walleij@linaro.org> <56CC2D39.80909@ti.com> <56CC546A.9070705@ti.com> <20160224104638.GL19428@n2100.arm.linux.org.uk> <56CD924F.50108@ti.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: linux-arm-kernel@lists.infradead.org On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou wrote: > IMHO DT+overlays handle all your cases just fine. > > As far as I see these are the cases which we need to handle: > > 1) The expansion board in question has some means of identification, whether it’s an > EEPROM or a GPIO keying combination etc. In that case it is the kernel’s job to match this > id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware(). Since the dawn of time the x86 people used that console to display the early boot crawl and collect crash data. What you're suggesting is that we can't get the console up until after the filesystems and mounts are up so the kernel can read firmware files. This kills of early boot graphics and getting crash logs on the fbdev console until that has happened. It also means there is no way to get the console up without the right firmware files in the filesystem. I think that is really crap compared to what we have today where the display will always come up, and basically a regression. I understand the stance with respect to things like add-on hardware like a Bluetooth board or WLAN or whatnot. But the fbdev console is just too basic, like a serial port IMO. Sure in the ARM world we usually have a serial console, but this is seriously breaking current practice. Yours, Linus Walleij From mboxrd@z Thu Jan 1 00:00:00 1970 From: linus.walleij@linaro.org (Linus Walleij) Date: Thu, 25 Feb 2016 14:43:46 +0100 Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree In-Reply-To: References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org> <1454594660-7532-12-git-send-email-linus.walleij@linaro.org> <56CC2D39.80909@ti.com> <56CC546A.9070705@ti.com> <20160224104638.GL19428@n2100.arm.linux.org.uk> <56CD924F.50108@ti.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou wrote: > IMHO DT+overlays handle all your cases just fine. > > As far as I see these are the cases which we need to handle: > > 1) The expansion board in question has some means of identification, whether it?s an > EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this > id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware(). Since the dawn of time the x86 people used that console to display the early boot crawl and collect crash data. What you're suggesting is that we can't get the console up until after the filesystems and mounts are up so the kernel can read firmware files. This kills of early boot graphics and getting crash logs on the fbdev console until that has happened. It also means there is no way to get the console up without the right firmware files in the filesystem. I think that is really crap compared to what we have today where the display will always come up, and basically a regression. I understand the stance with respect to things like add-on hardware like a Bluetooth board or WLAN or whatnot. But the fbdev console is just too basic, like a serial port IMO. Sure in the ARM world we usually have a serial console, but this is seriously breaking current practice. Yours, Linus Walleij