From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753477AbZE1WWd (ORCPT ); Thu, 28 May 2009 18:22:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751023AbZE1WW0 (ORCPT ); Thu, 28 May 2009 18:22:26 -0400 Received: from gate.crashing.org ([63.228.1.57]:43999 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750811AbZE1WWZ (ORCPT ); Thu, 28 May 2009 18:22:25 -0400 Subject: Re: [RFC] [PATCH] Device Tree on ARM platform From: Benjamin Herrenschmidt To: Grant Likely Cc: Dmitry Eremin-Solenikov , devicetree-discuss@ozlabs.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.arm.linux.org.uk In-Reply-To: References: <20090527175609.GB31861@flint.arm.linux.org.uk> <1243496236.3171.140.camel@pasglop> <20090528091513.GA14789@n2100.arm.linux.org.uk> <20090528.025739.16559619.davem@davemloft.net> Content-Type: text/plain Date: Fri, 29 May 2009 08:21:58 +1000 Message-Id: <1243549318.17903.9.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2009-05-28 at 08:13 -0600, Grant Likely wrote: > Two nodes are used to describe the device and a "phandle" is used to > link them. A device driver probe could be triggered (bind) against > the i2c half of the device and follow the phandle to get the rest of > the description. One thing I wouldn't do though is to put "phandle" in the property name :-) Just call it spi-interface. Now, that's an option. And it works to a certain extent. But I do understand the need in general to provide "methods". It's something we don't solve (but then we don't make it worse than it was before). I think the cleanest option might be named methods in the device-tree for example, a device can have an "enable-method" property and a "clock-method" property. The names would use the usual convention of "manuf,name" to avoid clashes and could be registered by the platform. Now, it -does- somewhat deviates from the moto that the DT should only contain OS agnostic HW representations, but appart for having a full blown OF with actual method calls in each nodes I don't see a nicer way at this stage. Now, the methods could then take "informations" from the target DT. For example, one could have a generic "simple-gpio-enable" method that can be used as "enable-method" anywhere, as long as the target device contains also a "enable-gpio" property that points to the actual GPIO (and maybe an "enable-delay" while at it). IE. We can provide a collection of "simple" methods that handle the easy cases in library code. I'm very much against putting actual function pointers in the tree though as Jon Smirl proposed. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [RFC] [PATCH] Device Tree on ARM platform Date: Fri, 29 May 2009 08:21:58 +1000 Message-ID: <1243549318.17903.9.camel@pasglop> References: <20090527175609.GB31861@flint.arm.linux.org.uk> <1243496236.3171.140.camel@pasglop> <20090528091513.GA14789@n2100.arm.linux.org.uk> <20090528.025739.16559619.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-mnsaURCQ41sdnm+yROfE0A@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-mnsaURCQ41sdnm+yROfE0A@public.gmane.org To: Grant Likely Cc: Dmitry Eremin-Solenikov , devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-xIg/pKzrS19vn6HldHNs0ANdhmdF6hFW@public.gmane.org List-Id: devicetree@vger.kernel.org On Thu, 2009-05-28 at 08:13 -0600, Grant Likely wrote: > Two nodes are used to describe the device and a "phandle" is used to > link them. A device driver probe could be triggered (bind) against > the i2c half of the device and follow the phandle to get the rest of > the description. One thing I wouldn't do though is to put "phandle" in the property name :-) Just call it spi-interface. Now, that's an option. And it works to a certain extent. But I do understand the need in general to provide "methods". It's something we don't solve (but then we don't make it worse than it was before). I think the cleanest option might be named methods in the device-tree for example, a device can have an "enable-method" property and a "clock-method" property. The names would use the usual convention of "manuf,name" to avoid clashes and could be registered by the platform. Now, it -does- somewhat deviates from the moto that the DT should only contain OS agnostic HW representations, but appart for having a full blown OF with actual method calls in each nodes I don't see a nicer way at this stage. Now, the methods could then take "informations" from the target DT. For example, one could have a generic "simple-gpio-enable" method that can be used as "enable-method" anywhere, as long as the target device contains also a "enable-gpio" property that points to the actual GPIO (and maybe an "enable-delay" while at it). IE. We can provide a collection of "simple" methods that handle the easy cases in library code. I'm very much against putting actual function pointers in the tree though as Jon Smirl proposed. Cheers, Ben.