On Mon, May 19, 2014 at 03:46:57PM -0700, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> Daniel requested in the bug that I use a 3GB fallback size. Since this
> is not in the spec as a valid size, I decided against it. We could
> potentially add a patch to bump it to 3GB on top of this one.
>
> T
On Mon, May 19, 2014 at 03:25:45PM -0700, Matt Roper wrote:
> On Sat, May 17, 2014 at 12:43:04AM +0200, Daniel Vetter wrote:
> > On Sat, May 17, 2014 at 12:38 AM, Matt Roper
> > wrote:
> > > + if (ret) {
> > > + if (req->flags & DRM_MODE_CURSOR_BO)
> > > +
This series is now mostly reviewed and has been sucessfully beaten upon
by QA. Who will step up and review the last few patches?
Note that this series only addresses the most common OOM failure where
we start killing processes before we even start touching swap. QA has
another bug where tests cons
Before the process killer is invoked, oom-notifiers are executed for one
last try at recovering pages. We can hook into this callback to be sure
that everything that can be is purged from our page lists, and to give a
summary of how much memory is still pinned by the GPU in the case of an
oom.
Ref
We can share a few lines of tricky lock handling we need to use for both
shrinker routines and in the process fix the return value for count()
when reporting a deadlock.
Signed-off-by: Chris Wilson
Reviewed-by: Rafael Barbalho
---
drivers/gpu/drm/i915/i915_gem.c | 42 +--
When the machine is under a lot of memory pressure and being stressed by
multiple GPU threads, we quite often report fewer than shrinker->batch
(i.e. SHRINK_BATCH) pages to be freed. This causes the shrink_control to
skip calling into i915.ko to release pages, despite the GPU holding onto
most of t
Try to flush out dirty pages into the swapcache (and from there into the
swapfile) when under memory pressure and forced to drop GEM objects from
memory. In effect, this should just allow us to discard unused pages for
memory reclaim and to start writeback earlier.
v2: Hugh Dickins warned that exp
shmemfs first checks if there is enough memory to allocate the page
and reports ENOSPC should there be insufficient, along with
the usual ENOMEM for a genuine allocation failure.
We use ENOSPC in our driver to mean that we have run out of aperture
space and so want to translate the error from shme
Daniel simplified the modesetting code to push the common work performed
by each of the architecture specific routines higher into the caller. This
took me a while to be sure that it was safe in the event of a
modesetting failure - to be sure that the dangling pointer we left in
the registers would
On Tue, May 20, 2014 at 08:47:41AM +0100, Chris Wilson wrote:
> Daniel simplified the modesetting code to push the common work performed
> by each of the architecture specific routines higher into the caller. This
> took me a while to be sure that it was safe in the event of a
> modesetting failure
On Tue, Mar 25, 2014 at 01:23:06PM +, Chris Wilson wrote:
> Try to flush out dirty pages into the swapcache (and from there into the
> swapfile) when under memory pressure and forced to drop GEM objects from
> memory. In effect, this should just allow us to discard unused pages for
> memory rec
On Mon, May 19, 2014 at 03:46:57PM -0700, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> Daniel requested in the bug that I use a 3GB fallback size. Since this
> is not in the spec as a valid size, I decided against it. We could
> potentially add a patch to bump it to 3GB on top of this one.
>
> T
On Tue, May 20, 2014 at 09:53:28AM +0200, Daniel Vetter wrote:
> On Tue, Mar 25, 2014 at 01:23:06PM +, Chris Wilson wrote:
> > Try to flush out dirty pages into the swapcache (and from there into the
> > swapfile) when under memory pressure and forced to drop GEM objects from
> > memory. In eff
On Mon, May 19, 2014 at 09:30:25AM -0700, Jesse Barnes wrote:
> On Mon, 19 May 2014 19:23:23 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > We should be waiting for the reset bit to clear, not remain set.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers
On Mon, May 19, 2014 at 10:25:19PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On pre-ctg GPU reset also resets the display hardware. Force a mode
> restore after the GPU reset, and also re-init clock gating.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i9
At Tue, 20 May 2014 02:52:19 +,
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 a
On Mon, May 19, 2014 at 04:12:26PM +, Mateo Lozano, Oscar wrote:
>
>
> -
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
>
> > ---
On Tue, May 20, 2014 at 08:56:08AM +0100, Chris Wilson wrote:
> On Tue, May 20, 2014 at 09:53:28AM +0200, Daniel Vetter wrote:
> > On Tue, Mar 25, 2014 at 01:23:06PM +, Chris Wilson wrote:
> > > Try to flush out dirty pages into the swapcache (and from there into the
> > > swapfile) when under
On Tue, May 20, 2014 at 08:47:41AM +0100, Chris Wilson wrote:
> Daniel simplified the modesetting code to push the common work performed
> by each of the architecture specific routines higher into the caller. This
> took me a while to be sure that it was safe in the event of a
> modesetting failure
On Tue, May 20, 2014 at 10:01:27AM +0200, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 09:30:25AM -0700, Jesse Barnes wrote:
> > On Mon, 19 May 2014 19:23:23 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > We should be waiting for the reset bit to clear
On g33, the documentation states
"HWS_PGA:
Format = Bits 28:12 of graphics memory address (bits 31:29 MBZ)."
which translates to that the address of the HWS must be below 256MiB,
which is conveniently the mappable aperture.
This also appears to be true (but not documented as so) for gen4 and
ge
On Tue, May 20, 2014 at 10:16:54AM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 08:47:41AM +0100, Chris Wilson wrote:
> > Daniel simplified the modesetting code to push the common work performed
> > by each of the architecture specific routines higher into the caller. This
> > took me a wh
On Tue, May 20, 2014 at 10:16:54AM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 08:47:41AM +0100, Chris Wilson wrote:
> > Daniel simplified the modesetting code to push the common work performed
> > by each of the architecture specific routines higher into the caller. This
> > took me a wh
On Tue, May 20, 2014 at 08:28:43AM +0100, Chris Wilson wrote:
> Before the process killer is invoked, oom-notifiers are executed for one
> last try at recovering pages. We can hook into this callback to be sure
> that everything that can be is purged from our page lists, and to give a
> summary of
On Tue, May 20, 2014 at 08:28:43AM +0100, Chris Wilson wrote:
> Before the process killer is invoked, oom-notifiers are executed for one
> last try at recovering pages. We can hook into this callback to be sure
> that everything that can be is purged from our page lists, and to give a
> summary of
On Tue, May 20, 2014 at 10:38:05AM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 08:28:43AM +0100, Chris Wilson wrote:
> And one bikeshed below.
> > + unbound = bound = pinned = 0;
> > + list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list) {
> > + if (!obj->base.
On Tue, May 20, 2014 at 11:18:44AM +0300, Ville Syrjälä wrote:
> On Tue, May 20, 2014 at 10:01:27AM +0200, Daniel Vetter wrote:
> > On Mon, May 19, 2014 at 09:30:25AM -0700, Jesse Barnes wrote:
> > > On Mon, 19 May 2014 19:23:23 +0300
> > > ville.syrj...@linux.intel.com wrote:
> > >
> > > > From:
On Tue, May 20, 2014 at 10:03:44AM +0200, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 10:25:19PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On pre-ctg GPU reset also resets the display hardware. Force a mode
> > restore after the GPU reset, and also re-init clo
On Tue, May 20, 2014 at 11:46:42AM +0300, Ville Syrjälä wrote:
> On Tue, May 20, 2014 at 10:03:44AM +0200, Daniel Vetter wrote:
> > On Mon, May 19, 2014 at 10:25:19PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > On pre-ctg GPU reset also resets the displa
Adding Greg just as an fyi since we've chatted briefly about the avsink
bus. Comments below.
-Daniel
On Tue, May 20, 2014 at 02:52:19AM +, Lin, Mengdong wrote:
> This RFC is based on previous discussion to set up a generic communication
> channel between display and audio driver and
> an inte
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 about the avsink
> bus. Comments below.
> -Daniel
>
> On Tue, May 20, 2014 at
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 the ibx case where plls have a fixed
> mapping and hence should always b
On Thu, Apr 24, 2014 at 11:55:13PM +0200, Daniel Vetter wrote:
> This is the last piece of code which write state to the hardware in
> the ironalake ->crtc_mode_set callback.
>
> I think we could merge this with the pll->enable hook, but otoh the
> ordering requirements with the ldvs port are real
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.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
--
Damien
> -
On Thu, Apr 24, 2014 at 11:55:31PM +0200, Daniel Vetter wrote:
> Signed-off-by: Daniel Vetter
The list of CRTCs using those shared PLLs would also be useful in the
mix.
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
> 1 fil
On Thu, Apr 24, 2014 at 11:55:32PM +0200, Daniel Vetter wrote:
> Just boring sed job for preparation.
>
> Signed-off-by: Daniel Vetter
We want want a ddi structure to gather all the DDI config fields later
down the road.
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/in
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
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
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
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
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
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
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 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: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: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 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 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: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 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 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: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: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
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/
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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
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 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
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
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
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ä
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
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
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
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, 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
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 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, 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 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, 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 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
- 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 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
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
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 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
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, 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
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 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
1 - 100 of 136 matches
Mail list logo
