between all three register formats */
intel_dp-DP |= DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;
Thanks. Wonder if we're clobbering any other BIOS must set this bit
and no one should touch it again bits elsewhere...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open
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
: https://bugzilla.kernel.org/show_bug.cgi?id=58971
Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
My hero!
So the later init change didn't work?
Either
{
+ i915_gem_write_fence(dev, i, NULL);
+ }
Why do we look at reg-obj here? Can it be NULL? Or would
reg-obj-tiling_mode != I915_TILING_NONE do the same thing?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
This should allow userland tools running under X to submit secure
batches for various things. This gives master DRM clients slightly more
permissions, but doesn't give regular processes any more, since a root
process can already map the registers directly and poke at hw.
Signed-off-by: Jesse
On Wed, 17 Jul 2013 21:20:07 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Jul 17, 2013 at 09:45:30AM -0700, Jesse Barnes wrote:
This should allow userland tools running under X to submit secure
batches for various things. This gives master DRM clients slightly more
differ, it might be better
to simply take an argv for the values, and have the sim vs. full
scripts pass different values.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
Since this is actual RAM space we can clobber any padding intended to
prevent MMIO allocations in this space.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_gem_stolen.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
map (like the i915
driver). So add a new entry point to allow this, that will shrink the
RAM buffer padding if needed.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/linux/ioport.h |6
kernel/resource.c | 75
2 files
Since we need to use them in early x86 boot code.
Signed-off-by: Jesse Barnes jbar...@virtuosugeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 158 ++
include/drm/i915_drm.h | 180 +++
2 files changed, 208 insertions
We need to do this early on before the E820 map is modified or
conflicting resources assigned on top.
---
arch/x86/kernel/early-quirks.c | 91
1 file changed, 91 insertions(+)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
This is getting ugly; looking for feedback.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
For use by userspace (at some point in the future) and other kernel code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 158 ++
include/drm/i915_drm.h | 180 +++
2 files
the efforts of the RAM buffer approach, which simply rounds memory
boundaries up to 64M to try to catch space that may decode as RAM and so
is not suitable for MMIO.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/include/asm/pci-direct.h |1 +
arch/x86/kernel/early-quirks.c| 150
;
+}
This is just read_pci_config().
Oops missed it probably due to the consistent naming (_byte, _16, maybe
we should add a _24). Will drop that bit.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 158 ++---
include/drm/i915_drm.h
-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/kernel/early-quirks.c | 175 +++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32 +++
3 files changed, 207 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/early
pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/kernel/early-quirks.c | 158 +++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32
3 files changed, 190
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 164
Patch 2/2 has the description, but suffice it to say I'm not really
pleased with this, though it does solve a problem we have. On some
machines, we get MMIO space allocated on top of this hidden memory,
which can cause problems. I'm not sure if there are similar problems
for other hunks of the
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 164
pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/kernel/early-quirks.c | 158 +++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32
3 files changed, 190
Art confirms that this should work fine. Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1
On Thu, 25 Jul 2013 18:17:59 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
Art confirms that this should work fine. Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases
On Thu, 25 Jul 2013 22:05:51 +0200
Ingo Molnar mi...@kernel.org wrote:
* Jesse Barnes jbar...@virtuousgeek.org wrote:
Patch 2/2 has the description, but suffice it to say I'm
not really pleased with this, though it does solve a
problem we have. On some machines, we get MMIO space
wrote:
So the bootloader is just as likely to step on things... what happens when/if
it does?
Ingo Molnar mi...@kernel.org wrote:
* Jesse Barnes jbar...@virtuousgeek.org wrote:
Patch 2/2 has the description, but suffice it to say I'm
not really pleased with this, though it does solve
On Thu, 25 Jul 2013 23:59:25 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Hmm, interesting licence block in i915_pciids.h - our claim to
grant licence but TG disclaims liability.
Oops my manual search replace obviously failed. Will fix up.
--
Jesse Barnes, Intel Open Source
To clarify: it'll either be marked reserved or not listed at all in e820, which
is why I did this early, before any other e820 stuff like the RAM buffer are
allocated, and before we could use the iomem resource (or maybe we could even
early per Linus? I'll check).
Jesse
--
Jesse Barnes
On Thu, 25 Jul 2013 20:31:27 -0700
H. Peter Anvin h...@zytor.com wrote:
On 07/25/2013 07:14 PM, Jesse Barnes wrote:
To clarify: it'll either be marked reserved or not listed at all in e820,
which is why I did this early, before any other e820 stuff like the RAM
buffer are allocated
: reserved
cba0-cf9f : Graphics Stolen Memory
cfa0-feaf : PCI Bus :00
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel
?
--
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 Fri, 26 Jul 2013 09:58:45 -0700
H. Peter Anvin h...@zytor.com wrote:
On 07/25/2013 09:37 AM, Jesse Barnes wrote:
Systems with Intel graphics controllers set aside memory exclusively for
+ /*
+* Almost universally we can find the Graphics Base of Stolen Memory
+* at offset
On Fri, 26 Jul 2013 18:08:48 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, Jul 26, 2013 at 09:59:42AM -0700, Jesse Barnes wrote:
4) review comments should be concrete and actionable, and ideally not
leave the author hanging with hints about problems the reviewer
These address the comments I've received so far, but omit the new E820
type for this mem.
Chris's patches could go on top if desired; they add a new type and
resource reservation function for looking up regions by name. That
allows us to remove some duplicate code in the driver for finding
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
v4: fix up PCI match structure init for easier use by userspace (Chris)
Signed-off-by: Jesse Barnes
-rps.min_delay = (rp_state_cap 0xff) 16;
+ dev_priv-rps.rp1_delay = (rp_state_cap 0xff00) 8;
dev_priv-rps.cur_delay = 0;
/* disable the counters and set deterministic thresholds */
--
Jesse Barnes, Intel Open Source Technology Center
on refactoring and rebasing his
PC8 stuff is time he could have spent on HSW bugs instead. Likewise
with Ben's stuff (and there the rebasing is actually reducing quality
rather than increasing it, at least from a bug perspective).
--
Jesse Barnes, Intel Open Source Technology Center
that will inevitably come in,
both from new test programs and from general usage. On top of that, if
someone is trying to refactor at the same time, things just become a
mess with all sorts of regressions introduced that weren't an issue
with the original patchset...
--
Jesse Barnes, Intel Open Source
to get you the NDA docs that should have the
info you need.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
/refactor bottleneck actively undermines the goals I think we
share.
But I'm done with this thread. Maybe others want to comment on things
they might think improve the situation.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
) SDVO_DETECTED) {
intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIB,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel
this as a fix in future releases?
-Ryan
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Wednesday, August 07, 2013 8:49 AM
To: Daniel Vetter
Cc: Matsumura, Ryan; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Second HDMI port not visible
On Wed
-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a0914db..fe37908 100644
--- a/drivers/gpu/drm/i915
(Jesse)
v3: fix TX and RX disable per spec (Paulo)
fix delays per spec (Paulo)
make RX symbol lock check match TX bit lock check (Paulo)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 142 +-
1 file changed, 72
On Sun, 18 Aug 2013 21:09:59 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Apr 08, 2013 at 05:50:07PM -0300, Paulo Zanoni wrote:
Hi
2013/3/28 Jesse Barnes jbar...@virtuousgeek.org:
The existing code was trying different vswing and preemphasis settings
in the wrong place
might need to avoid writing it on
resume...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Turns out the BIOS will do this for us as needed, and if we try to do it
again we risk hangs or other bad behavior.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_pm.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm
On Wed, 21 Aug 2013 23:23:04 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 21, 2013 at 08:08:55AM -0700, Jesse Barnes wrote:
Turns out the BIOS will do this for us as needed, and if we try to do it
again we risk hangs or other bad behavior.
Signed-off-by: Jesse Barnes jbar
current time in case interrupted by signal, or wedged * */
getrawmonotonic(before);
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
the right thing (when we use the
OpRegion stuff Jani did anyway).
Paulo, are you still out celebrating the PC8 bits or have you had a
chance to try this yet?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
On Fri, 23 Aug 2013 13:49:57 -0300
Paulo Zanoni przan...@gmail.com wrote:
2013/8/22 Jesse Barnes jbar...@virtuousgeek.org:
On Wed, 21 Aug 2013 15:29:17 +
Lin, Mengdong mengdong@intel.com wrote:
Hi Ben,
How will Gfx driver support runtime PM on Haswell? Will the Gfx driver
structure, and also
change the error from DRM_ERROR-DRM_INFO.
I hate this param.
But this looks like a better way to do it than the ID list we had in
pci_probe before.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
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, 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
/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
, 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
);
}
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
(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
801 - 900 of 2916 matches
Mail list logo
