Re: [RFC] [PATCH] Device Tree on ARM platform
From: Alexander Clouter
Date: Wed May 27 2009 - 18:15:19 EST
In gmane.linux.kernel Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
> On Wed, May 27, 2009 at 12:56 PM, Alexander Clouter <alex@xxxxxxxxxxxxx> wrote:
>> In gmane.linux.kernel Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
>>> On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel
>> 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 into a
>> new bus rather than just continuing the messy direction I have been
>> going to date.
>> 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
>> The 'magic' is that the FPGA code has some special value 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 :)
.sigmonster says: Who goeth a-borrowing goeth a-sorrowing.
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/