> unnusual contexts). I'm not sure whether your proposed instrumentation is > really worth it though - in i915-land we don't bother with this. But maybe In i915 land it's specific code paths so effectively it is marked up. We don't do it for every random delay in all the connectors and other bits. The bits of code believing they are safe use sleeping locks and we'll get spewage if that breaks. Ditto at this point I hope gma500 although I would not be surpised to find ones I still need to fix from being mdelay. > with the firmware provided and randomly b0rked atombios tables it might > make sense to add the WARN_ON_ONCE you've proposed in the other mail I think we need it because it can be added by firmware, it could be silently done and the atombios paths cover so many different things beyond modesetting using that exact same function we need the mark up. If some vendor puts a 100ms delay in a connector related hotplug check we are going to have a horrible time debugging 'bugzilla #zillion, 'poor performance in OpenGL game with Radeon foozillion' Alan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
