[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().

Alan Cox alan at lxorguk.ukuu.org.uk
Wed Jan 4 05:28:28 PST 2012


> 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


More information about the dri-devel mailing list