Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753409AbdF2OrY (ORCPT ); Thu, 29 Jun 2017 10:47:24 -0400 Received: from mail-pg0-f46.google.com ([74.125.83.46]:35808 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751974AbdF2OrQ (ORCPT ); Thu, 29 Jun 2017 10:47:16 -0400 Date: Thu, 29 Jun 2017 20:17:11 +0530 From: Viresh Kumar To: "Enrico Weigelt, metux IT consult" Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Rafael Wysocki , Vincent Guittot , Stephen Boyd , Mark Brown , Shiraz Hashim , Rob Herring , rnayak@codeaurora.org Subject: Re: [RFC 0/5] drivers: Add boot constraints core Message-ID: <20170629144711.GO29665@vireshk-i7> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2144 Lines: 51 On 29-06-17, 12:40, Enrico Weigelt, metux IT consult wrote: > Just curious: aren't the devices (at least w/ DT) only initialized after > dependencies (eg. regulators) are already up ? No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered separately (platform/amba devices get registered automatically with DT, hint: drivers/of/platform.c). The device core checks while registering devices/drivers if their drivers/devices are available or not. If yes, then the devices are probed using the drivers. Now the drivers must make sure all the dependencies are met at this point, else they can return -EPROBE_DEFER and the kernel will try probing them again. > Let's imagine a LCD panel driven by a regulator behind SPI. The panel > driver would ask the regulator framework to switch on, which would > call the regulator driver. This one now would talk to SPI framework, > which finally calls the SPI driver. If SPI isn't up yet, it would all > be deferred, leaving the panel driver uninitialized (tried again later). This should happen in probe, otherwise we are screwed. > If the bootloader already switched on the panel (therefore already > enabled SPI), why does it matter that the panel driver isn't up yet ? But the kernel doesn't know how it is configured, there can be so many configurable parameters. The kernel needs to do it again by itself. > Is there anything that accidentially switches it off again (eg. by > resetting the regulator) ? It is not just about switching it off, but the configuration here. Let me try with an example. A regulator is shared between LCD and DMA controller. Operable ranges of the regulator: 1.8 - 3.0 V Range required by LCD: 2.0 - 3.0 V Range required by DMA: 1.8 - 2.5 V Of course the right range for both of them to work here is 2.0 - 2.5 V. Now the LCD is already enabled by the bootloader and kernel doesn't know the ranges. DMA requests for the regulator and we set its voltage to 1.8 V. LCD is screwed while we are still booting. This will go worse if we add more devices to this example that share the same regulator. -- viresh