SPD frames are actually type 0x83, not just 0x3.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b330e7..756f3b9 100644
--- a/driv
Misc fixes based on tests with an infoframe analyzer:
- checksum *does* include header bytes
- DIP enable & AVI infoframe are tied together in hw, so disable both
and make sure AVI frames are enabled first
- use every vsync flag for SPD frames to avoid reserved value in
frequency fiel
DPCD 1.1+ adds some automated test infrastructure support. Add support
for reading the IRQ source and jumping to a test handling routine if
needed. Subsequent patches will handle particular tests; this patch
just ACKs any requested tests by default.
Signed-off-by: Jesse Barnes
---
drivers/gpu/
These aren't actually needed for correct functionality and can speed up
boot and resume a bit.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_lvds.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/i
Read link status first, followed by the full DPCD receiver cap field
rather than just the first 8 bytes.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_irq.c |2 ++
drivers/gpu/drm/i915/intel_dp.c |4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/
Using some test equipment here in Banaglore, I came up with the
following fixes. Also, it sounds like we can skip the PP_ON waits in
the LVDS code to speed up boot & resume, but that change needs lots of
soak time before I'll be happy pushing it upstream (works here though).
Thanks,
Jesse
__
Cc: Daniel Vetter
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c |1 +
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem.c | 23 +++
include/drm/i915_drm.h |7 +++
4 files changed, 33 insertions(+), 0 deletions(-
Daniel Vetter
Signed-off-by: Ben Widawsky
---
include/drm/i915_drm.h |7 +++
intel/intel_bufmgr_gem.c | 36 ++--
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index adc2392..4b6 1006
The drm patch goes on top of Daniel's patch. I'll squash before pushing,
it's just separate for review.
The kernel stuff is straight forward, just an IOCTL to query the cache
level.
Both patches will get better commit messages when resubmitted.
I ran a modified version of the test I posted earli
This adds a new mode to map gem objects in a non-blocking way.
The new kernel interface required to get the caching level/coherency
is not yet wired up. All the code to transparently choose between gtt
mappings or (if coherent) cpu mappings is already in place, though.
To make this useable for me
On Wed, 21 Sep 2011 10:19:13 +0200, Daniel Vetter
wrote:
> This adds a new mode to map gem objects in a non-blocking way. This
> needs to be enabled on a per-object basis with object_enable_nonblocking.
>
> The new kernel interface required to get the caching level/coherency
> is not yet wired u
On Wed, 21 Sep 2011 18:15:27 +0200, Rainer Dorsch wrote:
> Since I can ssh into the machine, when the problem occurs, are there some
> diagnosis scripts/tools I could run?
Hrm. As far as I can tell, we're turning on the monitor successfully.
You might try playing with xrandr over ssh to make s
On Wed, 21 Sep 2011 17:13:30 +0100, Simon Farnsworth
wrote:
> Signed-off-by: Simon Farnsworth
Looks good to me.
Reviewed-by: Keith Packard
Thanks again for your patience.
--
keith.pack...@intel.com
pgpEsqK5UiTRT.pgp
Description: PGP signature
On Wednesday 21 September 2011, Rainer Dorsch wrote:
>
> Are you refereing to the mail from Simon from yesterday:
>
> [Intel-gfx] [PATCHv5] drm/i915: Enable SDVO hotplug interrupts for HDMI and
> DVI
>
> ?
>
> Do you expect that it can be applied to a Linux 3.0 kernel?
>
I've just sent a v6 o
Keith,
many thanks for the quick and useful reply.
Am Wednesday, 21. September 2011 schrieb Keith Packard:
> On Wed, 21 Sep 2011 14:23:01 +0200, Rainer Dorsch wrote:
> > Hello,
> >
> > after resuming my graphics card sometimes does not come up (see my post
> > yesterday).
> >
> > Comparing drm
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
Note that this i
On Wed, 21 Sep 2011 15:49:07 +0100
Chris Wilson wrote:
> On Wed, 21 Sep 2011 07:25:03 -0700, Ben Widawsky
> wrote:
> > On Wed, 21 Sep 2011 12:42:22 +0100
> > Chris Wilson wrote:
> > > ---
> > > drivers/gpu/drm/i915/intel_ringbuffer.c |3 ++-
> > > 1 files changed, 2 insertions(+), 1 deleti
On Wed, 21 Sep 2011 16:18:55 +0100, Simon Farnsworth
wrote:
> I'm ANDing the value returned by hardware with 3 - I should be ANDing it with
> an appropriate ~3. The rest of the code (setting those bits in
> intel_sdvo_dvi_init based on what functions I have) should be OK.
Oh, that's a good po
On Wed, 21 Sep 2011 14:23:01 +0200, Rainer Dorsch wrote:
> Hello,
>
> after resuming my graphics card sometimes does not come up (see my post
> yesterday).
>
> Comparing drm outputs with drm.debug=6 in syslog reveals among others
>
> [drm:intel_crt_detect], CRT not detected via hotplug
On Wednesday 21 September 2011, Keith Packard wrote:
> On Wed, 21 Sep 2011 10:08:13 +0100, Simon Farnsworth
wrote:
> > I'm clearing the bits (&= not |=). I could respin setting it to 0, but
> > that takes me even further from the old (commented out) code, and I'd
> > really want someone to check
On Wed, 21 Sep 2011 10:08:13 +0100, Simon Farnsworth
wrote:
> I'm clearing the bits (&= not |=). I could respin setting it to 0, but that
> takes me even further from the old (commented out) code, and I'd really want
> someone to check SDVO specs before doing that.
What I see the code doing i
On Wed, 21 Sep 2011 07:25:03 -0700, Ben Widawsky wrote:
> On Wed, 21 Sep 2011 12:42:22 +0100
> Chris Wilson wrote:
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>
On Wed, 21 Sep 2011 12:42:22 +0100
Chris Wilson wrote:
> In addition to telling the GPU that we are comparing with a named MMIO
> register, we also apparently have to tell the GPU the address of that
> register.
>
> The lack of giving the GPU the duplicate information it seems to
> desire leads
On Wed, 21 Sep 2011 14:46:47 +0200, Daniel Vetter wrote:
> On Wed, Sep 21, 2011 at 12:42:22PM +0100, Chris Wilson wrote:
> > In addition to telling the GPU that we are comparing with a named MMIO
> > register, we also apparently have to tell the GPU the address of that
> > register.
>
> Unfortuna
On Wed, Sep 21, 2011 at 12:42:22PM +0100, Chris Wilson wrote:
> In addition to telling the GPU that we are comparing with a named MMIO
> register, we also apparently have to tell the GPU the address of that
> register.
Unfortunately this still doesn't fix the hard hangs on my kde on snb :(
But at
In addition to telling the GPU that we are comparing with a named MMIO
register, we also apparently have to tell the GPU the address of that
register.
The lack of giving the GPU the duplicate information it seems to desire
leads to such fun confusion as:
Blitter command stream:
seqno: 0x1c6
Hello,
after resuming my graphics card sometimes does not come up (see my post
yesterday).
Comparing drm outputs with drm.debug=6 in syslog reveals among others
[drm:intel_crt_detect], CRT not detected via hotplug hotplug"
Does that mean that the monitor (EIZO FlexScan L767) is not re
This adds a new mode to map gem objects in a non-blocking way. This
needs to be enabled on a per-object basis with object_enable_nonblocking.
The new kernel interface required to get the caching level/coherency
is not yet wired up. All the code to transparently choose between gtt
mappings or (if c
On Tuesday 20 September 2011, Keith Packard wrote:
> On Tue, 20 Sep 2011 18:31:25 +0100, Simon Farnsworth
wrote:
> > + /* Set up hotplug command - note paranoia about contents of reply.
> > +* We simply clear out the bits we understand, and hope that
> > +* the rest are in good shape f
On Tue, Sep 20, 2011 at 03:19:53PM -0700, Ben Widawsky wrote:
> On Tue, 20 Sep 2011 13:06:43 +0200
> Daniel Vetter wrote:
> > - I'm sorry having suggested to implement the clflush ioctl, I think
> > it's a foolish idea, now. Non-blocking mmaps is a performance
> > optimization, needing to sync cac
On Tue, Sep 20, 2011 at 10:16:39PM +0100, Chris Wilson wrote:
> On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter wrote:
> > Now non-blocking cpu mmaps make very much sense on llc/snooped buffer
> > objects. So I think we actually need an ioctl to get obj->cache_level so
> > userspace can de
31 matches
Mail list logo
