On Mon, 26 Nov 2012 20:09:00 +0200
Ville Syrjälä wrote:
> On Mon, Nov 26, 2012 at 05:46:48PM +, Chris Wilson wrote:
> > On Mon, 26 Nov 2012 19:40:16 +0200, Ville Syrjälä
> > wrote:
> > > On Mon, Nov 26, 2012 at 04:25:47PM +, Chris Wilson wrote:
> > > > On Mon, 26 Nov 2012 14:48:19 +0200
This bug was introduced by me:
commit e76e9aebcdbfebae8f4cd147e3c0f800d36e97f3
Author: Ben Widawsky
Date: Sun Nov 4 09:21:27 2012 -0800
drm/i915: Stop using AGP layer for GEN6+
The existing code uses memset_io which follows memset semantics in only
guaranteeing a write of individual bytes.
On Mon, Nov 26, 2012 at 10:21:28PM +0100, Daniel Vetter wrote:
> On Mon, Nov 05, 2012 at 03:20:53PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > intel_pipe_set_base() never actually waited for any pending page flips
> > on the CRTC. It looks like it tried to, by cal
On Mon, Nov 05, 2012 at 03:20:53PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_pipe_set_base() never actually waited for any pending page flips
> on the CRTC. It looks like it tried to, by calling intel_finish_fb() on
> the current front buffer. But the pending fli
On Mon, 26 Nov 2012 20:02:00 +0200, Ville Syrjälä
wrote:
> On Mon, Nov 26, 2012 at 04:28:33PM +, Chris Wilson wrote:
> > On Mon, 26 Nov 2012 14:48:18 +0200, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > According to BSpec the ring head and tail pointers must
On Mon, Nov 12, 2012 at 02:20:19PM +0200, Mika Kuoppala wrote:
> Dereference dev_priv only after we know it is valid.
> Found with smatch.
>
> Signed-off-by: Mika Kuoppala
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -
On Wed, Nov 21, 2012 at 02:26:57PM -0200, Paulo Zanoni wrote:
> 2012/11/21 Daniel Vetter :
> > Somehow a chunk of unused register defines ended up in the middle of
> > the PLL defines. They go back to the original kms merging.
> >
> > The only used #define is SR01, move it to the register name toge
On Fri, Nov 23, 2012 at 11:57:56AM +, Chris Wilson wrote:
> Some devices may respond very slowly and only flag that the reply is
> pending within the first 15us response window. Be kind to such devices
> and wait a further 15ms, before checking for the pending reply. This
> moves the existing s
On Fri, Nov 23, 2012 at 12:09:27PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We currently set "0" as the VIC value of the AVI InfoFrames. According
> to the specs this should be fine and work for every mode, so to my
> point of view we can't consider the current behavior as a bug. The
>
On Mon, Nov 26, 2012 at 05:46:48PM +, Chris Wilson wrote:
> On Mon, 26 Nov 2012 19:40:16 +0200, Ville Syrjälä
> wrote:
> > On Mon, Nov 26, 2012 at 04:25:47PM +, Chris Wilson wrote:
> > > On Mon, 26 Nov 2012 14:48:19 +0200, ville.syrj...@linux.intel.com wrote:
> > > > From: Ville Syrjälä
On Mon, Nov 26, 2012 at 04:28:33PM +, Chris Wilson wrote:
> On Mon, 26 Nov 2012 14:48:18 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > According to BSpec the ring head and tail pointers must not be
> > on the same cacheline when head > tail. The easiest way to en
On Mon, 26 Nov 2012 19:40:16 +0200, Ville Syrjälä
wrote:
> On Mon, Nov 26, 2012 at 04:25:47PM +, Chris Wilson wrote:
> > On Mon, 26 Nov 2012 14:48:19 +0200, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Ringbuffer tail pointer must be qword aligned. Warn if
On Mon, Nov 26, 2012 at 04:25:47PM +, Chris Wilson wrote:
> On Mon, 26 Nov 2012 14:48:19 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Ringbuffer tail pointer must be qword aligned. Warn if someone
> > makes a mistake and forgets to pad the ring when the commands
On Fri, Nov 23, 2012 at 03:11:52PM +0100, Thierry Reding wrote:
> On Fri, Nov 23, 2012 at 12:09:26PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > This function returns the VIC of the mode. This value can be used when
> > creating AVI InfoFrames.
> >
> > Cc: Thierry Reding
> > Bugzi
I like abstraction and vfuncs, but only if they actually abstract anything.
In this case here they just obfuscate, so let's rip this stuff out.
Aside: We really should move all the haswell stuff into it's own file ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
We don't use these on haswell, since haswell has per-pipe watermarks
and nothing global any more.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.
We already update watermarks at all the right places in the
crtc_enable/disable callbacks. And since ->mode_set doesn't change the
active state, nothing will have changed ...
v2: Rebase on top of latest haswell copy&pasta.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |
Both the dp and fdi code use the exact same computations (ignore minor
differences in conversion between bits and bytes).
This makes it even more apparent that we have a _massive_ mess between
cpu transcoder/fdi link/pch transcoder and pch link settings. And also
that we have hilarious amounts of
This has originally been added in
commit 8db9d77b1b14fd730561f64beea8c00e4478d7c5
Author: Zhenyu Wang
Date: Wed Apr 7 16:15:54 2010 +0800
drm/i915: Support for Cougarpoint PCH display pipeline
probably to combat issues with hw state left behind by the BIOS. And
indeed, I've checked out th
This could have happened with the old crtc helper based modeset code,
but can't happen any longer with the new code.
Hence put in a WARN and adjust the comment. If no one hits this, we
can eventually remove it (like a few other such cases across our
code).
Signed-off-by: Daniel Vetter
---
drive
17 ms is eerily close to 60 Hz ^-1
Unfortunately this goes back to the original DP enabling for ilk, and
unfortunately does not come with a reason for it's existance attached.
Some closer inspection of the code and DP specs shows that we set the
idle link pattern before we disable the port. And i
While reading docs I've noticed that this special workaround to select
the 1.6 GHz DP clock only applies to pre-production ilk machines.
Since the registers we're touching here are rather undocumented and
might be harmful on later chips, rip it out.
For the Bspec reference of this w/a look in "vol
Now that we enable the cpu edp pll in intel_dp->pre_enable and no
longer in crtc_mode_set, we can also move the modeset part to the
intel_dp->mode_set callback. Previously this was not possible because
the encoder ->mode_set callbacks are called after the crtc mode set
callback.
v2: Rebase on top
Especially getting rid of all things lvds is ... great!
v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 126 +--
1 file changed, 1 insertion(+), 125 deletions(-)
diff --gi
Only two things needed adjustment:
- pipe select for PCH_CPT
- There's no dithering bit on ilk+ in the lvds ctl reg
Reviewed-by: Paulo Zanoni
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 40
drivers/gpu/drm/i915/intel_lvds.c| 2
A few things needed to change:
- HAS_PCH_SPLIT since ilk+ is not yet converted to this.
- s/LVDS/intel_lvds->reg/ to prep for ilk conversion
- replace the clock.p2 == 7 check with a is_dual_link check
- s/adjusted_mode/intel_lvds->fixed_mode
v2: Rebase on top of Jani Nikula's panel rework. I'm won
To ditch at least some of the PCH_SPLIT ? PCH_LVDS : LVDS code ...
v2: Rebase on top of Jani Nikula's panel rework.
Reviewed-by: Paulo Zanoni
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 48 ---
1 file changed, 20 insertions(+), 28 de
Yeah, all users (both the clock selection special cases and the lvds
pin pair stuff) are still in common code, but this will change.
v2: Rebase on top of Jani Nikula's panel rework.
v3: Incorporate review from Paulo Zanoni:
- s/__is_dual_link_lvds/compute_is_dual_link_lvds
- kill dev_priv->lvds_v
Just a prep patch to make this a property of intel_lvds. Makes more
sense, removes clutter from intel_display.c and eventually I want to
move all the encoder special cases wrt clock handling to encoders
anyway.
v2: Add an intel_ prefixe to is_dual_link_lvds since it's non-static
now.
Reviewed-by:
... with is_dual_link_lvds introduced in
commit b03543857fd75876b96e10d4320b775e95041bb7
Author: Takashi Iwai
Date: Tue Mar 20 13:07:05 2012 +0100
drm/i915: Check VBIOS value for determining LVDS dual channel mode, too
All these checks predate this commit and have simply been overlooked.
Currently we have two encoder specific bits in the common mode_set
functions:
- lvds pin pair enabling
- dp m/n setting and computation
Now the lvds stuff needs to happen before the pll is enabled. Since
that is done in the crtc_mode_set functions, we need to add a new
callback to be able to move
Hi all,
Second round for my lvds/dp/watermark refactorings, which are a prep work for
the next step in reworking the modeset code (which is currently brewing at a
rather slow rate in my modeset-rework branch). Safe where I've disagreed this
should incorporate all review feedback from Paulo Zanoni.
On Mon, 26 Nov 2012 14:48:18 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> According to BSpec the ring head and tail pointers must not be
> on the same cacheline when head > tail. The easiest way to enforce
> this is to reduce the reported ring space.
I'm going to admit
On Mon, 26 Nov 2012 14:48:19 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Ringbuffer tail pointer must be qword aligned. Warn if someone
> makes a mistake and forgets to pad the ring when the commands
> inserted into the ring don't align to qword naturally.
The asserti
Hi!
Hm, this sounds rather interesting ... Can you please try to reproduce
this on a recent 3.7-rc kernel, and if your reproduction method is
still effective, please file a bug on bugs.freedesktop.org agains DRI
-> DRM(Intel)? We've never really gotten a good handle on these missed
interrupts, onl
On Mon, Nov 26, 2012 at 1:48 PM, wrote:
> + /* tail must be qword aligned */
> + WARN_ON(ring->tail & 7);
Minor bikeshed: Can you move the comment into the WARN argument so
that if someone forgets to correctly pad stuff, dmesg will directly
tell him wants wrong, instead of being forc
Hi, I have an app that uses the IVB bitstream hardware (via
libva/intel-driver), and I have noticed some reported missed bsd IRQs
in dmesg. After some testing I believe this only occurs when I run
intel_gpu_top, so I'm assuming this is an issue with intel_gpu_top
rather than the resolved bug 38862
From: Ville Syrjälä
Ringbuffer tail pointer must be qword aligned. Warn if someone
makes a mistake and forgets to pad the ring when the commands
inserted into the ring don't align to qword naturally.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ringbuffer.c |2 ++
1 files ch
From: Ville Syrjälä
According to BSpec the ring head and tail pointers must not be
on the same cacheline when head > tail. The easiest way to enforce
this is to reduce the reported ring space.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i
After getting slightly confused by the values of the ring registers
in the error state dumps, I started to actually read the specs and
compare what I learned with the code.
I spotted one possible issue with the head and tail handling. But I
don't know if my patch might fix some obscure bug, or not
The highlight of this release is gen4, from 965g to gm45. Quite an old
bug surfaced in the shader assembly, sparking a chance to review a few
design choices within that backend and experiment on fresh ways to
workaround the remaining issues.
* Avoid using inplace XOR'ed uploads for very large buf
Hi Dave,
One more on top.
On Fri, Nov 23, 2012 at 05:58:55PM +0100, Daniel Vetter wrote:
> Two small fixes for 3.7:
> - Unbreak mbp retina, this time with a much more fine-grained approach
> (since the previous "completely ignore edp vbt bpp value" regressed some
> machines even after fixing
On Sat, Nov 10, 2012 at 10:00:06AM +, Chris Wilson wrote:
> Even with the cumulative set of ilk w/a, rc6 is demonstrably still
> failing and causing GPU hangs as found by Peter Wu. So we need to disable
> it again until it is stable.
>
> This reverts
>
> commit 456470eb583f063ee84c6818251e638
On Thu, Nov 22, 2012 at 06:10:07PM +0200, Jani Nikula wrote:
>
> Reviewed-by: Jani Nikula
>
>
> On Wed, 21 Nov 2012, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson
Forgot to mention: Both now merged to dinq, thanks for the patches.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corp
44 matches
Mail list logo
