From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761155AbZE0Pjs (ORCPT ); Wed, 27 May 2009 11:39:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753697AbZE0Pjl (ORCPT ); Wed, 27 May 2009 11:39:41 -0400 Received: from yw-out-2324.google.com ([74.125.46.30]:42138 "EHLO yw-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752554AbZE0Pjl convert rfc822-to-8bit (ORCPT ); Wed, 27 May 2009 11:39:41 -0400 MIME-Version: 1.0 In-Reply-To: <20090527150527.GK6805@pengutronix.de> References: <1243408083.13460.14.camel@debian-nb> <20090527150527.GK6805@pengutronix.de> From: Grant Likely Date: Wed, 27 May 2009 09:39:21 -0600 Message-ID: Subject: Re: [RFC] [PATCH] Device Tree on ARM platform To: Robert Schwebel Cc: Timur Tabi , Janboe Ye , devicetree-discuss , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.arm.linux.org.uk, rmk@arm.linux.org.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel wrote: > Seriously: oftree in general is a good idea. Just that it doesn't work > in practise. The concept has some serious flaws: > > - The whole concept is based on the assumption that bindings are defined >  *once*, then never to be changed again. As this is not true (check >  MPC5200 to find out what I mean), oftree wreckage is *the* main cause >  of new kernels not working on old bootloaders any more. Is there a >  solution of this problem? I have not seen a good idea how to avoid the >  constant change in definitions. This is a MPC5200 is the posterchild for device tree wreckage; mostly because of my own inexperience at the time. A lot of mistakes were made and I freely admit that. However, my counter example is Xilinx Virtex support. The Virtex is an FPGA with all the devices instantiated in the FPGA fabric. It would be a nightmare to try and describe each different FPGA bitstream using hand coded platform devices, and the xparameters.h file exported by the Xilinx toolchain wasn't much better. Encoding the machine layout in a data structure (the device tree) has decoupled FPGA changes from the kernel image. Now FPGA engineers can make major changes to FPGA layouts without having to lockstep with changes in the kernel. I regularly boot a single kernel image on multiple bitstream images. That being said, the problems we have had are the reason why it is *not* recommended to hard link the device tree image into firmware. We do commit to not breaking old trees, but the ability to update is important; particularly for enabling new features/drivers. > - The oftree layering is fundamentally broken. We already have a sane >  abstraction for arbitrary hardware in the kernel: platform devices. >  Why not instanciate platform devices from a generic oftree core? No; the oftree is a data structure. That is it, nothing more. The device tree layout is well defined and independent of Linux kernel internal implementation details. In powerpc land we've chosen to use the of_platform bus to decode the data into Linux usable form, and I think it is the best approach. If a designer wanted to, then platform devices could be instantiated instead. In fact, that used to be done for most powerpc devices, but we've moved away from that model because the data still needs to be decoded somewhere, and that 'somewhere' should be as close to the driver as possible. > - Platform data makes it possible to store function pointers. There >  is no equivalent to this concept in oftree-land. But there is concept of platform specific code. In the majority of cases platform specific function pointers aren't needed at all. In the cases where they are; platform devices can still be used. > oftree could be a great tool if these things would be resolved. > Currently they are not, and in result, ARM just works and is easy, > whereas on PowerPC systems people often spend more time working on > binding stuff than on the actual functionality. That's a rather polarizing statement and I don't think its fair. The FDT is not a magic bullet. It makes aspects of platform independence, code sharing, and board porting simpler, but it is also requires forethought and has overhead associated with it. I don't think anyone is proposing to require all ARM platforms to use the FDT approach. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [RFC] [PATCH] Device Tree on ARM platform Date: Wed, 27 May 2009 09:39:21 -0600 Message-ID: References: <1243408083.13460.14.camel@debian-nb> <20090527150527.GK6805@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20090527150527.GK6805-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 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: Robert Schwebel Cc: devicetree-discuss , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-xIg/pKzrS19vn6HldHNs0ANdhmdF6hFW@public.gmane.org, Janboe Ye , Timur Tabi , rmk-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org List-Id: devicetree@vger.kernel.org On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel wrote: > Seriously: oftree in general is a good idea. Just that it doesn't work > in practise. The concept has some serious flaws: > > - The whole concept is based on the assumption that bindings are defined > =A0*once*, then never to be changed again. As this is not true (check > =A0MPC5200 to find out what I mean), oftree wreckage is *the* main cause > =A0of new kernels not working on old bootloaders any more. Is there a > =A0solution of this problem? I have not seen a good idea how to avoid the > =A0constant change in definitions. This is a MPC5200 is the posterchild for device tree wreckage; mostly because of my own inexperience at the time. A lot of mistakes were made and I freely admit that. However, my counter example is Xilinx Virtex support. The Virtex is an FPGA with all the devices instantiated in the FPGA fabric. It would be a nightmare to try and describe each different FPGA bitstream using hand coded platform devices, and the xparameters.h file exported by the Xilinx toolchain wasn't much better. Encoding the machine layout in a data structure (the device tree) has decoupled FPGA changes from the kernel image. Now FPGA engineers can make major changes to FPGA layouts without having to lockstep with changes in the kernel. I regularly boot a single kernel image on multiple bitstream images. That being said, the problems we have had are the reason why it is *not* recommended to hard link the device tree image into firmware. We do commit to not breaking old trees, but the ability to update is important; particularly for enabling new features/drivers. > - The oftree layering is fundamentally broken. We already have a sane > =A0abstraction for arbitrary hardware in the kernel: platform devices. > =A0Why not instanciate platform devices from a generic oftree core? No; the oftree is a data structure. That is it, nothing more. The device tree layout is well defined and independent of Linux kernel internal implementation details. In powerpc land we've chosen to use the of_platform bus to decode the data into Linux usable form, and I think it is the best approach. If a designer wanted to, then platform devices could be instantiated instead. In fact, that used to be done for most powerpc devices, but we've moved away from that model because the data still needs to be decoded somewhere, and that 'somewhere' should be as close to the driver as possible. > - Platform data makes it possible to store function pointers. There > =A0is no equivalent to this concept in oftree-land. But there is concept of platform specific code. In the majority of cases platform specific function pointers aren't needed at all. In the cases where they are; platform devices can still be used. > oftree could be a great tool if these things would be resolved. > Currently they are not, and in result, ARM just works and is easy, > whereas on PowerPC systems people often spend more time working on > binding stuff than on the actual functionality. That's a rather polarizing statement and I don't think its fair. The FDT is not a magic bullet. It makes aspects of platform independence, code sharing, and board porting simpler, but it is also requires forethought and has overhead associated with it. I don't think anyone is proposing to require all ARM platforms to use the FDT approach. g. -- = Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.