On Tue, Jul 29, 2014 at 11:33:43PM -0700, Ben Widawsky wrote:
> On Wed, Jul 30, 2014 at 07:19:26AM +0100, Chris Wilson wrote:
> > On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote:
> > > This adds two new data points to the trace event, wait time, and whether
> > > or not the event slept
On Wed, Jul 30, 2014 at 07:19:26AM +0100, Chris Wilson wrote:
> On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote:
> > This adds two new data points to the trace event, wait time, and whether
> > or not the event slept. Both of these should already be obtainable
> > through various means
On Wed, Jul 30, 2014 at 07:15:05AM +0100, Chris Wilson wrote:
> On Tue, Jul 29, 2014 at 01:14:29PM -0700, Ben Widawsky wrote:
> > So don't bother checking it again.
> > This was introduced:
> > commit b361237bcc7cea1d99f770490120d8bc2aed
> > Author: Chris Wilson
> > Date: Fri Aug 24 09:35:08
On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote:
> This adds two new data points to the trace event, wait time, and whether
> or not the event slept. Both of these should already be obtainable
> through various means. This patch just makes the data more accessible.
Right, the key poin
On Tue, Jul 29, 2014 at 01:14:29PM -0700, Ben Widawsky wrote:
> So don't bother checking it again.
> This was introduced:
> commit b361237bcc7cea1d99f770490120d8bc2aed
> Author: Chris Wilson
> Date: Fri Aug 24 09:35:08 2012 +0100
>
> drm/i915: Juggle code order to ease flow of the next
On 30.07.2014 06:32, Daniel Vetter wrote:
> As usual in both a crtc index and a struct drm_crtc * version.
>
> The function assumes that no one drivers their display below 10Hz, and
> it will complain if the vblank wait takes longer than that.
>
> v2: Also check dev->max_vblank_counter since some
From: Libin Yang
call the intel_hdmi_prepare() in chv_hdmi_pre_enable() for
hdmi audio.
Signed-off-by: Libin Yang
---
drivers/gpu/drm/i915/intel_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5f8f4ca..5a65
On Tue, Jul 29, 2014 at 11:32:19PM +0200, Daniel Vetter wrote:
> Atomic implemenations for legacy ioctls must be able to drop locks.
> Which doesn't cause havoc since we only do that while constructing
> the new state, so no driver or hardware state change has happened.
>
> The only troubling bit
On 30 July 2014 07:32, Daniel Vetter wrote:
> Atomic implemenations for legacy ioctls must be able to drop locks.
> Which doesn't cause havoc since we only do that while constructing
> the new state, so no driver or hardware state change has happened.
>
> The only troubling bit is the fb refcounti
> ---
> drivers/gpu/drm/drm_crtc.c | 8 ++--
> drivers/gpu/drm/drm_modeset_lock.c | 84
> ++
> include/drm/drm_crtc.h | 6 +++
> include/drm/drm_modeset_lock.h | 5 +++
> 4 files changed, 99 insertions(+), 4 deletions(-)
>
> diff --gi
On 30 July 2014 07:32, Daniel Vetter wrote:
> Somehow we've forgotten about this little bit of OCD.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Dave Airlie
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailm
On Tue, Jul 29, 2014 at 11:32:16PM +0200, Daniel Vetter wrote:
> In the atomic state we'll have an array of states for crtcs, planes
> and connectors and need to be able to at them by their index. We
> already have a drm_crtc_index function so add the missing ones for
> planes and connectors.
>
>
2014-07-14 16:10 GMT-03:00 Todd Previte :
> Implements an updated version of the automated testing function that handles
> Displayport compliance for EDID operations.
Both the commit message and the code should mention the name of the
specification that defines these tests, and also mention which
On 28/07/2014 18:26, Ville Syrjälä wrote:
On Mon, Jul 28, 2014 at 05:31:45PM +0100, arun.siluv...@linux.intel.com wrote:
From: Arun Siluvery
This patch moves BDW workarounds from init_clock_gating() to render ring
init fn otherwise they are lost when gpu is reset.
In case of execlists, some of
Am 29.07.2014 23:35, schrieb Daniel Vetter:
On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann wrote:
Am 18.07.2014 18:25, schrieb Daniel Vetter:
On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann wrote:
Am 18.07.2014 15:27, schrieb Daniel Vetter:
On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan
From: Clint Taylor
CEA SD interlaced modes use a horizontal 720 pixels that are pixel replicated
to 1440. The current driver reports 1440 pixel to the OS and does not set pixel
replicated modes.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_edid.c| 68 ++--
2014-07-22 18:11 GMT-03:00 Jesse Barnes :
> 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 b
On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann wrote:
> Am 18.07.2014 18:25, schrieb Daniel Vetter:
>>
>> On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann wrote:
>>
>>>
>>> Am 18.07.2014 15:27, schrieb Daniel Vetter:
On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote:
>>>
In the fbdev code we want to do trylocks only to avoid deadlocks and
other ugly issues. Thus far we've only grabbed the overall modeset
lock, but that already failed to exclude a pile of potential
concurrent operations. With proper atomic support this will be worse.
So add a trylock mode to the mo
Somehow we've forgotten about this little bit of OCD.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 95 --
drivers/gpu/drm/drm_modeset_lock.c | 95 ++
include/drm/drm_crtc.h | 4 --
inclu
So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.
Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those path
This has the upside that it will no longer steal interrupts from the
interrutp handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 41 +-
Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.
The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then i
As usual in both a crtc index and a struct drm_crtc * version.
The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.
v2: Also check dev->max_vblank_counter since some drivers register a
fake get_vblank_counter function.
In general having this can't hurt, and the atomic helpers will need
it to be able to reset the state objects properly. The overall idea
is to reset in the order pixels flow, so planes -> crtcs ->
encoders -> connectors.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 +
inclu
Hi all,
So I've split out every single hunk that touches existing code from my atomic
series and this is it. It mostly touches error handling code and other more
exceptional stuff. My idea is that if we get this in now we have a bit more
leeway with the actual atomic infrastructure work since that
In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.
If it later on turns out that the list walking is too expensive we can
add
Am 18.07.2014 18:25, schrieb Daniel Vetter:
On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann wrote:
Am 18.07.2014 15:27, schrieb Daniel Vetter:
On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote:
I'm experiencing an issue with 3.15.5 on my Lenovo T400:
Since 3.15 (or 3.14, can't s
So don't bother checking it again.
This was introduced:
commit b361237bcc7cea1d99f770490120d8bc2aed
Author: Chris Wilson
Date: Fri Aug 24 09:35:08 2012 +0100
drm/i915: Juggle code order to ease flow of the next patch
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i
This adds two new data points to the trace event, wait time, and whether
or not the event slept. Both of these should already be obtainable
through various means. This patch just makes the data more accessible.
Wait is obtainable with the current code by matching seqnos in
begin/end. In simple cas
On Tue, Jul 29, 2014 at 11:44:51AM -0700, Ben Widawsky wrote:
> On Tue, Jul 29, 2014 at 11:32:07AM -0700, Ben Widawsky wrote:
> > On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> > > VMAs should take a reference of the address space they use.
> > >
> > > Now, when the fd is closed
On Tue, Jul 29, 2014 at 10:18:46PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 29, 2014 at 08:06:57PM +0200, Daniel Vetter wrote:
> > On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
> > > On Sat, 28 Jun 2014 02:04:28 +0300
> > > ville.syrj...@linux.intel.com wrote:
> > >
> > > > From:
On Tue, Jul 29, 2014 at 08:06:57PM +0200, Daniel Vetter wrote:
> On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
> > On Sat, 28 Jun 2014 02:04:28 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > When switching from one pipe to another, the po
On Tue, Jul 29, 2014 at 09:34:34PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 29, 2014 at 08:04:59PM +0200, Daniel Vetter wrote:
> > On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
> > > On Sat, 28 Jun 2014 02:04:25 +0300
> > > ville.syrj...@linux.intel.com wrote:
> > >
> > > > From:
On Tue, Jul 29, 2014 at 09:55:39AM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:04:03 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > CHV display PHY registes have two swing margin/deemph settings. Make it
> > clear which ones we're using.
> >
> > Signed-of
On Tue, Jul 29, 2014 at 11:13:03AM -0700, Jesse Barnes wrote:
> On Thu, 17 Jul 2014 17:43:46 -0300
> Paulo Zanoni wrote:
>
> > From: Paulo Zanoni
> >
> > Since we started using intel_runtime_pm_disable_interrupts() at normal
> > (non-runtime) suspend/resume, we had to remove a WARN from
> > iro
On Tue, Jul 29, 2014 at 11:32:07AM -0700, Ben Widawsky wrote:
> On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> > VMAs should take a reference of the address space they use.
> >
> > Now, when the fd is closed, it will release the ref that the context was
> > holding, but it will
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ä
> >
> > Looks like the Punit is supposed to support the 400MHz cdclk directly on
> > chv, so we don't need the vlv tricks.
> >
> >
On Tue, Jul 29, 2014 at 08:04:59PM +0200, Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
> > On Sat, 28 Jun 2014 02:04:25 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > CHV supports DP training pattern 3. Add the req
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> VMAs should take a reference of the address space they use.
>
> Now, when the fd is closed, it will release the ref that the context was
> holding, but it will still be referenced by any vmas that are still
> active.
>
> ppgtt_rele
On Tue, Jul 29, 2014 at 06:06:15PM +0100, Damien Lespiau wrote:
> Turns out we were optimistic. intel_ prefixes don't tend to last and this is
> one of those times.
Pulled in the entire series to dinq, thanks.
-Daniel
>
> --
> Damien
>
> Damien Lespiau (10):
> drm/i915: Specify when the PLL
On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:04:28 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > 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
On Tue, Jul 29, 2014 at 06:06:20PM +0100, Damien Lespiau wrote:
> Future platform will use config->ddi_pll_sel in a different way.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i
Should be useful to test intel_ring_begin restart behaviour a bit.
Signed-off-by: Daniel Vetter
---
tests/gem_ringfill.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tests/gem_ringfill.c b/tests/gem_ringfill.c
index 5700a74d260b..750537a9bbab 100644
--- a/tests/gem_ring
On Tue, Jul 29, 2014 at 05:25:48PM +, Mcaulay, Alistair wrote:
>
> drv_suspend, gem_hangcheck_forcewake are working fine now with PPGTT
> enabled. Both with and without my patch.
>
> The results are the same with and without my patch for:
>
> $ sudo ~/drm_nightly/intel-gpu-tools/tests/drv_
On Thu, 17 Jul 2014 17:43:46 -0300
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Since we started using intel_runtime_pm_disable_interrupts() at normal
> (non-runtime) suspend/resume, we had to remove a WARN from
> ironlake_disable_display_irq to avoid a case where we were doing the
> correct th
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ä
> > >
> > > Looks like the Punit is supposed to support the 400M
On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:04:25 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > CHV supports DP training pattern 3. Add the required stuff.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/
On Tue, Jul 29, 2014 at 09:59:53AM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:04:20 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Kenneth Graunke
> >
> > We'll want to reuse this for a workaround.
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > drivers/gpu/drm/i915/inte
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ä
> >
> > Looks like the Punit is supposed to support the 400MHz cdclk directly on
> > chv, so we don't need the vlv tricks.
> >
> >
On Tue, Jul 29, 2014 at 08:31:55PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 19, 2014 at 05:41:24PM -0700, Matt Roper wrote:
> > On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a flag to drm_device which will cause the
On Thu, Jun 19, 2014 at 05:41:24PM -0700, Matt Roper wrote:
> On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add a flag to drm_device which will cause the vblank code to bypass the
> > disable timer and always disable the vblank inte
drv_suspend, gem_hangcheck_forcewake are working fine now with PPGTT enabled.
Both with and without my patch.
The results are the same with and without my patch for:
$ sudo ~/drm_nightly/intel-gpu-tools/tests/drv_hangman
IGT-Version: 1.7-g70e6ed9 (x86_64) (Linux: 3.16.0-rc5+ x86_64)
Subtest e
This is only going to get worse, so split it now to avoid adding more
cases to the if/else ladder.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 55 +++-
1 file changed, 38 insertions(+), 17 deletions(-)
dif
Turns out we were again way too naive and optimistic, of course things
will change.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_dd
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 98e2fd5..69dc54c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/dri
Future platform will slightly change that.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0
We'll need a different algorithm to select the shared DPLL.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/int
Turns out we were optimistic. intel_ prefixes don't tend to last and this is
one of those times.
--
Damien
Damien Lespiau (10):
drm/i915: Specify when the PLL hw state fields are valid
drm/i915: Add a space to the shared DPLL debug message
drm/i915: Extract the HSW DDI selection code into
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1edfd1a..0147652 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/dr
So we can easily provide an alternate implementation in the future.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 184890
Future platform will use config->ddi_pll_sel in a different way.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ea6ff71..bdbe8f7 100644
-
Since the run-time PM on DPMS series, this function has an outdated
comment. Refresh it a bit.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/i
Not all those fields are valid on a given platform. Make it explicit.
Unions could also be used, but were cluttering some code paths with
if/else ladders.
v2: Don't use anonymous unions (Daniel)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
1 file changed, 3 insert
On Sat, 28 Jun 2014 02:04:25 +0300
ville.syrj...@linux.intel.com wrote:
> 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 ++
On Sat, 28 Jun 2014 02:04:20 +0300
ville.syrj...@linux.intel.com wrote:
> 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 ins
On Sat, 28 Jun 2014 02:04:18 +0300
ville.syrj...@linux.intel.com wrote:
> 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: Vil
On Sat, 28 Jun 2014 02:04:05 +0300
ville.syrj...@linux.intel.com wrote:
> 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).
>
On Sat, 28 Jun 2014 02:04:03 +0300
ville.syrj...@linux.intel.com wrote:
> 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 ++--
>
On Sat, 28 Jun 2014 02:04:02 +0300
ville.syrj...@linux.intel.com wrote:
> 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 actuall
On Sat, 28 Jun 2014 02:04:00 +0300
ville.syrj...@linux.intel.com wrote:
> 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_prepa
On Sat, 28 Jun 2014 02:03:59 +0300
ville.syrj...@linux.intel.com wrote:
> 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
On Sat, 28 Jun 2014 02:03:58 +0300
ville.syrj...@linux.intel.com wrote:
> 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 ch
On Sat, 28 Jun 2014 02:03:57 +0300
ville.syrj...@linux.intel.com wrote:
> 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: V
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:
> > > > */
> > > > int
> > > > i915_gem_object_sync(struct drm_i915_ge
On Fri, Jun 27, 2014 at 09:35:13PM +0300, Imre Deak wrote:
> 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 th
2014-07-29 7:22 GMT-03:00 Ville Syrjälä :
> On Mon, Jul 28, 2014 at 03:37:12PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If we're runtime suspended and try to use the cursor interfaces, we
>> will get a lot of WARNs saying we did the wrong thing.
>>
>> For intel_crtc_update_cursor(),
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Barbalho, Rafael
> Sent: Tuesday, July 29, 2014 2:38 PM
> To: Ville Syrjälä
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, July 29, 2014 2:13 PM
> To: Barbalho, Rafael
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915: Correctly read backlight PWM for pipe B on
> vlv/chv
>
> On Tue, Jul 29, 20
On Tue, Jul 29, 2014 at 01:44:40PM +0100, rafael.barba...@intel.com wrote:
> From: Rafael Barbalho
>
> Make the vlv/chv backlight setup more generic by actually looking at which
> pipe the panel is attached to and read the backlight PWM registers that were
> setup by the bios from that pipe.
>
>
From: Rafael Barbalho
Make the vlv/chv backlight setup more generic by actually looking at which
pipe the panel is attached to and read the backlight PWM registers that were
setup by the bios from that pipe.
Cc: Ville Syrjälä
Signed-off-by: Rafael Barbalho
---
drivers/gpu/drm/i915/intel_panel
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
> Ensure that the DSI packets for a particular sequence are completely
> sent before going ahead in the enabling or disabling of the panel
>
> Signed-off-by: Shobhit Kumar
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_dsi.c
On Tue, 2014-07-15 at 18:15 +0530, Shobhit Kumar wrote:
> Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
> It will not be enabled for DSI and avoid dpio read WARN dumps.
>
> Absence of ->get_config was causing other WARN dumps as well. Update
> dpll_hw_state as well corre
On Tue, Jul 29, 2014 at 02:38:36PM +0300, Imre Deak wrote:
> On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
> > Call to vlv_crtc_clock_get is not needed for DSI and was causing dpio
> > read WARN dumps as well. Absence of ->get_config was casuing othet WARN
> > dumps as well. With this the
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
> Call to vlv_crtc_clock_get is not needed for DSI and was causing dpio
> read WARN dumps as well. Absence of ->get_config was casuing othet WARN
> dumps as well. With this the last of the known WARN dumps for DSI should
> be fixed.
>
> Signe
On Mon, Jul 28, 2014 at 05:34:55PM +0200, Daniel Vetter wrote:
> On Mon, Jul 28, 2014 at 04:24:49PM +0100, Thomas Wood wrote:
> > Ensure tests using igt_enable_connectors can still run even if the
> > relevant debugfs files are not available.
> >
> > Signed-off-by: Thomas Wood
> > ---
> > lib/ig
On Tue, Jul 29, 2014 at 01:06:40PM +0200, Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> > VMAs should take a reference of the address space they use.
> >
> > Now, when the fd is closed, it will release the ref that the context was
> > holding, but it will
Pushed those, before I forget.
--
Damien
On Fri, Jul 11, 2014 at 03:09:01PM +0100, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> lib/igt_fb.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> index 6d030e6..f5110d4 100644
> --- a/lib/igt_fb.
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> VMAs should take a reference of the address space they use.
>
> Now, when the fd is closed, it will release the ref that the context was
> holding, but it will still be referenced by any vmas that are still
> active.
>
> ppgtt_rele
On Tue, Jul 29, 2014 at 12:50 PM, Dave Airlie wrote:
> On 29 July 2014 20:46, Daniel Vetter wrote:
>> On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote:
>>> On 23 July 2014 06:02, Paulo Zanoni wrote:
2014-06-05 1:01 GMT-03:00 Dave Airlie :
> From: Dave Airlie
>
> This adds DP
On 29 July 2014 20:46, Daniel Vetter wrote:
> On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote:
>> On 23 July 2014 06:02, Paulo Zanoni wrote:
>>> 2014-06-05 1:01 GMT-03:00 Dave Airlie :
From: Dave Airlie
This adds DP 1.2 MST support on Haswell systems.
>>>
>>> Hi
>>>
>>> It loo
On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote:
> On 23 July 2014 06:02, Paulo Zanoni wrote:
>> 2014-06-05 1:01 GMT-03:00 Dave Airlie :
>>> From: Dave Airlie
>>>
>>> This adds DP 1.2 MST support on Haswell systems.
>>
>> Hi
>>
>> It looks like drm-intel-nightly now includes this patch. It ac
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:
> > > */
> > > int
> > > i915_gem_object_sync(struct drm_i915_gem_object *obj,
> > > - struct intel_engine_cs *to)
> > >
On Tue, Jul 29, 2014 at 06:14:16AM -0400, Anders Kaseorg wrote:
> On Tue, 29 Jul 2014, Hans de Goede wrote:
> > I've been thinking a bit about this, and I believe that the right answer
> > here is to do the linear to logarithmic mapping in user-space. The intel
> > backlight interface has a type
On Tue, Jul 29, 2014 at 08:36:33AM +0100, Chris Wilson wrote:
> On Mon, Jul 28, 2014 at 11:26:38AM +0200, Daniel Vetter wrote:
> > Oh, I guess that's the tricky bit why the old approach never worked -
> > because reset_in_progress is set we failed the context/ppgtt loading
> > through the rings and
On Tue, Jul 29, 2014 at 12:40:29PM +0300, Ville Syrjälä wrote:
> On Mon, Jul 28, 2014 at 08:47:22PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 28, 2014 at 06:29:41PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jul 15, 2014 at 05:43:37PM +0530, sonika.jin...@intel.com wrote:
> > > > From: Sonika Jind
On Tue, Jul 29, 2014 at 12:54:36PM +0300, Imre Deak wrote:
> On Mon, 2014-07-28 at 18:19 +0300, Ville Syrjälä wrote:
> > On Fri, Jul 25, 2014 at 04:30:29PM +0300, Imre Deak wrote:
> > > On Sat, 2014-06-28 at 02:04 +0300, ville.syrj...@linux.intel.com wrote:
> > > > From: Ville Syrjälä
> > > >
> >
On Tue, Jul 29, 2014 at 08:37:48AM +0100, Chris Wilson wrote:
> On Mon, Jul 28, 2014 at 10:54:06AM +0200, Daniel Vetter wrote:
> > On Sat, Jul 26, 2014 at 11:27:38AM +0100, Chris Wilson wrote:
> > > On Wed, Jun 18, 2014 at 10:54:13PM +0200, Daniel Vetter wrote:
> > > > On Fri, Jun 13, 2014 at 04:38
On Mon, Jul 28, 2014 at 03:37:12PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we're runtime suspended and try to use the cursor interfaces, we
> will get a lot of WARNs saying we did the wrong thing.
>
> For intel_crtc_update_cursor(), all we need to do is return if the
> CRTC is not
On Tue, 29 Jul 2014, Hans de Goede wrote:
> I've been thinking a bit about this, and I believe that the right answer
> here is to do the linear to logarithmic mapping in user-space. The intel
> backlight interface has a type of raw, clearly signalling to userspace
> that it is a raw "untranslate
1 - 100 of 114 matches
Mail list logo