On Sat, Oct 02, 2010 at 03:27:23PM -0500, David Hagood wrote: > On Sun, 2010-10-03 at 04:43 +0900, Paul Mundt wrote: > > One of the points of having an FPGA is that you can implement these > > things sensibly, rather than forcing the kernel to work around the crap > > that was implemented by people who have an aversion to the specifictions. > No, it's called "having an aversion to shutting my driver down while it > is doing its job". My point is that the behaviour you are looking for is something that could be supported more cleanly by implementing hotplug logic. The fact you have elected to depend on non-standard behaviour in a non-standard way is the issue, and unfortunately one that pops up almost any time the word FPGA gets thrown in to a discussion. While I have no doubt that you have your reasons for doing so, the point remains that you effectively invite pain upon yourself, and this also makes it nearly impossible to get your changes upstream. Hotplug drivers already need to contend with the case that the device may be going away or otherwise becoming unavailable, and you do have standard methods for both being notified of that and being able to signal when your driver is in a state where it can quickly go through a down/up cycle. Also keep in mind that a liberal interpretation of the specifictions is often far better than simply shafting them entirely. As an example, I can't think of a single PCI or PCI express controller in an embedded SoC that ends up being more than simply compliant with a subset of the specifictions in question, but many of those supported functions are chosen explicitly to support existing behaviour with the least amout of logic necessary. Something to consider for next time. > > If you can tolerate a suspend/resume cycle on the device > OK, do you have any pointers on how to trigger that from my driver - how > to do a quick down-and-up on the device so that the time it's not > handling its job is minimized? > I would recommend reading through Documentation/power/pci.txt to get a general overview. In your case I suspect the cleanest option will be to go down the runtime PM path. You presumably are only trying to resize the BAR when the device is idle, in which case the kernel can make these transitions for you via runtime PM. The alternative is to do explicit state transitions via sysfs or using open-coded calls to internal PM routines, neither of which are advisable, but are still options. -- 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
