On Tue, 21 Oct 2014 16:53:02 +0200
Daniel Vetter wrote:
> On Thu, Oct 09, 2014 at 12:57:45PM -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
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?
Eve
From: Kristian Høgsberg
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 Barnes
---
drivers/gpu/drm
From: Kristian Høgsberg
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.c | 8
include/drm
)
v3: trust BIOS configuration over VBT like we do for DP (Jani)
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
framebuffer (Daniel)
check display swizzle setting in detect_bit_6_swizzle (Daniel)
use gen6 as cutoff point (Daniel)
v4: fixup swizzle preserve again, had wrong init order (Daniel)
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.
v2: use a delayed work queue instead (Daniel)
v3: cancel delayed work at unload and suspend time (Jesse)
v4: make delayed work comment less scary (Chris)
Signed-off-by: Jesse Barnes
---
drivers/gpu
On Thu, 9 Oct 2014 11:11:32 +0100
Chris Wilson wrote:
> On Wed, Oct 08, 2014 at 07:32:12AM -0700, Jesse Barnes wrote:
> > On Wed, 8 Oct 2014 07:43:34 +0100
> > Chris Wilson wrote:
> >
> > > On Tue, Oct 07, 2014 at 01:25:23PM -0700, Jesse Barnes wrote:
> >
On Wed, 8 Oct 2014 07:43:34 +0100
Chris Wilson wrote:
> On Tue, Oct 07, 2014 at 01:25:23PM -0700, Jesse Barnes wrote:
> > Gets the detect code (which may take awhile) out of the resume path,
> > speeding things up a bit.
> >
> > v2: use a delayed work queue instead (
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.
v2: use a delayed work queue instead (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c | 10 ++
drivers/gpu/drm/i915/i915_drv.c | 8 ++--
drivers/gpu/drm/i915
har __user
> *buffer, 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 opera
0x00F0) == 0x0020)
> #define IS_HSW_ULT(dev) (IS_HASWELL(dev) && \
>(INTEL_DEVID(dev) & 0xFF00) == 0x0A00)
> #define IS_ULT(dev) (IS_HSW_ULT(dev) || IS_BDW_ULT(dev))
Looks correct based on the configs I&#x
On Mon, 29 Sep 2014 09:52:38 -0700
Rodrigo Vivi wrote:
> On Mon, Sep 29, 2014 at 9:38 AM, Daniel Vetter wrote:
> > On Mon, Sep 29, 2014 at 08:48:53AM -0700, Jesse Barnes wrote:
> >> On Mon, 29 Sep 2014 15:11:51 +0200
> >> Daniel Vetter wrote:
>
On Mon, 29 Sep 2014 15:11:51 +0200
Daniel Vetter wrote:
> This reverts commit c76bb61a71083b2d90504cc6d0dda2047c5d63ca.
>
> It's apparently too broken so that Rodrigo submitted a patch to add a
> config option for it. Given that the design is also ... suboptimal and
> that I've only merged this
This moved around on SKL, so we need to make sure we read/write the
correct regs.
v2: fixup WIN_POS offsets (Paulo)
zero out WIN_POS reg at disable time (Paulo)
Signed-off-by: Jesse Barnes
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 12 +++
drivers/gpu/drm
On Tue, 23 Sep 2014 17:50:29 -0300
Paulo Zanoni wrote:
> 2014-09-04 8:27 GMT-03:00 Damien Lespiau :
> > From: Jesse Barnes
> >
> > This moved around on SKL, so we need to make sure we read/write the
> > correct regs.
> >
> > Signed-off-by: Jesse Ba
* Use the maximum clock and number of lanes the
> >> eDP panel
> >> + * advertizes being capable of. Typically these
> >> values
> >> + * correspond to the native resolution of the
> >> panel.
> >> + */
> >&
On Tue, 26 Aug 2014 13:09:54 -0400
Charles Devereaux wrote:
> Hello
>
> I'm trying to use i915.fastboot on a Thinkpad X60t. The bios has been
> replaced by coreboot, which supports native video init.
>
> The goal is to boot to a console on a debian in less than 2 seconds
> (kernel
> + systemd),
On Tue, 2 Sep 2014 13:45:37 +0300
Ville Syrjälä wrote:
> On Tue, Sep 02, 2014 at 09:24:48AM +0100, Chris Wilson wrote:
> > As we may query the edid multiple times following a detect, record
> > the EDID found during output discovery and reuse it. This is a
> > separate issue from caching the outp
On Thu, 11 Sep 2014 14:59:35 +0300
Imre Deak wrote:
> On Thu, 2014-09-11 at 08:49 +0100, Chris Wilson wrote:
> > On Wed, Sep 10, 2014 at 06:17:01PM +0300, Imre Deak wrote:
> > > Since correctness wins over optimal code and since the optimization
> >
> > Optimal code is also correct ;-) s/optimal
On Tue, 09 Sep 2014 21:45:08 +0530
Deepak S wrote:
>
> On Monday 08 September 2014 08:10 PM, Daniel Vetter wrote:
> > On Mon, Sep 08, 2014 at 05:14:23PM +0300, Ville Syrjälä wrote:
> >> On Mon, Sep 08, 2014 at 05:02:43PM +0300, Ville Syrjälä wrote:
> >>> On Tue, Sep 09, 2014 at 07:14:16PM +0530,
On Mon, 8 Sep 2014 18:28:20 +0200
Daniel Vetter wrote:
> This was lost in
>
> commit e11aa362308f5de467ce355a2a2471321b15a35c
> Author: Jesse Barnes
> Date: Wed Jun 18 09:52:55 2014 -0700
>
> drm/i915: use runtime irq suspend/resume in freeze/thaw
>
> whi
gt; self-checks fire and complain.
> >
> > To fix that set the tracking boolen before enabling the irqs with
> > drm_irq_install. Quoting the discussion with Jesse why that's safe:
> >
> > On Tue, Aug 26, 2014 at 11:18 PM, Jesse Barnes
> > wrote:
> >
On Thu, 4 Sep 2014 18:59:55 +0200
Daniel Vetter wrote:
> On Thu, Sep 4, 2014 at 6:24 PM, Jesse Barnes wrote:
> > On Thu, 4 Sep 2014 17:59:18 +0200
> > Daniel Vetter wrote:
> >
> >> On Thu, Aug 28, 2014 at 1:00 AM, Jesse Barnes
> >> wrote:
> >>
On Thu, 4 Sep 2014 17:59:18 +0200
Daniel Vetter wrote:
> On Thu, Aug 28, 2014 at 1:00 AM, Jesse Barnes
> wrote:
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 9eb303c1b621..76bc4d0de5a4 100644
> >
On Thu, 4 Sep 2014 13:29:06 +0100
Damien Lespiau wrote:
> On Thu, Sep 04, 2014 at 03:03:27PM +0300, Jani Nikula wrote:
> > On Thu, 04 Sep 2014, Damien Lespiau wrote:
> > > From: Jesse Barnes
> > >
> > > No need to mess with display.
> >
> > W
On Wed, 3 Sep 2014 21:41:02 +0200
Daniel Vetter wrote:
> On Wed, Sep 3, 2014 at 9:01 PM, Jesse Barnes wrote:
> > On Wed, 3 Sep 2014 17:08:53 +0100
> > Chris Wilson wrote:
> >> On Wed, Sep 03, 2014 at 08:41:06AM -0700, Jesse Barnes wrote:
> >> > On Wed, 3
On Wed, 3 Sep 2014 08:01:55 +0100
Chris Wilson wrote:
> On Tue, Sep 02, 2014 at 02:32:41PM -0700, Jesse Barnes wrote:
> > Use a new reloc type to allow userspace to insert sync points within
> > batches before they're submitted. The corresponding fence fds are
> > re
Use a new reloc type to allow userspace to insert sync points within
batches before they're submitted. The corresponding fence fds are
returned in the offset field of the returned reloc tree, and can be
operated on with the sync fence APIs.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm
This set includes a sketch of how we might allow fences to be emitted
directly within a batch buffer. This gets rid of the need for flushing
around fence operations, which can be a win, and lets userspace more
finely control things.
If it looks reasonable, we could drop the separate ioctl and jus
using Maarten's new interface
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Kconfig | 2 +
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 10 ++
drivers/gpu/drm/i915/i915_gem.c | 15 +-
drivers/gpu/drm/i915/
On Wed, 27 Aug 2014 10:43:37 +0200
Daniel Vetter wrote:
> Now that vlv has runtime pm we kinda should check for that like on the
> pch split platforms. Looks like this was simply lost in the vlv rpm
> enabling.
>
> Cc: Paulo Zanoni
> Cc: Imre Deak
> Cc: Jesse Barnes
&g
On Wed, 27 Aug 2014 23:33:05 +0200
Daniel Vetter wrote:
> On Wed, Aug 27, 2014 at 9:59 PM, Jesse Barnes
> wrote:
> > Yi, can you get this one run through testing on multiple platforms? We
> > just want to make sure there's not some path we missed that's gonna
Yi, can you get this one run through testing on multiple platforms? We
just want to make sure there's not some path we missed that's gonna
spew a warning with this change.
Thanks,
Jesse
On Tue, 26 Aug 2014 22:51:13 +0200
Daniel Vetter wrote:
>
> On Tue, Aug 26, 2014 at 8:52
On Tue, 26 Aug 2014 22:51:13 +0200
Daniel Vetter wrote:
>
> On Tue, Aug 26, 2014 at 8:52 PM, Jesse Barnes
> wrote:
> > On Tue, 26 Aug 2014 09:23:54 +0200
> > Daniel Vetter wrote:
> >
> >> On Mon, Aug 25, 2014 at 04:24:55PM -0700, Jesse Barnes wrote:
&g
On Tue, 26 Aug 2014 21:03:11 +0200
Oliver Hartkopp wrote:
> On 26.08.2014 20:52, Jesse Barnes wrote:
> > On Tue, 26 Aug 2014 09:23:54 +0200
> > Daniel Vetter wrote:
>
> >>> This happens in irq_postinstall before we've set the pm._irqs_disabled
> >>
On Tue, 26 Aug 2014 09:23:54 +0200
Daniel Vetter wrote:
> On Mon, Aug 25, 2014 at 04:24:55PM -0700, Jesse Barnes wrote:
> > This happens in irq_postinstall before we've set the pm._irqs_disabled flag,
> > but shouldn't warn. So add a nowarn variant to allow this to h
This happens in irq_postinstall before we've set the pm._irqs_disabled flag,
but shouldn't warn. So add a nowarn variant to allow this to happen w/o
a backtrace and keep the rest of the IRQ tracking code happy.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_ir
> Well I admit to not having read the patches over the terrible wifi
> here, but I presumed Ben's patches did implement softpin. I guess I've
> made a mess of all of this now. In any case I still want to see
> relative improvements over what we have since the prelocated stuff
> l
On Mon, 25 Aug 2014 20:29:27 +0200
Oliver Hartkopp wrote:
> Hi Jesse,
>
> since the i915 stuff for 3.17 was merged I always get this
> warning on my core i7 with internal Intel HD graphics.
>
> Intel(R) Core(TM) i7 CPU M 640 @ 2.80GHz
>
> As this warning is triggered by the code which w
e time on this either.
So we're left with this patch, which does improve things for most
cases, or no patch, which leaves things universally bad.
Unless someone wants to pick up the additional work and testing of
using a timer scheme, making sure we don't have needless wakeups, an
ave an x86 compatible MMU in the GPU itself, so re-using the
defines makes sense. I suppose with your work you'll move them and
make them a bit more opaque? If so, we'll still want a way to get at
them directly, or access your mapping f
coded connector
> 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ä
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> Cc: Ville Syrjälä
&
l_dp_set_m_n()
>
> Signed-off-by: Vandana Kannan
> Cc: Daniel Vetter
> Cc: Jesse Barnes
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.c | 28 +---
> drivers/gpu/drm/i915/intel_dp.c | 18 +++---
> driv
On Tue, 5 Aug 2014 19:43:22 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 7:09 PM, Jesse Barnes wrote:
> >> >> >> Then we need similar flags for vblank events and pageflips to do the
> >> >> >> same (obviously those are drm core patches) and it
On Tue, 5 Aug 2014 18:08:16 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 6:05 PM, Jesse Barnes wrote:
> > On Tue, 5 Aug 2014 17:08:22 +0200
> > Daniel Vetter wrote:
> >
> >> On Tue, Aug 5, 2014 at 4:59 PM, Jesse Barnes
> >> wrote:
> >>
On Tue, 5 Aug 2014 18:08:16 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 6:05 PM, Jesse Barnes wrote:
> > But yes, I want the Android guys to try this out too. I've already
> > pinged them internally to check things out. Probably the biggest
> > remaining ope
On Tue, 5 Aug 2014 17:08:22 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 4:59 PM, Jesse Barnes wrote:
> >> This doesn't really look like the interface I'd expected. Imo we just
> >> need to add a flag to execbuf so that userspace can tell the kernel
On Tue, 05 Aug 2014 10:09:56 +0200
Maarten Lankhorst wrote:
> op 05-08-14 01:18, Jesse Barnes schreef:
> > Expose an ioctl to create Android fences based on the Android sync point
> > infrastructure (which in turn is based on DMA-buf fences). Just a
> > sketch at this point
On Tue, 5 Aug 2014 09:44:00 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 1:18 AM, Jesse Barnes wrote:
> > +#define DRM_IOCTL_I915_GEM_FENCE DRM_IOWR
> > (DRM_COMMAND_BASE + DRM_I915_GEM_FENCE, struct drm_i915_gem_fence)
> >
> >
using Maarten's new interface
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Kconfig | 2 +
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 10 ++
drivers/gpu/drm/i915/i915_gem.c | 15 +-
drivers/gpu/drm/i915/
e
ringbuffers and whatever else we allocate out of stolen at early boot.
We might be able to avoid that by doing stolen allocations top down, or
by reserving the displayed fb even if we can't allocate an obj for it,
only freeing it after our first mode set.
Can you file a bug or JIRA for tha
e and I'm afraid we'll run into issues that don't exist
with the execlist path if we stick with the legacy submission path (we
may have already hit one in fact).
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing l
On Fri, 01 Aug 2014 10:04:55 +0100
Tvrtko Ursulin wrote:
> Hi Jesse,
>
> On 07/31/2014 07:58 PM, Jesse Barnes wrote:
> > Expose an ioctl to create Android fences based on the Android sync point
> > infrastructure (which in turn is based on DMA-buf fences). Just a
> &g
associated buffer
2) re-use a common API so userspace doesn't have to impedance mismatch
between different driver implementations too much
3) allow applications and libraries to use explicit synchronization if
they choose by exposing fences directly
Signed-off-by: Jesse B
This hasn't seen any testing yet, but I'm still interested in any bugs
people see in review, I'll fix them up.
If there are no major objections, I'll add some tests and a man page to
libdrm for this and we can move forward into the brave new world of
fences, giving userspace a lot more rope to han
this patch,
> with the exception that its original patch, when applied to the
> current tree, procduces a WARN.
>
> Related commits:
>
> commit daa390e5ee45cc051d6bf37b296901f2f92b002d
> Author: Jesse Barnes
> drm/i915: don't warn if IRQs are disabled when
On Tue, 29 Jul 2014 19:59:26 +0200
Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 09:51:03AM -0700, Jesse Barnes wrote:
> > On Sat, 28 Jun 2014 02:03:57 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > >
I915_WRITE(intel_dp->output_reg, DP |
> DP_LINK_TRAIN_PAT_IDLE_CPT);
> } else {
> - DP &= ~DP_LINK_TRAIN_MASK;
> + if (IS_CHERRYVIEW(dev))
> + DP &= ~DP_LINK_TRAIN_MASK_CHV;
> + else
> + DP &
_emit(ring, flags);
> - intel_ring_emit(ring, scratch_addr);
> - intel_ring_emit(ring, 0);
> - intel_ring_emit(ring, 0);
> - intel_ring_emit(ring, 0);
> - intel_ring_advance(ring);
> -
> - return 0;
> -
> + return gen8_emit_pi
or=%d, B:
> plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n",
> + DRM_DEBUG_KMS("Setting FIFO watermarks - A: plane=%d, cursor=%d, "
> + "B: plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n",
> planea_wm, cursora_wm,
&
+
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER;
> + val |= DPIO_RIGHT_TXFIFO_RST_MASTER;
> + val |= DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
&g
_hdmi_pre_enable(struct intel_encoder
> *encoder)
>
> for (i = 0; i < 4; i++) {
> val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
> - val &= ~DPIO_SWING_MARGIN_MASK;
> - val |= 102 << DPIO_SWIN
intel_hdmi_prepare(encoder);
> +
> mutex_lock(&dev_priv->dpio_lock);
>
> /* program left/right clock distribution */
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
->config.dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
> -
> - crtc->config.dpll_hw_state.dpll_md =
> - (crtc->config.pixel_multiplier - 1) <<
> DPLL_MD_UDI_MULTIPLIER_SHIFT;
> -
> bestn = crtc->config.dpll.n;
> bestm2_frac
PLL_SSC_REF_CLOCK_CHV | DPLL_REFA_CLK_ENABLE_VLV;
> if (pipe != PIPE_A)
> val |= DPLL_INTEGRATED_CRI_CLK_VLV;
> I915_WRITE(DPLL(pipe), val);
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
> u32 val;
> int divider;
>
> + /* FIXME: Punit isn't quite ready yet */
> + if (IS_CHERRYVIEW(dev))
> + return 40;
> +
> mutex_lock(&dev_priv->dpio_lock);
> val = vlv_cck_read(dev_priv, CCK_DISPLAY_CL
int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
>
> - if (req_cdclk != dev_priv->vlv_cdclk_freq)
> - valleyview_set_cdclk(dev, req_cdclk);
> + if (req_cdclk != dev_priv->vlv_cdclk_freq) {
> + if (IS_CHERRYVIEW(dev))
> + cherryview_set
On Tue, 29 Jul 2014 12:41:26 +0200
Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 08:29:53AM +0100, Chris Wilson wrote:
> > On Mon, Jul 28, 2014 at 01:44:12PM -0700, Jesse Barnes wrote:
> > > > @@ -3038,44 +3203,35 @@ out:
> > > > */
> > > &
t does this comment mean? How does VEBOX break this? Does it not
have semaphore support or something?
> @@ -3038,44 +3203,35 @@ out:
> */
> int
> i915_gem_object_sync(struct drm_i915_gem_object *obj,
> - struct intel_engine_cs *to)
> + str
tp://blog.ffwll.ch
> _______
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
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 Wed, 23 Jul 2014 16:10:32 +0100
John Harrison wrote:
> On 02/07/2014 19:20, Jesse Barnes wrote:
> > On Thu, 26 Jun 2014 18:24:04 +0100
> > john.c.harri...@intel.com wrote:
> >
> >> From: John Harrison
> >>
> >> The scheduler decouples th
On Tue, 24 Jun 2014 18:27:39 +0300
Jani Nikula wrote:
> Reviewed-by: Jesse Barnes
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --gi
On Mon, 30 Jun 2014 08:05:34 -0700
Jesse Barnes wrote:
> On Sat, 28 Jun 2014 16:45:03 +0300
> Jani Nikula wrote:
> > >> +/* Scale user_level in range [0..user_max] to [0..hw_max], clamping the
> > >> result
> > >> + * to [hw_min..hw_max]. */
> &g
On Tue, 22 Jul 2014 22:53:44 +0200
Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 10:48 PM, Jesse Barnes
> wrote:
> > Are you saying
> > you'll reject this approach entirely?
>
> I'm saying that I don't see terrible lot of value in adding a bunch of
&
On Tue, 22 Jul 2014 22:44:54 +0200
Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 10:40 PM, Jesse Barnes
> wrote:
> >> > + /* Set link rate directly */
> >> > + intel_dp->link_bw = rxdata[0];
> >> > + /* Preserve 7:5 when setting lane cou
On Tue, 22 Jul 2014 13:48:45 -0700
Jesse Barnes wrote:
> On Tue, 22 Jul 2014 08:41:11 +0200
> Daniel Vetter wrote:
>
> > On Mon, Jul 14, 2014 at 12:10:35PM -0700, Todd Previte wrote:
> > > >This patch set adds the foundational support for Displayport compli
n the link training paths which we
desperately need.
Having some additional user level tests would be great, but that's a
much bigger and different task than simply implementing what's required
for the DP compliance test. Asking Todd to take on a huge new task
just because he posted this series is a big request. Are you saying
you'll reject this approach entirely?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
rain functions, it looks like messing with the
intel_dp->foo fields will roughly do what Todd wants, which is to
simply try a re-train with a different set of params, ignoring the
actual fb and pipe configuration.
Or is that what you had in mind? You'd like to see valid data and mode
timings
On Mon, 14 Jul 2014 14:47:07 -0300
Paulo Zanoni wrote:
> 2014-07-14 14:26 GMT-03:00 Daniel Vetter :
> > On Mon, Jul 14, 2014 at 12:23:11PM -0300, Paulo Zanoni wrote:
> >> 2014-06-20 13:29 GMT-03:00 Jesse Barnes :
> >> > Before we've installed the handler,
On Mon, 14 Jul 2014 12:19:54 -0300
Paulo Zanoni wrote:
> 2014-07-14 12:06 GMT-03:00 Paulo Zanoni :
> > 2014-06-20 13:29 GMT-03:00 Jesse Barnes :
> >> Now that we use the runtime IRQ enable/disable functions in our suspend
> >> path, we can simply check the pm._irqs_di
v_priv->rps.work);
> > +
> > + /* Force GPU to min freq during suspend */
> > + gen6_rps_idle(dev_priv);
> > }
> >
> > void intel_disable_gt_powersave(struct drm_device *dev)
>
> Hi Jesse,
>
> Please review the patch
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
gt; vlv_set_rps_idle(dev_priv);
> > else
> > gen6_set_rps(dev_priv->dev,
> > dev_priv->rps.min_freq_softlimit);
>
> Hi Jesse,
>
> can you please review this patch?
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
c_config *pipe_config,
> @@ -837,7 +839,6 @@ void intel_mode_from_pipe_config(struct drm_display_mode
> *mode,
> int intel_format_to_fourcc(int format);
> void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc);
>
> -
> /* intel_dp.c */
> void intel_dp_init(struct drm_device *dev, int output_reg, enum port port);
> bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
A few whitespace issues and one gen8 check got left in, but otherwise
looks fine.
We could probably do some additional cleanups on top too, like making
the transcoder m_n function look more like the dp one (unless there are
cases when we need to pass around a m_n struct separate from the one in
the intel_crtc, I didn't check).
Anyway, this one looks ok.
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
2,7 @@ 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(stru
drivers/gpu/drm/i915/intel_drv.h
> @@ -315,6 +315,7 @@ struct intel_crtc_config {
>
> /* m2_n2 for eDP downclock */
> struct intel_link_m_n dp_m2_n2;
> + bool has_drrs;
>
> /*
>* Frequence the dpll for the port should run at. Differs from th
_list[] =
> {
> {"i915_gem_hws_blt", i915_hws_info, 0, (void *)BCS},
> {"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
> {"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
> - {"i915_rstdby_delays", i915_rst
880,6 @@ static const struct drm_info_list i915_debugfs_list[] =
> {
> {"i915_drpc_info", i915_drpc_info, 0},
> {"i915_emon_status", i915_emon_status, 0},
> {"i915_ring_freq_table", i915_ring_freq_table, 0},
> - {"i915_gfxec"
On Wed, 9 Jul 2014 15:10:43 +0300
Mika Kuoppala wrote:
> CHV hard hangs on reading these registers. As these have not
> been used since cantiga & ilk, remove the debugfs entry.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=80893
> Suggested-by: Jesse Barn
On Mon, 7 Jul 2014 18:48:47 -0300
Paulo Zanoni wrote:
> (documenting what we discussed on IRC)
>
> 2014-06-20 13:29 GMT-03:00 Jesse Barnes :
> > This was always the case on our suspend path, but it was recently
> > exposed by the change to use our runtime IRQ disable routin
llowing the pin ioctl as root is such a problem? You
need to come up with an alternative proposal and we need to get it
implemented in some reasonable amount of time if we're not going to
just do the simple thing that's already been shown to work...
IOW don't plug you
7;s unreasonable to use a macro that checks a global
list for whether to apply a given WA. They'll be scattered all over,
but at least it'll be easy to see:
1) whether we implement a given workaround
and
2) which platforms & steppings it applies to based on the table.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
s an excellent idea.
>
> However I am still curious to _why_ it has to be done in the first place.
The display part of the GPU is partly on the PCH, and it's possible to
mix & match them a bit, so we have this detection code to figure things
out. In some cases, the PCH display portion may not even be present,
so we look for that too.
Practically speaking, we could probably assume specific CPU/PCH combos,
as I don't think they're generally mixed across generations, though SNB
and IVB did have compatible sockets, so there is the possibility of
mixing CPT and PPT PCHs, but those are register identical as far as the
graphics driver is concerned, so even that should be safe.
Beyond that, the other MCH data we need to look at is mirrored into the
GPU's MMIO space on current gens. On older gens, we do need to poke at
the memory controller a bit to get some info (see
intel_setup_mchbar()), but that's not true of newer stuff. Looks like
we only short circuit that on VLV though; we could probably do it on
SNB+.
--
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 Thu, 3 Jul 2014 16:59:17 +0100
Chris Wilson wrote:
> On Thu, Jul 03, 2014 at 08:49:22AM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 15:29:26 +0100
> > Chris Wilson wrote:
> >
> > > Baytrail uses the RPS wait-boosting mechanism of Sandybridge+
On Thu, 3 Jul 2014 16:51:11 +0100
Chris Wilson wrote:
> On Thu, Jul 03, 2014 at 08:44:20AM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 08:09:01 +0100
> > Chris Wilson wrote:
> >
> > > Since we rely on hangcheck to wait up and kick us out of an indefinite
he change (well you did mix in a cleanup to
set_rps_thresholds), I just want us to get better at collecting numbers
for this stuff...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http:
}
>
> + i915_check_hangcheck(dev);
> +
> io_schedule_timeout(1);
>
> if (dev_priv->mm.interruptible && signal_pending(current)) {
Are there any bugs associated with this?
i915_rearm_hangcheck() or something mig
.) do { } while (0)
> #define DRM_DEBUG_KMS(fmt, args...) do { } while (0)
> #define DRM_DEBUG_PRIME(fmt, args...)do { } while (0)
> +#define DRM_DEBUG_SCHED(fmt, args...) do { } while (0)
> #define DRM_DEBUG(fmt, arg...)
ing, intel_ring_get_seqno(ring), flags);
>
> - i915_gem_execbuffer_move_to_active(&eb->vmas, ring);
> i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
>
> err:
I'd like Chris to take a look too, but it looks safe afaict.
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
l_engine_cs *ring);
> static inline void intel_ring_emit(struct intel_engine_cs *ring,
> u32 data)
> {
This ought to be ok even w/o the scheduler, we'll just pick up the
lazy_seqno later on rather than allocating a new one at ring_begin
ri
401 - 500 of 3350 matches
Mail list logo
