At Mon, 20 May 2013 19:26:57 +0800,
Wang Xingchao wrote:
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio
At Mon, 20 May 2013 19:26:58 +0800,
Wang Xingchao wrote:
For Intel Haswell chip, HDA controller and codec have
power well dependency from GPU side. This patch added support
to request/release power well in audio driver. Power save
feature should be enabled to get runtime power saving.
On Wed, May 15, 2013 at 06:45:35PM -0300, Paulo Zanoni wrote:
2013/5/14 Jesse Barnes jbar...@virtuousgeek.org:
We can use this for fetching encoder specific pipe_config state, like
mode flags, adjusted clock, etc.
Just used for mode flags atm, so we can check the pipe config state at
On Wed, May 15, 2013 at 09:40:30PM +0300, Jani Nikula wrote:
No functional changes.
Signed-off-by: Jani Nikula jani.nik...@intel.com
I'd vote to move the sbi sideband stuff on the haswell pch to this place,
too. Maybe in a follow-up patch though.
-Daniel
---
drivers/gpu/drm/i915/Makefile
On Wed, May 15, 2013 at 09:40:29PM +0300, Jani Nikula wrote:
Okay, I'm stuck with this a bit, and whichever approach I choose I
expect there to be a bunch of bikeshedding. So I won't polish this
further before comments.
Both the intel_dpio_{read,write} and valleyview_{punit,nc}_{read,write}
On Thu, May 16, 2013 at 04:54:04PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Intermediate Pixel Storage is a feature that should reduce the number
of times the display engine wakes up memory to read pixels, so it
should allow deeper PC states. IPS can only be
On Fri, May 03, 2013 at 06:55:35PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 6:36 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
Along the modesetting short cut where we skip trying to do a full
modeset and instead simply update the framebuffer base registers, we
failed to handle
On Thu, May 16, 2013 at 02:40:35PM +0300, Imre Deak wrote:
On ValleyView for both eDP and DP the AUX input clock is 200MHz, so we
can calculate for both the clock divider for the 2MHz target rate at the
same place. Afterwards we can also replace the is_cpu_edp() check with a
check for port A.
On Thu, May 16, 2013 at 02:40:34PM +0300, Imre Deak wrote:
On port A and for Valleyview on port C we can have only eDP and in both
cases it's a CPU port. So we can replace is_cpu_edp() with a port check
for these two cases. This allows us to remove is_cpu_edp() completely in
a later patch.
On Fri, May 03, 2013 at 05:23:39PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
... instead of mode-crtc_display. The spec says pipe horizontal
total number of pixels and the Haswell Watermark Calculator tool
uses the Pipe H Total instead of Pipe H Src as the value.
On Fri, May 03, 2013 at 05:23:41PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If we're using DP/eDP, adjusted_mode-clock may be just the port link
clock, but we also can't use mode-clock because it's wrong when we're
using the using panel fitter.
Signed-off-by:
On Fri, May 03, 2013 at 05:23:45PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Commit 1544d9d57396d5c0c6b7644ed5ae1f4d6caad07a added a workaround
inside haswell_init_clock_gating and mentioned it is a workaround for
early silicon revisions and should be removed
Release 2.21.7 (2013-05-21)
===
A couple of weeks turned into a month and a couple of weeks... Amidst
the usual bug fixes, we have added the complete set of Haswell PCI IDs -
hopefully future proofing ourselves against being surprised by new
products. We can also now use
On Tue, May 21, 2013 at 09:54:09AM +0100, Chris Wilson wrote:
On Fri, May 03, 2013 at 06:55:35PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 6:36 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Along the modesetting short cut where we skip trying to do a full
modeset and
On Tue, 2013-05-21 at 11:15 +0200, Daniel Vetter wrote:
On Thu, May 16, 2013 at 02:40:34PM +0300, Imre Deak wrote:
On port A and for Valleyview on port C we can have only eDP and in both
cases it's a CPU port. So we can replace is_cpu_edp() with a port check
for these two cases. This allows
On Tue, 2013-05-21 at 11:12 +0200, Daniel Vetter wrote:
On Thu, May 16, 2013 at 02:40:35PM +0300, Imre Deak wrote:
On ValleyView for both eDP and DP the AUX input clock is 200MHz, so we
can calculate for both the clock divider for the 2MHz target rate at the
same place. Afterwards we can
On Tue, May 21, 2013 at 12:36 PM, Imre Deak imre.d...@intel.com wrote:
On Tue, 2013-05-21 at 11:12 +0200, Daniel Vetter wrote:
On Thu, May 16, 2013 at 02:40:35PM +0300, Imre Deak wrote:
On ValleyView for both eDP and DP the AUX input clock is 200MHz, so we
can calculate for both the clock
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, May 21, 2013 3:19 PM
To: Wang Xingchao
Cc: dan...@ffwll.ch; Girdwood, Liam R; david.hennings...@canonical.com; Lin,
Mengdong; Li, Jocelyn; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org;
On Tue, 2013-05-21 at 12:42 +0200, Daniel Vetter wrote:
On Tue, May 21, 2013 at 12:36 PM, Imre Deak imre.d...@intel.com wrote:
On Tue, 2013-05-21 at 11:12 +0200, Daniel Vetter wrote:
On Thu, May 16, 2013 at 02:40:35PM +0300, Imre Deak wrote:
On ValleyView for both eDP and DP the AUX input
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, May 21, 2013 3:18 PM
To: Wang Xingchao
Cc: dan...@ffwll.ch; Girdwood, Liam R; david.hennings...@canonical.com; Lin,
Mengdong; Li, Jocelyn; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org;
At Tue, 21 May 2013 10:58:36 +,
Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, May 21, 2013 3:19 PM
To: Wang Xingchao
Cc: dan...@ffwll.ch; Girdwood, Liam R; david.hennings...@canonical.com; Lin,
Mengdong; Li, Jocelyn;
This series tries to get the trickle feed settings corrected for all gen4+.
Note that I've only compile tested the gen4 and vlv bits as I don't have
either type of machine set up at the moment. The g4x patch (well, v1 actually)
was smoke tested on real hardware at some point.
From: Ville Syrjälä ville.syrj...@linux.intel.com
The docs say that the trickle feed disable bit is present (for primary
planes only, not video sprites) on CTG, and that it must be set
for ELK. Just set it for all g4x chipsets.
v2: Do it in init_clock_gating too
Signed-off-by: Ville Syrjälä
On Tue, May 21, 2013 at 03:28:32PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The docs say that the trickle feed disable bit is present (for primary
planes only, not video sprites) on CTG, and that it must be set
for ELK. Just set it for all
On Tue, May 21, 2013 at 2:35 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, May 21, 2013 at 03:28:32PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The docs say that the trickle feed disable bit is present (for primary
planes
On Thu, May 09, 2013 at 05:13:41PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We were previously calling sandybridge_update_wm on HSW, but the SNB
function didn't really match the HSW specification, so we were just
writing the wrong values. For example, I was not
2013/5/21 Daniel Vetter dan...@ffwll.ch:
On Fri, May 03, 2013 at 05:23:45PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Commit 1544d9d57396d5c0c6b7644ed5ae1f4d6caad07a added a workaround
inside haswell_init_clock_gating and mentioned it is a workaround for
early
On Tue, May 21, 2013 at 4:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, May 17, 2013 at 09:26:18AM -0400, Ben Guthro wrote:
On Fri, May 17, 2013 at 7:52 AM, Ben Guthro b...@guthro.net wrote:
On Thu, May 16, 2013 at 9:24 AM, Ben Guthro b...@guthro.net wrote:
On Wed, May 15, 2013 at 4:42
On Tue, May 21, 2013 at 9:44 AM, Ben Guthro b...@guthro.net wrote:
On Tue, May 21, 2013 at 4:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, May 17, 2013 at 09:26:18AM -0400, Ben Guthro wrote:
On Fri, May 17, 2013 at 7:52 AM, Ben Guthro b...@guthro.net wrote:
On Thu, May 16, 2013 at 9:24
On Tue, May 21, 2013 at 3:44 PM, Ben Guthro b...@guthro.net wrote:
This will break kms since now you have the vbios and the linux kms driver
fighting over the same piece of hw. Does
xset dpms force off
xset dpms force on
cause similar issues?
No, these work as expected (on 3.8)
I didn't
Hi Jan,
First things first, please _always_ cc relevant mailing lists.
Second: I've submitted a proper patch to revert this behaviour change,
but it has been nacked. I've poked Dave Airlie about it again on irc.
See https://patchwork.kernel.org/patch/2402211/
Thanks, Daniel
On Tue, May 21,
2013/5/21 Daniel Vetter dan...@ffwll.ch:
On Fri, May 03, 2013 at 05:23:39PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
... instead of mode-crtc_display. The spec says pipe horizontal
total number of pixels and the Haswell Watermark Calculator tool
uses the Pipe H
On Tue, May 21, 2013 at 02:52:24PM +0200, Daniel Vetter wrote:
On Tue, May 21, 2013 at 2:35 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, May 21, 2013 at 03:28:32PM +0300, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The docs
From: Ville Syrjälä ville.syrj...@linux.intel.com
We disable trickle feed in all the (relevant) clock gating functions,
except ironlake_init_clock_gating(). Copy paste the same code there as
well.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 8
On Tue, May 21, 2013 at 4:33 PM, Paulo Zanoni przan...@gmail.com wrote:
2013/5/21 Daniel Vetter dan...@ffwll.ch:
On Fri, May 03, 2013 at 05:23:39PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
... instead of mode-crtc_display. The spec says pipe horizontal
total
On Wed, May 08, 2013 at 12:50:24PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Follow the same sequence when enabling the cursor plane during
modeset. No point in doing this stuff in different order on different
generations.
This should
On Tue, May 21, 2013 at 4:30 PM, Jan Niggemann j...@hz6.de wrote:
Hi Daniel,
you misunderstood my mail, I just wanted to know:
Are patches in patchwork that correct kernel bugs in any way linked to
bugzilla issues and if so, how?
In other words: What bugzilla bug corresponds to
This should help debugging the truly unexpected cases where it occurs -
in particular to see which value is garbage.
References: https://bugzilla.kernel.org/show_bug.cgi?id=58511
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |5 -
1 file
On Tue, May 21, 2013 at 04:58:49PM +0100, Chris Wilson wrote:
This should help debugging the truly unexpected cases where it occurs -
in particular to see which value is garbage.
References: https://bugzilla.kernel.org/show_bug.cgi?id=58511
Signed-off-by: Chris Wilson
On Mon, May 20, 2013 at 02:13:22PM -0700, Jesse Barnes wrote:
On Fri, 3 May 2013 19:44:07 +0200
Egbert Eich e...@suse.de wrote:
From: Imre Deak imre.d...@intel.com
Currently the driver's assumed behavior for a modeset with an attached
FB is that the corresponding connector will be
We need this to avoid premature timeouts whenever scheduling a timeout
based on the current jiffies value. For an explanation see [1].
The following patches will take the helper into use.
Once the more generic solution proposed in the thread at [1] is accepted
this patch can be reverted while
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 5d24503..98cd8535 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++
During DP AUX communication we might time out 1 jiffy too early, because
the calculated expiry jiffy value is one less than needed.
This is only one reason for false DP AUX timeouts. For a complete
solution we also need the following fix, which is now queued for
mainline:
At the moment wait_event_timeout/wait_event_interruptible_timeout may
time out 1 jiffy too early, as the calculated expiry time is 1 less than
needed. Besides timing out too early this also means that the
calculation of the remaining time will be incorrect and we will pass a
non-zero remaining
We have another one of these in the wait_for register wait macro in
intel_drv.h Can you please amend your patch with that fixed up, too?
Thanks, Daniel
On Tue, May 21, 2013 at 7:03 PM, Imre Deak imre.d...@intel.com wrote:
Signed-off-by: Imre Deak imre.d...@intel.com
---
On Tue, May 21, 2013 at 10:02 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, May 21, 2013 at 3:44 PM, Ben Guthro b...@guthro.net wrote:
This will break kms since now you have the vbios and the linux kms driver
fighting over the same piece of hw. Does
xset dpms force off
xset dpms force on
On Tue, 2013-05-21 at 19:20 +0200, Daniel Vetter wrote:
We have another one of these in the wait_for register wait macro in
intel_drv.h Can you please amend your patch with that fixed up, too?
I noticed it, but didn't change it since we don't need there the +1
adjustment to begin with. The
On Tue, May 21, 2013 at 8:00 PM, Imre Deak imre.d...@intel.com wrote:
On Tue, 2013-05-21 at 19:20 +0200, Daniel Vetter wrote:
We have another one of these in the wait_for register wait macro in
intel_drv.h Can you please amend your patch with that fixed up, too?
I noticed it, but didn't
Pineview is just different.
Also split out i9xx_clock from intel_clock and drop the now redundant
struct device * parameter.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 92 ++--
1 file changed, 77 insertions(+),
Hi all,
So pipe config conversion progresses neatly, and this pile here contains a few
more prep work things:
- fix up the pll limits (or at least what the current believe about the correct
values is ...)
- unconfuse the meaning of adjusted_mode-clock, a side effect of this is that
it makes
Now that the DP madness is cleared out, this is all only per-platform.
So move it out from the intel clock limits structure.
While at it drop the intel prefix on the static functions, call the
vtable entry find_dpll (since it's for the display pll) and rip out
the now unnecessary forward
So apparently the pll limits in the docs are the real values, but the
formula actually seems to consistenly use register values. See
commit 4f7dfb6788dd022446847fbbfbe45e13bedb5be2
Author: Patrik Jakobsson patrik.r.jakobs...@gmail.com
Date: Wed Feb 13 22:20:22 2013 +0100
drm/i915: Set i9xx
We can get at this easily through intel_crtc-config now.
v2: Drop more stuff gcc spotted.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git
... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.
Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
Panel fitters on ivb/hsw are not created equal since not all of them
support the new high-quality upscaling mode. To offset this the hw
allows us to freely assign the pfits to pipes.
Since our code currently doesn't support this we might fall over when
taking over firmware state. So check for
All this pipe config abstraction adds another layer of complexity, so
it's good to have better visibility into what's going on exactly.
Doesn't dump out everything yet, and some bits are a bit duplicated
but this should be a good start.
v2: Remove a few more now redudant debug output lines.
This is new to me as of 3.10-rc2.
WARNING: at drivers/gpu/drm/i915/intel_display.c:997
intel_wait_for_pipe_off+0x194/0x1a0 [i915]()
pipe_off wait timed out
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_LOG
xt_limit ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
On Wed, May 22, 2013 at 1:01 AM, Dave Jones da...@redhat.com wrote:
This is new to me as of 3.10-rc2.
If this is an ironlake with a DP output it's a know issue which seems
to pop up every once in a while. Otherwise we need to take a look
here. If so can you please boot with drm.debug=0xe,
On Wed, May 22, 2013 at 01:10:36AM +0200, Daniel Vetter wrote:
On Wed, May 22, 2013 at 1:01 AM, Dave Jones da...@redhat.com wrote:
This is new to me as of 3.10-rc2.
If this is an ironlake with a DP output it's a know issue which seems
to pop up every once in a while.
00:02.0 VGA
59 matches
Mail list logo
