[RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 12:56 PM, Alexander Clouter <alex at digriz.org.uk> wrote:
> In gmane.linux.kernel Grant Likely <grant.likely at secretlab.ca> wrote:
>> On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel
>> <r.schwebel at pengutronix.de> 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.
>>
> 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.  The *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?  Is 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.  This 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.