Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.
VBT doesn't provide any values for T1 or T2, so we'll alw
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.
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.
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
l.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/20110919/51a157a2/attachment-0001.pgp>
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
achments/20110919/68b89281/attachment.pgp>
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
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(
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.
>
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.
> -Original Message-
> From: Rob Clark [mailto:robdclark at gmail.com] On Behalf Of Rob Clark
> Sent: Sunday, September 18, 2011 6:32 AM
> To: dri-devel at lis
https://bugs.freedesktop.org/show_bug.cgi?id=39320
Michal Suchanek changed:
What|Removed |Added
Attachment #51377|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=39320
Michal Suchanek changed:
What|Removed |Added
Attachment #51377|text/x-log |text/plain
mime type|
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
--- 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
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
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
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
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
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
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 +
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
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 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
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@
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
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
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
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
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
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 +
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
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 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
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.
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
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
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
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(
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
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
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=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=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
Attachment #51369|text/x-log |text/plain
mime type|
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=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
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
Summary: DPMS doesn't work correctly
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
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
Hello, Konrad Rzeszutek Wilk.
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk at oracle.com]
> Sent: Thursday, September 15, 2011 11:15 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> sw0312.kim at samsung.com; kyungmin.park at sams
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=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=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
--
On Fri, 2011-09-16 at 17:53 +0100, Alan Cox wrote:
> > I'm not sure a common interface to all of these different
> > channels makes sense, but surely a DSI library and an aux channel
> > library would fit nicely alongside the existing DDC library.
>
> DSI and the various other MIPI bits tend to be
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=41002
Fabian Deutsch changed:
What|Removed |Added
Summary|Switching doesn't work |Switching doesn't work
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
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=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
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
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=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
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=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
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
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.
>
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
https://bugs.freedesktop.org/show_bug.cgi?id=34218
Pavel Ondračka changed:
What|Removed |Added
Summary|[r300g] Unigine Sanctuary: |[r300g] Unigine: some
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
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
74 matches
Mail list logo
