Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755511Ab2HFC0D (ORCPT ); Sun, 5 Aug 2012 22:26:03 -0400 Received: from hqemgate03.nvidia.com ([216.228.121.140]:7583 "EHLO hqemgate03.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755468Ab2HFC0A (ORCPT ); Sun, 5 Aug 2012 22:26:00 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Sun, 05 Aug 2012 19:20:57 -0700 Message-ID: <501F2BAA.8000808@nvidia.com> Date: Mon, 6 Aug 2012 11:27:54 +0900 From: Alex Courbot Organization: NVIDIA User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Mark Brown CC: Stephen Warren , Stephen Warren , Simon Glass , Grant Likely , Rob Herring , Greg Kroah-Hartman , Arnd Bergmann , "linux-tegra@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , "devicetree-discuss@lists.ozlabs.org" , Thierry Reding Subject: Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences References: <1343390750-3642-1-git-send-email-acourbot@nvidia.com> <1343390750-3642-2-git-send-email-acourbot@nvidia.com> <50170EA0.1010408@wwwdotorg.org> <501A338D.7080105@nvidia.com> <20120802082157.GA14866@avionic-0098.adnet.avionic-design.de> <20120802181111.GM4537@opensource.wolfsonmicro.com> <501B2642.4080805@nvidia.com> <20120804141155.GJ10523@opensource.wolfsonmicro.com> In-Reply-To: <20120804141155.GJ10523@opensource.wolfsonmicro.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2606 Lines: 74 On 08/04/2012 11:12 PM, Mark Brown wrote: > On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote: >> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote: > >>> I missed some of the earlier bits of the thread here but why can't we do >>> device based lookups? > >> That is because the phandles would not be properties of the device >> node but rather of its sub-nodes: > >> backlight { >> compatible = "pwm-backlight"; >> ... >> power-on-sequence { >> step@0 { >> regulator = <&backlight_reg>; >> enable; >> }; >> > >> So here simply using regulator_get on the backlight device would not work. > > Ah, right. DT isn't being terribly helpful here... I think the thing > I'd expect to work here is that you have a reference back to the supply > property of the backlight device rather than direct to the regulator so > you end up writing "enable supply X" rather than "enable regulator X". > > Not quite sure how exactly you'd accomplish that - I guess if > regulator_get() would recursively follow phandles until it hits a node > that'd do the trick? Do you mean that regulator_get() would parse sub-nodes looking for a match? That seems rather dangerous and error-prone, especially if one has actual devices within the sub-nodes - their regulators could be stolen by the parent device. I think we only have two choices for this: 1) Stick to the scheme where resources are declared at the device level, such as they can be referenced by name in the sub-nodes (basically what I did in this patch): backlight { compatible = "pwm-backlight"; ... backlight-supply = <&backlight_reg>; power-on-sequence { step@0 { regulator = "backlight"; enable; }; This would translate by a get_regulator(dev, "backlight") in the code which would be properly resolved. 2) Export a lower-level DT API for resolving phandles directly from a property, similar to of_get_named_gpio. We would then have of_get_named_regulator and of_get_named_pwm. If 2) is deemed acceptable, then I think we should go for it as it would provide the most compact and readable DT syntax. Otherwise 1) is still acceptable IMHO, as it should at least make sense to people already familiar with how the DT works. Opinions from DT experts? Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/