On Fri, Jun 27, 2014 at 03:21:20PM -0700, Rodrigo Vivi wrote:
>Reviewed-by: Rodrigo Vivi <[1]rodrigo.v...@intel.com>
>
>On Fri, Jun 27, 2014 at 3:09 PM, Ben Widawsky
><[2]benjamin.widaw...@intel.com> wrote:
>
> There are some cases in the code where we need to know how many rings
On Fri, Jun 27, 2014 at 03:21:20PM -0700, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
I have a couple of spots that I think are important to add, all in error
state. I'll repost v2 after I can actually test it.
[snip]
--
Ben Widawsky, Intel Open Source Technology Center
___
From: Ville Syrjälä
In case the pipe's power sequencer has been locked to another port, we
need to kick it to make it unstuck. Otherwise it will prevent the port
from starting up even if it's a regular DP port and not eDP.
We can't use the regular panel power sequencer function on a DP port,
so
From: Ville Syrjälä
Currently we do all kinds vdd frobbing from both the modeset and
->detect. ->detect isn't protected by the connection_mutex as the
current locking stuff seems to expect. Switch it all over the
mode_config.mutex instead since we hold that in both places.
In the long run we'll
From: Kenneth Graunke
On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set
must be preceded by a PIPE_CONTROL with the "CS Stall" bit set.
Documented on the BSpec 3D workarounds page.
Signed-off-by: Kenneth Graunke
[vsyrjala: add chv w/a note too]
Signed-off-by: Ville Syrjä
From: Ville Syrjälä
Add defines for all the watermark registers on modernish gmch platforms.
VLV has increased the number of bits available for certain watermaks so
expand the masks appropriately. Also vlv and chv have added some extra
FW registers.
Not sure what happened on chv because a new r
From: Ville Syrjälä
When we pick a new power sequencer for the port but we're not doing a
full modeset, the power sequencer may have locked on to another port.
So kick it a bit to make sure it controls the port we want.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 57
From: Ville Syrjälä
VLV and CHV disable the DP port only in the .post_disable() hook, so we
need to make intel_sanitize_encoder() call that when it's trying to
disable encoders without an active pipes.
My bsw actaully hits this when an external display is connected. The
BIOS still likes to turn
From: Ville Syrjälä
CHV has a power well for each pipe. Add the code to deal with them.
The Punit in current hardware doesn't seem ready for this yet, so
leave it iffed out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 12
drivers/gpu/drm/i915/intel_pm.c | 126
From: Ville Syrjälä
The panel power sequencer locks into the port once used. We need to keep
track wich power sequencers are locked to which ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 172 ---
drivers/gpu/drm/i915/intel_drv.h
From: Ville Syrjälä
Clear the override bits to make sure the hardware maanages
the TX FIFO reset master on its own.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 20 +++-
drivers/gpu/drm/i915/intel_hdmi.c | 20 +++-
2 files changed, 6 inse
From: Ville Syrjälä
CHV supports DP training pattern 3. Add the required stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 18 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i91
From: Ville Syrjälä
It looks like frobbing the cmnreset line on pne PHY disturbs the other
PHY on chv. The result is a black screen. On HDMI it's just a flash of
black, but DP usually falls over and can't get back up.
As a workaround set up the power domains so that both common lane
wells power
From: Ville Syrjälä
My bsw is an unhappy camper if we delay the workaround init until
init_clock_gating(). Move a bunch of it to the render ring init.
FIXME: need to do this for all platforms since some of the registers
also get clobbered at reset. Just need to figure out which
reg
From: Ville Syrjälä
Allow calling the vdd off functions when vdd is already off. Makes
things simpler later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/d
From: Kenneth Graunke
We'll want to reuse this for a workaround.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 36 -
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers
From: Ville Syrjälä
In
commit 62942ed7279d3e06dc15ae3d47665eff3b373327
Author: Jesse Barnes
Date: Fri Jun 13 09:28:33 2014 -0700
drm/i915/vlv: disable PPGTT on early revs v3
we forgot about CHV. IS_VALLEYVIEW() is true for CHV, so we need to
explicitly avoid disabling PPGTT on CHV.
S
From: Ville Syrjälä
Split some WM debug prints to multiple lines. This shouldn't hurt
grappability since the important part is at the start and the rest
is just repeated stuff for each pipe.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 6 --
1 file changed, 4 insertio
From: Ville Syrjälä
CHV has a third pipe so we need to compute the watermarks for its
planes. Add cherryview_update_wm() to do just that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 77 -
1 file changed, 76 insertions(+), 1 deletio
From: Ville Syrjälä
Replace the semi-funky cmnlane assert/deassert macros with something a
bit more conventional. Also protect the macro arguments properly (also
for PHY_POWERGOOD()).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 7 ++-
drivers/gpu/drm/i915/intel_pm.c
From: Ville Syrjälä
When switching from one pipe to another, the power sequencer of the new
pipe seems to need a bit of kicking to lock into the port. Even the vdd
force bit doesn't work before the power sequencer has been sufficiently
kicked, so this must be done even before any AUX transactions
From: Ville Syrjälä
The VLV/CHV DDL registers are uniform, and neatly enough the register
offsets are sane so we can easily unify them to a single set of defines
and just pass the pipe as the parameter to compute the register offset.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_r
From: Ville Syrjälä
Add the TX wells for ports B and C just like on VLV.
Again Punit doesn't seem ready (or the wells don't even exist anymore)
so leave it iffed out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 30 ++
1 file changed, 30 inser
From: Ville Syrjälä
The DDL registers can hold 7bit numbers. Make the most of those seven
bits by adjusting the threshold where we switch between the 64 vs. 32
precision multipliers.
Also we compute 'entries' to make the decision about precision, and then
we recompute the same value to calculate
From: Ville Syrjälä
Punit seems a bit WIP still. Disable cdclk changes until we have
hardware where it works.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/dr
From: Ville Syrjälä
Split chv_update_pll() into two parts ala:
commit bdd4b6a655749970cc632aafc5fd596c07b60b1c
Author: Daniel Vetter
Date: Thu Apr 24 23:55:11 2014 +0200
drm/i915: Extract vlv_prepare_pll
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 30
From: Zhenyu Wang
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/i915_reg.h | 50 -
drivers/gpu/drm/i915/intel_pm.c | 12 +-
2 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i9
From: Ville Syrjälä
CHV has two display PHYs so there are also two cmnlane power wells. Add
the approriate code to power the wells up/down.
Like on VLV we do the cmnreset assert/deassert and the DPLL refclock
enabling at approriate times.
This code actually works on my bsw.
Signed-off-by: Vill
From: Ville Syrjälä
Not sure if it's still there since chv has per-pipe power wells.
At least with current Punit this doesn't work. Also the display
irq handling would need to be adjusted for pipe C. So leave the
code iffed out for now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/int
From: Ville Syrjälä
Just an attempt to frob these bits. Apparently we should not need to
touch them (apart from maybe making sure the override is disabled so
that the hardware automagically does the right thing).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 12 +
From: Ville Syrjälä
The register can house two different swing marging/deemph settings at
once. However only one gets used based on some other bits. Make sure we
set those bits correctly to make the hardware use the settings we
provided.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i9
From: Ville Syrjälä
CHV display PHY registes have two swing margin/deemph settings. Make it
clear which ones we're using.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 8 ++--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_hdmi.c | 4 ++--
3 f
From: Ville Syrjälä
Add chv_power_wells[] so we can start to build up the power well support
for chv. Just the "always on" well there initialy.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915
From: Ville Syrjälä
Add the TX wells for port D. The Punit subsystem numbers are a total
guess at this time. Also I'm not sure these even exist. Certainly the
Punit in current hardware doesn't deal with these.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/
From: Ville Syrjälä
Both VLV and CHV handle the cmnreset stuff in the power well code now,
so intel_reset_dpio() is no longer needed.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/driver
From: Ville Syrjälä
CHV wants even rps opcodes so make sure the min/max/rpe values are also
even.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 8
drivers/gpu/drm/i915/intel_pm.c | 19 ++-
2 files changed, 22 insertions(+), 5 deletions(-)
From: Ville Syrjälä
We enable the DPLL refclock already when bringing up the cmnlane power
well, so also leave it on when otherwise disabling the DPLL.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
From: Ville Syrjälä
init_clock_gating() is too late to read out the mem_freq. We already
want to print out the GPU MHz numbers before it's called. Move the
mem_freq setup to init_gt_powersave().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 68 +++--
From: Ville Syrjälä
CHV was forgotten the intel_{dp,hdmi}_prepare() were introduced (or the
chv patches were still in flight?). Call these when enabling the ports.
Things tend to work much better when we actually write something
to the port registers :)
Signed-off-by: Ville Syrjälä
---
driver
From: Ville Syrjälä
mem_freq is needed to decode the GPU freq opcodes.
FIXME: Punit reg seems to contain garbage so this isn't right
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/in
From: Ville Syrjälä
No need to re-read the hardware rps fuses when we already have all the
values tucked away in dev_priv->rps.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel
From: Ville Syrjälä
Looks like the Punit is supposed to support the 400MHz cdclk directly on
chv, so we don't need the vlv tricks.
FIXME: Punit doesn't seem ready for this yet on current hw
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/in
From: Ville Syrjälä
I was slaving over my bsw for most of the past week and this is the
result. It should really be split up into several series, but no
time now when vacation is calling. So I figured that I'll just post
the entire pile and disappear.
The whole lot can be found here (sitting on
I have the feeling the safest side would be disable rc6 on resume instead
of force its enabling... or am I missing something?
why don't you just cancel the work? and put another after resume?
but if the patch really solves the problem and this is what you meant feel
free to use:
Reviewed-by: Rodri
Reviewed-by: Rodrigo Vivi
On Fri, Jun 27, 2014 at 3:09 PM, Ben Widawsky
wrote:
> There are some cases in the code where we need to know how many rings to
> iterate over, but cannot use for_each_ring(). These are always error cases
> which happen either before ring setup, or after ring teardown
As pointed out before we don't have a reliable way to read back ips
status on BDW without the risk to disable it when reading.
However now we are pretending that IPS on BDW is always on and getting
people confused about it.
So this patch allows people to know if ips was ever attempted to be enable
There are some cases in the code where we need to know how many rings to
iterate over, but cannot use for_each_ring(). These are always error cases
which happen either before ring setup, or after ring teardown (or
reset).
Note, a NUM_RINGS issue exists in semaphores, but this is fixed by the
remai
From: Paulo Zanoni
It is possible that, by the time we run i915_drm_freeze(),
delayed_resume_work was already queued but did not run yet. If it
still didn't run after intel_runtime_pm_disable_interrupts(), by the
time it runs it will try to change the interrupt registers with the
interrupts alrea
Hi Egbert,
On Fri, 2014-06-27 at 15:55 +0200, Egbert Eich wrote:
> Chris Wilson writes:
> > On Fri, Jun 27, 2014 at 12:07:47AM +0200, Egbert Eich wrote:
> > >
> > > Hi Daniel, hi Imre,
> > >
> > > Daniel Vetter writes:
> > > > Adding Egbert since he's done the original hack here. Imre ple
This will be needed by an upcoming patch too that needs to sanitize the
VDD state during resume. The additional async disabling is only needed
for the resume path, here it doesn't make a difference since we enable
VDD right after the sanitize call.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i9
Just like during booting the BIOS can leave the VDD bit enabled after
system resume. So apply the same state sanitization there too. This
fixes a problem where after resume the port power domain refcount gets
unbalanced.
Reported-by: Jarkko Nikula
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i9
On 06/11/2014 08:41 AM, Jesse Barnes wrote:
On Wed, 11 Jun 2014 17:39:29 +0200
Daniel Vetter wrote:
On Wed, Jun 11, 2014 at 5:13 PM, Jesse Barnes wrote:
- If you have a machine which uses tiled framebuffers and enables
swizzling in the BIOS your code will a) drop the swizzle setup in
g
The Toshiba CB35 Chromebook laptop has a controllable backlight although
its VBT reports otherwise.
Patch tested by author on Toshiba CB35.
Signed-off-by: Scot Doyle
CC: Jani Nikula
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 89d9fe8..90
The HP 14 (Celeron 2955U) Chromebook laptop has a controllable backlight
although its VBT reports otherwise.
Signed-off-by: Scot Doyle
CC: Jani Nikula
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2ac699b..89d9fe8 100644
--- a/drivers/gpu/d
The Dell 11 Chromebook laptop has a controllable backlight although its
VBT reports otherwise.
Signed-off-by: Scot Doyle
CC: Jani Nikula
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2855d29..2ac699b 100644
--- a/drivers/gpu/drm/i915/intel_
On Tue, 24 Jun 2014 18:27:40 +0300
Jani Nikula wrote:
> Historically we've exposed the full backlight PWM duty cycle range to
> the userspace, in the name of "mechanism, not policy". However, it turns
> out there are both panels and board designs where there is a minimum
> duty cycle that is requ
The Acer C720 laptop has a controllable backlight although its VBT reports
otherwise.
Tested-by: James Duley
Signed-off-by: Scot Doyle
CC: Jani Nikula
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c583b07..2855d29 100644
--- a/drivers/gpu/
Add a quirk to assert the presence of a controllable backlight. Use it to
ignore the VBT backlight presence check during backlight setup.
Tested-by: James Duley
Signed-off-by: Scot Doyle
CC: Jani Nikula
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8
On Fri, Jun 27, 2014 at 05:19:23PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> There's no need for this to be modifiable. Make it const so that it can
> be put into the .rodata section.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Thierry Reding
Definitely a good thing. For Ar
commit c675949ec58ca50d5a3ae3c757892f1560f6e896
drm/i915: do not setup backlight if not available according to VBT
caused a regression on machines with a misconfigured VBT. Add a quirk to
assert the presence of a controllable backlight, overriding the VBT. Then
apply this quirk to four Hasw
From: Thierry Reding
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
driver
From: Daniel Vetter
Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.
This race is especially noticable on embedded platforms where the
driver
From: Thierry Reding
A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized yet. This happ
From: Thierry Reding
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplu
From: Tim Gore
igt_subtest_init mainly does stuff that we also want for
simple/single tests, such as looking for --list-subtests
and --help options and calling common_init. So just call
this from igt_simple_init and then set tests_with_subtests
to false. NOTE that this means that check_igt_exit i
From: Tim Gore
Quite a few single tests do not use the igt_simple_main
macro because they want access to argc/argv. So change the
igt_simple_main macro to pass these arguments through to the
"__real_mainxxx" function, and change these tests to use
the macro.
Signed-off-by: Tim Gore
---
lib/igt
From: Tim Gore
A step towards towards removing the distinction between
single and multiple tests. The first step is to change
the igt_simple_main macro to pass argc/v through to the
real_main function, so that several simple tests that want
argc/v can still use this macro.
Once this is done, all
Chris Wilson writes:
> On Fri, Jun 27, 2014 at 12:07:47AM +0200, Egbert Eich wrote:
> >
> > Hi Daniel, hi Imre,
> >
> > Daniel Vetter writes:
> > > Adding Egbert since he's done the original hack here. Imre please keep
> > > him on cc.
> > > -Daniel
> >
> > I finally managed to get
On Thu, 26 Jun 2014, Pavel Machek wrote:
> Ok, so I have set up machines for ktest / autobisect, and found out that
> 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun,
> anyway...
I am still seeing the problem with 3.16-rc2.
--
Jiri Kosina
SUSE Labs
__
On 6/27/2014 4:08 PM, Tvrtko Ursulin wrote:
Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+struct drm_property *prop,
+uint64_t val)
+{
+struct drm_device *dev
On 6/27/2014 4:42 PM, Tvrtko Ursulin wrote:
On 06/27/2014 11:49 AM, Jindal, Sonika wrote:
On 6/27/2014 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+
On 06/27/2014 11:49 AM, Jindal, Sonika wrote:
On 6/27/2014 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+struct drm_property *prop,
+
On 6/27/2014 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+struct drm_property *prop,
+uint64_t val)
+{
+struct drm_device *dev
Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+ struct drm_property *prop,
+ uint64_t val)
+{
+ struct drm_device *dev = plane->dev;
Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+ struct drm_property *prop,
+ uint64_t val)
+{
+ struct drm_device *dev = plane->dev;
On Sat, Jun 28, 2014 at 11:26:11AM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Workaround fixed in Latest VLV revision. Forcing Gfx clk up not needed, and
> Requesting the
> min freq should bring bring the voltage Vnn.
>
> v2: Drop WA for Latest VLV revision (Ville)
>
> Signed-
On Sat, 28 Jun 2014, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Workaround fixed in Latest VLV revision. Forcing Gfx clk up not needed, and
> Requesting the
> min freq should bring bring the voltage Vnn.
>
> v2: Drop WA for Latest VLV revision (Ville)
Bugzilla: https://bugs.freedesktop
77 matches
Mail list logo
