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

Daniel Vetter daniel at ffwll.ch
Wed Jan 4 04:58:21 PST 2012


On Wed, Jan 04, 2012 at 12:09:36PM +0000, Alan Cox wrote:
> > I think Alan's simply wrong.
> 
> In what way ? You stated this, then go on below to say what I did ?
> 
> > Splattering the entire driver for
> > these two corner cases which don't happen at all under normal
> > circumstances is imho utter nonsense.
> 
> Which is what I said
> 
> | > > Is this only special cases like a panic - if so can it not be called
> in a
> | > > way that distinguishes between normality and nasty cases.  
> | > 
> | > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in
> | > theory it could be indirectly called from anywhere that uses ATOM
> BIOS.  
> 
> | So lets stick to practice, and the real world. Screwing up everything
> | else because of a crappy problem in your Atom BIOS code sucks but hey it
> | happens. screwing up everything because of a theoretical concern is just
> | dumb.

Meh, missed the first part of your mail here. Looks like a
misunderstanding on my side, I was assuming you're proposing to add an
atom_exec_atomic thing which
- would unconditionally do the spinning delay (by completely abolishing
  the in_atomic checks) and
- which would require to pass around a flag from at least the panic
  handler throught the entire modeset code.

Your actual proposal makes much more sense, and as I've said I kinda like
the warning, altough I'm not really sold on the usefulness of it all.
After all we already have all the nice ftrace instrumentation to put blame
for hoggin the cpu in atomic contexts where it needs to be put.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48


More information about the dri-devel mailing list