On Mon, 4 Oct 2010 20:13:33 +1000, Dave Airlie wrote:
> We don't do dynamic connectors now, so adding locking with no way of
> actually really testing it would just mean you'd probably have just as
> much pain when you do add dyanamic connectors.
I looked in the radeon and nouveau drivers and
events.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
V3: document Hotplug option in man page
Signed-off-by: Keith Packard
---
configure.ac |5 ++
man/intel.man |6 +++
src/Makefile.am|4 +-
src/intel.h| 12 +
src/intel_driver.c
.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
V3: document Hotplug option in man page
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac |5 ++
man/intel.man |6 +++
src/Makefile.am|4 +-
src/intel.h| 12 +
src
On Mon, 4 Oct 2010 20:13:33 +1000, Dave Airlie airl...@gmail.com wrote:
We don't do dynamic connectors now, so adding locking with no way of
actually really testing it would just mean you'd probably have just as
much pain when you do add dyanamic connectors.
I looked in the radeon and nouveau
Cancel the output polling work proc before acquiring the struct mutex
to avoid acquiring the work proc mutex with the struct mutex
held. This avoids inverting the lock order seen when the work proc
runs.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files
On Mon, 4 Oct 2010 01:15:08 +0200, Peter Stuge wrote:
> If there is the infrastructure to do so, then it seems that the 600ms
> delay while polling unconnected monitors could easily be removed.
Newer hardware generates interrupts for VGA and TV hotplug events; older
hardware doesn't.
--
On Mon, 4 Oct 2010 06:33:01 +1000, Dave Airlie wrote:
> don't you do this already? both radeon/nouveau handle DP replug fine,
> I thought Intel would have been where I stole the code from.
There was a one-line bug. Patch already posted.
--
keith.packard at intel.com
-- next part
events.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
Signed-off-by: Keith Packard
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 12 +
src/intel_driver.c | 114
4 files change
On Sun, 03 Oct 2010 22:05:13 +0100, Chris Wilson
wrote:
> It appears that all users (crtc and encoders) are tracking dpms_mode, in
> one form or another. Should we move this to core?
Sounds like a good idea. Would you prefer to do that yourself?
> Is there any hardware that requires
events.
Signed-off-by: Keith Packard
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 11 +
src/intel_driver.c | 114
4 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/configur
On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes
wrote:
> Do these fixes help with the DP issues you've been seeing, Keith?
> Seems like the first one shouldn't change behavior since we ought to
> time out on waiting on vblank in that case, and the timeout is the same
> as the msleep we used to
only do this when we're not about to wait for
the pipe to turn off.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 62 +-
drivers/gpu/drm/i915/intel_drv.h |1 -
2 files changed, 38 insertions(+), 25 deletions(-)
diff --git
.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1a51ee0..9ab8708 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b
.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1a51ee0..9ab8708 100644
--- a/drivers/gpu/drm/i915
only do this when we're not about to wait for
the pipe to turn off.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 62 +-
drivers/gpu/drm/i915/intel_drv.h |1 -
2 files changed, 38 insertions(+), 25 deletions
On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Do these fixes help with the DP issues you've been seeing, Keith?
Seems like the first one shouldn't change behavior since we ought to
time out on waiting on vblank in that case, and the timeout is the same
as
On Sun, 03 Oct 2010 22:05:13 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
It appears that all users (crtc and encoders) are tracking dpms_mode, in
one form or another. Should we move this to core?
Sounds like a good idea. Would you prefer to do that yourself?
Is there any hardware
.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 12 +
src/intel_driver.c | 114
4
On Mon, 4 Oct 2010 06:33:01 +1000, Dave Airlie airl...@gmail.com wrote:
don't you do this already? both radeon/nouveau handle DP replug fine,
I thought Intel would have been where I stole the code from.
There was a one-line bug. Patch already posted.
--
keith.pack...@intel.com
On Mon, 4 Oct 2010 01:15:08 +0200, Peter Stuge pe...@stuge.se wrote:
If there is the infrastructure to do so, then it seems that the 600ms
delay while polling unconnected monitors could easily be removed.
Newer hardware generates interrupts for VGA and TV hotplug events; older
hardware
Cancel the output polling work proc before acquiring the struct mutex
to avoid acquiring the work proc mutex with the struct mutex
held. This avoids inverting the lock order seen when the work proc
runs.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c
On Thu, 8 Jul 2010 09:49:26 -0700, Jesse Barnes
wrote:
> That's the part I had trouble with as well. Passing the blob through
> the kernel saves a little IPC but also seems unnecessary, and so rubs
> against my kernel minimalist side...
Yeah, if the kernel doesn't need to know it, why is the
On Thu, 8 Jul 2010 11:23:25 -0400, Kristian H?gsberg
wrote:
> - a mechanism to attach a binary blob to an flink_to buffer name.
>open_with_data returns the data. Userspace (typically libdrm)
>decides the layout and versioning of the blob and the contents
>will be chipset
On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
- a mechanism to attach a binary blob to an flink_to buffer name.
open_with_data returns the data. Userspace (typically libdrm)
decides the layout and versioning of the blob and the contents
will be
On Thu, 8 Jul 2010 09:49:26 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
That's the part I had trouble with as well. Passing the blob through
the kernel saves a little IPC but also seems unnecessary, and so rubs
against my kernel minimalist side...
Yeah, if the kernel doesn't need to
On Fri, 11 Jun 2010 18:00:09 -0400, Alex Deucher
wrote:
> Disables the crts as per dpms and also disables the ppll
> associated with the crtc. This should save additional power.
Any reason the pll isn't just disabled for dpms as well?
--
keith.packard at intel.com
-- next part
On Fri, 11 Jun 2010 18:00:09 -0400, Alex Deucher alexdeuc...@gmail.com wrote:
Disables the crts as per dpms and also disables the ppll
associated with the crtc. This should save additional power.
Any reason the pll isn't just disabled for dpms as well?
--
keith.pack...@intel.com
1001 - 1027 of 1027 matches
Mail list logo
