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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Well, hotplug is alreay a giant pain because of the single lock to rule
> them all design of the current kms code: Long delays already stall
> everything else (well, cursor updates and pageflips) and we have tons of

Yes I hit this with the gma500, it's one reason I did the GTT based
scrolling.

> bugreports that complain about it. In a sense your example undermines my
> point that we have lower hanger fruit to fix all over the place already ...

Yes.. I'm trying to stop the rotting fruit getting any further down the
tree!

The KMS locking isn't just a KMS problem, KMS inherits some of it from
the framebuffer which inherits some of it from printk which gets some of
it from panic an in IRQ error handling. It's all very messy as a result.

I keep poking at the vt and tty layer end of this to try and sort it out
from the bottom but it's like a bad cess pit, every time you poke it the
smell drives you back to other things.

> But as I've said I like the WARN_ON you want to add, but otoh hand think
> it shouldn't be used to stall the small&hackish fix of adding the relevant
> in_atomic checks.

Then I think we basically agree.

Alan
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux