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 14:46:37 -0600 Message-ID: References: <1243408083.13460.14.camel@debian-nb> <20090527150527.GK6805@pengutronix.de> <2ve0f6-8fn.ln1@woodchuck.wormnet.eu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <2ve0f6-8fn.ln1-kuKQLpWnKMRB2HF5bZY0Orm56z/blAVA@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: Alexander Clouter Cc: 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 Wed, May 27, 2009 at 12:56 PM, Alexander Clouter wr= ote: > In gmane.linux.kernel Grant Likely wrote: >> 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 t= he >>> =A0constant change in definitions. >> >> This is a MPC5200 is the posterchild for device tree wreckage; mostly >> because of my own inexperience at the time. =A0A lot of mistakes were >> made and I freely admit that. >> >> However, my counter example is Xilinx Virtex support. =A0The Virtex is >> an FPGA with all the devices instantiated in the FPGA fabric. =A0It >> 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. =A0Encoding the machine >> layout in a data structure (the device tree) has decoupled FPGA >> changes from the kernel image. =A0Now FPGA engineers can make major >> changes to FPGA layouts without having to lockstep with changes in the >> kernel. =A0I 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. >> > Although I have no input of value here, I'm hoping I do not become the > next posterchild for "pain++". > > I'm working through redo'ing the FPGA support in the TS-7800[1] into a > new bus rather than just continuing the messy direction I have been > going to date[2]. > > My current approach is that the bus handles the 'hotplug'ing of the FPGA > bitstream by unregistering all the devices and then when it's informed > the new bitstream is ready it prods all the registered drivers if any > devices need bringing up (obviously drivers can be modprobe'd as and > when). > > The 'magic' is that the FPGA code has some special value[3] that what it > is and the drivers (outside the platform code) have a list of FPGA magic > values (with a mask) that they are willing to service. =A0The *bus* > (platform code) is what installs the devices effectively and only does > so if the loaded driver says it can drive a particular loaded bitstream > (in the bus driver struct is a array of ID's it checks). > > Does this sound sane? =A0Is it an approach that could be ACKed one day? > Currently the bit that might be considered sinful is there is for some > of the drivers (rtc-m48t86, timeriomem-rng and plat_nand) the FPGA bus > 'driver' is a light wrapper around the platform device driver. =A0This is > so that the hooks still exist so the bus know what to load and unload as > and when. Personally, I'd not write a separate bus. I'd write a platform driver which turns around and registers more platform devices with the original device as the parent in the _probe routine, and unregisters them in _remove. Should have the same affect with less complex code. However, someone with more device-model-foo may have better advice. g. -- = Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.