On Wed, 29 Dec 2010 22:11:09 +0100
Alex Riesen wrote:
> On Wed, Dec 29, 2010 at 21:16, Jesse Barnes
> wrote:
> > On Wed, 29 Dec 2010 11:40:04 -0800
> > Linus Torvalds wrote:
> >> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
> >> we
e bug, looks like it is panel power
related. Can you try this patch?
If it doesn't work, can you send me the output of intel_reg_dumper from
before you turn off the display and after you try to turn it back on?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drive
if (IS_I85X(dev))
> >
> >
> > --
>
> Ugh, looks like I have confused things horribly. Sorry about this.
>
> 2.6.37-rc8 with no patches works for me. My original report was incorrect --
> I was using -rc7 when I thought I was using -rc8. :(
Can you confirm that the above doesn't break your setup just in case we
need to apply it?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 30 Dec 2010 00:09:56 +0100
Alex Riesen wrote:
> On Wed, Dec 29, 2010 at 22:53, Jesse Barnes
> wrote:
> >> > Doesn't change anything here. Display stays blank.
> >>
> >> Sounds like your problem is separate from SSC then, more likely related
On Thu, 30 Dec 2010 00:35:15 +0100
Alex Riesen wrote:
> On Thu, Dec 30, 2010 at 00:20, Alex Riesen wrote:
> > On Thu, Dec 30, 2010 at 00:13, Jesse Barnes
> > wrote:
> >>> After closing and opening the lid (displays backlight is back)
> >>>
>
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT)
Jeff Chua wrote:
>
> On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes
> wrote:
>
> > Randy, Jeff and Alex, does the below help at all? If so, it may be the
> > minimal fix we want for 2.6.37.
>
> Jesse,
>
> Yes, t
Emit a trace point for vblank events. This can be helpful for mapping
drawing activity against the vblank frequency and period.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/Makefile |5 +++-
drivers/gpu/drm/drm_irq.c |3 ++
drivers/gpu/drm/drm_trace.h
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files changed, 53 insertions
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_trace.h| 36 ++
drivers/gpu/drm/i915/intel_display.c |5
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915
ow it won't light up" bug).
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3779d2..32f67cb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -315,8 +315,9 @@ static void drm_fb_helper_on(s
f. Much of the
drm source has doxygen rather than kdoc style comments though, I need
to clean those up before I can actually include the source generated
info in the drm.tmpl.
--
Jesse Barnes, Intel Open Source Technology Center
es should be
> kept opaque to the kernel as well and left open to interpretation by
> userland. What I am most unclear about is under which circumstances is
> this backchannel communication preferable to passing the extra information
> over the IPC that needs to be performed anyway in
iguration into something they couldn't change. :)
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
Make drm_edid_read take a new argument, edid_read, to allow drivers to
provide their own EDID fetch routine. Export the bit banging DDC over
i2c version of the EDID fetching routine and make the drivers use it.
This sets the stage for GMBUS support in the Intel driver.
Signed-off-by: Jesse
Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC. The hope is that this method will be more reliable than bit
banging for fetching EDIDs from buggy monitors or through switches.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h| 52
On Wed, 21 Jul 2010 08:54:30 +1000
Dave Airlie wrote:
> On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > Make drm_edid_read take a new argument, edid_read, to allow drivers to
> > provide their own EDID fetch routine. Export the bit banging DDC over
> > i2
On Wed, 21 Jul 2010 09:27:54 +1000
Dave Airlie wrote:
> On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > On Wed, 21 Jul 2010 08:54:30 +1000
> > Dave Airlie wrote:
> >
> > > On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > > &
On Tue, 20 Jul 2010 16:34:39 -0700
Jesse Barnes wrote:
> On Wed, 21 Jul 2010 09:27:54 +1000
> Dave Airlie wrote:
>
> > On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > > On Wed, 21 Jul 2010 08:54:30 +1000
> > > Dave Airlie wrote:
> > >
On Sun, 6 Jun 2010 17:36:24 +0100 (BST)
James Simmons wrote:
>
> > On Fri, 9 Apr 2010 15:10:50 -0700
> > Jesse Barnes wrote:
> >
> > > This set of 3 patches makes it a little more likely we'll get panic
> > > output onto the screen even when X is
ic daily tests? To unload you need to unbind the fbcon interface
first, my script is like this:
echo 0 > /sys/class/vtconsole/vtcon1/bind
rmmod i915
rmmod drm_kms_helper
rmmod drm
modprobe i915
echo 1 > /sys/class/vtconsole/vtcon1/bind
If unload and re-load doesn't work please file a bug and see if you can
bisect it.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Fri, 9 Apr 2010 15:10:50 -0700
Jesse Barnes wrote:
> This set of 3 patches makes it a little more likely we'll get panic
> output onto the screen even when X is running, assuming a KMS enabled
> stack anyway.
>
> It gets me from a blank or very sparsely populated black sc
On Thu, 20 May 2010 04:27:07 +0300
Maxim Levitsky wrote:
> On Thu, 2010-05-20 at 04:13 +0300, Maxim Levitsky wrote:
> > On Wed, 2010-05-19 at 17:34 -0700, Jesse Barnes wrote:
> > > On Fri, 9 Apr 2010 15:10:50 -0700
> > > Jesse Barnes wrote:
> > >
>
On Sat, 22 May 2010 00:57:30 +0300
Maxim Levitsky wrote:
> On Fri, 2010-05-21 at 00:14 +0300, Maxim Levitsky wrote:
> > On Thu, 2010-05-20 at 09:28 -0700, Jesse Barnes wrote:
> > > On Thu, 20 May 2010 04:27:07 +0300
> > > Maxim Levitsky wrote:
> > >
>
NTROL;
Hah yeah that's a good one, thanks for the fix.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
Add structs and functions necessary for the new plane and fb handling code,
including a new header, drm_fourcc.h, that includes the surface formats
supported by various DRM drivers.
Signed-off-by: Jesse Barnes
---
include/drm/Makefile.am |1 +
include/drm/drm.h| 13 -
include
On Tue, 6 Dec 2011 15:23:57 -0800
Jesse Barnes wrote:
> Add structs and functions necessary for the new plane and fb handling code,
> including a new header, drm_fourcc.h, that includes the surface formats
> supported by various DRM drivers.
>
> Signed-off-by: Jesse Barnes
Import the current kernel bits into libdrm for client code.
Signed-off-by: Jesse Barnes
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 43695bd..2923ab4 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -26,6 +26,7 @@ klibdrmincludedir = ${includedir
tian has a few patches outstanding for CEA mode handling.
Getting them in makes sense to me and this patch looks like it's
structured nicely at least (I haven't checked the CEA bits against the
specs though).
Any chance we can get them included for 3.3?
Thanks,
--
Jesse Barnes, Intel Open
ed out was that you don't
seem to be validating the zpos ioctl parameters for sanity. Not sure
if there's much to do, but it may be worth checking for a max zpos or
something...
--
Jesse Barnes, Intel Open Source Technology Center
hang?
>
> No, it doesn't have any effect.
Yeah I don't think we use that flag for rc6, though we probably should.
The bisect is interesting, I'd have expected a failure when we
re-enabled rc6 on ILK or when we fixed up the ring buffer init.
The cleanup patch should be just t
On Tue, 01 Feb 2011 16:57:37 +
Chris Wilson wrote:
> On Tue, 1 Feb 2011 08:31:12 -0800, Jesse Barnes
> wrote:
> > The bisect is interesting, I'd have expected a failure when we
> > re-enabled rc6 on ILK or when we fixed up the ring buffer init.
>
> Yes,
rtly.
reverting the cleanup wasn't sufficient?
Francesco, if you revert the cleanup patch you bisected to, what
does /sys/kernel/debug/dri/0/i915_drpc_info report?
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 9 Feb 2011 09:50:47 -0800
Jesse Barnes wrote:
> On Wed, 09 Feb 2011 17:09:10 +
> Chris Wilson wrote:
>
> > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > gmail.com> wrote:
> > > On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote:
On Wed, 9 Feb 2011 09:53:26 -0800
Jesse Barnes wrote:
> On Wed, 9 Feb 2011 09:50:47 -0800
> Jesse Barnes wrote:
>
> > On Wed, 09 Feb 2011 17:09:10 +
> > Chris Wilson wrote:
> >
> > > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > >
>
> > That should work its way upstream shortly.
>
> I've tried to apply it on top of 2.6.38-rc4, and now it doesn't hang
> when I start X, but it hangs when I resume from suspend to RAM.
Since intel_reg_read won't work, can you try this patch instead? Just
patch
On Fri, 11 Feb 2011 00:23:09 +0100
Francesco Allertsen wrote:
> On Thu, Feb 10, 2011 at 10:34:43AM -0800, Jesse Barnes wrote:
> > Since intel_reg_read won't work, can you try this patch instead? Just
> > patch it in, then cat /sys/kernel/debug/dri/0/i915_drpc_info
>
On Fri, 11 Feb 2011 08:28:37 +0100
Francesco Allertsen wrote:
> On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
> > Does this kernel have the problem patch included? Or is it reverted?
>
> That was without the patch reverted, now I've reverted it and
t to the one set before closing the lid).
>
> It is this bug, I believe:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=25072
>
> I somehow missed it at first, and only noticed after sending the patch.
There's also this patch: https://patchwork.kernel.org/patch/499221/.
On Wed, 16 Feb 2011 20:59:35 +0100
Alex Riesen wrote:
> On Wed, Feb 16, 2011 at 20:54, Jesse Barnes
> wrote:
> > On Wed, 16 Feb 2011 20:46:45 +0100
> > Alex Riesen wrote:
> >> > The backlight level on this Dell XPS M1330 reduces every time I reopen
> >&g
> > Tested-by: Alex Riesen
>
> Guys, should I apply this, or will I get it through somebody's pull?
I'm worried that removing combo mode will break some working setups,
but if it's seen a lot of testing and is ok, then I'm fine with it, as
it definitely simplifies things.
--
Jesse Barnes, Intel Open Source Technology Center
the server also fill these needs? It would be a
bigger API, but presumably would allow us to share fbs between early
boot and subsequent, accelerated usage. We'd still need to settle on
the basic allocation API, but we seem to manage that on the server
side...
--
Jesse Barnes, Intel Open Source Technology Center
ersave=0 help any?
>
>Dave.
Arg. It's been ok on my ILK systems, but Chris has found some issues with out
watermarking code iirc; apparently we're underflowing the display FIFO, causing
all sorts of trouble. If it works before the pull of Dave's tree, can you
bisect?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
o trigger the watermark related issues
you've found?
--
Jesse Barnes, Intel Open Source Technology Center
On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes
> wrote:
> >
> > Have you tried reproducing it using xset dpms force off or similar?
>
> That doesn't seem to do anything bad.
>
> In fact, I think the
27;re actually offloading to our video decode kernels for
Flash video on your machine, it could very well be a memory bw issue.
Can you try this small patch to see if one of the low power watermarks
is giving you trouble (note: cut & pasted)?
It could also be the normal power watermarks though to
On Wed, 12 Jan 2011 13:28:53 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
> wrote:
> > On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes > virtuousgeek.org> wrote:
> >>
> >> Since I doubt we're actually offloading to our
On Wed, 12 Jan 2011 14:31:33 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes
> wrote:
> >
> > Ah, ok. ?So it could be our internal FDI link is underrunning; it goes
> > between the CPU and PCH and carries display bits.
>
> I'm no
On Sat, 2 Jul 2011 17:55:53 +0200
Wolfram Sang wrote:
> On Mon, Jun 20, 2011 at 10:38:54AM -0700, Jesse Barnes wrote:
> > On Mon, 20 Jun 2011 19:36:11 +0200
> > Wolfram Sang wrote:
> >
> > > Commit 6067aa (drm/i915: split clock gating init into per-chipset
On Wed, 04 May 2011 15:17:31 -0700
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> > We only spec a 32 bit swap count, so drop the high sbc field.
> >
> > Signed-off-by: Jesse Barnes
>
&g
On Wed, 4 May 2011 16:16:37 -0700
Jesse Barnes wrote:
> On Wed, 04 May 2011 15:17:31 -0700
> Ian Romanick wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> > > We only spec a 32
On Thu, 05 May 2011 09:32:46 +1000
Dave Airlie wrote:
> On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote:
> > On Wed, 04 May 2011 15:17:31 -0700
> > Ian Romanick wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
On Wed, 4 May 2011 17:49:37 -0700
Jesse Barnes wrote:
> How about you look at git and see what happened last time?
>
> We added some dri2 proto requests, and people wanted to build with old
> versions w/o the new requests. So they added some ifdefs but didn't
> check all
be sure to submit it soon.
Early registration for LPC is open until June 1st, so regardless of
whether you're submitting a topic, if you see discussions or proposed
talks of interest to you, be sure to register soon to get the
discounted rate.
Thanks,
Jesse Barn
t altogether, or we preserve the idea of a
"primary" plane (whatever that means for a given platform) that's tied
to each CRTC, which each additional plane described in a separate
structure. Z order and blend restrictions will have to be communicated
separately I think...
Thanks,
--
ng on a new feature for the next window), and as a
downstream gfx developer I'd like to see this on the Intel side as
well, unless other developers have big objections...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, 06 Jun 2011 16:24:46 -0700
Keith Packard wrote:
> On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes
> wrote:
>
> > Can you keep drm-intel-next fairly up to date with respect to the fixes
> > branch? I.e. keep it a superset of drm-intel-fixes for the most part?
>
On Mon, 6 Jun 2011 16:30:25 -0700
Jesse Barnes wrote:
> On Mon, 06 Jun 2011 16:24:46 -0700
> Keith Packard wrote:
>
> > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes
> > wrote:
> >
> > > Can you keep drm-intel-next fairly up to date with respect to the
This patchset updates the previous one, incorporating the feedback I
received:
1) uses the v4l fourcc codes to communicate pixel format
2) adds a new addfb ioctl that takes a format
3) adds working SNB support for the new code
Comments welcome. I'll be pushing intel-gpu-tools testdisplay su
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 core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 230
drivers/gpu/drm/drm_
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +/* Planes blend with or override other bits on the CRTC */
> +struct drm_mode_set_plane {
> + __u32 plane_id;
> + __u32 crtc_id;
> + __u32 fb_id; /* contains surface format type */
> +
> +
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +#define DRM_MODE_PLANE_FORMAT_YUV422 1 /* YUV 4:2:2 packed */
> +#define DRM_MODE_PLANE_FORMAT_RGBX101010 2 /* RGB 10bpc, ign. alpha */
> +#define DRM_MODE_PLANE_FORMAT_RGBX8883 /* Standard x:8:8
On Wed, 8 Jun 2011 11:41:17 +0200
Marcus Lorentzon wrote:
> On 06/07/2011 11:01 PM, Jesse Barnes wrote:
> > On Tue, 7 Jun 2011 13:07:39 -0700
> > Jesse Barnes wrote:
> >
> >
> >> +/* Planes blend with or override other bits on the CRTC */
> >&g
On Tue, 7 Jun 2011 13:07:38 -0700
Jesse Barnes wrote:
> This patchset updates the previous one, incorporating the feedback I
> received:
> 1) uses the v4l fourcc codes to communicate pixel format
> 2) adds a new addfb ioctl that takes a format
> 3) adds working SNB supp
check_feature(dev, DRIVER_MODESET) is False.
Ouch, a non-KMS config. Any reason you can't use KMS?
This patch should help at any rate.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0defd42..a1a
(HAS_PCH_SPLIT(dev)) {
> ...
> } else
> dev_priv->display.update_wm = NULL;
> }
We'll only hit this path on non-existent hardware. Since a clock
gating routine is required I'd rather just see the panic and add a new
routine at that time (i.e. what we nor
; > gating routine is required I'd rather just see the panic and add a new
> > routine at that time (i.e. what we normally do during bringup).
>
> How about BUG_ON(!ptr) in the init-routine for a bit more grace? And/or
> a warning
n -ENODEV in this case and propagate it to the upper
> layers.
>
> Signed-off-by: Wolfram Sang
> Cc: Jesse Barnes
> Cc: Chris Wilson
> ---
Looks good, thanks Wolfram.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
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.
I'd be interested to see whether thes
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 core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 235 +++-
drivers/gpu/drm/drm_
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
On Tue, 21 Jun 2011 10:55:39 +0200
Marcus Lorentzon wrote:
> On 06/20/2011 10:11 PM, Jesse Barnes wrote:
> > 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.
> >
>
On Tue, 21 Jun 2011 06:21:11 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > 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.
>
doesn't log the drm debug.
> > Is there another parameter to append at the kernel to send via ethernet
> > also the debug?
>
> I don't know how to get the drm debug sent to ethernet; perhaps someone
> else does?
Use netconsole. Documentation/networki
32becf6e51535d36b690f2a
> > bdd92c9ad287e03a2ec52f5a89c470cd5caae1c2
> >
> >
> >
> > I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> > cause. Can you check if the appended revert of that commit makes
> > things disappe
interesting, didn't realize X startup was so GPU intensive. :)
The patch you reverted will definitely cause the GPU to ramp up its
frequency much faster than before, but it sounds like on your system
you might also see it with the revert if you run something GPU
intensive like nexuiz.
The CPU
On Wed, 29 Jun 2011 00:01:58 +0200
Olaf Freyer wrote:
> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> > On Tue, 28 Jun 2011 23:09:45 +0200
> > Olaf Freyer wrote:
> >>>>> I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> >>>>
Chad Versace (1):
Add attachment token DRI2BufferHiz
Jesse Barnes (2):
Revert "dri2proto: make DRI2 swap event match GLX spec"
dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec
git tag: dri2proto-2.6
http://xorg.freedesktop.org/archive/indivi
On Sat, 2 Jul 2011 17:55:53 +0200
Wolfram Sang wrote:
> On Mon, Jun 20, 2011 at 10:38:54AM -0700, Jesse Barnes wrote:
> > On Mon, 20 Jun 2011 19:36:11 +0200
> > Wolfram Sang wrote:
> >
> > > Commit 6067aa (drm/i915: split clock gating init into per-chipset
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 c
On Thu, 21 Jul 2011 19:15:24 +0900
Joonyoung Shim wrote:
> Hi,
>
> 2011/6/16 Jesse Barnes :
> > On Tue, 7 Jun 2011 13:07:38 -0700
> > Jesse Barnes wrote:
> >
> >> This patchset updates the previous one, incorporating the feedback I
> >> rec
On Fri, 22 Jul 2011 08:52:52 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > /**
> > + * drm_plane_funcs - driver plane control functions
> > + * @update_plane: update the plane configuration
> > + */
> > +stru
On Thu, 30 Jun 2011 08:37:09 +0200
Olaf Freyer wrote:
> Am 29.06.2011 00:06, schrieb Jesse Barnes:
> > On Wed, 29 Jun 2011 00:01:58 +0200
> > Olaf Freyer wrote:
> >
> >> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> >>> Ok interesting, did
ust fire off a uevent and let userspace tell us what to do */
> drm_helper_hpd_irq_event(dev);
> }
yay, sounds like this will fix Andrew's problem and probably lots of
other random DP related failures.
Looks like the ->detect function is similarly protected at the call
site (though
On Mon, 25 Jul 2011 23:36:31 -0700
Keith Packard wrote:
> This describes the function better, allowing it to be used where the
> DPCD value is relevant.
>
> Signed-off-by: Keith Packard
> ---
Ah I see you've addressed my previous comment already. :)
You can add my
Revie
p->dpcd)) {
> + if (ret) {
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
> dev_priv->no_aux_handshake =
> intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
Reviewed-by: Jesse Barnes
output_reg);
> }
>
> +static enum drm_connector_status
> +i915_dp_detect_common(struct intel_dp *intel_dp)
Maybe you can fix the prefix of this function while you're at it since
it's not i915 or even i9xx specific?
--
Jesse Barnes, Intel Open Source Technology Center
_
erence from other outputs
> connected to that pch port
>
> Signed-off-by: Keith Packard
> ---
Ah nice catch. I expect one day we'll have all the chipset and PCH
differences coded...
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
viously I had only checked our internal driver
callbacks but missed that the lock was held across the helper too.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 27 Jul 2011 02:21:24 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes
> wrote:
>
> > I'd like to amend my reviewed by and say the lock shouldn't be held
> > around the call to the drm helper function. It queues some wo
t;HDMI dongle to my HDMI TV.
Does the HDMI HDA codec need any special parameters to work?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
r this...
> I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
> + if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))
> + DRM_ERROR("timed out waiting for panel to power off status
> 0x%08x control 0x%08x\n",
> +
only think we might want to sprinkle about are
checks for panel off so we can avoid visible corruption if we whack
timing or fb stuff while the panel is on.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel ma
Packard
> ---
> drivers/gpu/drm/i915/i915_reg.h | 13 ++-
> drivers/gpu/drm/i915/intel_display.c | 60 ++---
> 2 files changed, 58 insertions(+), 15 deletions(-)
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Cente
On Sat, 6 Aug 2011 10:54:08 -0700
Keith Packard wrote:
> Just an extra parameter which isn't actually needed.
>
> Signed-off-by: Keith Packard
> ---
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 08 Aug 2011 11:42:56 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
> wrote:
>
> > Yep, looks fine. The only think we might want to sprinkle about are
> > checks for panel off so we can avoid visible corruption if we whack
> &g
501 - 600 of 3329 matches
Mail list logo
