[dri-devel] [PATCH] drm: add locked variant of drm_fb_helper_force_kernel_mode

Needed for panic and kdb, since we need to avoid taking the mode_config mutex. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_fb_helper.c | 42 +- 1 files changed, 36 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers

[dri-devel] [PATCH] fbcon: assume console is active if panicing

This allows us to draw to the fbcon buffer in a panic situation, in case the low level driver can flip to it at panic time. Signed-off-by: Jesse Barnes --- drivers/video/console/fbcon.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/console/fbcon.c b

[dri-devel] [PATCH] vt: try harder to print output when panicing

At panic time (i.e. when oops_in_progress is set) we should try a bit harder to update the screen and make sure output gets to the VT, since some drivers are capable of flipping back to it. So make sure we try to unblank and update the display if called from a panic context. Signed-off-by: Jesse

[PATCH] drm: add locked variant of drm_fb_helper_force_kernel_mode

On Mon, 12 Apr 2010 10:05:00 +1000 Dave Airlie wrote: > On Sat, Apr 10, 2010 at 8:11 AM, Jesse Barnes > wrote: > > Needed for panic and kdb, since we need to avoid taking the mode_config > > mutex. > > One comment below. > > > > > Signed-off-by: Jes

[PATCH] drm: add locked variant of drm_fb_helper_force_kernel_mode

On Mon, 12 Apr 2010 10:05:00 +1000 Dave Airlie wrote: > On Sat, Apr 10, 2010 at 8:11 AM, Jesse Barnes > wrote: > > Needed for panic and kdb, since we need to avoid taking the mode_config > > mutex. > > One comment below. Updated patch below. -- Jesse Barnes, Inte

[PATCH] drm: add locked variant of drm_fb_helper_force_kernel_mode

Needed for panic and kdb, since we need to avoid taking the mode_config mutex. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_fb_helper.c | 43 -- 1 files changed, 36 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers

[RFC] Try a bit harder to get output on the screen at panic time

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 screen

DRM connector/encoder/crtc framework documentation?

t just depends on your needs. Check out i915_gem.c for details on how the driver specific portion of GEM should work (basically cache domain management, buffer tracking, and execution buffer management). -- Jesse Barnes, Intel Open Source Technology Center -- next part ---

[dri-devel] [RFC] Try a bit harder to get output on the screen at panic time

est these out and let me know if they work for you. -- Jesse Barnes, Intel Open Source Technology Center

[PATCH] drm: fixed brace, spacing and whitespace coding style issues

though, whitespace isn't top of my > priorities most days. I think you should just reject it, unless it comes as part of a series with actual work in it. At least that's been my policy lately... -- Jesse Barnes, Intel Open Source Technology Center

[PATCH 2/2] drm/i915: Revert extra intel_wait_for_vblank to prevent stalls.

r vblank off will spin until the display line reg stops incrementing, so it's important that we flush any previous writes to shut off the pipe before waiting. So adding a POSTING_READ() above it might help? But that still doesn't explain why it would cause the hangcheck timer to notice a hang... -- Jesse Barnes, Intel Open Source Technology Center

[PATCH 1/2] drm/i915: Revert wait for vblank to prevent X refresh issues

oblems all because of this line? Maybe because we wait for a longer period here now? Can you check and see if we're timing out in the wait_for_vblank function? -- Jesse Barnes, Intel Open Source Technology Center

[PATCH] drm, video: fix use-before-NULL-check

tartwrite, *startread; > int offset; > - int bytesperline = dev->vbi_width; > + int bytesperline; > > if (dev == NULL) { > em28xx_isocdbg("dev is null\n"); > return; > } > + bytesperline = dev->vbi_w

[PATCH] drm: Add missing drm_vblank_put() along queue vblank error path

On Wed, 1 Dec 2010 19:41:31 + Chris Wilson wrote: > Signed-off-by: Chris Wilson > Cc: Kristian H?gsberg > Cc: Jesse Barnes > --- > drivers/gpu/drm/drm_irq.c | 19 ++- > 1 files changed, 14 insertions(+), 5 deletions(-) > > diff --git a/dri

[stable] [PATCH] drm/kms: remove spaces from connector names

nector_enum_list[] = > > { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO", 0 }, > > { DRM_MODE_CONNECTOR_LVDS, "LVDS", 0 }, > > { DRM_MODE_CONNECTOR_Component, "Component", 0 }, > > - { DRM_MODE_CONNECTOR_9PinDIN, "9-pin DIN", 0 }, >

[stable] [PATCH] drm/kms: remove spaces from connector names

On Thu, 09 Dec 2010 20:33:18 +0300 Sergej Pupykin wrote: > At Thu, 9 Dec 2010 09:18:14 -0800, > Jesse Barnes wrote: > > > > On Wed, 8 Dec 2010 15:30:26 -0800 > > Greg KH wrote: > > > What kernel version did these options first show up in? Does any >

[PATCH] drm-vblank: Always return true vblank count of scheduled vblank event.

this actually causes us to return the current count rather than the requested count if the event requested is in the past, right? > } else { > list_add_tail(>base.link, >vblank_event_list); > + vblwait->reply.sequence = vblwait->request.

[PATCH] drm-vblank: Always return true vblank count of scheduled vblank event.

On Mon, 13 Dec 2010 18:21:20 +0100 Mario Kleiner wrote: > On Dec 10, 2010, at 6:45 PM, Jesse Barnes wrote: > > > On Fri, 10 Dec 2010 16:00:19 +0100 > > Mario Kleiner wrote: > > > >> > >> > >> Original Message > >>

[Intel-gfx] [PATCH] drm: Aggressively disable vblanks

it_vblank from > userspace for testing? I know approximately nothing about libdrm or > any userspace graphics stuff whatsoever. Yeah, libdrm has a test program called vbltest; it should do what you need. -- Jesse Barnes, Intel Open Source Technology Center

[PATCH] vgaarb: use bridges to control VGA routing where possible. (v2)

ng simple bridge routing. Acked-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center

[Intel-gfx] [PATCH] drm: Aggressively disable vblanks

H] drm: Aggressively disable vblanks > > To: Andy Lutomirski , Jesse Barnes > > , Chris Wilson > chris-wilson.co.uk>, > > David Airlie > > Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org > > Message-ID: > > Content-Type: t

[git pull] drm fixes

figure it out or disable SSC enabling altogether failing that (risking interference with other components like wireless and sound). -- Jesse Barnes, Intel Open Source Technology Center

Linux 2.6.37-rc8 (no fb)

force disable until we can parse this correctly */ + if (IS_GEN5(dev) || IS_GEN6(dev)) + dev_priv->lvds_use_ssc = 0; if (dev_priv->lvds_use_ssc) { if (IS_I85X(dev)) -- Jesse Barnes, Intel Open Source Technology Center

Linux 2.6.37-rc8 (no fb)

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

Linux 2.6.37-rc8 (no fb)

he 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/drivers/gpu/drm

Linux 2.6.37-rc8 (no fb)

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

Linux 2.6.37-rc8 (no fb)

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 >

Linux 2.6.37-rc8 (no fb)

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) > >>> >

Linux 2.6.37-rc8 (no fb)

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, > >

[PATCH 1/3] drm: add vblank event trace point

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

[PATCH 2/3] drm: add per-event vblank event trace points

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

[PATCH 3/3] drm/i915: add tracepoints for flip requests & completions

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

[PATCH] drm: correctly update connector DPMS status in drm_fb_helper

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(struct fb_info *

Documentation of DRM's API?

f 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

[PATCH] drm/gem: Add new flink_to ioctl

pt 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 order to open a sur

[PATCH 1/2] drm: Return EBUSY if the framebuffer is unbound when flipping.

iguration into something they couldn't change. :) Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center

[PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine

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

[PATCH 2/2] drm/i915: use GMBUS for EDID fetching

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

[PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine

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

[PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine

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: > > > &

[Intel-gfx] [PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine

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: > > >

[RFC] Try a bit harder to get output on the screen at panic time

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 runn

[patch] i915: take struct_mutex in i915_dma_cleanup()

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

[PATCH 1/4] drm: add plane support

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 core &

[RFC] Updated DRM plane handling patches

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 > >>

[PATCH 2/2] libdrm: add plane handling functions & structs

--- include/drm/drm.h |7 +- include/drm/drm_mode.h | 33 +++ xf86drmMode.c | 148 xf86drmMode.h | 29 + 4 files changed, 201 insertions(+), 16 deletions(-) diff --git a/include/drm/drm.h

[PATCH 1/4] drm: add plane support

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

Erroneous package power limit notification since kernel 2.6.39

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

[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

ce 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 one level up in ->fill_modes),

[Intel-gfx] [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd

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 Reviewed-b

[Intel-gfx] [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd

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

[Intel-gfx] [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper function

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

[Intel-gfx] [PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT

t interference 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

[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

internal driver callbacks but missed that the lock was held across the helper too. -- Jesse Barnes, Intel Open Source Technology Center

[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

On Wed, 27 Jul 2011 02:21:24 -0700 Keith Packard wrote: > On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes virtuousgeek.org> 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 wor

[PATCH v2] pass ELD to HDMI/DP audio driver

gle to my HDMI TV. Does the HDMI HDA codec need any special parameters to work? Thanks, -- Jesse Barnes, Intel Open Source Technology Center

drivers/drm/i915 maintenance process

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

drivers/drm/i915 maintenance process

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? >

[Intel-gfx] drivers/drm/i915 maintenance process

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 > virtuousgeek.org> wrote: > > > > > Can you keep drm-intel-next fairly up to date wi

[RFC] Updated DRM plane handling patches

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

[PATCH 1/4] drm: add plane support

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_drv.c

[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

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

[PATCH 4/4] drm/i915: add SNB video sprite support

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

[PATCH 3/4] drm/i915: rename existing overlay support to "legacy"

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

[PATCH 1/4] drm: add plane support

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 */ > + > +

[PATCH 1/4] drm: add plane support

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

[PATCH 1/4] drm: add plane support

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

[RFC] Updated DRM plane handling patches

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

Oops in i915 intel_init_clock_gating

_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..a1a28fb 10064

[PATCH] drm/i915: add check for valid init_clock_gating-pointer

(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 normally do d

[PATCH] drm/i915: add check for valid init_clock_gating-pointer

; 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 in the else-block? It seems to happen to users... Yeah, a BUG_ON would be fine. -- Jesse Barnes, Intel Open Source Technology Center

[PATCH V2] drm/i915: gracefully bail out when init_clock_gating-pointer is not set

turn -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

[RFC] Updated plane support v3

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

[PATCH 1/4] drm: add plane support

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_drv.c

[PATCH 3/4] drm/i915: rename existing overlay support to "legacy"

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

[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

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

[PATCH 4/4] drm/i915: add SNB video sprite support

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

[RFC] Updated plane support v3

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. > > >

[RFC] Updated plane support v3

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. &

Reverting rc6 by default

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/networking/netconsole.txt has all the gory details. -- Jesse Barnes, Intel Open Source Technology Center

Erroneous package power limit notification since kernel 2.6.39

6b690f2a > > bdd92c9ad287e03a2ec52f5a89c470cd5caae1c2 > > > > > > > > I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the > > cause. Can you check if the appended revert of that commit makes > > things disappear? > It seems like you guessed perfectly correct - reverting the commit makes > those notifications go away at once. > Without this reverted you see messages? I missed the earlier stuff, what message are you seeing? -- Jesse Barnes, Intel Open Source Technology Center

Erroneous package power limit notification since kernel 2.6.39

resting, 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 (and by ex

Erroneous package power limit notification since kernel 2.6.39

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 > >>>&

[ANNOUNCE] dri2proto 2.6

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

vblank problem (and proposed fix) on crtc > 1

On Thu, 3 Mar 2011 17:34:53 -0600 (CST) Ilija Hadzic wrote: > The fix/improvement I propose is to extend the request.type field > in drmVBlank structure with additional 5 bits that I call high_crtc > (there are lots of unused bits in that field). 5 bits covers for 32 > CRTCs, which seems to be

drm/i915: Fix DPMS and suspend interaction for intel_panel.c

On Fri, 11 Mar 2011 02:35:45 +0100 (CET) "Indan Zupancic" wrote: > drm/i915: Fix DPMS and suspend interaction for intel_panel.c > > When suspending intel_panel_disable_backlight() is never called, > but intel_panel_enable_backlight() is called at resume. With the > effect that if the brightness

[PATCH] drm: Hold the mode mutex whilst probing for sysfs status

ector->funcs->detect(connector, true); > + mutex_unlock(>dev->mode_config.mutex); > + How about adding a mutex assertion check in the detect hook as well? I think we need a more generous sprinkling of those around the CRTC helper code in general... -- Jesse Barnes, Intel Open Source Technology Center

[PATCH] xf86-video-ati: vblank wait on crtc > 1

ted code in each function is begging to get pulled out into a separate function... -- Jesse Barnes, Intel Open Source Technology Center

[PATCH] kernel/drm: vblank wait on crtc > 1

ew param check, but I'd still prefer a new ioctl to abusing the old one. -- Jesse Barnes, Intel Open Source Technology Center

[PATCH] kernel/drm: vblank wait on crtc > 1

On Fri, 18 Mar 2011 18:13:11 -0500 (CDT) Ilija Hadzic wrote: > > > On Fri, 18 Mar 2011, Jesse Barnes wrote: > > > > > I like the new param check, but I'd still prefer a new ioctl to abusing > > the old one. > > > > It's not "abusing&qu

Future desktop on dumb frame buffers?

> "advanced" things like compositing using the CPU. Transparency may stretch > it a bit on lower end CPUs, but you don't always need that. There's nothing in DRM that precludes doing simple fbdev-like drivers as well, though for many embedded uses I wouldn't expect it to provide a whole lot of benefit. -- Jesse Barnes, Intel Open Source Technology Center

Future desktop on dumb frame buffers?

On Mon, 21 Mar 2011 19:19:43 + timofonic timofonic wrote: > So if KMS is so cool and provides many advantages over fbdev and > such... Why isn't more widely used intead of still relying on fbdev? > Why still using fbdev emulation (that is partial and somewhat broken, > it seems) instead using

Future desktop on dumb frame buffers?

On Mon, 21 Mar 2011 20:50:20 +0100 Geert Uytterhoeven wrote: > On Mon, Mar 21, 2011 at 20:25, Jesse Barnes > wrote: > > On Mon, 21 Mar 2011 19:19:43 + > > timofonic timofonic wrote: > >> So if KMS is so cool and provides many advantages over fbdev and > &g

Future desktop on dumb frame buffers?

es reallocation of the framebuffer somewhat difficult. IIRC plymouth or whatever Fedora is using these days uses the KMS APIs though... -- Jesse Barnes, Intel Open Source Technology Center

Future desktop on dumb frame buffers?

tional features it would provide (output > > management, memory management, execution management) > > 3) its got documentation Jeez, some people want it all. You looking for docs for the ioctls and such? -- Jesse Barnes, Intel Open Source Technology Center

[PATCH 1/2] i915: Remove pipe A force quirk for 855GM and 845G

gest that the problems > related to disabling part A may actually have been related to handover > to the console driver before KMS. Yes, definitely possible. We didn't have all the assertion checks we have now, so we may have just been masking other problems without knowing it. -- Jesse Barnes, Intel Open Source Technology Center

[RFC PATCH] HDMI:Support for EDID parsing in kernel.

RM. If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need. Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code. Do you really think the differences between your code and the existing DRM code are irreconcilable? -- Jesse Barnes, Intel Open Source Technology Center

[git pull] drm next tree

set/restarted when this happens? When a nic card > gets hung it is reinitialized > and restarted why not the gpu? Yeah, we try to restart in this case, but often just end up back in the same situation when the app runs again. We could be meaner about things and SIGILL the app, but often it's an innocent bystander, and the real problem is kernel object synchronization and/or the DRI driver generating bad commands. -- Jesse Barnes, Intel Open Source Technology Center

[git pull] drm next tree

but it does seem a likely candidate. -- Jesse Barnes, Intel Open Source Technology Center

[git pull] drm fixes

this on the Intel side at least; we add feature flags every time we change something, and make sure userspace is forward and backward compatible). This is more work for us, but I think it benefits the user in the end. And it could be worse, at least we're not still dealing with memory layout com

<    2   3   4   5   6   7   8   9   >