and have still been found to have failures on
some configurations.
v2: extract simpler set_power_well function for use in reset_dpio (Imre)
move to reset_dpio (Daniel Ville)
v3: don't reset if DPIO reset is already de-asserted (Imre)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
We do this at runtime and later on now.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_uncore.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 27fe2df
We need to do this anytime we power gate the DPIO common well.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 13
drivers/gpu/drm/i915/intel_pm.c | 39 +++-
2 files changed, 30 insertions(+), 22
There may be a dependency here.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e8f0c85..fb7e23e
On Thu, 22 May 2014 09:51:22 +0300
Imre Deak imre.d...@intel.com wrote:
On Wed, 2014-05-21 at 21:43 +0300, Ville Syrjälä wrote:
On Wed, May 21, 2014 at 11:11:15AM -0700, Jesse Barnes wrote:
And to answer more specifically...
On Wed, 21 May 2014 20:54:03 +0300
Ville Syrjälä
: Jesse Barnes jbar...@virtuousgeek.org
Date: Tue Mar 26 09:25:45 2013 -0700
drm/i915: enable VT switchless resume v3
introducing an unlocked access to the CRTC whilst disabling it for
suspend.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78114
Signed-off-by: Chris Wilson
On Wed, 21 May 2014 08:52:34 +0200
Daniel Vetter dan...@ffwll.ch 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 jbar...@virtuousgeek.org
On Wed, 21 May 2014 20:54:03 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Tue, May 20, 2014 at 11:09:03AM -0700, Jesse Barnes wrote:
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
that it resets the whole common lane section of the PHY
More of an example of where to use the stepping macro than anything
else. I think these early steppings never went outside of Intel.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 17 +++--
1 file changed, 15 insertions(+), 2
In some cases to enable or disable features workarounds, we may need
to check the GPU stepping. Add a macro to do that based on caching the
PCI revision ID reg.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 2
On Wed, 21 May 2014 19:50:53 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, May 21, 2014 at 11:42:25AM -0700, Jesse Barnes wrote:
In some cases to enable or disable features workarounds, we may need
to check the GPU stepping. Add a macro to do that based on caching the
PCI
(Imre)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 19 +++
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_pm.c | 13 ++---
3 files changed, 31 insertions(+), 4 deletions(-)
diff --git
On Mon, 19 May 2014 16:16:37 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
that it resets the whole common lane section of the PHY. This is
required on machines where the BIOS doesn't do this for us on boot or
resume
);
+ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
return wait_for((I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR)
ILK_GRDOM_RESET_ENABLE) == 0, 500);
}
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
);
+ if (ret)
+ return ret;
+
+ I915_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR, 0);
+
+ return 0;
}
static int gen6_do_reset(struct drm_device *dev)
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
the reset flow stuff works this seems sensible, but I
couldn't find it in the docs I have. Shouldn't do any harm at the very
worst...
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx
;
-}
-
/* Set up chip specific backlight functions */
void intel_panel_init_backlight_funcs(struct drm_device *dev)
{
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing
== 0);
+
+ return dev_priv-vbt.backlight.min_brightness *
+ panel-backlight.max / 255;
+}
Is this the user version or the hw version? If hw, why not just use
min_brightness directly?
--
Jesse Barnes, Intel Open Source Technology Center
On Fri, 16 May 2014 23:42:23 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, May 16, 2014 at 11:38:07PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 03:20:47PM -0700, Jesse Barnes wrote:
On Mon, 21 Apr 2014 18:37:31 +0200
Knut Petersen knut_peter...@t-online.de wrote
On Tue, 20 May 2014 12:53:29 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 16 May 2014 23:42:23 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, May 16, 2014 at 11:38:07PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 03:20:47PM -0700, Jesse Barnes wrote
On Tue, 20 May 2014 22:15:45 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Ah, poll_enable is false until after _thaw finishes, so
our hotplug_resume call of hpd_irq_event does nothing. So aside from
On Tue, 20 May 2014 14:10:16 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 20 May 2014 22:15:45 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Ah, poll_enable is false until after _thaw
On Tue, 20 May 2014 14:18:07 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 20 May 2014 14:10:16 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 20 May 2014 22:15:45 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Tue, May 20, 2014 at 9:58 PM, Jesse
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 daniel.vet...@ffwll.ch
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 20
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
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
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 jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_probe_helper.c | 8
include/drm
);
}
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
);
}
Nice find... is this documented somewhere so we can put a reference
in? Or is it in the Punit HAS somewhere already and we just missed it?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
1
-#define PUNIT_OPCODE_REG_READ6
-#define PUNIT_OPCODE_REG_WRITE 7
-
#endif /* _I810_REG_H */
Looks fine to me... you have commit access right?
--
Jesse Barnes, Intel Open Source Technology Center
-primary-fb);
Updating our page flip ioctl man page (hah!) with the timeout info
would be good, in case people like Mario queue flips for after lunch. :)
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
a new patch with Tested-by on it.
BR,
Jani.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=76619#c16
Ben, will you re-post this or can you find someone else who can?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing
On Mon, 19 May 2014 18:10:18 +0300
Imre Deak imre.d...@intel.com wrote:
On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 11:41:18 +0300
Imre Deak imre.d...@intel.com wrote:
So far we used the wrong opcodes to access the DSI registers, so the
register writes
On Mon, 19 May 2014 17:18:40 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 16:09:35 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We can apperently miss them, but breaking the entire driver hampers
resetting display ... */
gdrst = I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR);
gdrst = ~GRDOM_MASK;
I915_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR,
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
, I lost the docs on this, but it matches what I remember.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org
);
}
static int gen6_do_reset(struct drm_device *dev)
Can't find docs, but if you tested that wins anyway.
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
On Mon, 19 May 2014 18:13:22 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
This reverts commit f00efff326610fdba92dbc91d951790a3320052e.
This is a temporary revert since I want QA to first test with the
original testcase whether it got faster again. This is to test the
effects of
Yeah
, such machines won't resume correctly much of the time,
with the symptom being a 'port ready' timeout and/or a link training
failure.
v2: extract simpler set_power_well function for use in reset_dpio (Imre)
move to reset_dpio (Daniel Ville)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
, right? If so, we ought to fix that and only
use it for ones where it's necessary (e.g. wait events or similar). I
agree with Ken and Chris here.
Chris?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, May 16, 2014 at 12:05:45PM -0700, Jesse Barnes wrote:
On Thu, 27 Mar 2014 16:22:44 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
On 03/27/2014 03:44 PM, Daniel Vetter wrote:
On Thu, Mar 27
On Fri, 16 May 2014 12:34:08 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Yes, X only sets the secure bit when it pokes the display registers, and
those registers should be privileged even with a cmd
On Fri, 16 May 2014 20:49:30 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, May 16, 2014 at 12:34:08PM -0700, Jesse Barnes wrote:
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
We haven't even fixed the major regression from enabling FBC
On Fri, 16 May 2014 13:12:27 -0700
Volkin, Bradley D bradley.d.vol...@intel.com wrote:
On Fri, May 16, 2014 at 12:53:30PM -0700, Jesse Barnes wrote:
On Fri, 16 May 2014 12:34:08 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson ch
on all platforms.
I haven't thought it through for the other power wells, but that type
of approach may make more sense than trying to abstract the wells at
the high level we're doing today, especially since things are likely to
get finer grained over time rather than coarser.
--
Jesse Barnes
, ifbdev-helper, sizes-fb_width,
sizes-fb_height);
Is it sufficient to just revert this part? Or are the other bits
needed too?
Sorry for the delay on this, I've been traveling a lot the past month
and buried in other stuff so out of touch with much of my email.
Thanks,
--
Jesse Barnes, Intel
On Sat, 17 May 2014 00:19:09 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Fri, May 16, 2014 at 02:48:27PM -0700, Jesse Barnes wrote:
On Thu, 24 Apr 2014 23:55:42 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
+ if (enable) {
+ if (!intel_crtc-active
/show_bug.cgi?id=73154
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 56 +++
drivers
config that tries to enable a connector (disabling is easy!).
Based on earlier patches by Jesse Barnes.
v2: Remove Jesse's patch
Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Ville
On Tue, 13 May 2014 08:08:55 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, May 13, 2014 at 12:37 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Like on ILK, the pipe won't be running until later on.
Like on ilk?! Since when is vlv display derived from that? [PATCH
3/4] drm/i915
));
+ modes[i] = list_first_entry(struct drm_display_mode,
+ connector-modes, head);
Please imagine that I wrote this correctly.
Imagining you wrote it correctly:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source
off a separate flag as to whether
the delay was needed, but the above is pretty simple too, albeit VLV
specific.
The pr_crit() could probably be dropped though, and the magic 0x1f
needs a comment.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
easier than with sed.
Way, way too easy.
Why? For an eventual move to embedding drm_device in i915?
May as well move over all the rest of the driver internals that use
drm_device * while you're at it. :) Would be nice to get rid of the
typedef too...
--
Jesse Barnes, Intel Open Source
),
cache_level, true);
+
if (++act_pte == I915_PPGTT_PT_ENTRIES) {
kunmap_atomic(pt_vaddr);
pt_vaddr = NULL;
Some extra whitespace here.
Otherwise:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Might be good to expose
think Chris meant that these bits belonged in intel_gen6_power_mgmt
too.
Other than that it looks like Ville has given this his r-b so it ought
to be fine.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
;
+
index += current_size;
}
Oh cool, did we see stuff in the wild where it all went sideways?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On Wed, 14 May 2014 00:30:34 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, May 13, 2014 at 03:05:24PM -0700, Jesse Barnes wrote:
On Tue, 11 Feb 2014 14:19:03 +0530
akash.g...@intel.com wrote:
@@ -810,6 +815,7 @@ static void gen6_ppgtt_insert_entries(struct
i915_address_space
On Wed, 14 May 2014 00:32:30 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, May 13, 2014 at 02:53:22PM -0700, Jesse Barnes wrote:
On Tue, 13 May 2014 22:26:08 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, May 13, 2014 at 11:51:11AM -0700, clinton.a.tay...@intel.com
wrote
On Tue, 13 May 2014 14:56:28 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 13 May 2014 22:22:00 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
coccinelle is seriously a tool I should have played around with much
earlier. Extremely powerful, and extremely dangerous
Like on ILK, the pipe won't be running until later on.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c65e7f7
On Tue, 15 Apr 2014 19:17:59 +0200
Daniel Vetter daniel.vet...@intel.com wrote:
Ok there are a few cases where we can indeed make tests faster, but it
will be work for us. And that won't really speed up much since we're
adding piles more testcases at a pretty quick rate. And many of these
new
, then call a generic function which
will warn. I'd prefer to just expose the specific domains directly for
low level platform code like this.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_pm.c |4 ++--
drivers/gpu/drm/i915/intel_uncore.c | 19
On Fri, 11 Apr 2014 19:16:32 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Apr 11, 2014 at 10:00:16AM -0700, Jesse Barnes wrote:
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
that it resets the whole common lane section of the PHY. This is
required on machines
On Fri, 11 Apr 2014 20:26:24 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Apr 11, 2014 at 10:00:16AM -0700, Jesse Barnes wrote:
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
that it resets the whole common lane section of the PHY
On Fri, 11 Apr 2014 21:10:21 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Apr 11, 2014 at 10:35:40AM -0700, Jesse Barnes wrote:
On Fri, 11 Apr 2014 20:26:24 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Apr 11, 2014 at 10:00:16AM -0700, Jesse
We do this wait elsewhere, so drop it to speed things up a bit.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 728a5db..7642415
I don't think this is necessary; at least it doesn't appear to be on my
BYT. Dropping it speeds up our shutdown code a little, in some cases
resulting in faster init times.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 3 ---
1 file changed, 3
On Mon, 07 Apr 2014 11:36:46 +0300
Jani Nikula jani.nik...@linux.intel.com wrote:
On Sat, 05 Apr 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
This only applies to external sinks.
[citation needed]
eDP 1.3 has SET_POWER_CAPABLE (bit 7) in in DPCD
EDP_GENERAL_CAPABILITY_REGISTER_1
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 benjamin.widaw...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Dave Airlie airl
On Sat, 5 Apr 2014 17:21:04 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Apr 04, 2014 at 03:12:08PM -0700, Jesse Barnes wrote:
Needs to happen after clock is running or it doesn't behave correctly.
v2: fix subject (Ville)
make it clearer that this occurs in pre_enable (Paulo
Needs to happen after clock is running or it doesn't behave correctly.
v2: fix subject (Ville)
make it clearer that this occurs in pre_enable (Paulo)
misc bikesheds (Paulo)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_hdmi.c | 18
On Sat, 5 Apr 2014 17:22:40 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Sat, Apr 05, 2014 at 07:29:22AM +0100, Chris Wilson wrote:
On Fri, Apr 04, 2014 at 04:12:09PM -0700, Jesse Barnes wrote:
This always indicates a bug somewhere.
We keep turning this off because we hadn't fixed all
Needs to happen after clock is running or it doesn't behave correctly.
v2: fix subject (Ville)
make it clearer that this occurs in pre_enable (Paulo)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_hdmi.c | 18 --
1 file changed, 16
Needs to happen after clock is running or it doesn't behave correctly.
v2: fix subject (Ville)
make it clearer that this occurs in pre_enable (Paulo)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_hdmi.c | 18 --
1 file changed, 16
The spec changed the order awhile back to put the ports at the end
again, but we never updated. Things seem to work ok either way, but
apparently there are some failures fixed by the new order, so let's just
go ahead and do it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers
This always indicates a bug somewhere.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6a6406f
This is supposed to fix some eDP PPS issues on some platforms.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
This only applies to external sinks.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7642415..df7cc11 100644
On Thu, 3 Apr 2014 17:19:56 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Apr 02, 2014 at 10:08:54AM -0700, Jesse Barnes wrote:
Needs to happen after clock is running or it doesn't behave correctly.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915
On Thu, 3 Apr 2014 22:55:24 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Apr 3, 2014 at 6:49 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
static bool intel_hdmi_get_hw_state(struct intel_encoder *encoder,
@@ -738,9 +736,13 @@ static void intel_enable_hdmi(struct intel_encoder
freqs used on current machines matches.
---
I don't know what to do about this... I don't have a bunch of machines
to test with, and the docs say different.
But if you have feedback from the hw guys, I guess
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source
In case we end up bouncing these around between ports.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_hdmi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index
Allows sending of the null packets for conformance.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_hdmi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index
We also do a disable later when we write a specific infoframe, but here
we do it to prevent sending a stale one before updating the infoframes.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_hdmi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions
Needs to happen after clock is running or it doesn't behave correctly.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_hdmi.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915
These all have a
Tested-by: Joon Jung joon.j...@intel.com
too.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
(intel_crtc);
/* pipesrc and dspsize control the size that is scaled from,
Yeah I like it.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
;
}
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
enable_mask) == 0)
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
(dev_priv-info.display_mmio_offset + 0x70080)
Oh fun.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
@@
#include i915_trace.h
#include intel_drv.h
+#define CACHELINE_BYTES 64
+
Are you sure it's 64 on every gen? It changes on the CPU side from
time to time... I thought it might have changed over time on the GPU
too but I haven't checked the specs.
Either way a doc ref would be nice here.
--
Jesse
(ring, val)
I915_WRITE(RING_MI_MODE((ring)-mmio_base), val)
enum intel_ring_hangcheck_action {
HANGCHECK_IDLE = 0,
Bad Chris, mixing a nice refactor and a nice fix in the same patch.
I'll still give you a cookie though.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse
things down on suspend?
Maybe it's all the refactoring making me miss it. :)
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
in this case? If so,
then
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 01 Apr 2014 10:19:29 +0300
Jani Nikula jani.nik...@linux.intel.com wrote:
On Mon, 31 Mar 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
To make sure we properly follow the enable/disable sequences.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm
On Tue, 01 Apr 2014 12:27:43 +0300
Jani Nikula jani.nik...@linux.intel.com wrote:
On Tue, 01 Apr 2014, Jani Nikula jani.nik...@linux.intel.com wrote:
On Mon, 31 Mar 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
To make sure we properly follow the enable/disable sequences.
Signed-off
On Tue, 01 Apr 2014 11:08:13 +0300
Jani Nikula jani.nik...@linux.intel.com wrote:
On Mon, 31 Mar 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
Going below the minimum value may affect the BLC_EN line, so try to use
the VBT provided minimum where possible, otherwise use an experimentally
With the new checks in place, we can see we're doing things backwards,
so fix them up per the spec.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915
To make sure we properly follow the enable/disable sequences.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c| 62 --
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_panel.c | 5 ++-
3 files
Going below the minimum value may affect the BLC_EN line, so try to use
the VBT provided minimum where possible, otherwise use an experimentally
derived value to prevent the panel from coming up.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h| 1
of these conditions 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 vandana.kan...@intel.com
Cc: Jesse Barnes jesse.bar...@intel.com
Cc
601 - 700 of 2916 matches
Mail list logo
