Instead of reusing the polling code for hpd handling, split them up.
This has a few consequences:
- Don't touch HPD capable connectors in the poll loop.
- Only touch HPD capable connectors in drm_helper_hpd_irq_event.
- Run the HPD handling directly instead of going through a work item -
all call
Am 28.05.2012 12:46, schrieb Niccolò Belli:
Il 28/05/2012 08:14, Oliver Seitz ha scritto:
Is this true? I've seen no changes for a long time. I thought maybe
maintainers see no need to work on software that does it's job. I would
be very sorry if it was really dead.
No need? What about trying
Instead of reusing the polling code for hpd handling, split them up.
This has a few consequences:
- Don't touch HPD capable connectors in the poll loop.
- Only touch HPD capable connectors in drm_helper_hpd_irq_event.
- We could run the HPD handling directly (because all callers already
use their
All drivers already have a work item to run the hpd code, so we don't
need to launch a new one in the helper code. Dave Airlie mentioned
that the cancel+re-queue might paper over DP related hpd ping-pongs,
hence why this is split out.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_hel
Il 29/05/2012 11:36, Oliver Seitz ha scritto:
But isn't this a decision to be made by the mainline maintainers?
Obviously, but why shouldn't they reject a widely requested feature when
the code is mature enough?
By the way, since there are no ebuilds with the latest code available (I
still ca
Il 29/05/2012 12:54, Niccolò Belli ha scritto:
Obviously, but why shouldn't they reject a widely requested feature when
the code is mature enough?
Err... shouldn't ---> should I'm sorry :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
htt
Il 29/05/2012 12:54, Niccolò Belli ha scritto:
By the way, since there are no ebuilds with the latest code available (I
still can't believe it) I made my own
media-video/mplayer-1.0_rc4_p20120116 ebuild with the vaapi use flag. I
will post it as soon as I finish to set up git on my server.
As p
On Mon, May 28, 2012 at 10:33:02PM +0100, Chris Wilson wrote:
> When we reset the ring control registers, including the HEAD and TAIL of
> the ring, we also need to reset associated state. In this instance, we
> were failing to reset the cached value of ring->last_retired_head and so
> upon the fir
On Tue, May 29, 2012 at 6:54 AM, Niccolò Belli
wrote:
> Il 29/05/2012 11:36, Oliver Seitz ha scritto:
>
>> But isn't this a decision to be made by the mainline maintainers?
>
>
> Obviously, but why shouldn't they reject a widely requested feature when the
> code is mature enough?
> By the way, sin
