On Tue, May 20, 2014 at 03:25:33PM -0700, Jesse Barnes wrote:
> We really just want to go detect displays again and fire off a hotplug
> event if things have changed, not go through full hotplug processing.
>
> Requested-by: Daniel Vetter
> Signed-off-by: Jesse Barnes
Yeah, still can't remember
On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> Gets the detect code (which may take awhile) out of the resume path,
> speeding things up a bit.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On Wed, May 21, 2014 at 12:41:58PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> If some outputs go away we race with this call and apps
> get X errors and fall over. Do what SNA does and don't
> bother trying.
Horrible clients is why I gave up trying to report BadMatch for the
inactive pipe
On Tue, May 20, 2014 at 03:25:34PM -0700, Jesse Barnes wrote:
> In some cases, the callers of this function may not need the return
> value and delaying the uevent is ok. So add an async version of the
> function for use in those cases.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/dr
From: Dave Airlie
this is just prep work for mst support.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drive
From: Dave Airlie
This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 5 +
2 files chang
From: Dave Airlie
This is required to get fbcon probing to work on new connectors,
callers should acquire the mode config lock before calling these.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c | 53 +
include/drm/drm_fb_helper.h |
From: Dave Airlie
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/d
From: Dave Airlie
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm/i915/
From: Dave Airlie
use the mst helper code to dump the topology in debugfs.
v0.2: drop is_mst check - as we want to dump other info
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i9
From: Dave Airlie
These are just from the Haswell spec.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..557b37a 100644
From: Dave Airlie
This just adds the defines from the DP 1.2 spec, which we
will use later.
Signed-off-by: Dave Airlie
---
include/drm/drm_dp_helper.h | 78 +
1 file changed, 78 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/dr
Hey,
So this set is pretty close to what I think we should be merging initially,
Since the last set, it makes fbcon and suspend/resume work a lot better,
I've also fixed a couple of bugs in -intel that make things work a lot
better.
I've bashed on this a bit using kms-flip from intel-gpu-tools,
From: Dave Airlie
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a3fe324..f1753e6 10
From: Dave Airlie
If some outputs go away we race with this call and apps
get X errors and fall over. Do what SNA does and don't
bother trying.
Signed-off-by: Dave Airlie
---
src/uxa/intel_dri.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/uxa/intel_dri.c b/src/uxa
It seems it needs a rebase...
I couldn't figure out where exactly you will put the wait_for_pending so
I'm going to wait a v2.
But this is my fault that took a century to review it... I'm sorry...
On Tue, Apr 15, 2014 at 11:41 AM, wrote:
> From: Ville Syrjälä
>
> We have to write to the prima
Reviewed-by: Rodrigo Vivi
On Fri, Apr 25, 2014 at 3:30 AM, wrote:
> From: Ville Syrjälä
>
> Now that we've plugged the mmio vs. ring flip race, we shouldn't need
> these vblank waits in the modeset codepaths anymore. So get rid of
> them.
>
> v2: gen2 needs to wait for planes to turn off befo
Reviewed-by: Rodrigo Vivi
On Tue, Apr 15, 2014 at 11:41 AM, wrote:
> From: Ville Syrjälä
>
> Now that the vblank wait is gone from intel_enable_primary_plane(),
> hsw_enable_ips() needs to do the vblank wait itself.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display
needs a small rebase but everything looks good for me so
Reviewed-by: Rodrigo Vivi
On Tue, Apr 15, 2014 at 11:41 AM, wrote:
> From: Ville Syrjälä
>
> Starting from ILK, mmio flips also cause a flip done interrupt to be
> signalled. This means if we first do a set_base and follow it
> immediat
In some cases, the callers of this function may not need the return
value and delaying the uevent is ok. So add an async version of the
function for use in those cases.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_probe_helper.c | 8
include/drm/drm_crtc_helper.h | 2 ++
2
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
ind
We really just want to go detect displays again and fire off a hotplug
event if things have changed, not go through full hotplug processing.
Requested-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20 +---
1 file changed, 1 insertion(+), 19
On Tue, 20 May 2014 14:18:07 -0700
Jesse Barnes wrote:
> On Tue, 20 May 2014 14:10:16 -0700
> Jesse Barnes wrote:
>
> > On Tue, 20 May 2014 22:15:45 +0200
> > Daniel Vetter wrote:
> >
> > > On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> > > wrote:
> > > > Ah, poll_enable is false until aft
On Tue, 20 May 2014 14:10:16 -0700
Jesse Barnes wrote:
> On Tue, 20 May 2014 22:15:45 +0200
> Daniel Vetter wrote:
>
> > On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> > wrote:
> > > Ah, poll_enable is false until after _thaw finishes, so
> > > our hotplug_resume call of hpd_irq_event does n
On Tue, 20 May 2014 22:15:45 +0200
Daniel Vetter wrote:
> On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> wrote:
> > Ah, poll_enable is false until after _thaw finishes, so
> > our hotplug_resume call of hpd_irq_event does nothing. So aside from
> > the encoder hot_plug callbacks (which really
On Tue, May 20, 2014 at 09:46:01PM +0530, Shobhit Kumar wrote:
> >- UI is a period, so is homogeneous to time (s), but ui_num being in
> > s^-1 and ui_den a constant, ui_num/ui_den looks like a frequency. Or
> > could it be that UI = ui_den / ui_num? would be confusing, but the
> > code below
Since
commit 2e82a7203182d0883d0f9450d40ad6e1c6578ad9
Author: Imre Deak
Date: Fri Jan 17 15:46:43 2014 +0200
drm/i915: don't disable DP port after a failed link training
and
commit 5d6a1116c6475404e6505b708320f9579ae19acd
Author: Imre Deak
Date: Thu Jan 16 18:35:57 2014 +0200
drm
On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes wrote:
> Ah, poll_enable is false until after _thaw finishes, so
> our hotplug_resume call of hpd_irq_event does nothing. So aside from
> the encoder hot_plug callbacks (which really just check dp link status,
> which ought to be a no-op) our resume_h
On Tue, 20 May 2014 12:53:29 -0700
Jesse Barnes wrote:
> On Fri, 16 May 2014 23:42:23 +0100
> Chris Wilson wrote:
>
> > On Fri, May 16, 2014 at 11:38:07PM +0100, Chris Wilson wrote:
> > > On Fri, May 16, 2014 at 03:20:47PM -0700, Jesse Barnes wrote:
> > > > On Mon, 21 Apr 2014 18:37:31 +0200
>
On Fri, 16 May 2014 23:42:23 +0100
Chris Wilson wrote:
> On Fri, May 16, 2014 at 11:38:07PM +0100, Chris Wilson wrote:
> > On Fri, May 16, 2014 at 03:20:47PM -0700, Jesse Barnes wrote:
> > > On Mon, 21 Apr 2014 18:37:31 +0200
> > > Knut Petersen wrote:
> > > > > + /* This driver doesn't need
On Tue, 29 Apr 2014 23:30:49 +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
On Tue, May 20, 2014 at 12:00:27PM -0700, Jesse Barnes wrote:
> On Tue, 29 Apr 2014 23:30:48 +0300
> Jani Nikula wrote:
>
> > Somehow a few functions have been dropped in the middle of backlight
> > code. Move them around. No functional changes.
> >
> > Signed-off-by: Jani Nikula
> > ---
> > d
On Tue, 29 Apr 2014 23:30:48 +0300
Jani Nikula wrote:
> Somehow a few functions have been dropped in the middle of backlight
> code. Move them around. No functional changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_panel.c | 150
> ++---
On Mon, 19 May 2014 19:23:27 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently we need to disable VCP unit clock gating around media reset
> on g4x.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/int
On Mon, 19 May 2014 19:23:26 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Clear the reset domain after a succesful GPU reset on ilk. We already
> do that on gen4, so let's try to be a bit more consistent. And if
> ether render or media reset fails, we might use the leftov
On Mon, 19 May 2014 19:23:25 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> All the other bits in the GDSR register are read-only, so we don't have
> to preserve them when we perform a GPU reset.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_uncore.
On Mon, 19 May 2014 16:16:37 -0700
Jesse Barnes wrote:
> This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
> that it resets the whole common lane section of the PHY. This is
> required on machines where the BIOS doesn't do this for us on boot or
> resume to properly re-calibra
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
that it resets the whole common lane section of the PHY. This is
required on machines where the BIOS doesn't do this for us on boot or
resume to properly re-calibrate and get the PHY ready to transmit data.
Without this patch, s
On Tue, 2014-05-20 at 11:59 +, Chris Wilson wrote:
> On Tue, May 20, 2014 at 04:19:46PM +0530, sourab.gu...@intel.com wrote:
> > +int i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno);
>
> Be strict and add __must_check
>
We'll add this.
> > +static bool intel_use_mmio_flip(struc
On Tue, May 20, 2014 at 07:47:20PM +0300, Imre Deak wrote:
> I'm trying to reduce the WARNs during driver reload and this was one of
> them. Also while at it remove the redundant condition from before
> unregister_shrinker().
>
> v2:
> - fix the error path too and move the unregister to its logica
On Tue, May 20, 2014 at 05:20:05PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If a pipe is already active when we init/resume there might not be a
> full modeset afterwards so drm_vblank_on() may not get called. In such
> a case if someone is holding a vblank reference
I'm trying to reduce the WARNs during driver reload and this was one of
them. Also while at it remove the redundant condition from before
unregister_shrinker().
v2:
- fix the error path too and move the unregister to its logical place
(Chris)
- remove redundant condition from before unregister_shr
On Monday 19 May 2014 07:53 PM, Damien Lespiau wrote:
On Mon, Apr 14, 2014 at 11:18:27AM +0530, Shobhit Kumar wrote:
+#define NS_MHZ_RATIO 100
[...]
+static bool generic_init(struct intel_dsi_device *dsi)
+{
[...]
+ /*
+* ui(s) = 1/f [f in hz]
+* ui(ns) = 10^9/f
On Tue, May 20, 2014 at 5:15 PM, Thierry Reding
wrote:
> The component/master helpers don't allow you to do that. Essentially
> what it does is provide a way to glue together multiple devices (the
> components) to produce a meta-device (the master). What you get is a
> pair of .bind()/.unbind() fu
- Some debug logging for the ts continuity checks.
- Add a plain vblank-vs-suspend test where kms_flip doesn't switch off
the displays first.
- Ensure that we do at least 2 rounds, the suspend tests bailed out
after 1 round and so didn't test anything.
- Frob the testnames a bit.
Signed-off-by
On Tue, May 20, 2014 at 4:20 PM, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrjälä wrote:
>> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
>> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
>> > > On Wed, May 14, 2014 at 08:51:11PM +02
On Tue, May 20, 2014 at 05:07:51PM +0200, Daniel Vetter wrote:
> On 20/05/2014 16:57, Thierry Reding wrote:
> >On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote:
> >>>On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote:
> >On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> >>>
On 20/05/2014 16:57, Thierry Reding wrote:
On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote:
>On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote:
> >On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> >>This RFC is based on previous discussion to set up a generic
> >>communic
On Tue, 2014-05-20 at 20:05 +0530, Vinod Koul wrote:
> On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote:
> > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> > > This RFC is based on previous discussion to set up a generic
> > > communication channel between display and audio driv
On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote:
> > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> >> This RFC is based on previous discussion to set up a generic
> >> communication channel between display and audio driv
On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote:
> On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> > This RFC is based on previous discussion to set up a generic
> > communication channel between display and audio driver and
> > an internal design of Intel MCG/VPG HDMI audio dri
On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote:
> On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
>> This RFC is based on previous discussion to set up a generic
>> communication channel between display and audio driver and
>> an internal design of Intel MCG/VPG HDMI audio driver. It's s
From: Ville Syrjälä
If a pipe is already active when we init/resume there might not be a
full modeset afterwards so drm_vblank_on() may not get called. In such
a case if someone is holding a vblank reference across a suspend/resume
cycle drm_vblank_get() called after resuming won't re-enable the
On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> This RFC is based on previous discussion to set up a generic
> communication channel between display and audio driver and
> an internal design of Intel MCG/VPG HDMI audio driver. It's still an
> initial draft and your advice would be appreci
On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrjälä wrote:
> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > > > Now that we unconditionally
From: Ville Syrjälä
Make sure drm_vblank_get() never succeeds when called between
drm_vblank_off() and drm_vblank_on(). Borrow a trick from the
old drm_vblank_{pre,post}_modeset() functions and just bump
the refcount in drm_vblank_off() and drop it in drm_vblank_on().
Hopefully the use of inmode
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index df58afc..9420f4f 100644
--- a/drivers/gpu/drm/i915/in
From: Ville Syrjälä
We have a few more corner cases with the drm_vblank_on/off stuff. This
series aims to fix those.
I couldn't think of a good way to write a test case for the drm_vblank_get()
issue since it's a transient state that occurs briefly during modeset. So
I added asserts for it inste
On Fri, Apr 25, 2014 at 7:44 PM, Daniel Vetter wrote:
> On Fri, Apr 25, 2014 at 7:14 PM, wrote:
>> From: Ville Syrjälä
>>
>> Document the internal structure of the VLV display PHY a bit to help
>> people understand how the different register blocks relate to each
>> other.
>>
>> v2: Add a bit m
On Tue, May 20, 2014 at 4:11 PM, Ville Syrjälä
wrote:
> On Tue, May 20, 2014 at 03:50:02PM +0200, Daniel Vetter wrote:
>> On Wed, Apr 09, 2014 at 07:56:50PM +0300, Ville Syrjälä wrote:
>> > On Wed, Apr 09, 2014 at 06:18:38PM +0200, Daniel Vetter wrote:
>> > > On Wed, Apr 09, 2014 at 01:29:02PM +03
Currently broken :(
Signed-off-by: Daniel Vetter
---
tests/kms_flip.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index f2ec9ef64701..634b6274afae 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -75,6 +75,7 @@
#define TEST_SUSPEND
On Fri, Apr 25, 2014 at 08:14:30PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The comments in i915_reg.h aren't proper kernel-doc comments, so replace
> the magic /** with just /*
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Damien Lespiau
--
Damien
> ---
> dri
On Tue, May 20, 2014 at 03:50:02PM +0200, Daniel Vetter wrote:
> On Wed, Apr 09, 2014 at 07:56:50PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 09, 2014 at 06:18:38PM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 09, 2014 at 01:29:02PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From
On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
> > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > > don't need any hacks any l
On Tue, May 20, 2014 at 04:41:13PM +0300, Ville Syrjälä wrote:
> On Tue, May 20, 2014 at 02:22:51PM +0100, Damien Lespiau wrote:
> > On Wed, Apr 09, 2014 at 01:28:41PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > The following workarounds should be needed
Date 20.5.2014 14:43, Thierry Reding wrote:
> On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote:
>> Also adding dri-devel and linux-media. Please don't forget these lists for
>> the next round.
>> -Daniel
>>
>> On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
>>> Adding Gr
On Wed, Apr 09, 2014 at 07:56:50PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 09, 2014 at 06:18:38PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 09, 2014 at 01:29:02PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > All PCS groups access reads return 0xff
On Tue, May 20, 2014 at 02:22:51PM +0100, Damien Lespiau wrote:
> On Wed, Apr 09, 2014 at 01:28:41PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The following workarounds should be needed for pre-production hardware
> > only:
> > * WaDisablePwrmtrEvent:chv
> > * Wa
On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
> On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > don't need any hacks any longer to keep the vblank logic sane when
> > all the registers go poof.
On Wed, Apr 09, 2014 at 01:28:49PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 91
> -
> 1 file changed, 17 insertions(+), 74 deletions(-)
>
> diff --git a/
On Wed, Apr 09, 2014 at 01:28:50PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Same cautious note about conflicts here ...
-Daniel
> ---
> drivers/gpu/drm/i915/i915_irq.c | 29 ++---
> 1 file changed, 14 insertions
On Wed, Apr 09, 2014 at 01:28:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The following workarounds should be needed for pre-production hardware
> only:
> * WaDisablePwrmtrEvent:chv
> * WaSetMaskForGfxBusyness:chv
> * WaDisableGunitClockGating:chv
> * WaDisableFfDop
On Mon, Apr 28, 2014 at 02:00:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Rafael Barbalho
>
> Add support for the third pipe in cherrview
>
> v2: Don't use spaces for indentation (Jani)
> Wrap long lines
>
> Reviewed-by: Imre Deak
> Signed-off-by: Rafael Barbalho
> [vsyrjala:
On Mon, Apr 28, 2014 at 07:19:50PM -0300, Paulo Zanoni wrote:
> 2014-04-28 5:23 GMT-03:00 Ville Syrjälä :
> > On Fri, Apr 25, 2014 at 05:55:38PM -0300, Paulo Zanoni wrote:
> >> 2014-04-09 7:28 GMT-03:00 :
> >> > From: Rafael Barbalho
> >> >
> >> > Cherryview also needs this WA.
> >>
> >> At least
On Tue, May 20, 2014 at 11:29:54AM +0100, Damien Lespiau wrote:
> On Thu, Apr 24, 2014 at 11:55:14PM +0200, Daniel Vetter wrote:
> > Besides the fairly useless BUG_ON the logic is completely generic
> > and cane be used on any platform what wants to reuse the shared
> > dpll support code.
> >
> >
On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote:
> Also adding dri-devel and linux-media. Please don't forget these lists for
> the next round.
> -Daniel
>
> On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
> > Adding Greg just as an fyi since we've chatted briefly abou
On Tue, May 20, 2014 at 05:29:46PM +0530, Kumar, Shobhit wrote:
> On 4/25/2014 3:24 AM, Daniel Vetter wrote:
> >Looking at our current dsi driver I note that:
> >- We don't have any slave driver right now.
> >- There's zero support for the hardware state readout and cross check
> > code.
> >- All
On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> Now that we unconditionally dtrt when disabling/enabling crtcs we
> don't need any hacks any longer to keep the vblank logic sane when
> all the registers go poof. So let's rip it all out.
Hmm. drm_update_vblank_count() will now see
On Tue, May 20, 2014 at 04:19:46PM +0530, sourab.gu...@intel.com wrote:
> +int i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno);
Be strict and add __must_check
> +static bool intel_use_mmio_flip(struct drm_device *dev)
> +{
> + /* If module parameter is disabled, use CS flips.
>
On 4/25/2014 3:24 AM, Daniel Vetter wrote:
Looking at our current dsi driver I note that:
- We don't have any slave driver right now.
- There's zero support for the hardware state readout and cross check
code.
- All the modeset state seems to be tracked in the intel_dsi structure
instead of
Mixing script and standlone tests didn't mix well with the
strict i915_ring_stop flags handling. Also squash drv_missed_irq_hang
to the new test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78322
Suggested-by: Daniel Vetter
Signed-off-by: Mika Kuoppala
---
tests/Makefile.sources|
Guarantees that error capture works at a very basic level.
v2: Also check that the ring object contains a reloc with MI_BB_START
for the presumed batch object's address.
v3: Chris review comments:
- Move variables to local scope.
- Do not assume there is only one request.
- Some gen encode fla
drm/i915: Shovel hw setup code out of i9xx_crtc_mode_set
drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_set
drm/i915: Shovel hw setup code out of ilk_crtc_mode_set
drm/i915: Shovel hw setup code out of hsw_crtc_mode_set
drm/i915: Extract i9xx_set_pll_dividers
drm/
On Thu, Apr 24, 2014 at 11:55:41PM +0200, Daniel Vetter wrote:
> 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
On Thu, Apr 24, 2014 at 11:55:40PM +0200, Daniel Vetter wrote:
> 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 h
On Thu, Apr 24, 2014 at 11:55:38PM +0200, Daniel Vetter wrote:
> 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.
>
On Thu, Apr 24, 2014 at 11:55:39PM +0200, Daniel Vetter wrote:
> 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
Revi
On Tue, May 20, 2014 at 11:56:28AM +0100, Damien Lespiau wrote:
> On Thu, Apr 24, 2014 at 11:55:34PM +0200, Daniel Vetter wrote:
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -272,6 +272,7 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
> >
On Tue, May 20, 2014 at 11:47:35AM +0100, Damien Lespiau wrote:
> On Thu, Apr 24, 2014 at 11:55:33PM +0200, Daniel Vetter wrote:
> > 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 co
On Tue, May 20, 2014 at 11:18:54AM +0100, Damien Lespiau wrote:
> On Thu, Apr 24, 2014 at 11:55:12PM +0200, Daniel Vetter wrote:
> > Instead of every time it isn't active: We only need to do that when
> > the pll is currently unused, i.e. when pll->refcount == 0. For
> > paranoia add a warning for
On Thu, Apr 24, 2014 at 11:55:37PM +0200, Daniel Vetter wrote:
> 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/i9
On Thu, Apr 24, 2014 at 11:55:36PM +0200, Daniel Vetter wrote:
> The WRPLLs won't use them.
>
> Signed-off-by: Daniel Vetter
/*
* Comments spawning multiple lines are formatted...
* ...this way
*/
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> 1
On Thu, Apr 24, 2014 at 11:55:35PM +0200, Daniel Vetter wrote:
> 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
On Thu, Apr 24, 2014 at 11:55:34PM +0200, Daniel Vetter wrote:
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -272,6 +272,7 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
> I915_WRITE(WRPLL_CTL1, val & ~WRPLL_PLL_ENABLE);
>
On Tue, May 20, 2014 at 10:10:00AM +0200, Takashi Iwai wrote:
> > struct avsink_client {
> > const char *name; /* client name */
> > int type; /* client type*/
> > void *context;
> > struct module *module; /* top-level module for locking */
> >
> > st
From: Sourab Gupta
Using MMIO based flips on Gen5+ for Media power well residency optimization.
The blitter ring is currently being used just for command streamer based
flip calls. For pure 3D workloads, with MMIO flips, there will be no use
of blitter ring and this will ensure the 100% residency
From: Sourab Gupta
This patch is for using mmio flips by default on VLV.
The module parameter controlling use of MMIO flips allows us to
control the default behaviour, which is set true for VLV and false
elsewhere.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_params.c | 5 +++--
From: Sourab Gupta
This patch fixes the race condition between flip done interrupt
from set base and mmio based page flip.
This patch is dependent on
http://lists.freedesktop.org/archives/intel-gfx/2014-April/043761.html
Also, for the details of the race condition please refer to the mentioned
From: Sourab Gupta
Using MMIO based flips for Media power well residency optimization.
The blitter ring is currently being used just for command streamer based
flip calls. For pure 3D workloads, with MMIO flips, there will be no use
of blitter ring and this will ensure the 100% residency for Medi
On Thu, Apr 24, 2014 at 11:55:33PM +0200, Daniel Vetter wrote:
> 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 ma
1 - 100 of 136 matches
Mail list logo
