output once
> - * the mode has been programmed, along with possible test patterns.
> - */
> #ifdef HAVE_CONFIG_H
> #include "config.h"
> #endif
Yep, thanks.
Reviewed-by: Jesse Barnes
On 12/12/2015 07:16 AM, Emil Velikov wrote:
> On 11 December 2015 at 21:55, Jesse Barnes
> wrote:
>> Pick up context flags, softpin, etc.
>>
>> Signed-off-by: Jesse Barnes
>> ---
>> include/drm/i915_drm.h | 57
>> +++
Pick up context flags, softpin, etc.
Signed-off-by: Jesse Barnes
---
include/drm/i915_drm.h | 57 ++
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..4ce1fe9 100644
Cc'ing Maarten and Matt; I'm guessing this may be related to one of
their recent patches.
Jesse
On 09/21/2015 11:48 AM, Dave Jones wrote:
> On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> > >
> > > Hi Linus,
>
> - dev_priv->vbt.lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
> - DREF_SSC1_ENABLE);
> -
> intel_modeset_init_hw(dev);
>
> intel_setup_overlay(dev);
>
Yeah looks good (and I'm having deja vu here; I thought I ran into the same
ordering issue at one point in a report from krh, but I guess I never fixed it;
didn't have test hw at the time).
Reviewed-by: Jesse Barnes
Thanks,
Jesse
On 07/16/2015 01:27 AM, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 11:14:43PM +0200, Daniel Vetter wrote:
>> On Thu, Jul 09, 2015 at 01:15:34PM +1000, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> This really doesn't seem to have much chance of working anymore,
>>>
>>> esp for irq context,
TL_I915_SET_SPRITE_COLORKEY ioctl.
>>>
>>> Signed-off-by: Tommi Rantala
>>
>> Whoa. Broken since its introduction in
>>
>> commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e
>> Author: Jesse Barnes
>> Date: Tue Jan 3 08:05:39 2012 -0800
>>
>
> Whoa. Broken since its introduction in
>
> commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e
> Author: Jesse Barnes
> Date: Tue Jan 3 08:05:39 2012 -0800
>
> drm/i915: add color key support v4
>
> Cc: stable at vger.kernel.org
>
> BR,
> Jani.
>
On 12/14/2014 4:59 AM, Chris Wilson wrote:
> One of the things wbinvd is considered evil for is that it blocks the
> CPU for an indeterminate amount of time - upsetting latency critcial
> aspects of the OS. For example, the x86/mm has similar code to use
> wbinvd for large clflushes that caused a
talk now, while there are still
> some useful slots available.
>
> Also, for those who have filed already but who have left their abstracts
> open, please get those filed in ASAP. Your talk will be only be ordered
> in when at least the basics are provided.
Hey Luc, thanks for
On Thu, 6 Nov 2014 19:35:51 -0500
Rob Clark wrote:
> On Thu, Nov 6, 2014 at 6:29 PM, Daniel Vetter wrote:
> >
> > That aside I guess I need to elaborate on what makes dpms special in
> > i915, and why there's a real difference between crtc->enable == true
> > && ->active == false and
_BW_5_4 || intel_dp->use_tps3)
> >> >> + if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
> >> >> && !HAS_DDI(dev))
> >> >
> >> > CHV has pattern 3.
> >>
> >> Is "supports tps3" the same set of platforms as "supports 5.4 Gbps"? We
> >> should abstract the check from intel_dp_max_link_bw.
> >
> > Not quite. HSW-ULX supports pattern 3 even though it doesn't do 5.4 Gbps.
>
> How about [1] instead? I forgot --in-reply-to, sorry.
>
> BR,
> Jani.
>
>
> [1] http://mid.gmane.org/1414573406-17071-1-git-send-email-jani.nikula at
> intel.com
Looks like we need something like that at least, assuming we're not
hitting the link_bw == DP_LINK_BW_5_4 case.
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 16 Oct 2014 13:47:38 +0200
Daniel Vetter wrote:
> We need ww mutexes and need to rewrite i915 a bit fo fix this all.
> I.e. known issue. As long as your userspace isn't nasty nothing bad
> will ever happen though.
So do we already have a bug open with a good description of the issue?
ffer, e->destroy(e);
> }
>
> - return total;
> + return total ?: -EAGAIN;
> }
> EXPORT_SYMBOL(drm_read);
I'd prefer "total" to be spelled out after the ? (is this just a GNU
thing or does recent C implicitly use the first operand too?), but
that's no biggie. Looks fine.
Reviewed-by: Jesse Barnes
haven't looked at how to handle server vs client side arb_sync with the
scheduler and explicit fencing in place; might need some extra work
there...
--
Jesse Barnes, Intel Open Source Technology Center
om causing grief for other GPU users. I think that's
> the minimum level that's intended also for example also for the struct
> file accounting.
>
> > My comment really was about balancing mm users under the assumption that
> > they're all unlimited.
>
> Yeah, sorry for stealing the thread. I usually bring this up now and
> again but nowadays with an exponential backoff.
Yeah I agree we're missing some good limits stuff in i915 and DRM in
general probably. Chris started looking at this awhile back, but I
haven't seen anything recently. Tying into the ulimits/rlimits might
make sense, and at the very least we need to account for things
properly so we can add new limits where needed.
--
Jesse Barnes, Intel Open Source Technology Center
de their
> own set of ioctl through their own platform.
Yeah things are different enough that a uniform ioctl doesn't make
sense. If/when all the vendors decide on a single standard, we can use
that, but until then I don't see a nice way to share our doorbell &
submission scheme with HSA, and I assume nvidia is the same.
Using HSA as a basis for non-HSA systems seems like it would add a lot
of complexity, since non-HSA hardware would have to intercept the queue
writes and manage the submission requests etc as bytecodes in the
kernel driver, or maybe as a shim layer library that wraps that stuff.
Probably not worth the effort given that the command sets themselves
are all custom as well, driven by specific user level drivers like GL,
CL, and libva.
--
Jesse Barnes, Intel Open Source Technology Center
RC and ia64 (iirc on
sparc anyway, maybe MIPS too): "allocate" a PASID everytime you need
one, but don't tie it to the process at all, just use it as a counter
that lets you know when you need to do a full TLB flush, then start the
allocation process over. This lets you minimize TLB flushing and
gracefully handles oversubscription.
My current code doesn't bother though; context creation will fail if we
run out of PASIDs on a given device.
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 23 Jul 2014 11:47:15 +0200
Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes
> wrote:
> >> We don't have the code yet ready, but that's the direction i915 will
> >> move towards for the near future. Jesse is working on some patches
> >&g
gt; move towards for the near future. Jesse is working on some patches
> already.
Yeah I'd like to get some feedback from Maarten on my bits so I can get
them ready for upstream. I still need to add documentation and tests,
but I'd like to make sure the interfaces and internals get acked first.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
@ extern int drm_mode_create_dvi_i_properties(struct
> drm_device *dev);
> extern int drm_mode_create_tv_properties(struct drm_device *dev, int
> num_formats,
>char *formats[]);
> extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> +extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
> extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
>
--
Jesse Barnes, Intel Open Source Technology Center
On Tue, 8 Jul 2014 15:56:04 +0200
Daniel Vetter wrote:
> On Wed, Jul 02, 2014 at 01:42:38PM -0700, Jesse Barnes wrote:
> > On Wed, 2 Jul 2014 13:35:19 -0700
> > St?phane Marchesin wrote:
> >
> > > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter
> > > w
On Wed, 2 Jul 2014 13:35:19 -0700
St?phane Marchesin wrote:
> On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter wrote:
> > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes
> > wrote:
> >> People keep whining about this, but no one seems to send a patch. This
> >>
rtcs during
> suspend
Here's one that may be fixed by this series, needs testing though:
https://bugs.freedesktop.org/show_bug.cgi?id=79054
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 11 Jun 2014 17:39:29 +0200
Daniel Vetter wrote:
> On Wed, Jun 11, 2014 at 5:13 PM, Jesse Barnes
> wrote:
> >> - If you have a machine which uses tiled framebuffers and enables
> >> swizzling in the BIOS your code will a) drop the swizzle setup in
> >>
On Wed, 11 Jun 2014 11:23:26 +0200
Daniel Vetter wrote:
> On Tue, Jun 10, 2014 at 12:45:38PM -0700, Jesse Barnes wrote:
> > On Tue, 10 Jun 2014 21:33:27 +0200
> > Daniel Vetter wrote:
> >
> > > On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes > > virtuousgeek.
On Tue, 10 Jun 2014 21:33:27 +0200
Daniel Vetter wrote:
> On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes
> wrote:
> > Yes, that's what I do below... I even added it to the changelog:
> > http://patchwork.freedesktop.org/patch/27223/
> >
> > Did you miss the
On Tue, 10 Jun 2014 11:01:06 -0700
St?phane Marchesin wrote:
> On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes
> wrote:
> > On Tue, 10 Jun 2014 16:07:44 +0200
> > Daniel Vetter wrote:
> >
> >> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
On Tue, 10 Jun 2014 16:07:44 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
> > Let them eat mincemeat pie.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i915_params.c | 4 ++--
> > 1 fil
On Tue, 10 Jun 2014 16:05:36 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:30AM -0700, Jesse Barnes wrote:
> > From: Kristian H?gsberg
> >
> > The BIOS may set a native mode that doesn't quite match the preferred
> > mode timings. It should be o
On Tue, 10 Jun 2014 16:02:51 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:28AM -0700, Jesse Barnes wrote:
> > Some machines (like MBAs) might use a tiled framebuffer but not enable
> > display swizzling at boot time. We want to preserve that configuration
Let them eat mincemeat pie.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index d05a2af..081ab2f 100644
--- a/drivers/gpu/drm
From: Kristian H?gsberg <hoegsb...@gmail.com>
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian H?gsberg
Signed-off-by: Jesse
From: Kristian H?gsberg <hoegsb...@gmail.com>
Like mode_equal but w/o the clock checks. Useful for checking if modes
are close enough to re-use to avoid a boot time mode set for example.
Signed-off-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_modes
)
check display swizzle setting in detect_bit_6_swizzle (Daniel)
use gen6 as cutoff point (Daniel)
Reported-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem.c| 3 +++
drivers/gpu/drm/i915/i915_gem_tiling.c
)
Reported-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
On Wed, 21 May 2014 08:52:34 +0200
Daniel Vetter wrote:
> On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> > Gets the detect code (which may take awhile) out of the resume path,
> > speeding things up a bit.
> >
> > Signed-off-by: Jesse Barnes
> &
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
In some cases, the callers of this function may not need the return
value and delaying the uevent is ok. So add an async version of the
function for use in those cases.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_probe_helper.c | 8
include/drm/drm_crtc_helper.h | 2 ++
2
We really just want to go detect displays again and fire off a hotplug
event if things have changed, not go through full hotplug processing.
Requested-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20 +---
1 file changed, 1 insertion(+), 19
https://bugs.freedesktop.org/show_bug.cgi?id=73154
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> Cc: Ville Syrj?l?
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 56 +++
> drivers/gpu/drm/drm_fb_helper.c| 64
> +
> happens in intel_alloc_plane_obj in intel_display.c.
>
> Since no one else uses this we can savely remove the WARN without
> repercursions.
>
> Reported-by: Ben Widawsky
> Cc: Ben Widawsky
> Cc: Jesse Barnes
> Cc: Dave Airlie
> Signed-off-by: Daniel Vetter
> ---
> drivers
nfoframe.
> >
> > v2: Ville's inputs incorporated. Added picture aspect ratio as part of
> > edid_cea_modes instead of DRM_MODE
> >
> > Signed-off-by: Vandana Kannan
> > Reviewed-by: Alex Deucher
>
> Reviewed-by: Ville Syrj?l?
Note this one is needed for
onditions are
> satisfied, PAR is NONE as per initialization.
>
> As a next step, create a property that would enable a user space app to set
> aspect ratio. (will be pushed as a separate patch)
>
> Signed-off-by: Vandana Kannan
> Cc: Jesse Barnes
> Cc: Vijay Purushothaman
>
Let them eat cake.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_params.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index a66ffb6..5f81047 100644
--- a/drivers/gpu/drm/i915
From: Kristian H?gsberg <hoegsb...@gmail.com>
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian H?gsberg
Signed-off-by: Jesse
As of IVB, the memory controller does internal swizzling already, so we
shouldn't need to enable these. Based on an earlier fix from Kristian.
v2: preserve swizzling if BIOS had it set (Daniel)
Reported-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h
)
Reported-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_display.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915
c ID %d\n",
> - plane_req->crtc_id);
> - ret = -ENOENT;
> - goto out;
> - }
> - crtc = obj_to_crtc(obj);
> -
> fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
> if (!fb) {
> DRM_DE
o for another opinion too. This makes me nervous but it
seems ok.
I think you should update the docbook (with examples) as well so other
driver writers will know how to use this stuff.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
on_get;
> +
> /* array of size num_crtcs */
> struct drm_vblank_crtc *vblank;
>
This seems like the sort of thing it would be good to have a test
for... I'm surprised we haven't hit it yet. But in looking at the code
I don't see where we'd re-enable things properly in this situation, so
I guess it's a real bug.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
more than
> once per disable */
> + bool reject;/* reject drm_vblank_get()? */
> };
>
> /**
> @@ -1400,7 +1401,8 @@ extern void drm_send_vblank_event(struct drm_device
> *dev, int crtc,
> extern bool drm_handle_vblank(struct drm_device *dev, int crtc);
> extern int drm_vblank_get(struct drm_device *dev, int crtc);
> extern void drm_vblank_put(struct drm_device *dev, int crtc);
> -extern void drm_vblank_off(struct drm_device *dev, int crtc);
> +extern void drm_vblank_off(struct drm_device *dev, int crtc, bool reject);
> +extern void drm_vblank_on(struct drm_device *dev, int crtc);
> extern void drm_vblank_cleanup(struct drm_device *dev);
> extern u32 drm_get_last_vbltimestamp(struct drm_device *dev, int crtc,
>struct timeval *tvblank, unsigned flags);
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
/* Display driver is setting mode */
> + int crtc; /* crtc index */
> bool enabled; /* so we don't call enable more than
> once per disable */
> };
> @@ -1157,7 +1160,6 @@ struct drm_device {
>
> spinlock_t vblank_time_lock;/**< Protects vblank count and time
> updates during vblank enable/disable */
> spinlock_t vbl_lock;
> - struct timer_list vblank_disable_timer;
>
> u32 max_vblank_count; /**< size of vblank counter register */
>
Yeah this looks like a good fix.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
int drm_vblank_get(struct drm_device *dev, int crtc)
> drm_update_vblank_count(dev, crtc);
> }
> }
> - spin_unlock_irqrestore(>vblank_time_lock, irqflags2);
> + spin_unlock(>vblank_time_lock);
> } else {
> if (!dev->vblank[crtc
rove fruitful,
> >either because I messed it up or there's a combination of things that
> >fix the issue. So instead I did a regular git bisect between 3.12 and
> >3.13 to see which commit _broke_ things and caused the above behavior.
> > That landed me at:
> >
> >Auth
This allows drivers to use them in custom initial_config functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c |6 --
include/drm/drm_fb_helper.h |6 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b
Begin forwarded message:
Date: Wed, 12 Feb 2014 12:26:24 -0800
From: Jesse Barnes <jbar...@virtuousgeek.org>
To: intel-gfx at lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 1/6] drm: export cmdline and preferred mode
functions from fb helper
This allows drivers to use them in
This allows drivers to use them in custom initial_config functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c |6 --
include/drm/drm_fb_helper.h |6 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b
Just like we have for connector type etc.
v2: drop static array (Chris)
v3: add kdoc (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 23 +++
include/drm/drm_crtc.h |1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm
UX
> >
> > Signed-off-by: Todd Previte
>
> Reviewed-by: Jani Nikula
Did this ever go in?
--
Jesse Barnes, Intel Open Source Technology Center
then update the pipesrc and pfit state, even on the flip path.
On top of that, other state like info frames and audio state needs to
be tracked and preserved for fastboot as applicable. Then we can
remove the parameter hacks.
--
Jesse Barnes, Intel Open Source Technology Center
the time of my old machine, but the GPU side has
been something of a step backwards...
Well we definitely don't want that...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
ut you'll need docs for it. Charlie
Huang ought to be able to get you the NDA docs that should have the
info you need.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
to get you the NDA docs that should have the
info you need.
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
eedesktop.org/show_bug.cgi?id=54089
> References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
> Signed-off-by: Konstantin Khlebnikov
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Jesse Barnes
> ---
My hero!
So the later init change didn't work?
Either way, great to
On Tue, 16 Jul 2013 22:43:49 +0200
Daniel Vetter wrote:
> On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote:
> > On Tue, 16 Jul 2013 10:06:54 -0700
> > Jesse Barnes wrote:
> >
> > > On Tue, 16 Jul 2013 11:34:25 +0400
> > > Konstantin Khlebnikov
On Tue, 16 Jul 2013 10:06:54 -0700
Jesse Barnes wrote:
> On Tue, 16 Jul 2013 11:34:25 +0400
> Konstantin Khlebnikov wrote:
> > I've tested that patch and it really works for me. If you want change
> > something for other hardware or
> > extend range where for
to forcewake around everywhere we need it.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 12ea1a9..9152cba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.
trying
to forcewake around everywhere we need it.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 12ea1a9..9152cba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915
On Tue, 16 Jul 2013 10:06:54 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 16 Jul 2013 11:34:25 +0400
Konstantin Khlebnikov khlebni...@openvz.org wrote:
I've tested that patch and it really works for me. If you want change
something for other hardware or
extend range where
On Tue, 16 Jul 2013 22:43:49 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote:
On Tue, 16 Jul 2013 10:06:54 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 16 Jul 2013 11:34:25 +0400
Konstantin Khlebnikov khlebni
On Sat, 22 Jun 2013 13:04:09 -0700
Guenter Roeck wrote:
> On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote:
> > On Fri, 21 Jun 2013 23:58:08 -0700
> > Guenter Roeck wrote:
> >
> > > Hi all,
> > >
> > > after upgrading one
On Sat, 22 Jun 2013 13:04:09 -0700
Guenter Roeck li...@roeck-us.net wrote:
On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote:
On Fri, 21 Jun 2013 23:58:08 -0700
Guenter Roeck li...@roeck-us.net wrote:
Hi all,
after upgrading one of my servers to 3.8, then 3.9.7
else I can do besides using a special kernel with the backed out
> commit ? Is it possible that others have the same problem ?
Ouch, so a BIOS that uses the other forcewake mechanism seems to have
escaped. Is there a newer one available for your system? I'm hoping
it'll fix the issue, otherwise we
? Is it possible that others have the same problem ?
Ouch, so a BIOS that uses the other forcewake mechanism seems to have
escaped. Is there a newer one available for your system? I'm hoping
it'll fix the issue, otherwise we may have to introduce both methods
for IVB again...
--
Jesse Barnes, Intel Open
the direct structure reference; a couple of
inlines are just as easy to read. So no argument from me.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
ntf(stderr, "clock_gettime failed: %s\n", strerror(ret));
> + fprintf(stderr, "clock_gettime failed: %s\n", strerror(errno));
> goto out;
> }
> timeout.tv_sec++;
Applied, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
failed: %s\n, strerror(ret));
+ fprintf(stderr, clock_gettime failed: %s\n, strerror(errno));
goto out;
}
timeout.tv_sec++;
Applied, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel
of
inlines are just as easy to read. So no argument from me.
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
o this stuff seems to be a nop.
>
> And if these writes can get reordered somewhere, why not everything
> else too? I'm sure we have places where we write a bunch of registers,
> and the final write enables something which requires the earlier
> writes to have landed beforehand.
Yeah we shouldn't need mmiowb() anywhere in our driver (until our
on-chip topology gets really complicated anyway).
--
Jesse Barnes, Intel Open Source Technology Center
reakage introduced in
>
> commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
> Author: Daniel Vetter
> Date: Tue Dec 11 00:59:24 2012 +0100
>
> drm: refcounting for sprite framebuffers
>
> Reported-by: Jesse Barnes
> Cc: Jesse Barnes
> Cc: Rob Clark
> Sig
isn't ready yet either I've dropped the offending
> patches.
I sent a patch yesterday for this. I'll bounce it over again.
--
Jesse Barnes, Intel Open Source Technology Center
patches.
I sent a patch yesterday for this. I'll bounce it over again.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
introduced in
commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Tue Dec 11 00:59:24 2012 +0100
drm: refcounting for sprite framebuffers
Reported-by: Jesse Barnes jbar...@virtuousgeek.org
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc
On Fri, 25 Jan 2013 16:54:11 +0100
David Herrmann wrote:
> Hi Jesse
>
> On Fri, Jan 18, 2013 at 5:54 PM, Jesse Barnes
> wrote:
> > On Fri, 18 Jan 2013 17:01:59 +0100
> > David Herrmann wrote:
> >
> >> On Fri, Jan 18, 2013 at 5:00 PM, David
On Fri, 25 Jan 2013 16:54:11 +0100
David Herrmann dh.herrm...@googlemail.com wrote:
Hi Jesse
On Fri, Jan 18, 2013 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 18 Jan 2013 17:01:59 +0100
David Herrmann dh.herrm...@googlemail.com wrote:
On Fri, Jan 18, 2013 at 5:00
> Ah sorry, I now saw the "subs" => "subst" typo. Still I wonder why
> distcheck works here. But the patch looks fine. Thanks!
Works here too. Pushed with David's reviewed-by. Thanks Thierry.
--
Jesse Barnes, Intel Open Source Technology Center
. But the patch looks fine. Thanks!
Works here too. Pushed with David's reviewed-by. Thanks Thierry.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
ocally. You can disable building manpages with
> --disable-manpages so the quite expensive xsltproc procedure can be
> skipped.
>
> Signed-off-by: David Herrmann
> ---
Seems to work here, pushed. Thanks David.
--
Jesse Barnes, Intel Open Source Technology Center
are
available locally. You can disable building manpages with
--disable-manpages so the quite expensive xsltproc procedure can be
skipped.
Signed-off-by: David Herrmann dh.herrm...@googlemail.com
---
Seems to work here, pushed. Thanks David.
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 10 Jan 2013 22:00:20 +0100
David Herrmann wrote:
> Hi Jesse
>
> On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes
> wrote:
> > On Fri, 28 Sep 2012 23:44:18 +0200
> > David Herrmann wrote:
> >
> >> Hi
> >>
> >> This is revi
On Thu, 10 Jan 2013 22:00:20 +0100
David Herrmann dh.herrm...@googlemail.com wrote:
Hi Jesse
On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 28 Sep 2012 23:44:18 +0200
David Herrmann dh.herrm...@googlemail.com wrote:
Hi
This is revision 2
tation.
>
> Other than that I only fixed typos and the small corrections you guys
> mentioned.
> Thanks for reviewing!
I went ahead and pushed these finally.
Can you just apply for an fdo account though so we can let you push
things in the future? :)
--
Jesse Barnes, Intel Open Source Technology Center
documentation.
Other than that I only fixed typos and the small corrections you guys
mentioned.
Thanks for reviewing!
I went ahead and pushed these finally.
Can you just apply for an fdo account though so we can let you push
things in the future? :)
--
Jesse Barnes, Intel Open Source Technology
On Wed, 12 Dec 2012 23:00:34 +0100
Daniel Vetter wrote:
> On Wed, Dec 12, 2012 at 12:54:47PM -0800, Jesse Barnes wrote:
> > On Wed, 12 Dec 2012 14:06:44 +0100
> > Daniel Vetter wrote:
> >
> > > Spinning for up to 200 us with interrupts locked out is not good. So
&
lk gate prior to programming
>* the divisors, and gate it back when it is done.
>*/
> @@ -3041,6 +3024,8 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
> udelay(24);
>
> I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_UNGATE);
> +
> + mutex_unlock(_priv->dpio_lock);
> }
>
> /*
> @@ -4268,6 +4253,8 @@ static void vlv_update_pll(struct drm_crtc *crtc,
> bool is_sdvo;
> u32 temp;
>
> + mutex_lock(_priv->dpio_lock);
> +
> is_sdvo = intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
> intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
>
> @@ -4351,6 +4338,8 @@ static void vlv_update_pll(struct drm_crtc *crtc,
> temp |= (1 << 21);
> intel_dpio_write(dev_priv, DPIO_DATA_CHANNEL2, temp);
> }
> +
> + mutex_unlock(_priv->dpio_lock);
> }
>
> static void i9xx_update_pll(struct drm_crtc *crtc,
Looks fine, I guess you could convert the wait_for_atomic_us to the
non-atomic variant now that you have a mutex. Either way:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
that you have a mutex. Either way:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
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, 12 Dec 2012 23:00:34 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Dec 12, 2012 at 12:54:47PM -0800, Jesse Barnes wrote:
On Wed, 12 Dec 2012 14:06:44 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Spinning for up to 200 us with interrupts locked out is not good. So
connector->base.id,
> drm_get_connector_name(connector),
> - old_status, connector->status);
> + connector_status_str(old_status),
> + connector_status_str(connector->status));
> if (old_status != connector->status)
> changed = true;
> }
Yeah, thanks.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
!= connector-status)
changed = true;
}
Yeah, thanks.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
1 - 100 of 836 matches
Mail list logo
