p; DP_DETECTED;
> + intel_dp->DP = I915_READ(intel_dp->output_reg) &
> +(DP_DETECTED | DDI_A_4_LANES);
>
> /* Handle DP bits in common between all three register formats */
> intel_dp->DP |= DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;
Thanks.
er than 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 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 forcew
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
://bugs.freedesktop.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?
Eithe
gt; + } else {
> + 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
_
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:
On Wed, 17 Jul 2013 21:20:07 +0100
Chris Wilson 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
> > per
s 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://lists.fr
On Thu, 18 Jul 2013 17:55:00 +0100
Damien Lespiau wrote:
> On Thu, Jul 18, 2013 at 09:31:15AM -0700, Ben Widawsky wrote:
> > On Thu, Jul 18, 2013 at 09:18:34AM -0700, Jesse Barnes wrote:
> > > On Thu, 18 Jul 2013 16:19:07 +0100
> > > Damien Lespiau wrote:
> >
Since this is actual RAM space we can clobber any padding intended to
prevent MMIO allocations in this space.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem_stolen.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
n the E820 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
---
include/linux/ioport.h |6
kernel/resource.c | 75
Since we need to use them in early x86 boot code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 158 ++
include/drm/i915_drm.h | 180 +++
2 files changed, 208 insertions(+), 130 deletions(-)
diff
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
i
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
---
drivers/gpu/drm/i915/i915_drv.c | 158 ++
include/drm/i915_drm.h | 180 +++
2 files changed, 208 insertions
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
---
arch/x86/include/asm/pci-direct.h |1 +
arch/x86/kernel/early-quirks.c
arch/x86/pci/early.c
> > +++ b/arch/x86/pci/early.c
> > @@ -31,6 +31,14 @@ u16 read_pci_config_16(u8 bus, u8 slot, u8 func, u8
> > offset)
> > return v;
> > }
> >
> > +u32 read_pci_config_32(u8 bus, u8 slot, u8 func, u8 offset)
> > +{
> > + u32 v;
> > + outl(0x8000 | (bus<<16) | (slot<<11) | (func<<8) | offset, 0xcf8);
> > + v = inl(0xcfc);
> > + return v;
> > +}
>
> 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@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.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 158 ++---
include/drm/i915_drm.h |2 +
include/drm
ned-off-by: Jesse Barnes
---
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-quirks.c
a function pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes
---
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 inserti
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
---
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 ad
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
---
drivers/gpu/drm/i915/i915_drv.c | 164
a function pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes
---
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 inserti
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
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On Thu, 25 Jul 2013 18:17:59 +0100
Chris Wilson 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
> &
On Thu, 25 Jul 2013 22:05:51 +0200
Ingo Molnar wrote:
>
> * Jesse Barnes 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 spa
eter Anvin" wrote:
> So the bootloader is just as likely to step on things... what happens when/if
> it does?
>
> Ingo Molnar wrote:
> >
> >* Jesse Barnes wrote:
> >
> >> Patch 2/2 has the description, but suffice it to say I'm
> >> n
On Thu, 25 Jul 2013 23:59:25 +0100
Chris Wilson 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 Technol
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).
Jes
On Thu, 25 Jul 2013 20:31:27 -0700
"H. Peter Anvin" 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 "
ffer
cfa0-feaf : PCI Bus :00
d000-dfff : :00:02.0
After (yay):
cb00-cb9f : RAM buffer
cba0-cf9f : 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-gfx
onable, and ideally not
leave the author hanging with hints about problems the reviewer
has spotted, leaving the author looking for easter eggs
For the most part I think we adhere to this, though reviews from the
domain experts are done more on an ad-hoc basis these days...
Thoughts?
--
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" 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 M
On Fri, 26 Jul 2013 18:08:48 +0100
Chris Wilson 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 stolen
v3: use a function pointer (Chris)
drop gen2 bits (Daniel)
v4: call e820_sanitize_map after adding the region
v5: fixup comments (Peter)
simplify loop (Chris)
Acked-by: Ingo Molnar
Signed-off-by: Jesse Barnes
---
arch/x86/kernel/early-quirks
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
elay);
> + else
> + gen6_set_rps(dev_priv->dev, new_delay);
>
> if (IS_VALLEYVIEW(dev_priv->dev)) {
> /*
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 4e6d618..e9e467c 100644
> --- a/drivers/g
since vague feedback is more likely to leave a
patchset in the doldrums and de-motivate the author.
I think the "slowing things down" may hurt more than it helps here.
For example all the time Paulo spends on refactoring and rebasing his
PC8 stuff is time he could have spent on H
7;T BE TESTED* reasonably. So if
you're waiting for all tests to be written before going upstream, all
you're doing is delaying the bug reports 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 sa
mplicated, but 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
I've botched the job (there are plentiful to pick from
> imo) and concrete suggestion for how to improve our overall process.
I've suggested some already, but they've fallen on deaf ears afaict. I
don't know what more I ca
if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIB) & 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-gfx
is 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] Se
Ryan noticed that on his board, HDMI was wired up to port C but not
exposed by the kernel, which had only expected DP on that port. Fix
that up by enumerating both ports if possible.
Tested-by: "Matsumura, Ryan"
Acked-by: Chris Wilson
Signed-off-by: Jesse Barnes
---
drivers/gp
hecks (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
---
drivers/gpu/drm/i915/intel_display.c | 142 +-
1 file changed, 72 insertions(+
On Sun, 18 Aug 2013 21:09:59 +0200
Daniel Vetter wrote:
> On Mon, Apr 08, 2013 at 05:50:07PM -0300, Paulo Zanoni wrote:
> > Hi
> >
> > 2013/3/28 Jesse Barnes :
> > > The existing code was trying different vswing and preemphasis settings
> > > in the wro
reg is 0. And after resume, it is broken, and that
> reg is still 0. So something else is going on. Maybe this reg is
> write-once-ever?
Apparently it is. And if the BIOS writes that bit, we're not supposed
to write it either. However, since it's WO, we can't easily tell if
it
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
---
drivers/gpu/drm/i915/intel_pm.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers
On Wed, 21 Aug 2013 23:23:04 +0200
Daniel Vetter 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.
> >
> >
On Tue, 15 Apr 2014 19:17:59 +0200
Daniel Vetter 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 testcases are CRC ba
Like on ILK, the pipe won't be running until later on.
Signed-off-by: Jesse Barnes
---
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..c66d2ea 100644
On Tue, 13 May 2014 08:08:55 +0200
Daniel Vetter wrote:
> On Tue, May 13, 2014 at 12:37 AM, Jesse Barnes
> 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/i91
r->modes)) {
> > + DRM_DEBUG_KMS("using first mode listed on connector
> > %s\n",
> > + drm_get_connector_name(connector));
> > + modes[i] = list_first_entry(struct drm_display_mode,
> > +
en't full done a PPS, we'll get into
trouble and potentially confuse the panel in the worst case.
Previous BIOS-free systems may have had this problem too, but this was
the first one we got an actual eDP timing spec violation about, so it's
a good first step. It can easily be ext
er 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 S
ddress(&sg_iter),
> 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
Might be good
ei calculation */
> + struct intel_rps_ei_calc rps_down_ei;
> +
I 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
_
n NULL;
> +
> if (current_id == section_id)
> return base + index;
> +
> index += current_size;
> }
>
Oh cool, did we see stuff in the wild where it all went sideways?
--
Jesse Barnes, Intel Open Source Technology Center
_
On Wed, 14 May 2014 00:30:34 +0200
Daniel Vetter 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
On Wed, 14 May 2014 00:32:30 +0200
Daniel Vetter 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 wrote:
> >
> > > On Tue, May 13, 2014 at 11:51:11AM -0700, clinton.a.tay...@intel.
On Tue, 13 May 2014 14:56:28 -0700
Jesse Barnes wrote:
> On Tue, 13 May 2014 22:22:00 +0200
> Daniel Vetter wrote:
>
> > coccinelle is seriously a tool I should have played around with much
> > earlier. Extremely powerful, and extremely dangerous in causing
> >
Bugzilla: 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|
hat 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ä
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> Cc: Ville Syrjälä
> -
but enabling it universally is *not* OK.
Daniel, I'm not sure what you mean by 0 coverage. Surely DRI clients
count for something? And X shouldn't be submitting all its batches
with the secure bit set, right? If so, we ought to fix that and only
use it for ones where it's necessary
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson 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 wrote:
> >
> > > On 03/27/2014 03:44 PM, Daniel Vetter wrote:
> > > >
On Fri, 16 May 2014 12:34:08 -0700
Jesse Barnes wrote:
> On Fri, 16 May 2014 20:20:50 +0100
> Chris Wilson wrote:
> > Yes, X only sets the secure bit when it pokes the display registers, and
> > those registers should be privileged even with a cmd parser in place
&
On Fri, 16 May 2014 20:49:30 +0100
Chris Wilson 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 wrote:
> > > We haven't even fixed the major regression from enabling FBC. What
On Fri, 16 May 2014 13:12:27 -0700
"Volkin, Bradley D" 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 wrote:
> >
> > > On Fri, 16 May 2014 20:20:50 +0100
> > >
per-platform and save us the
"get_crtc_power_domains" call which may not make sense 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,
drm_fb_helper_fill_var(info, &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 o
On Sat, 17 May 2014 00:19:09 +0200
Daniel Vetter 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 wrote:
> >
> > > + if (enable) {
> > > + if (!intel_crtc->
val)
> {
> vlv_sideband_rw(dev_priv, DPIO_DEVFN,
> DPIO_PHY_IOSF_PORT(DPIO_PHY(pipe)),
> - DPIO_OPCODE_REG_WRITE, reg, &val);
> + SB_MWR_NP, reg, &val);
> }
>
> /* SBI access */
> @@ -261,13 +270,13 @@ void intel_sbi_writ
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRWRDA_NP,
> reg, &val);
> }
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 Barn
b/lib/intel_reg.h
> index 4b3a102..5520624 100644
> --- a/lib/intel_reg.h
> +++ b/lib/intel_reg.h
> @@ -3576,9 +3576,4 @@ typedef enum {
> #define VLV_IOSF_DATA(VLV_DISPLAY_BASE +
> 0x2104)
> #define VLV_IOSF_ADDR(VLV_D
60*HZ) == 0);
>
> mutex_lock(&dev->struct_mutex);
> intel_finish_fb(crtc->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 Barn
here's no such config for x86.
>
> There's CONFIG_X86_32 though. Which I think matches the original
> approach of #ifndef CONFIG_64BIT in the referenced bug. However, "with
> this patch only, the system still hung while booting." [1].
>
> I want a new patc
On Mon, 19 May 2014 18:10:18 +0300
Imre Deak wrote:
> On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
> > On Mon, 19 May 2014 11:41:18 +0300
> > Imre Deak wrote:
> >
> > > So far we used the wrong opcodes to access the DSI registers, so the
> > >
On Mon, 19 May 2014 17:18:40 +0200
Daniel Vetter 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 wrote:
> >
> > > We can apperently miss them, but breaking the entire driver hampers
&g
(ret)
> return ret;
>
> - /* We can't reset render&media without also resetting display ... */
> gdrst = I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR);
> gdrst &= ~GRDOM_MASK;
> I915_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR,
Reviewed-by: Jesse Barn
GRDOM_RESET_ENABLE) == 0, 500);
> }
>
> static int gen6_do_reset(struct drm_device *dev)
Arg, I lost the docs on this, but it matches what I remember.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
15_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR,
> -gdrst | GRDOM_MEDIA | GRDOM_RESET_ENABLE);
> +gdrst | ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
> return wait_for((I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR) &
> - GRDOM_RESET_ENABLE) == 0, 500);
>
On Mon, 19 May 2014 18:13:22 +0200
Daniel Vetter 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 this is fine as lo
patch, 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 Barn
reset is already de-asserted (Imre)
Signed-off-by: Jesse Barnes
---
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
On Mon, 19 May 2014 16:16:37 -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 where the BIOS doesn't do this for us on boot or
> resu
ASK;
> I915_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR,
> -gdrst | ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
> +ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
> return wait_for((I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR) &
>
SR) &
> + ILK_GRDOM_RESET_ENABLE) == 0, 500);
> + 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
--
e 5: return ironlake_do_reset(dev);
> - case 4: return i965_do_reset(dev);
> + case 4:
> + if (IS_G4X(dev))
> + return g4x_do_reset(dev);
> + else
> + return i965_do_re
e->vsync_start &&
> - scan->vsync_end == fixed_mode->vsync_end &&
> - scan->vtotal == fixed_mode->vtotal) {
> - if (scan->clock < temp_downclock) {
> - /*
> -
props.brightness = scale_hw_to_user(connector,
> + panel->backlight.level,
> + props.max_brightness);
>
> /*
>* Note: using the same name independent of the connector prevents
> @@ -965
On Fri, 16 May 2014 23:42:23 +0100
Chris Wilson 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 wrote:
> > &
On Tue, 20 May 2014 12:53:29 -0700
Jesse Barnes wrote:
> On Fri, 16 May 2014 23:42:23 +0100
> Chris Wilson 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 wrote:
> On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> wrote:
> > Ah, poll_enable is false until after _thaw finishes, so
> > our hotplug_resume call of hpd_irq_event does nothing. So aside from
> > the encoder h
On Tue, 20 May 2014 14:10:16 -0700
Jesse Barnes wrote:
> On Tue, 20 May 2014 22:15:45 +0200
> Daniel Vetter wrote:
>
> > On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> > wrote:
> > > Ah, poll_enable is false until after _thaw finishes, so
> > > our ho
On Tue, 20 May 2014 14:18:07 -0700
Jesse Barnes wrote:
> On Tue, 20 May 2014 14:10:16 -0700
> Jesse Barnes wrote:
>
> > On Tue, 20 May 2014 22:15:45 +0200
> > Daniel Vetter wrote:
> >
> > > On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> > >
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
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
201 - 300 of 3350 matches
Mail list logo
