On Mar 12, 2011, at 5:28 AM, Rolf Eike Beer wrote: > David Hagood wrote: >> On Fri, 2011-03-11 at 13:45 -0800, Greg KH wrote: >>> What was the response? >> >> Mostly "This always comes up when people do FPGAs and they always do it >> wrong." >> And when I asked "OK, so what is right?" <crickets_chirp.wav> >> >> There's nothing like "here's how an FPGA might trigger a hot plug >> event." or "here's how your driver can trigger a hot plug event" or >> anything like that. > > First you need the device configurable do have it configured ;) That can > either be that it already loads a design on bootup (e.g. from SPI) or you use > a non-FPGA bridge chip (e.g. one of those crappy PLX9656 things). For the in- > FPGA thing you need something that comes up fast enough for the initial scan > time limit (IIRC ~50ms or something like that). We don't have such a bridge. We have one FPGA (virtex5 or spartan6) and this is a pretty strong design requirement. > > For Xilinx FPGAs they e.g. support "compressed bitstreams" so they can > configure all identical blocks in parallel. If you leave the initial design > mostly empty you can shrink the size of the bitstream and with it the > configuration time to be small enough. For newer Xilinx chips (IIRC Spartan 6) > there is even a solution directly from Xilinx doing exactly this. > If I unserstand correctly, this would still imply a PROM next to the FPGA, something I want to avoid. I would like to send the bitstream to the FPGA directly from a filesystem file to SPI from a driver or userspace. > Coming up with a physically connected but PCI-wise dead board doesn't seem > like a good idea to me as this basically gives you no benefit but makes > accessing the device harder. Unless there is something else I don't see, I still think this is the way to go for us. > > Doing the hotplug thing later, well, I leave this to Greg to explain. > > Eike Thanks for all the help guys, I (and David I'm sure) appreciate the thread.-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
