[RFC] [PATCH] Device Tree on ARM platform

[Dmitry Eremin-Solenikov]

Alexander Clouter wrote:

> In gmane.linux.kernel Grant Likely
> <grant.likely at secretlab.ca> wrote:
>> 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
>>>>
>>>> [snipped]
>>>>
>>> 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.
>> 
> That's a thought, but this 'bus' does not just drive platform devices,
> there are other drivers that will live outside the scope.
> 
> I have a half completed GPIO expander for the 'factory' FPGA bitstream
> that could not be done as a platform device.  The GPIO pin's also
> multiplex as an ISA (PC/104) bus and chip select's a SPI bus too.
> 
> Another driver is a DMA engine provisioned by the factory bitstream too
> as well as AVR+ADC+watchdog system too.
> 
> What would make sense for this approach would be if it was to drive
> bit's from the opencores.org website.
> 
> Because there is a mix of platform devices and 'awkward' bit's, this is
> why I was thinking about a seperate bus.
> 
> Cheers for the suggestion, it's got me thinkingthat there still has to
> be a better way :)

When facing nearly the same problems with Toshiba Multi I/O chips,
we have created and used the special set of functions. You can check
the drivers/mfd/mfd-core.c and include/linux/mfd/core.h for details.

-- 
With best wishes
Dmitry