> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Tuesday, June 24, 2014 11:58 PM
> To: Wang, Quanxian
> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable
> for valleyview p
I'm sure this might affect Wayne, so, cc'ing him here.
from my point of view this is right so:
Reviewed-by: Rodrigo Vivi
On Tue, Jun 24, 2014 at 3:59 AM, wrote:
> From: Ville Syrjälä
>
> BDW signals the flip done interrupt immediately after the DSPSURF write
> when the plane is disabled. Thi
Apparently trinary logic is hard. We were falling through all the forced
cases and simply enabling aliasing PPGTT or not based on hardware,
rather than full PPGTT if available.
References: https://bugs.freedesktop.org/show_bug.cgi?id=80083
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i9
On Mon 2014-06-09 13:03:31, Jiri Kosina wrote:
> On Mon, 9 Jun 2014, Pavel Machek wrote:
>
> > > > Strange. It seems 3.15 with the patch reverted only boots in 30% or so
> > > > cases... And I've seen resume failure, too, so maybe I was just lucky
> > > > that it worked for a while.
> > >
> > > g
On Fri, Jun 20, 2014 at 01:43:50PM +0200, Joerg Roedel wrote:
> Change_pte is also called when the underlying page of an address
> changes in the kernel which would matter for DMA. But that can only
> happen in KSM and uprobes code which is probably not of interest for the
> i915 driver.
>
> The o
On Wed, Jun 25, 2014 at 12:03:01PM -0700, Jesse Barnes wrote:
> On Fri, 13 Jun 2014 13:37:56 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Now that the CMNRESET deassert is part of the cmnlane power well,
> > intel_reset_dpio() is called too late to make any diff
On Wed, Jun 25, 2014 at 11:55:58AM -0700, Jesse Barnes wrote:
> On Fri, 13 Jun 2014 13:37:53 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > If someone is interested in the current cdclk frquency it should
> > be stable and not in process of changing frquency. Warn
On Wed, Jun 25, 2014 at 11:54:06AM -0700, Jesse Barnes wrote:
> On Fri, 13 Jun 2014 13:37:51 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Drop the cdclk frequency to 200MHz on vlv when all pipes are off. In
> > theory we should be able to use 200MHz also when th
From: Daniel Vetter
To be able to do this we need to separately keep track of how many
crtcs need a given WRPLL and how many actually actively use it. The
common shared dpll framework already has all this, including massive
state readout and cross checking. Which allows us to do this switch in
a
From: Daniel Vetter
Currently still with a redudant WARN_ON in there, the common shared
dpll code will take care of this in the future.
Also we need to flip the switch for the transitional hack now to make
sure that we disable the right pll.
Signed-off-by: Daniel Vetter
Reviewed-by: Damien Les
From: Daniel Vetter
To make things a bit more manageable extract a new function for
reading out common ddi port state. This means a bit of duplication
between encoders and the core since both look at the same registers,
but doesn't seem worth to make a fuzz about.
We can also remove the state re
From: Daniel Vetter
Similar to how the ->crtc_mode_set hook should touch the hardware to
enable anything the ->crtc_off hook should disable anything in the
hardware. Otherwise runtime pm for dpms will not work.
Currently the only things left int the haswell_crtc_off hook is
disabling the ddi pll
From: Daniel Vetter
SPLL would be a reference clock we could potentially share,
especially if we want to use the SSC mode. But currently we
don't, so let's rip out this complexity for a simpler conversion
to the new display pll framework.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i
From: Daniel Vetter
Just filing in names and ids, but not yet officially registering them
so that the hw state cross checker doesn't completely freak out about
them. Still since we do already read out and cross check
config->shared_dpll the basics are now there to flesh out the wrpll
shared dpll
From: Daniel Vetter
The WRPLLs won't use them.
Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b0cbe4..650a5ad 100644
---
This is needed by an upcoming patch that moves the PCH/CRT PLL disabling
into the post_disable hook, after which we want to keep the modeset
sequence at its current state. At this point this won't have an effect
since the PCH/CRT post_disable hook is atm a NOP.
Signed-off-by: Imre Deak
---
drive
From: Daniel Vetter
Mostly this patch is one big excersize in deleting code and asserts
which are no longer needed. Note that we still abuse the shared dpll
framework a bit since we call the enable/disable functions from the
crtc mode_set and off hooks. But changing the actual hardware sequence
w
From: Daniel Vetter
Just boring sed job for preparation.
Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c | 34 +-
drivers/gpu
On Fri, 13 Jun 2014 13:37:57 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Set some bits in CCK/CCU to turn off display clocks when disp2d is power
> gated. Not sure this really helps with anything. Docs aren't all that clear.
>
> XXX: Doesn't actually work. CCK_DISPLAY_R
From: Daniel Vetter
This time around another cute hack to pre-fill the pll->hw_state with
the right values. And also remove a bunch of checks which will be
replaced by lots more checks in the common framework.
Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
---
drivers/gpu/drm/i915/i
From: Daniel Vetter
Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a93b3bf..a0d8733
From: Daniel Vetter
The call to intel_ddi_pll_enable in haswell_crtc_mode_set is the only
function that still touches the hardware state from the crtc mode_set
callback on hsw. Since the SPLL isn't ever shared we can easily take
it out into the hsw crt encoder functions.
Temporarily we'll loose
From: Daniel Vetter
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 62b6896..35e7c89 100644
--- a/driver
From: Daniel Vetter
This way only the dynamic WRPLL selection for hdmi ddi mode is
done in intel_ddi_pll_select.
v2: Don't clobber the precomputed values when selecting clocks fro
hdmi encoders.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 4 +++-
drivers/gpu/drm/i915/
From: Daniel Vetter
Still tacked onto the side, but slowly getting there.
v2: Don't forget the debugfs file.
Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h
On Fri, 13 Jun 2014 13:37:56 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that the CMNRESET deassert is part of the cmnlane power well,
> intel_reset_dpio() is called too late to make any difference. We've
> deasserted CMNRESET by that time, and so the off+on toggle w
From: Daniel Vetter
All the other checks also check hw state, so checking our software
refcounts for the plls looks a bit odd. Also this will simplify the
conversion over to the shared dpll framework, which itself has massive
amounts of checks to make sure that we never leave a display pll
enable
From: Daniel Vetter
Luckily the bit definitions match, but it's still confusing
to use one when handling the other. So sprinkle some OCD over
the #defines to make them match and use the right version in
each place.
Maybe we should unify these definitions completely, but that
can always be done s
This is a respin of the unmerged part of Daniel's runtime PM for DPMS
patchset [1]. The original one also included a refactoring of the DDI
PCH/CRT encoder modesetting path, I left the corresponding patches out
from this series. This is because there hasn't been yet an agreement on
those parts, but
This is needed by an upcoming patch that moves the PCH/CRT PLL enabling
into the pre_enable hook, after which we want to keep the modeset
sequence at its current state. At this point this won't have an effect
since the PCH/CRT pre_enable hook is atm a NOP.
Signed-off-by: Imre Deak
---
drivers/gp
On Fri, 13 Jun 2014 13:37:55 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Remove the clutter in __vlv_set_power_well() by moving the cmnlane
> handling into custom enable/disable hooks for the cmnlane.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel
On Fri, 13 Jun 2014 13:37:54 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have a slightly different way of readoing out the cdclk in
> gmbus_set_freq(). Kill that and just call .get_display_clock_speed().
>
> Also need to remove the GMBUSFREQ update from intel_i2c_res
On Fri, 13 Jun 2014 13:37:53 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If someone is interested in the current cdclk frquency it should
> be stable and not in process of changing frquency. Warn if the current
> and requested cdclk don't match in .get_display_clock_spee
On Fri, 13 Jun 2014 13:37:52 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> VLV Punit doesn't support the 400MHz cdclk option, so we bypass the
> Punit and poke at CCK directly. However we forgot to wait for the
> frequeency change to complete. Poll the CCK clock status to
On Fri, 13 Jun 2014 13:37:51 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Drop the cdclk frequency to 200MHz on vlv when all pipes are off. In
> theory we should be able to use 200MHz also when the pixel clock is at
> most 90% of 200MHz. However in practice all we seem to
On Fri, 13 Jun 2014 13:37:50 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Depending on the HPLL frequency one of the supported cdclk frquencies is
> either 320MHz or 333MHz. Figure out which one it is to accurately pick
> the minimal required cdclk. This would also avoid
On Wed, 25 Jun 2014, Ville [iso-8859-1] Syrj�l� wrote:
> On Wed, Jun 25, 2014 at 02:06:55PM -0400, Alan Stern wrote:
> > Daniel:
> >
> > I encountered a new problem in the i915 driver the first time I booted
> > a 3.16-rc kernel on this computer. When it switched over to the frame
> > buffer d
On Fri, 13 Jun 2014 13:37:49 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have a standard hook for reading out the current cdclk. Move the VLV
> code from valleyview_cur_cdclk() to .get_display_clock_speed().
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/
On Fri, 13 Jun 2014 13:37:48 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Avoid using magic values for CCK frequency bits. Also the mask we were
> using for the requested frequency was one bit too short. Fix it up.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/d
On Fri, 13 Jun 2014 13:37:47 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Use kHz units in vlv cdclk code since that's more customary.
>
> Also replace the precomputed 90% values with *9/10 computation
> for extra clarity.
>
> Signed-off-by: Ville Syrjälä
> ---
> driv
On Wed, Jun 25, 2014 at 08:24:29AM -0700, Jesse Barnes wrote:
> Apparently we can't trust this field on other platforms and need to find
> some other way.
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Ville Syrjälä
Since it's a regression it might be a good idea to note the
offender:
commit 27
On Wed, Jun 25, 2014 at 02:06:55PM -0400, Alan Stern wrote:
> Daniel:
>
> I encountered a new problem in the i915 driver the first time I booted
> a 3.16-rc kernel on this computer. When it switched over to the frame
> buffer driver, the screen went blank and stayed that way.
>
> 3.15 works ok
Daniel:
I encountered a new problem in the i915 driver the first time I booted
a 3.16-rc kernel on this computer. When it switched over to the frame
buffer driver, the screen went blank and stayed that way.
3.15 works okay.
Attached are log extracts from 3.15 and 3.16 (both with drm.debug=0xe
Apparently we can't trust this field on other platforms and need to find
some other way.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu
On Wed, 25 Jun 2014 15:21:12 +0300
Jani Nikula wrote:
> On Mon, 31 Mar 2014, Jesse Barnes wrote:
> > With the new checks in place, we can see we're doing things backwards,
> > so fix them up per the spec.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 13
On Wed, Jun 25, 2014 at 02:26:52PM +0100, Tvrtko Ursulin wrote:
> >That's a good question to ask a GL team. In the light of sparse
> >textures I think the region idea would be better.
> >
> >We would need to define what the coordinates mean, for instance:
> > - 2D view of the buffer, and the kern
On 06/25/2014 01:57 PM, Damien Lespiau wrote:
On Wed, Jun 25, 2014 at 12:46:57PM +0100, Siluvery, Arun wrote:
On 25/06/2014 12:14, Damien Lespiau wrote:
On Wed, Jun 25, 2014 at 11:51:33AM +0100, Damien Lespiau wrote:
(This is not necessarily things one would need to take into account for
this
On Wed, Jun 25, 2014 at 03:03:44PM +0200, Tom Van Braeckel wrote:
> Hi,
>
> There seems to be a regression in the upcoming Linux 3.16-rc2 release
> candidate that I bisected down to this first bad commit:
> [dbb42748ac4929987c1449ecb296b39ef8956b62] drm/i915: Move the C3 LP
> write bit setup to ge
On Wed, Jun 25, 2014 at 12:46:57PM +0100, Siluvery, Arun wrote:
> On 25/06/2014 12:14, Damien Lespiau wrote:
> >On Wed, Jun 25, 2014 at 11:51:33AM +0100, Damien Lespiau wrote:
> >>(This is not necessarily things one would need to take into account for
> >>this work, just a few thoughts).
> >>
> >>O
On Tue, 01 Apr 2014, Jesse Barnes wrote:
> On Tue, 01 Apr 2014 10:19:29 +0300
> Jani Nikula wrote:
>
>> On Mon, 31 Mar 2014, Jesse Barnes wrote:
>> > To make sure we properly follow the enable/disable sequences.
>> >
>> > Signed-off-by: Jesse Barnes
>> > ---
>> > drivers/gpu/drm/i915/intel_dp.
On Mon, 31 Mar 2014, Jesse Barnes wrote:
> With the new checks in place, we can see we're doing things backwards,
> so fix them up per the spec.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_dp.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff
On 25/06/2014 12:14, Damien Lespiau wrote:
On Wed, Jun 25, 2014 at 11:51:33AM +0100, Damien Lespiau wrote:
(This is not necessarily things one would need to take into account for
this work, just a few thoughts).
One thing I'm wondering is how fitting the "size" parameter really is
when talking
On Wed, Jun 25, 2014 at 11:51:33AM +0100, Damien Lespiau wrote:
> (This is not necessarily things one would need to take into account for
> this work, just a few thoughts).
>
> One thing I'm wondering is how fitting the "size" parameter really is
> when talking about inherently 2D buffers.
>
> Fo
On Tue, 24 Jun 2014, Aaron Lu wrote:
> Some Thinkpad laptops' firmware will initiate a backlight level change
> request through operation region on the events of AC plug/unplug, but
> since we are not using firmware's interface to do the backlight setting
> on these affected laptops, we do not wan
On Mon, Apr 28, 2014 at 04:01:29PM +0100, arun.siluv...@linux.intel.com wrote:
> From: "Siluvery, Arun"
>
> This patch adds support to have gem objects of variable size.
> The size of the gem object obj->size is always constant and this fact
> is tightly coupled in the driver; this implementation
On Wed, 25 Jun 2014, Chris Wilson wrote:
> On Tue, Jun 24, 2014 at 05:05:02PM -0700, Matt Roper wrote:
>> crtc->primary->fb may be NULL upon entry to intel_pipe_set_base() if the
>> primary plane has previously been disabled via the universal plane
>> interface. We need to check for NULL before t
On Tue, Jun 24, 2014 at 05:05:02PM -0700, Matt Roper wrote:
> crtc->primary->fb may be NULL upon entry to intel_pipe_set_base() if the
> primary plane has previously been disabled via the universal plane
> interface. We need to check for NULL before trying to reference
> old_fb's obj.
>
> This fi
On Wed, 25 Jun 2014, Todd Previte wrote:
> Implements some of the basic EDID tests for Displayport compliance. These
> tests
> include reading the EDID, verifying the checksum and writing the test
> responses
> back to the sink device.
>
> Signed-off-by: Todd Previte
> ---
> drivers/gpu/drm/i9
Il 25/06/2014 09:34, Chen, Tiejun ha scritto:
On 2014/6/25 14:48, Paolo Bonzini wrote:
Second problem. Your IGD passthrough code currently works with QEMU's
PIIX4-based machine. But what happens if you try to extend it, so that
Yes, current xen machine, xenpv, is based on pii4, and also I do
On 2014/6/25 14:48, Paolo Bonzini wrote:
Il 22/06/2014 10:25, Chen, Tiejun ha scritto:
In qemu-upstream, as you commented we can't create this as a ISA class
type explicitly.
Note I didn't say that QEMU doesn't like having two ISA bridges.
I commented that the firmware will see two ISA bridge
60 matches
Mail list logo
