Minor nitpick. s/queuing/queueing/ and s/queuable/queueable/.
On 2020-05-08 15:46, Lyude Paul wrote:
Add some simple wrappers around incrementing/decrementing
kthread_work.cancelling under lock, along with checking whether queuing
is currently allowed on a given kthread_work, which we'll use
On 9/13/19 6:28 PM, José Roberto de Souza wrote:
> Currently we restrict the number of encoders that can be linked to
> a connector to 3, increase it to match the maximum number of encoders
> that can be initialized(32).
>
> To more effiently do that lets switch from an array of encoder ids to
>
On 8/14/19 2:59 AM, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma. Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks. This removes a lot
> of boilerplate code as-is, and
On 8/8/19 1:04 PM, Lyude Paul wrote:
> I -thought- I had fixed this entirely, but it looks like that I didn't
> test this thoroughly enough as we apparently still make one big mistake
> with nv50_msto_atomic_check() - we don't handle the following scenario:
>
> * CRTC #1 has n VCPI allocated to
On 07/30/2018 07:39 PM, Lyude Paul wrote:
> I'm sure I don't need to tell you that fb_helper's locking is a mess.
> That being said; fb_helper's locking mess can seriously complicate the
> runtime suspend/resume operations of drivers because it can invoke
> atomic commits and connector probing
Minor nitpick in the patch title: s/Retreive/Retrieve/.
On 04/10/2017 02:50 PM, Roy Spliet wrote:
> Signed-off-by: Roy Spliet
> ---
> drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/perf.h | 1 +
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/perf.c | 14
I hope I'm writing to people who can help me. If not you, then I have a
serious inconvenience and am going to be at a complete loss for where to turn.
Let me explain my setup. I have an HTPC with a GeForce GT620. It is connected
to a Denon AVR-1913 via HDMI, because that does all the