Re: [RFC] [PATCH] Device Tree on ARM platform

[Alexander Clouter]

In gmane.linux.kernel Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
> On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel
> <r.schwebel@xxxxxxxxxxxxxx> 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.

I cannot think of another way to do this as implementing the FPGA as a 
'parent' *device* rather than a bus would shift all the bitstream 
specific code back into the platform code :-/  There might be a magic 
method I have not seen yet though.

I would dish out patches, but currently it's not a patch set, just one 
phat one; obviously it will be broken up later :)

Cheers

[1] http://ts78xx.digriz.org.uk/
	http://armlinux.simtec.co.uk/kautobuild/2.6.29/index.html#machine_1653
[2] http://git.marvell.com/?p=orion.git;a=blob;f=arch/arm/mach-orion5x/ts78xx-setup.c;hb=HEAD
[3] ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7800-linux/docs/ts-7800-syscon-regmap.txt

-- 
Alexander Clouter
.sigmonster says: Good leaders being scarce, following yourself is allowed.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/