[PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper
[PATCH 2/5] drm/i915: Rename i915_dp_detect_common to
[PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with
These three are simple cleanups to centralize all places where the
DPCD block was read from the device. Now everyo
If the connector is inserted or removed slowly, the hotplug line may
well change state before the data lines do. So, assume the user isn't
trying to fool us and give them 250ms to get the connector plugged or
unplugged.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c |2 ++
Display port pipe selection on CPT is not done with a bit in the
output register, rather it is controlled by a couple of bits in the
separate transcoder register which indicate which display port output
is connected to the transcoder.
This patch replaces the simplistic macro DP_PIPE_ENABLED with t
This describes the function better, allowing it to be used where the
DPCD value is relevant.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers
This uses the common dpcd reading routine, i915_dp_detect_common,
instead of open-coding a call to intel_dp_aux_native_read. Besides
reducing duplicated code, this also gains the read retries which
may be necessary when a cable is first plugged back in and the link
needs to be retrained.
Signed-of
Eliminates an open-coded read and also gains the retry behaviour of
intel_dp_get_dpcd, which seems like a good idea.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/
Display port pipe selection on CPT is not done with a bit in the
output register, rather it is controlled by a couple of bits in the
separate transcoder register which indicate which display port output
is connected to the transcoder.
This patch replaces the simplistic macro DP_PIPE_ENABLED with t
If the connector is inserted or removed slowly, the hotplug line may
well change state before the data lines do. So, assume the user isn't
trying to fool us and give them 250ms to get the connector plugged or
unplugged.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c |2 ++
Eliminates an open-coded read and also gains the retry behaviour of
intel_dp_get_dpcd, which seems like a good idea.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/
This describes the function better, allowing it to be used where the
DPCD value is relevant.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers
This uses the common dpcd reading routine, i915_dp_detect_common,
instead of open-coding a call to intel_dp_aux_native_read. Besides
reducing duplicated code, this also gains the read retries which
may be necessary when a cable is first plugged back in and the link
needs to be retrained.
Signed-of
[PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper
[PATCH 2/5] drm/i915: Rename i915_dp_detect_common to
[PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with
These three are simple cleanups to centralize all places where the
DPCD block was read from the device. Now everyo
On Mon, 25 Jul 2011 22:52:15 -0400, Andrew Lutomirski wrote:
> Doesn't help :(
Oh, it helps, just not this issue :-)
> When I do 'xset dpms force off', one of two things happens. Either
> the display comes back all by itself or it never comes back until I
> power cycle it.
Oh. Right. Actual D
On Mon, 25 Jul 2011 22:52:15 -0400, Andrew Lutomirski wrote:
> Doesn't help :(
Oh, it helps, just not this issue :-)
> When I do 'xset dpms force off', one of two things happens. Either
> the display comes back all by itself or it never comes back until I
> power cycle it.
Oh. Right. Actual D
tput_poll_execute], [CONNECTOR:19:DP-3] status updated
from 2 to 2
[ 290.913994] [drm:intel_crtc_cursor_set],
[ 290.913998] [drm:intel_crtc_cursor_set], cursor off
[ 309.750888] this time it made noise and went to sleep. it failed to come
back on its own and needed a power cycle
-- next part --
A non-text attachment was scrubbed...
Name: i915_dpms_trace.patch
Type: text/x-patch
Size: 1825 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110725/90378c5e/attachment-0001.bin>
com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110725/4fe1c43d/attachment.pgp>
2011/7/25 Rob Clark :
> On Mon, Jul 25, 2011 at 3:18 AM, Joonyoung Shim wrote:
>> 2011/7/22 Jesse Barnes :
>>> On Thu, 21 Jul 2011 19:30:00 +0900
>>> Joonyoung Shim wrote:
>>>
Hi,
simple questions :)
2011/6/21 Jesse Barnes :
> Planes are a bit like half-CRTCs. They
On Mon, 18 Jul 2011 09:08:15 -0400, Prarit Bhargava wrote:
> This patch introduces a general System Firmware interface to the kernel,
> called
> sysfw.
>
> Inlcluded in this interface is the ability to search a standard set of fields,
> sysfw_lookup(). The fields are currently based upon the x86
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes wrote:
> On Mon, 25 Jul 2011 10:10:29 -0700
> Keith Packard wrote:
>
>> Hotplug detection is a mode setting operation and must hold the
>> struct_mutex or risk colliding with other mode setting operations.
>>
>> In particular, the display port hotplug
https://bugs.freedesktop.org/show_bug.cgi?id=39534
Guido Trentalancia changed:
What|Removed |Added
Summary|failed udev tests (intended |failed general and udev
https://bugs.freedesktop.org/show_bug.cgi?id=39534
Guido Trentalancia changed:
What|Removed |Added
Summary|failed udev tests (intended |failed general and udev
https://bugs.freedesktop.org/show_bug.cgi?id=39534
Guido Trentalancia changed:
What|Removed |Added
Summary|failed tests|failed udev tests (intended
https://bugs.freedesktop.org/show_bug.cgi?id=39534
Guido Trentalancia changed:
What|Removed |Added
Summary|failed tests|failed udev tests (intended
https://bugs.freedesktop.org/show_bug.cgi?id=39534
Summary: failed tests
Product: DRI
Version: XOrg CVS
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: medium
Component: libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=39534
Summary: failed tests
Product: DRI
Version: XOrg CVS
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: medium
Component: libdrm
From: Alex Deucher
Need to add vddci setting to pm init as well as
resume. Fixes hangs on load on some boards.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38754
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/radeon_pm.c |3 +++
1 files changed, 3
2011/7/22 Jesse Barnes :
> On Thu, 21 Jul 2011 19:30:00 +0900
> Joonyoung Shim wrote:
>
>> Hi,
>>
>> simple questions :)
>>
>> 2011/6/21 Jesse Barnes :
>> > Planes are a bit like half-CRTCs. ?They have a location and fb, but
>> > don't drive outputs directly. ?Add support for handling them to the
From: Alex Deucher
Need to add vddci setting to pm init as well as
resume. Fixes hangs on load on some boards.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38754
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_pm.c |3 +++
1 files changed, 3 ins
Will test tonight.
It looks like there is a lot of hotplug activity when 'xset dpms force
off' gets run. (That's not a typo. I do mean "off," not "on."
See attached trace. perf rocks, even over ssh :)
--Andy
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes
wrote:
> On Mon, 25 Jul 2011 10:10:2
Ping ?
As stated in my previous mail, I'd like to reach an agreement on the API, and
implement it. I'm fine with either grayscale or nonstd to store the FOURCC
(with a slight preference for grayscale), and with either a vmode flag or
using the most significant byte of the grayscale/nonstd field
On Mon, 18 Jul 2011 09:08:15 -0400, Prarit Bhargava wrote:
> This patch introduces a general System Firmware interface to the kernel,
> called
> sysfw.
>
> Inlcluded in this interface is the ability to search a standard set of fields,
> sysfw_lookup(). The fields are currently based upon the x86
On Tue, Jul 5, 2011 at 9:12 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> The same way it was already done for r300.
>
> Also fix typo in gart warning messages.
Causes a new warning per line on x86-64 build.
dma_addr_t doesn't go into %08x.
Dave.
From: Jerome Glisse
DPEncoderService newer than 1.1 can't properly program the DP (display port)
link training. When facing such version use the DIGxEncoderControl method
instead. Fix DP link training on some R7XX.
Signed-off-by: Jerome Glisse
Reviewed-by: Alex Deucher
Cc: stable at kernel.org
On Mon, 25 Jul 2011 13:40:58 -0400, Andrew Lutomirski wrote:
> Will test tonight.
Thanks.
> It looks like there is a lot of hotplug activity when 'xset dpms force
> off' gets run. (That's not a typo. I do mean "off," not "on."
Yup, that's what I've seen as well -- do a mode set to turn stuf
Makes me optimistic that a bit of locking will help a lot here.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110725/ce05d5e3/attachment.pgp>
Will test tonight.
It looks like there is a lot of hotplug activity when 'xset dpms force
off' gets run. (That's not a typo. I do mean "off," not "on."
See attached trace. perf rocks, even over ssh :)
--Andy
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes wrote:
> On Mon, 25 Jul 2011 10:10:29
On Mon, 25 Jul 2011 10:10:29 -0700
Keith Packard wrote:
> Hotplug detection is a mode setting operation and must hold the
> struct_mutex or risk colliding with other mode setting operations.
>
> In particular, the display port hotplug function attempts to re-train
> the link if the monitor is su
On Mon, 25 Jul 2011 10:10:29 -0700
Keith Packard wrote:
> Hotplug detection is a mode setting operation and must hold the
> struct_mutex or risk colliding with other mode setting operations.
>
> In particular, the display port hotplug function attempts to re-train
> the link if the monitor is su
Hotplug detection is a mode setting operation and must hold the
struct_mutex or risk colliding with other mode setting operations.
In particular, the display port hotplug function attempts to re-train
the link if the monitor is supposed to be running when plugged back
in. If that happens while mod
Hotplug detection is a mode setting operation and must hold the
struct_mutex or risk colliding with other mode setting operations.
In particular, the display port hotplug function attempts to re-train
the link if the monitor is supposed to be running when plugged back
in. If that happens while mod
On Mon, Jul 25, 2011 at 3:18 AM, Joonyoung Shim wrote:
> 2011/7/22 Jesse Barnes :
>> On Thu, 21 Jul 2011 19:30:00 +0900
>> Joonyoung Shim wrote:
>>
>>> Hi,
>>>
>>> simple questions :)
>>>
>>> 2011/6/21 Jesse Barnes :
>>> > Planes are a bit like half-CRTCs. ?They have a location and fb, but
>>> >
From: Jerome Glisse
DPEncoderService newer than 1.1 can't properly program the DP (display port)
link training. When facing such version use the DIGxEncoderControl method
instead. Fix DP link training on some R7XX.
Signed-off-by: Jerome Glisse
Reviewed-by: Alex Deucher
Cc: sta...@kernel.org
--
On Mon, Jul 25, 2011 at 3:18 AM, Joonyoung Shim wrote:
> 2011/7/22 Jesse Barnes :
>> On Thu, 21 Jul 2011 19:30:00 +0900
>> Joonyoung Shim wrote:
>>
>>> Hi,
>>>
>>> simple questions :)
>>>
>>> 2011/6/21 Jesse Barnes :
>>> > Planes are a bit like half-CRTCs. They have a location and fb, but
>>> >
https://bugs.freedesktop.org/show_bug.cgi?id=39513
--- Comment #1 from Alex Deucher 2011-07-25 06:00:26 PDT ---
What kernel are you using? I added support for sensor chips on combios boards
in 3.0.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=39513
--- Comment #1 from Alex Deucher 2011-07-25 06:00:26 PDT
---
What kernel are you using? I added support for sensor chips on combios boards
in 3.0.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rece
On Tue, Jul 5, 2011 at 9:12 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> The same way it was already done for r300.
>
> Also fix typo in gart warning messages.
Causes a new warning per line on x86-64 build.
dma_addr_t doesn't go into %08x.
Dave.
__
Ping ?
As stated in my previous mail, I'd like to reach an agreement on the API, and
implement it. I'm fine with either grayscale or nonstd to store the FOURCC
(with a slight preference for grayscale), and with either a vmode flag or
using the most significant byte of the grayscale/nonstd field
2011/7/22 Jesse Barnes :
> On Thu, 21 Jul 2011 19:30:00 +0900
> Joonyoung Shim wrote:
>
>> Hi,
>>
>> simple questions :)
>>
>> 2011/6/21 Jesse Barnes :
>> > Planes are a bit like half-CRTCs. They have a location and fb, but
>> > don't drive outputs directly. Add support for handling them to the
48 matches
Mail list logo
