mainlining shenanigans
8f2cb9379f
Instead of having a work item that never stops (which really should be a kthread), with a dedicated workqueue to not upset anyone else, use a delayed work. A bunch of changes: - We can throw out all the custom wakeup and requeue logic and state tracking. If we schedule the work with a 0 delay it'll get scheduled immediately. - Persistent state (frame & draw_status_timeout) need to be moved out of the work. - diff is bigger than the changes, biggest chunk is reindenting the work fn because it lost its while loop. Lots of code deleting as consequence all over. Specifically we can delete the drm_driver.release code now! v2: Review from Hans: - Use mod_delayed_work in the plane update path to make sure we do actually schedule immediately). In the worker we still want queue_delayed_work, which won't modify the timeout when the work is already scheduled. Which is exactly what we want if the work races with a plane update. - Switch to system_long_wq, Hans says on usb2 a plane upload can take 80 ms. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-46-daniel.vetter@ffwll.ch |
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.