In gmane.linux.kernel Grant Likely <[email protected]> wrote: > On Wed, May 27, 2009 at 12:56 PM, Alexander Clouter <[email protected]> > wrote: >> In gmane.linux.kernel Grant Likely <[email protected]> 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 :) Cheers -- Alexander Clouter .sigmonster says: Who goeth a-borrowing goeth a-sorrowing. _______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
