https://bugs.freedesktop.org/show_bug.cgi?id=35861
--- Comment #3 from Pavel Ondračka 2011-09-19
00:05:34 PDT ---
Created an attachment (id=51327)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51327)
Oilrush output with RADEON_DEBUG=vp
(In reply to comment #2)
> Is this still an issue wi
https://bugs.freedesktop.org/show_bug.cgi?id=34218
Pavel Ondračka changed:
What|Removed |Added
Summary|[r300g] Unigine Sanctuary: |[r300g] Unigine: some
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote:
> On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
> wrote:
>
> > I think it's a bit more complex than that. True, there are MIPI
> > standards, for the video there are DPI, DBI, DSI, and for the commands
> > there is DCS. And, as you men
2011/6/21 Jesse Barnes :
> This version adds both source and dest rect params to the set_plane
> ioctl, and makes the source fixed point to support hardware that needs
> it.
>
> I haven't changed the name of the SNB implementation yet (per Chris's
> suggestions) but will before it gets upstream.
>
https://bugs.freedesktop.org/show_bug.cgi?id=29951
--- Comment #7 from Chris Rankin 2011-09-19 01:29:22
PDT ---
(In reply to comment #6)
> I just tested this with the latest version from git, and it appears to be
> working. Can you confirm this?
Sorry, it's not fixed yet. I ran antspotlight ab
Hi Linus,
Some fixes for page size mismatches in radeon, a lockdep noticed locking
problem, and a fix to zero some memory that was being passed to userspace.
Dave.
The following changes since commit 003f6c9df54970d8b19578d195b3e2b398cdbde2:
lib/sha1.c: quiet sparse noise about symbol not de
https://bugs.freedesktop.org/show_bug.cgi?id=41002
Summary: Switching doesn't work between plymouth and xorg.
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: med
https://bugs.freedesktop.org/show_bug.cgi?id=40935
--- Comment #4 from Michal Suchanek 2011-09-19 04:21:10
PDT ---
It's a redwood.
The bootup dmesg is below the locup messages.
I am not sure what dev_err() would be.
And now I rebooted and tried to kill Xorg with suspend and it would not lock
On Mon, Sep 19, 2011 at 2:44 AM, Inki Dae wrote:
> Hello Rob.
>
> Is there some reason that you don't head your driver gpu/drm, just staging?
> and below is my short comments. thank you.
>
mainly because it is still a work-in-progress.. I expect some
re-shuffling of the mode-setting code when drm
https://bugs.freedesktop.org/show_bug.cgi?id=41002
Fabian Deutsch changed:
What|Removed |Added
Summary|Switching doesn't work |Switching doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #7 from Michal Suchanek 2011-09-19 09:39:58
PDT ---
According to apitrace author the glretrace crash is due to gallium reading more
data than is in the buffer.
https://github.com/apitrace/apitrace/issues/39#issuecomment-2134199
--
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Summary: DPMS doesn't work correctly
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41019
--- Comment #1 from Wojciech Pyczak 2011-09-19 11:56:00
PDT ---
Created an attachment (id=51370)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51370)
Xorg log..
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Alex Deucher changed:
What|Removed |Added
Attachment #51369|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=28847
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #8 from Marek Olšák 2011-09-19 12:44:51 PDT ---
Created an attachment (id=51371)
View: https://bugs.freedesktop.org/attachment.cgi?id=51371
Review: https://bugs.freedesktop.org/review?bug=39320&attachment=51371
print debug info
I
From: Dave Airlie
This just adds a tracepoint that can be caught in perf for when the clocks
change.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c|3 +++
drivers/gpu/drm/radeon/radeon_trace.h | 18 ++
2 files changed, 21 insertions(+), 0 deletions(
From: Dave Airlie
If we add more options in the future this will need rework.
this is modelled after the example in /sys/power/disk.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #9 from Michal Suchanek 2011-09-19 14:52:19
PDT ---
I get this extra output:
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u
Here's a sequence of eDP patches which are necessary to make the
driver work on the Sandybridge MacBook Air
The key trick was to make sure that the eDP power was applied before
trying to communicate with the device.
___
dri-devel mailing list
dri-devel@
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/dr
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..f0c
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertion
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 +
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 delet
The eDP panel may not be able to respond to aux channel communications
unless it has power supplied. During mode setting, power may be
cut-off during panel power sequencing. Make sure that any aux channel
communications will work by forcing vdd power active as needed.
This also delays after turnin
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respecte
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #10 from Michal Suchanek 2011-09-19 15:36:08
PDT ---
Created an attachment (id=51377)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51377)
backtrace of glretrace
backtrace of glretrace on older unpatched mesa
--
Configure b
https://bugs.freedesktop.org/show_bug.cgi?id=39320
Michal Suchanek changed:
What|Removed |Added
Attachment #51377|text/x-log |text/plain
mime type|
This is a single patch which cleans up almost all of the whitespace
errors in the i915 driver. It currently merges cleanly with your fdo
drm-core-next tree.
I've checked this patch quite carefully, examining the .o files with
objdump -s to make sure nothing significant changed. The only thing tha
I've created a (temporary?) git repository for the drm/i915 driver at
git://people.freedesktop.org/~keithp/linux
This has the drm-intel-next and drm-intel-fixes branches, and may also
have occasional temporary branches with code which has not been merged yet.
--
keith.pack...@intel.com
pgp1w
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for everything except Ironlake where it has been
seen to cause trouble with screen updates.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915/intel_display.
https://bugs.freedesktop.org/show_bug.cgi?id=35861
--- Comment #3 from Pavel Ondračka 2011-09-19
00:05:34 PDT ---
Created an attachment (id=51327)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51327)
Oilrush output with RADEON_DEBUG=vp
(In reply to comment #2)
> Is this still an issue wi
https://bugs.freedesktop.org/show_bug.cgi?id=34218
Pavel Ondračka changed:
What|Removed |Added
Summary|[r300g] Unigine Sanctuary: |[r300g] Unigine: some
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote:
> On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
> wrote:
>
> > I think it's a bit more complex than that. True, there are MIPI
> > standards, for the video there are DPI, DBI, DSI, and for the commands
> > there is DCS. And, as you men
2011/6/21 Jesse Barnes :
> This version adds both source and dest rect params to the set_plane
> ioctl, and makes the source fixed point to support hardware that needs
> it.
>
> I haven't changed the name of the SNB implementation yet (per Chris's
> suggestions) but will before it gets upstream.
>
https://bugs.freedesktop.org/show_bug.cgi?id=29951
--- Comment #7 from Chris Rankin 2011-09-19 01:29:22
PDT ---
(In reply to comment #6)
> I just tested this with the latest version from git, and it appears to be
> working. Can you confirm this?
Sorry, it's not fixed yet. I ran antspotlight ab
Hi Linus,
Some fixes for page size mismatches in radeon, a lockdep noticed locking
problem, and a fix to zero some memory that was being passed to userspace.
Dave.
The following changes since commit 003f6c9df54970d8b19578d195b3e2b398cdbde2:
lib/sha1.c: quiet sparse noise about symbol not de
https://bugs.freedesktop.org/show_bug.cgi?id=41002
Summary: Switching doesn't work between plymouth and xorg.
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: med
https://bugs.freedesktop.org/show_bug.cgi?id=40935
--- Comment #4 from Michal Suchanek 2011-09-19 04:21:10
PDT ---
It's a redwood.
The bootup dmesg is below the locup messages.
I am not sure what dev_err() would be.
And now I rebooted and tried to kill Xorg with suspend and it would not lock
On Mon, Sep 19, 2011 at 2:44 AM, Inki Dae wrote:
> Hello Rob.
>
> Is there some reason that you don't head your driver gpu/drm, just staging?
> and below is my short comments. thank you.
>
mainly because it is still a work-in-progress.. I expect some
re-shuffling of the mode-setting code when drm
https://bugs.freedesktop.org/show_bug.cgi?id=41002
Fabian Deutsch changed:
What|Removed |Added
Summary|Switching doesn't work |Switching doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #7 from Michal Suchanek 2011-09-19 09:39:58
PDT ---
According to apitrace author the glretrace crash is due to gallium reading more
data than is in the buffer.
https://github.com/apitrace/apitrace/issues/39#issuecomment-2134199
--
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Summary: DPMS doesn't work correctly
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41019
--- Comment #1 from Wojciech Pyczak 2011-09-19 11:56:00
PDT ---
Created an attachment (id=51370)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51370)
Xorg log..
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Alex Deucher changed:
What|Removed |Added
Attachment #51369|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=28847
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #8 from Marek Olšák 2011-09-19 12:44:51 PDT ---
Created an attachment (id=51371)
View: https://bugs.freedesktop.org/attachment.cgi?id=51371
Review: https://bugs.freedesktop.org/review?bug=39320&attachment=51371
print debug info
I
From: Dave Airlie
This just adds a tracepoint that can be caught in perf for when the clocks
change.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c|3 +++
drivers/gpu/drm/radeon/radeon_trace.h | 18 ++
2 files changed, 21 insertions(+), 0 deletions(
From: Dave Airlie
If we add more options in the future this will need rework.
this is modelled after the example in /sys/power/disk.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #9 from Michal Suchanek 2011-09-19 14:52:19
PDT ---
I get this extra output:
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u
Here's a sequence of eDP patches which are necessary to make the
driver work on the Sandybridge MacBook Air
The key trick was to make sure that the eDP power was applied before
trying to communicate with the device.
___
dri-devel mailing list
dri-devel@
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/dr
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..f0c
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertion
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 +
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 delet
The eDP panel may not be able to respond to aux channel communications
unless it has power supplied. During mode setting, power may be
cut-off during panel power sequencing. Make sure that any aux channel
communications will work by forcing vdd power active as needed.
This also delays after turnin
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respecte
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #10 from Michal Suchanek 2011-09-19 15:36:08
PDT ---
Created an attachment (id=51377)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51377)
backtrace of glretrace
backtrace of glretrace on older unpatched mesa
--
Configure b
https://bugs.freedesktop.org/show_bug.cgi?id=39320
Michal Suchanek changed:
What|Removed |Added
Attachment #51377|text/x-log |text/plain
mime type|
This is a single patch which cleans up almost all of the whitespace
errors in the i915 driver. It currently merges cleanly with your fdo
drm-core-next tree.
I've checked this patch quite carefully, examining the .o files with
objdump -s to make sure nothing significant changed. The only thing tha
I've created a (temporary?) git repository for the drm/i915 driver at
git://people.freedesktop.org/~keithp/linux
This has the drm-intel-next and drm-intel-fixes branches, and may also
have occasional temporary branches with code which has not been merged yet.
--
keith.pack...@intel.com
pgp1w
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for everything except Ironlake where it has been
seen to cause trouble with screen updates.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915/intel_display.
https://bugs.freedesktop.org/show_bug.cgi?id=35861
--- Comment #3 from Pavel Ondračka 2011-09-19
00:05:34 PDT ---
Created an attachment (id=51327)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51327)
Oilrush output with RADEON_DEBUG=vp
(In reply to comment #2)
> Is this still an issue wi
https://bugs.freedesktop.org/show_bug.cgi?id=34218
Pavel Ondračka changed:
What|Removed |Added
Summary|[r300g] Unigine Sanctuary: |[r300g] Unigine: some
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote:
> On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
> wrote:
>
> > I think it's a bit more complex than that. True, there are MIPI
> > standards, for the video there are DPI, DBI, DSI, and for the commands
> > there is DCS. And, as you men
2011/6/21 Jesse Barnes :
> This version adds both source and dest rect params to the set_plane
> ioctl, and makes the source fixed point to support hardware that needs
> it.
>
> I haven't changed the name of the SNB implementation yet (per Chris's
> suggestions) but will before it gets upstream.
>
https://bugs.freedesktop.org/show_bug.cgi?id=29951
--- Comment #7 from Chris Rankin 2011-09-19 01:29:22
PDT ---
(In reply to comment #6)
> I just tested this with the latest version from git, and it appears to be
> working. Can you confirm this?
Sorry, it's not fixed yet. I ran antspotlight ab
Hi Linus,
Some fixes for page size mismatches in radeon, a lockdep noticed locking
problem, and a fix to zero some memory that was being passed to userspace.
Dave.
The following changes since commit 003f6c9df54970d8b19578d195b3e2b398cdbde2:
lib/sha1.c: quiet sparse noise about symbol not de
https://bugs.freedesktop.org/show_bug.cgi?id=41002
Summary: Switching doesn't work between plymouth and xorg.
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: med
https://bugs.freedesktop.org/show_bug.cgi?id=40935
--- Comment #4 from Michal Suchanek 2011-09-19 04:21:10
PDT ---
It's a redwood.
The bootup dmesg is below the locup messages.
I am not sure what dev_err() would be.
And now I rebooted and tried to kill Xorg with suspend and it would not lock
On Mon, Sep 19, 2011 at 2:44 AM, Inki Dae wrote:
> Hello Rob.
>
> Is there some reason that you don't head your driver gpu/drm, just staging?
> and below is my short comments. thank you.
>
mainly because it is still a work-in-progress.. I expect some
re-shuffling of the mode-setting code when drm
https://bugs.freedesktop.org/show_bug.cgi?id=41002
Fabian Deutsch changed:
What|Removed |Added
Summary|Switching doesn't work |Switching doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #7 from Michal Suchanek 2011-09-19 09:39:58
PDT ---
According to apitrace author the glretrace crash is due to gallium reading more
data than is in the buffer.
https://github.com/apitrace/apitrace/issues/39#issuecomment-2134199
--
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Summary: DPMS doesn't work correctly
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41019
--- Comment #1 from Wojciech Pyczak 2011-09-19 11:56:00
PDT ---
Created an attachment (id=51370)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51370)
Xorg log..
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Alex Deucher changed:
What|Removed |Added
Attachment #51369|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=28847
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41019
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #8 from Marek Olšák 2011-09-19 12:44:51 PDT ---
Created an attachment (id=51371)
View: https://bugs.freedesktop.org/attachment.cgi?id=51371
Review: https://bugs.freedesktop.org/review?bug=39320&attachment=51371
print debug info
I
From: Dave Airlie
This just adds a tracepoint that can be caught in perf for when the clocks
change.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c|3 +++
drivers/gpu/drm/radeon/radeon_trace.h | 18 ++
2 files changed, 21 insertions(+), 0 deletions(
From: Dave Airlie
If we add more options in the future this will need rework.
this is modelled after the example in /sys/power/disk.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #9 from Michal Suchanek 2011-09-19 14:52:19
PDT ---
I get this extra output:
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u_vbuf_upload_buffers
u
Here's a sequence of eDP patches which are necessary to make the
driver work on the Sandybridge MacBook Air
The key trick was to make sure that the eDP power was applied before
trying to communicate with the device.
___
dri-devel mailing list
dri-devel@
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/dr
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..f0c
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertion
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 +
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 delet
The eDP panel may not be able to respond to aux channel communications
unless it has power supplied. During mode setting, power may be
cut-off during panel power sequencing. Make sure that any aux channel
communications will work by forcing vdd power active as needed.
This also delays after turnin
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respecte
1 - 100 of 210 matches
Mail list logo
