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@xxxxxxxx Mobile: +41 (0)79 365 57 48 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
