On Mon, Aug 11, 2014 at 03:33:02PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Intel HDMI does not correctly configure pixel replicated HDMI modes
> 480i and 576i. Remove support for these modes until DRM has been
> changed to correctly identify SD interlaced modes by report
On 8/11/2014 5:53 PM, Daniel Vetter wrote:
On Mon, Aug 11, 2014 at 05:37:20PM +0530, Jindal, Sonika wrote:
On 8/11/2014 5:12 PM, Daniel Vetter wrote:
On Mon, Aug 11, 2014 at 04:37:00PM +0530, Jindal, Sonika wrote:
Hi Daniel,
Are you taking this patch back in drm-intel?
We should still c
From: Clint Taylor
Intel HDMI does not correctly configure pixel replicated HDMI modes
480i and 576i. Remove support for these modes until DRM has been
changed to correctly identify SD interlaced modes by reporting there
true horizontal resolution 720 instead of the pre-pixel doubled 1440.
Signe
The expected design is a constant timer which will trigger GT busyness
calculation steadily, I understand.
Yet the case is that we would have to wrap up BDW related works as we
mentioned with Jesse, there are not enough resources to do further
development on the constant timer scheme, sorry tha
On Mon, Aug 11, 2014 at 11:08:38AM -0700, Daisy Sun wrote:
> BDW supports GT C0 residency reporting in constant time unit. Driver
> calculates GT utilization based on C0 residency and adjusts RP
> frequency up/down accordingly. For offscreen workload specificly,
> set frequency to RP0.
>
> Offscre
On Thu, Jul 24, 2014 at 05:04:37PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Each logical ring context has the tail pointer in the context object,
> so update it before submission.
>
> v2: New namespace.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 19
On Thu, Jul 24, 2014 at 05:04:36PM +0100, Thomas Daniel wrote:
> From: Ben Widawsky
>
> A context switch occurs by submitting a context descriptor to the
> ExecList Submission Port. Given that we can now initialize a context,
> it's possible to begin implementing the context switch by creating th
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> The batchbuffer that sets the render context state is submitted
> in a different way, and from different places.
>
> We needed to make both the render state preparation and free functions
> outside accesible,
On Mon, Aug 11, 2014 at 11:09:39PM +0200, Daniel Vetter wrote:
> On Thu, Jul 24, 2014 at 05:04:32PM +0100, Thomas Daniel wrote:
> > From: Oscar Mateo
> >
> > Dispatch_execbuffer's evil twin.
> >
> > Signed-off-by: Oscar Mateo
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c| 28 +
On Thu, Jul 24, 2014 at 05:04:32PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Dispatch_execbuffer's evil twin.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 28
> drivers/gpu/drm/i915/intel_ringbuffer.h |2 ++
> 2 f
On Thu, Jul 24, 2014 at 05:04:31PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> We need to attend context switch interrupts from all rings. Also, fixed
> writing
> IMR/IER and added HWSTAM at ring init time.
>
> Notice that, if added to irq_enable_mask, the context switch interrupts woul
On Thu, Jul 24, 2014 at 05:04:31PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> We need to attend context switch interrupts from all rings. Also, fixed
> writing
> IMR/IER and added HWSTAM at ring init time.
>
> Notice that, if added to irq_enable_mask, the context switch interrupts woul
On Thu, Jul 24, 2014 at 05:04:29PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> On a previous iteration of this patch, I created an Execlists
> version of __i915_add_request and asbtracted it away as a
> vfunc. Daniel Vetter wondered then why that was needed:
>
> "with the clean split in
On Thu, Jul 24, 2014 at 05:04:34PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> The normal flip function places things in the ring in the legacy
> way, so we either fix that or force MMIO flips always as we do in
> this patch.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/
On Thu, Jul 24, 2014 at 05:04:26PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Well, new-ish: if all this code looks familiar, that's because it's
> a clone of the existing submission mechanism (with some modifications
> here and there to adapt it to LRCs and Execlists).
>
> And why did
On Thu, Jul 24, 2014 at 05:04:33PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> This is what i915_gem_do_execbuffer calls when it wants to execute some
> worload in an Execlists world.
>
> v2: Check arguments before doing stuff in intel_execlists_submission. Also,
> get rel_constants pars
2014-06-30 7:10 GMT-03:00 Jani Nikula :
> On Thu, 26 Jun 2014, Rodrigo Vivi wrote:
>> 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
>
> Pushed to -fixes, thanks for the patch and review.
>
> BR,
> Jani.
>
>
>>
>>
Atm we may retrain the DP link even if the CRTC is inactive through
HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY
(at least on BYT), since the DP port is disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
Signed-off-by: Imre Deak
---
drivers/gpu/drm
Atm we may leave eDP VDD enabled during system suspend after the CRTCs
are disabled through an HPD->DPCD read event. So disable VDD during
suspend at a point when no HPDs can occur.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 15 +++
drivers/gpu/drm/i915/intel_dp.
Make sure these work handlers don't run after we system suspend or
unload the driver. Note that we don't cancel the handlers during runtime
suspend. That could lead to a lockup, since we take a runtime PM ref
from the handlers themselves. Fortunaltely canceling there is not needed
since the RPM ref
Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.
Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling
BDW supports GT C0 residency reporting in constant time unit. Driver
calculates GT utilization based on C0 residency and adjusts RP
frequency up/down accordingly. For offscreen workload specificly,
set frequency to RP0.
Offscreen task is not restricted by frame rate, it can be
executed as soon as
2014-08-11 11:42 GMT-03:00 Ville Syrjälä :
> On Mon, Aug 11, 2014 at 11:29:21AM -0300, Paulo Zanoni wrote:
>> 2014-08-11 8:32 GMT-03:00 Ville Syrjälä :
>> > On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> If we're runtime suspended and try to use
On Mon, Aug 11, 2014 at 06:05:24PM +0100, Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 06:37:37PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Don't print raw numbers, use port_name() and tell the user whether it's
> > long or short without having to figure out w
On Mon, Aug 11, 2014 at 09:57:12AM -0700, Rodrigo Vivi wrote:
> Well, this fix the issue Linus faced.
>
> Actually the issue I was aware of and trying to fix with this patch for a
> long time was reported by chromeos guys saying the psr wasn't propperly
> working after suspend/resume. They got the
On Mon, Aug 11, 2014 at 06:37:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Don't print raw numbers, use port_name() and tell the user whether it's
> long or short without having to figure out what the other magic number
> means.
>
> Signed-off-by: Ville Syrjälä
Re
On Fri, Aug 08, 2014 at 04:23:41PM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal
>
> Rename the defines to have levels instead of values for vswing and
> pre-emph levels as the values may differ in other scenarios like low vswing of
> eDP1.4 where the values are different.
>
> Done
On Fri, Aug 08, 2014 at 04:23:40PM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal
>
> Adding new defines, older one will be removed in the last patch in the series.
> This is to rename the defines to have levels instead of values for vswing and
> pre-emph levels as the values may dif
Well, this fix the issue Linus faced.
Actually the issue I was aware of and trying to fix with this patch for a
long time was reported by chromeos guys saying the psr wasn't propperly
working after suspend/resume. They got the screen back but never got psr
back again.
The original patch fix suspe
From: Ville Syrjälä
Don't print raw numbers, use port_name() and tell the user whether it's
long or short without having to figure out what the other magic number
means.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 4 +++-
drivers/gpu/drm/i915/intel_dp.c | 3 ++-
2 files
On Thu, Jul 24, 2014 at 05:04:25PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> No mistery here: the seqno is still retrieved from the engine's
> HW status page (the one in the default context. For the moment,
> I see no reason to worry about other context's HWS page).
>
> Signed-off-by:
On Thu, Jul 24, 2014 at 05:04:24PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Logical rings do not need most of the initialization their
> legacy ringbuffer counterparts do: we just need the pipe
> control object for the render ring, enable Execlists on the
> hardware and a few workaroun
On Thu, Jul 24, 2014 at 05:04:21PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> As suggested by Daniel Vetter. The idea, in subsequent patches, is to
> provide an alternative to these vfuncs for the Execlists submission
> mechanism.
>
> v2: Splitted into two and reordered to illustrate ou
On Thu, Jul 24, 2014 at 05:04:23PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Allocate and populate the default LRC for every ring, call
> gen-specific init/cleanup, init/fini the command parser and
> set the status page (now inside the LRC object). These are
> things all engines/rings h
On Mon, Aug 11, 2014 at 11:29:21AM -0300, Paulo Zanoni wrote:
> 2014-08-11 8:32 GMT-03:00 Ville Syrjälä :
> > On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> If we're runtime suspended and try to use the plane interfaces, we
> >> will get a lot of WA
On Thu, Jul 24, 2014 at 05:04:21PM +0100, Thomas Daniel wrote:
> @@ -1408,8 +1408,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> else
> exec_start += i915_gem_obj_offset(batch_obj, vm);
>
> - ret = legacy_ringbuffer_submission(dev, file, ring, ctx,
>
On Mon, Aug 11, 2014 at 04:36:53PM +0200, Daniel Vetter wrote:
> On Thu, Jul 24, 2014 at 05:04:21PM +0100, Thomas Daniel wrote:
> > From: Oscar Mateo
> >
> > As suggested by Daniel Vetter. The idea, in subsequent patches, is to
> > provide an alternative to these vfuncs for the Execlists submissi
On Thu, Jul 24, 2014 at 05:04:21PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> As suggested by Daniel Vetter. The idea, in subsequent patches, is to
> provide an alternative to these vfuncs for the Execlists submission
> mechanism.
>
> v2: Splitted into two and reordered to illustrate ou
On Thu, Aug 07, 2014 at 01:17:40PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> This is mostly for correctness so that we know we are running the LR
> context correctly (this is, the PDPs are contained inside the context
> object).
>
> v2: Move the check to inside the enable PPGTT functio
From: Paulo Zanoni
If we're runtime suspended and try to use the plane 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 active, since writing the registers won't really have any
effect if the scre
On Mon, Aug 11, 2014 at 03:59:52PM +0200, Daniel Vetter wrote:
> Depending upon one module option to be sanitized (through USES_PPGTT)
> for the other is a bit too fragile for my taste. At least WARN about
> this.
>
> Cc: Ben Widawsky
> Cc: Damien Lespiau
> Cc: Oscar Mateo
> Signed-off-by: Dani
On Thu, Jul 24, 2014 at 05:04:19PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> These two functions make no sense in an Logical Ring Context & Execlists
> world.
>
> v2: We got rid of lrc_enabled and centralized everything in the sanitized
> i915.enbale_execlists instead.
>
> Signed-off-
2014-08-11 8:32 GMT-03:00 Ville Syrjälä :
> On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If we're runtime suspended and try to use the plane interfaces, we
>> will get a lot of WARNs saying we did the wrong thing.
>>
>> For intel_crtc_update_cursor(), a
On Thu, Jul 24, 2014 at 05:04:18PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> The backing objects and ringbuffers for contexts created via open
> fd are actually empty until the user starts sending execbuffers to
> them. At that point, we allocate & populate them. We do this because,
> a
On Mon, Aug 11, 2014 at 04:14:13PM +0200, Daniel Vetter wrote:
> On Thu, Jul 24, 2014 at 05:04:16PM +0100, Thomas Daniel wrote:
> > From: Oscar Mateo
> >
> > Any given ringbuffer is unequivocally tied to one context and one engine.
> > By setting the appropriate pointers to them, the ringbuffer s
On Thu, Jul 24, 2014 at 05:04:16PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Any given ringbuffer is unequivocally tied to one context and one engine.
> By setting the appropriate pointers to them, the ringbuffer struct holds
> all the infromation you might need to submit a workload for
On Thu, Jul 24, 2014 at 05:04:12PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> For the moment this is just a placeholder, but it shows one of the
> main differences between the good ol' HW contexts and the shiny
> new Logical Ring Contexts: LR contexts allocate and free their
> own backi
Depending upon one module option to be sanitized (through USES_PPGTT)
for the other is a bit too fragile for my taste. At least WARN about
this.
Cc: Ben Widawsky
Cc: Damien Lespiau
Cc: Oscar Mateo
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lrc.c | 2 ++
1 file changed, 2 inse
Add the helpers to be used by modules wishing to expose unsafe debugging
or testing module parameters that taint the kernel when set.
Cc: Rusty Russell
Cc: Jean Delvare
Cc: Andrew Morton
Cc: Li Zhong
Cc: Jon Mason
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
include/linux/moduleparam.h
Taint the kernel if the semaphores, enable_rc6, enable_fbc, or ppgtt
module parameters are modified. These module parameters are for
debugging and testing only, and should never be changed from their
platform specific default values by the users. We do not provide support
for people enabling all th
On Thu, Jul 24, 2014 at 05:04:11PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts".
> These expanded contexts enable a number of new abilities, especially
> "Execlists".
>
> The macro is defined to off until we have things
This is a generic version of Daniel's patch [1] letting us have unsafe
module parameters (experimental, debugging, testing, etc.) that taint
the kernel when set. Quoting Daniel,
"""
Users just love to set random piles of options since surely enabling all
the experimental stuff helps. Later on we g
Make it clear this is about kernel_param_ops, not kernel_param (which
will soon have a flags field of its own). No functional changes.
Cc: Rusty Russell
Cc: Jean Delvare
Cc: Andrew Morton
Cc: Li Zhong
Cc: Jon Mason
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
include/linux/moduleparam.
Add flags field to struct kernel_params, and add the first flag: unsafe
parameter. Modifying a kernel parameter with the unsafe flag set, either
via the kernel command line or sysfs, will issue a warning and taint the
kernel.
Cc: Rusty Russell
Cc: Jean Delvare
Cc: Andrew Morton
Cc: Li Zhong
Cc
Hi
When you have this type of question, please always CC our mailing
list, since you're more likely to get a fast answer when using it. And
it also helps documenting all the common problems people have.
2014-08-09 13:31 GMT-03:00 Brayden Williams :
> Hi Paulo,
>
> I have been desperately trying t
On Mon, Aug 11, 2014 at 03:12:34PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> s/struct drm_crtc/struct drm_plane/ in drm_mode_config_reset() so that we
> actually dereference the correct type of structure when calling the
> plane->reset() hook.
>
> Imre mentioned that
On Mon, Aug 11, 2014 at 05:37:20PM +0530, Jindal, Sonika wrote:
>
>
> On 8/11/2014 5:12 PM, Daniel Vetter wrote:
> >On Mon, Aug 11, 2014 at 04:37:00PM +0530, Jindal, Sonika wrote:
> >>
> >>Hi Daniel,
> >>Are you taking this patch back in drm-intel?
> >
> >We should still call the primary_plane->u
On Sun, Aug 10, 2014 at 06:29:11AM +0100, Chris Wilson wrote:
> Even though we should not try to use 4+GiB GTTs on 32-bit systems, by
> using a local variable we can future proof the code whilst making it
> easier to read.
>
> Signed-off-by: Chris Wilson
Appeased checkpatch a bit for the long li
From: Ville Syrjälä
s/struct drm_crtc/struct drm_plane/ in drm_mode_config_reset() so that we
actually dereference the correct type of structure when calling the
plane->reset() hook.
Imre mentioned that his VLV was crashing there on resume. I deciced to have
a quick look at the code and immediat
On Sun, Aug 10, 2014 at 06:29:09AM +0100, Chris Wilson wrote:
> This just allows the compiler to pessimise callers who try to abuse the
> ioctl in the hope of making the correct users faster.
>
> Signed-off-by: Chris Wilson
I'm not that much of a fan of likely/unlikely really. If it helps with
d
On 8/11/2014 5:12 PM, Daniel Vetter wrote:
On Mon, Aug 11, 2014 at 04:37:00PM +0530, Jindal, Sonika wrote:
Hi Daniel,
Are you taking this patch back in drm-intel?
We should still call the primary_plane->update hook directly instead of
open-coding it.
-Daniel
But we are already doing dev_pr
On Mon, Aug 11, 2014 at 12:35:42PM +0100, Chris Wilson wrote:
> On Mon, Aug 11, 2014 at 01:22:19PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 11, 2014 at 11:17:40AM +0100, Chris Wilson wrote:
> > > On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote:
> > > > Based upon a hunk from a patc
On Mon, Aug 11, 2014 at 04:37:00PM +0530, Jindal, Sonika wrote:
>
> Hi Daniel,
> Are you taking this patch back in drm-intel?
We should still call the primary_plane->update hook directly instead of
open-coding it.
-Daniel
>
> -Sonika
>
> On 8/7/2014 5:41 PM, Daniel Vetter wrote:
> >On Thu, Aug
On Mon, Aug 11, 2014 at 01:22:19PM +0200, Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 11:17:40AM +0100, Chris Wilson wrote:
> > On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote:
> > > Based upon a hunk from a patch from Chris Wilson, but augmented to:
> > > - Process the batch in th
On Mon, Aug 11, 2014 at 11:07:10AM +0100, Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 10:35:25AM +0100, Chris Wilson wrote:
> > On Mon, Aug 11, 2014 at 10:30:09AM +0100, Damien Lespiau wrote:
> > > On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> > > > During ring initialisation,
On Mon, Aug 11, 2014 at 01:15:36PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> During suspend we turn off the crtcs, but leave the staged config in
> place so that we can restore the display(s) to their previous state on
> resume.
>
> During resume when we attempt to ap
On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we're runtime suspended and try to use the plane 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 Mon, Aug 11, 2014 at 01:25:49PM +0200, Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 11:26:07AM +0100, Chris Wilson wrote:
> > On Mon, Aug 11, 2014 at 01:14:50PM +0300, Jani Nikula wrote:
> > > On Sat, 09 Aug 2014, Chris Wilson wrote:
> > > > Adapt the macro so that we can pass either the stru
On Mon, Aug 11, 2014 at 01:15:35PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_enable_pipe_a() gets called with all the modeset locks already
> held (by drm_modeset_lock_all()), so trying to grab the same
> locks using another drm_modeset_acquire_ctx is going to fa
On Mon, Aug 11, 2014 at 11:26:07AM +0100, Chris Wilson wrote:
> On Mon, Aug 11, 2014 at 01:14:50PM +0300, Jani Nikula wrote:
> > On Sat, 09 Aug 2014, Chris Wilson wrote:
> > > Adapt the macro so that we can pass either the struct drm_device or the
> > > struct drm_i915_private pointers and get the
On Mon, Aug 11, 2014 at 01:05:03PM +0300, Jani Nikula wrote:
> On Sat, 09 Aug 2014, Chris Wilson wrote:
> > This is so that we can make the drm_i915_private->info always the
> > preferred source for chipset type and feature queries.
>
> Reviewed-by: Jani Nikula
Queued for -next, thanks for the
On Mon, Aug 11, 2014 at 11:17:40AM +0100, Chris Wilson wrote:
> On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote:
> > Based upon a hunk from a patch from Chris Wilson, but augmented to:
> > - Process the batch in the full ppgtt vm so that self-relocations
> > match again with userspa
Hi Daniel,
Are you taking this patch back in drm-intel?
-Sonika
On 8/7/2014 5:41 PM, Daniel Vetter wrote:
On Thu, Aug 07, 2014 at 01:45:31PM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 11:11:37AM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@inte
On Mon, Aug 11, 2014 at 01:14:50PM +0300, Jani Nikula wrote:
> On Sat, 09 Aug 2014, Chris Wilson wrote:
> > Adapt the macro so that we can pass either the struct drm_device or the
> > struct drm_i915_private pointers and get the answer we want. Over time,
> > my plan is to convert all users over t
On Sat, Aug 09, 2014 at 05:37:24PM +0100, Chris Wilson wrote:
> This migrates the fence tracking onto the existing seqno
> infrastructure so that the later conversion to tracking via requests is
> simplified.
>
> Signed-off-by: Chris Wilson
Pulled in all 3 with the changes to patch 2 as discusse
On Sat, 09 Aug 2014, Chris Wilson wrote:
> Adapt the macro so that we can pass either the struct drm_device or the
> struct drm_i915_private pointers and get the answer we want. Over time,
> my plan is to convert all users over to using drm_i915_private and so
> trimming down the pointer dance. Ha
From: Ville Syrjälä
During suspend we turn off the crtcs, but leave the staged config in
place so that we can restore the display(s) to their previous state on
resume.
During resume when we attempt to apply the force pipe A quirk we use the
load detect mechanism. That doesn't check whether there
On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote:
> Based upon a hunk from a patch from Chris Wilson, but augmented to:
> - Process the batch in the full ppgtt vm so that self-relocations
> match again with userspace's expectations..
> - Add a comment why plain pin for the global gtt
From: Ville Syrjälä
intel_enable_pipe_a() gets called with all the modeset locks already
held (by drm_modeset_lock_all()), so trying to grab the same
locks using another drm_modeset_acquire_ctx is going to fail miserably.
Move most of the drm_modeset_acquire_ctx handling (init/drop/fini)
out fro
On Mon, Aug 11, 2014 at 11:07:10AM +0100, Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 10:35:25AM +0100, Chris Wilson wrote:
> > On Mon, Aug 11, 2014 at 10:30:09AM +0100, Damien Lespiau wrote:
> > > On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> > > > During ring initialisation,
Based upon a hunk from a patch from Chris Wilson, but augmented to:
- Process the batch in the full ppgtt vm so that self-relocations
match again with userspace's expectations..
- Add a comment why plain pin for the global gtt binding is safe at
that point.
v2: Drop local bind_vm variable (Chr
On Mon, Aug 11, 2014 at 10:35:25AM +0100, Chris Wilson wrote:
> On Mon, Aug 11, 2014 at 10:30:09AM +0100, Damien Lespiau wrote:
> > On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> > > During ring initialisation, sometimes we observe, though not in
> > > production hardware, that the
On Sat, 09 Aug 2014, Chris Wilson wrote:
> This is so that we can make the drm_i915_private->info always the
> preferred source for chipset type and feature queries.
Reviewed-by: Jani Nikula
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_dma.c | 5 +++--
> drivers/gpu/drm/i9
Based upon a hunk from a patch from Chris Wilson, but augmented to:
- Process the batch in the full ppgtt vm so that self-relocations
match again with userspace's expectations..
- Add a comment why plain pin for the global gtt binding is safe at
that point.
Cc: Chris Wilson
Cc: Ben Widawsky
On Sun, Aug 10, 2014 at 08:06:57AM +0100, Chris Wilson wrote:
> Move the decision on whether we need to have a mappable object during
> execbuffer to the fore and then reuse that decision by propagating the
> flag through to reservation. As a corollary, before doing the actual
> relocation through
On Sat, Aug 09, 2014 at 11:00:57PM +0100, Damien Lespiau wrote:
> Running smatch adds quite a few checks to what sparse is doing. This is
> one of them.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_display.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers
On Sat, Aug 09, 2014 at 05:37:22PM +0100, Chris Wilson wrote:
> If an object is not bound into the global GTT, then it cannot be
> accessed via the GTT. This restores the original code that was muddled
> by ppGTT. In the process, we remove a WARN that had long outlived its
> usefulness and was simp
On Mon, Aug 11, 2014 at 10:30:09AM +0100, Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> > During ring initialisation, sometimes we observe, though not in
> > production hardware, that the idle flag is not set even though the ring
> > is empty. Double check
On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> During ring initialisation, sometimes we observe, though not in
> production hardware, that the idle flag is not set even though the ring
> is empty. Double check before giving up.
>
> Signed-off-by: Chris Wilson
> Cc: Damien Lespiau
On Mon, Aug 11, 2014 at 11:22:51AM +0300, Jani Nikula wrote:
> On Sat, 09 Aug 2014, Damien Lespiau wrote:
> > I keep telling myself that those tables aren't great because their size
> > is the number of dwords we need to program and not the number of entries
> > (number of dwords = number of entri
On Mon, Aug 11, 2014 at 09:06:39AM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal
>
> Removing the check for HAS_PCH_SPLIT, it looks redundant here. Anyways all the
> platforms are checked separately.
>
> v2: Reordering as per the gen (Ville)
>
> Signed-off-by: Sonika Jindal
Queu
On Sun, Aug 10, 2014 at 09:04:10AM +0100, Chris Wilson wrote:
> On Sat, Aug 09, 2014 at 01:15:16PM -0700, Ben Widawsky wrote:
> > See the following for many more details.
> >
> > commit acc240d41ea1ab9c488a79219fb313b5b46265ae
> > Author: Daniel Vetter
> > Date: Thu Dec 5 15:42:34 2013 +0100
>
On Mon, Aug 11, 2014 at 12:38:41AM +0100, Pedro Ribeiro wrote:
> On 2 June 2014 21:15, Pedro Ribeiro wrote:
> > On 27 May 2014 08:15, Daniel Vetter wrote:
> >> On Mon, May 26, 2014 at 9:44 PM, Pedro Ribeiro wrote:
> >>> Kern.log is attached, but as you can see it does not contain the same
> >>>
On Sat, 09 Aug 2014, Damien Lespiau wrote:
> I keep telling myself that those tables aren't great because their size
> is the number of dwords we need to program and not the number of entries
> (number of dwords = number of entries * 2).
>
> And... I got it wrong when I refactored the code. Fortun
During ring initialisation, sometimes we observe, though not in
production hardware, that the idle flag is not set even though the ring
is empty. Double check before giving up.
Signed-off-by: Chris Wilson
Cc: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++-
1 file changed
95 matches
Mail list logo
