Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751785AbdF3Ddn (ORCPT ); Thu, 29 Jun 2017 23:33:43 -0400 Received: from smtp.csie.ntu.edu.tw ([140.112.30.61]:37212 "EHLO smtp.csie.ntu.edu.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751093AbdF3Ddm (ORCPT ); Thu, 29 Jun 2017 23:33:42 -0400 MIME-Version: 1.0 In-Reply-To: <20170630031648.GR29665@vireshk-i7> References: <20170629144711.GO29665@vireshk-i7> <1522ae7b-fd5b-5403-62bf-b0140e116d65@gr13.net> <20170630031648.GR29665@vireshk-i7> From: Chen-Yu Tsai Date: Fri, 30 Jun 2017 11:33:17 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 0/5] drivers: Add boot constraints core To: Viresh Kumar Cc: "Enrico Weigelt, metux IT consult" , Rafael Wysocki , Vincent Guittot , Rob Herring , Greg Kroah-Hartman , Stephen Boyd , linux-kernel , Mark Brown , rnayak@codeaurora.org, Shiraz Hashim , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3906 Lines: 92 On Fri, Jun 30, 2017 at 11:16 AM, Viresh Kumar wrote: > On 29-06-17, 15:06, Enrico Weigelt, metux IT consult wrote: >> On 29.06.2017 14:47, Viresh Kumar wrote: >> >> >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. >> >> Could we somehow introduce an strict ordering ? > > The problem I am trying to solve isn't really related to ordering. > > Consider this for example: > > A supply shared between LCD and I2C controller (Not sure if such > configurations are there in any of the hardware we have), where the > same I2C controller is used to access the LCD controller's registers. > Both are enabled at boot and the supply is configured to satisfy both. > If the voltage requirements of the I2C controller are below that of > LCD, then we can't decide on which one to probe first. We can't probe > LCD first as its bus isn't active yt and if we probe I2C first, then > it may take the supply down to a level that isn't acceptable for the > LCD (which was on from boot). AFAIK regulator constraints are supposed to satisfy all users of it. >> Maybe by letting the device core know of the dependencies, before >> individual probe()'s explicitly ask for them ? > > That's what we are sorting out in probe() and I am not sure if we need > any more intelligence on that. Though, you may want to look at the > "functional dependency" stuff, which can be of some help in such > cases. Its mentioned in cover-letter as well. > >> >This should happen in probe, otherwise we are screwed. >> >> Yes, but the probe result may be deferred, so it's tried again in the >> next round. Correct ? > > Right. > >> >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. >> >> Could it read back the config ? > > First, it may not always be possible to do that. And even if the > kernel reads it all well, then it wouldn't know why things are > configured the way they are. And trying to read the config in drivers > is going to be so so hacky, that we wouldn't want to do it anyway. We > need a clean way of doing this, so that the kernel knows of what's > going on and that's what this series is targeting here. > >> By the way: I've got a similar problem w/ gpmc right now: uboot already >> sets it up, but the kernel only knows about one CS (for the nand) and >> screwes up the others (eg. fpga), so it cant access the fpga . Until >> I've sorted out all the parameters for DT (unfortunately, only have the >> raw register values), I'll have to rely on an userland test program >> to set it all up ... >> >> >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 So for the example here, the regulator constraint should be 2.5 - 3.0 V, or the intersection of all voltage requirements. ChenYu >> >> Would a config readback help here ? >> >> The regulator core then should know that we're already in proper >> range for DMA and no need to touch the regulator. > > No body is going to allow that kind of hacky code to get merged :) > > -- > viresh > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel