On Tue, Feb 04, 2014 at 09:23:06PM +, Chris Wilson wrote:
> On Tue, Feb 04, 2014 at 09:59:15PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On SNB we set up WaSetupGtModeTdRowDispatch:snb early in
> > gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE
On Wed, 2014-02-05 at 00:19 +0100, Daniel Vetter wrote:
> On Wed, Feb 05, 2014 at 12:04:46AM +0200, Imre Deak wrote:
> > On Tue, 2014-02-04 at 21:29 +, Chris Wilson wrote:
> > > On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote:
> > > > It's not signal safe and I got kms_flip in hung st
On Wed, Feb 05, 2014 at 08:54:15AM +0100, Daniel Vetter wrote:
> On Tue, Feb 4, 2014 at 8:37 PM, Daniel Vetter wrote:
> > On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter
> > wrote:
> >> Moved to a common location so that Jani also can push to it, to avoid
> >> moving it every time I go on vacation
On Wed, Feb 05, 2014 at 11:27:31AM +0200, Ville Syrjälä wrote:
> On Tue, Feb 04, 2014 at 09:23:06PM +, Chris Wilson wrote:
> > On Tue, Feb 04, 2014 at 09:59:15PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > On SNB we set up WaSetupGtModeTdRowDispatch:
On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> Certain OpenGL features (e.g. transform feedback, performance monitoring)
> require userspace code to submit batches containing commands such as
> MI_LOAD_REGISTER_IMM to access various registers.
From: Ville Syrjälä
Add a comment next to our WIZ hashing setup to remind people about the
link between WIZ hashing disable bit and PS/WM thread counts.
Suggested-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 16
1 file changed, 16 insert
On Wed, Feb 05, 2014 at 12:43:47PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a comment next to our WIZ hashing setup to remind people about the
> link between WIZ hashing disable bit and PS/WM thread counts.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Ville S
From: Tvrtko Ursulin
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers on common address space
operati
From: Tvrtko Ursulin
A simple userptr benchmark measuring creation and destruction of userptr
surfaces and also impact of having a different number of them in the
process address space.
Example test output from i7-4550U running Android is below.
Questions, comments and ideas are welcome.
IGT-V
On Thu, 16 Jan 2014, Daniel Vetter wrote:
> On Thu, Jan 16, 2014 at 5:54 PM, Paulo Zanoni wrote:
>> 2014/1/16 Daniel Vetter :
>>> Our init_clock_gating functions and related code should already take
>>> care of this. And if they don't we'd better know.
>>
>> For both registers, I see functions ap
On Wed, Feb 5, 2014 at 2:01 PM, Jani Nikula wrote:
> On Thu, 16 Jan 2014, Daniel Vetter wrote:
>> On Thu, Jan 16, 2014 at 5:54 PM, Paulo Zanoni wrote:
>>> 2014/1/16 Daniel Vetter :
Our init_clock_gating functions and related code should already take
care of this. And if they don't we'd
On Wed, Jan 22, 2014 at 12:53:50PM +0900, Mike Hommey wrote:
> Hi,
>
> What is the current status for DP MST support on Haswell? Are there
> experimental patches that can be tested? If not, what can be done to
> help progress?
No patches to test yet. I would gate DP MST on the current DP aux
refa
From: Ville Syrjälä
Not sure what would happen if an interrupt is generated between enabling
the interrupt in PIPESTAT and frobbing the AGPBUSY# bit in INSTPM. Would
the already pending interrupt cause exit from C3 or not? Let's not play
such guessing games, and simply flip AGPBUSY# bit before en
From: Ville Syrjälä
My Gen3 Bspec lists the AGPBUSY# bit in INSTPM as an enable bit rather
than a disable bit. Our code has the opposite idea. Make the code match
the spec.
Might fix some gen3 C3 related interrupt delivery problems. Untested
due to lack of hardware.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
The AGBBUSY# bit in INSTPM caught my eye while reading the code and
having the spec open at the same time. This series makes the code match
the spec, and also closes a potential race condition (which may or may
not be real, depending on how the hardware works).
Ville Syrjälä
N.B. I'll likely make multiple passes on the patches while reviewing,
for example I did not check any of the #define values here.
On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> Add command tables defining irregular length commands for each ring.
> This requires a
On Wed, Feb 05, 2014 at 12:41:45PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A simple userptr benchmark measuring creation and destruction of userptr
> surfaces and also impact of having a different number of them in the
> process address space.
>
> Example test output from i7-4550
On Tue, Feb 04, 2014 at 09:35:50PM +0200, Imre Deak wrote:
> At least on VLV we can't get at the pipestat status bits by simply right
> shifting the corresponding enable bits. The mapping between enable and
> status bits for the sprite0,1 flip done and the PSR events don't follow
> this rule, so we
On Tue, 7 Jan 2014 18:01:33 +0200
Jani Nikula wrote:
> Make it available outside of intel_dp.c.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 33 +
> drivers/gpu/drm/i915/intel_dp.c | 34
> --
Hello,
In our current driver implementation we support flip notifications only
for primary plane. So, in a full screen video playback scenario where
only one sprite plane is active, the user space is forced to rely on
primary plane flip notification even though there is no real need for
this
On Wed, 2014-02-05 at 16:54 +0200, Ville Syrjälä wrote:
> On Tue, Feb 04, 2014 at 09:35:50PM +0200, Imre Deak wrote:
> > At least on VLV we can't get at the pipestat status bits by simply right
> > shifting the corresponding enable bits. The mapping between enable and
> > status bits for the sprite
On Thu, 30 Jan 2014 19:58:43 -0200
Rodrigo Vivi wrote:
> > + seq_printf(m, ", mode:\n");
> > + seq_printf(m, "\t\t%d:\"%s\" %d %d %d %d %d %d %d
> > %d %d %d 0x%x 0x%x\n",
> > + mode->base.id, mode->name,
> > +
On Sat, 14 Dec 2013 12:36:30 +0100
Daniel Vetter wrote:
> On Sat, Dec 14, 2013 at 12:13:45PM +0100, Daniel Vetter wrote:
> > On Thu, Dec 12, 2013 at 12:41:54PM -0800, Jesse Barnes wrote:
> > > + ifbdev->helper.funcs->initial_config = intel_fb_initial_config;
> >
> > This here is a bit surprising
Future platform require the phy input to determine which PHY to target for.
Signed-off-by: Chon Ming Lee
---
lib/intel_iosf.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/intel_iosf.c b/lib/intel_iosf.c
index f57212f..0c9f4d8 100644
--- a/lib/intel_ios
On Tue, 4 Feb 2014 12:18:55 +
Ben Widawsky wrote:
> We get a large number of bugs which have a, "hey I have that too"
> because they see a GPU hang in dmesg. While two machines of the same
> model having a GPU hang is indeed a coincidence, it is far from enough
> evidence to suggest they are
On Wed, Feb 05, 2014 at 08:35:11PM +0530, Vijay Purushothaman wrote:
> Hello,
>
> In our current driver implementation we support flip notifications only
> for primary plane. So, in a full screen video playback scenario where
> only one sprite plane is active, the user space is forced to rely on
On Tue, Feb 04, 2014 at 09:35:51PM +0200, Imre Deak wrote:
> Atm we call the handlers for pending pipestat interrupt events even if
> they aren't explicitly enabled by i915_enable_pipestat(). This isn't an
> issue for events other than the vblank start event, since those are
> always enabled anyway
On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> The command parser scans batch buffers submitted via execbuffer ioctls before
> the driver submits them to hardware. At a high level, it looks for several
> things:
>
> 1) Commands which are explicitly defined as privil
On Wed, Feb 05, 2014 at 02:59:08PM +, Jesse Barnes wrote:
> On Tue, 4 Feb 2014 12:18:55 +
> Ben Widawsky wrote:
>
> > We get a large number of bugs which have a, "hey I have that too"
> > because they see a GPU hang in dmesg. While two machines of the same
> > model having a GPU hang is
On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> The spec defines most of these commands as privileged. A few others,
> like the semaphore mbox command and some display commands, are also
> reserved for the driver's use. Subsequent patches relax some of
> these restri
On Wed, 2014-02-05 at 17:11 +0200, Ville Syrjälä wrote:
> On Tue, Feb 04, 2014 at 09:35:51PM +0200, Imre Deak wrote:
> > Atm we call the handlers for pending pipestat interrupt events even if
> > they aren't explicitly enabled by i915_enable_pipestat(). This isn't an
> > issue for events other than
On Tue, 4 Feb 2014 21:35:45 +0200
Imre Deak wrote:
> Bspec and the code suggests that the interrupt signaled by IIR[7,5]
> (DISPLAY_PIPE_A/B_VBLANK) is a first level IRQ flag for the second
> level PIPEA/BSTAT[2] (Start of Vertical Blank) interrupt. Measuring
> the relative timings of when IIR[7
On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> These registers are currently used by mesa for blitting,
> transform feedback extensions, and performance monitoring
> extensions.
>
> Signed-off-by: Brad Volkin
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 55
>
On Tue, 4 Feb 2014 21:35:46 +0200
Imre Deak wrote:
> This will be used by other platforms too, so factor it out.
>
> The only functional change is the reordeing of gmbus_irq_handler() wrt.
> the hotplug handling, but since it only schedules a work, it isn't an
> issue.
>
> Signed-off-by: Imre
On Tue, 4 Feb 2014 21:35:47 +0200
Imre Deak wrote:
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_irq.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b5524ea..e0e5190 100644
On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM, and MI_LOAD_REGISTER_IMM
> commands allow userspace access to registers. Only certain registers
> should be allowed for such access, so enable checking for those commands.
>
On Tue, 4 Feb 2014 21:35:48 +0200
Imre Deak wrote:
> s/FLIPDONE/FLIP_DONE/ to make all FLIP_DONE macro names consistent.
>
> No functional change.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 18 +-
> 2 file
On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> Various commands that access memory have a bit to determine whether
> the graphics address specified in the command should use the GGTT or
> PPGTT for translation. These checks ensure that the bit indicates
> PPGTT tran
On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> PIPE_CONTROL and MI_FLUSH_DW have bits that would write to the
> hardware status page. The driver stores request tracking info
> there, so don't let userspace overwrite it.
>
> Signed-off-by: Brad Volkin
> ---
> drive
FYI, I did an initial review "sweep" of this. Will focus more on the
logic and registers etc. next.
BR,
Jani.
On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> Certain OpenGL features (e.g. transform feedback, performance monitoring)
> require userspace code to sub
On Tue, 4 Feb 2014 21:35:49 +0200
Imre Deak wrote:
> There isn't any PSR interrupt enable bit for pipe A, so we couldn't
> enable it through the current API. Passing the corresponding status bits
> solves this and also makes the mapping between enable and status bits
> simpler on VLV (addressed
On 2/5/2014 8:43 PM, Ville Syrjälä wrote:
On Wed, Feb 05, 2014 at 08:35:11PM +0530, Vijay Purushothaman wrote:
Hello,
In our current driver implementation we support flip notifications only
for primary plane. So, in a full screen video playback scenario where
only one sprite plane is active, th
On Tue, Feb 04, 2014 at 09:35:46PM +0200, Imre Deak wrote:
> This will be used by other platforms too, so factor it out.
>
> The only functional change is the reordeing of gmbus_irq_handler() wrt.
> the hotplug handling, but since it only schedules a work, it isn't an
> issue.
>
> Signed-off-by:
On Tue, 4 Feb 2014 11:56:47 +0100
Daniel Vetter wrote:
> On Mon, Feb 03, 2014 at 03:28:37PM +, Tvrtko Ursulin wrote:
> >
> > On 01/29/2014 08:34 PM, Daniel Vetter wrote:
> > >Actually I've found something else to complain about:
> > >
> > >On Tue, Jan 28, 2014 at 2:16 PM, Chris Wilson
> >
On Wed, 5 Feb 2014 16:15:02 +0100
Daniel Vetter wrote:
> On Wed, Feb 05, 2014 at 02:59:08PM +, Jesse Barnes wrote:
> > On Tue, 4 Feb 2014 12:18:55 +
> > Ben Widawsky wrote:
> >
> > > We get a large number of bugs which have a, "hey I have that too"
> > > because they see a GPU hang in
On Wed, Feb 05, 2014 at 03:35:15PM +, Jesse Barnes wrote:
> I almost think we should just separate enable vs status entirely. As
> long as the bits are named consistently it may be easier to follow (as
> Ville found in your next patch with the subtle remapping of status
> bits).
Yeah, I think
On Wed, Feb 05, 2014 at 04:03:45PM +, Jesse Barnes wrote:
> On Wed, 5 Feb 2014 16:15:02 +0100
> Daniel Vetter wrote:
>
> > On Wed, Feb 05, 2014 at 02:59:08PM +, Jesse Barnes wrote:
> > > On Tue, 4 Feb 2014 12:18:55 +
> > > Ben Widawsky wrote:
> > >
> > > > We get a large number of
On Wed, Feb 5, 2014 at 5:18 PM, Daniel Vetter wrote:
> I'd still like to see the same information
> dumped into the error state though.
This was re: Jesse's idea on irc to dump pid/comm, too. But adding the
same gpu hang cookie computation to the error state decoder might
still make sense.
-Danie
After finding the guilty batch and request, we can use it to find the
process that submitted the batch and then add the culprit into the error
state.
This is a slightly different approach from Ben's in that instead of
adding the extra information into the struct i915_hw_context, we use the
informa
On Wed, Feb 05, 2014 at 09:25:36PM +0530, Vijay Purushothaman wrote:
> On 2/5/2014 8:43 PM, Ville Syrjälä wrote:
> > On Wed, Feb 05, 2014 at 08:35:11PM +0530, Vijay Purushothaman wrote:
> >> Hello,
> >>
> >> In our current driver implementation we support flip notifications only
> >> for primary pl
On Wed, Feb 05, 2014 at 05:12:39PM +0100, Daniel Vetter wrote:
> On Wed, Feb 05, 2014 at 03:35:15PM +, Jesse Barnes wrote:
> > I almost think we should just separate enable vs status entirely. As
> > long as the bits are named consistently it may be easier to follow (as
> > Ville found in your
The BIOS or boot loader will generally create an initial display
configuration for us that includes some set of active pipes and
displays. This routine tries to figure out which pipes and connectors
are active and stuffs them into the crtcs and modes array given to us by
the drm_fb_helper code.
S
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
v2: update for new pitch_for_width function (Jesse)
comment how
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fi
On Wed, 5 Feb 2014 16:40:41 +
Chris Wilson wrote:
> After finding the guilty batch and request, we can use it to find the
> process that submitted the batch and then add the culprit into the error
> state.
>
> This is a slightly different approach from Ben's in that instead of
> adding the
From: Tvrtko Ursulin
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers on common address space
operati
This should allow BIOS fb inheritance to work on ILK+ machines too.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_di
On Wed, Feb 05, 2014 at 05:30:43PM +, Jesse Barnes wrote:
> For use by get_plane_config.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_displa
On Wed, Feb 05, 2014 at 05:33:06PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This adds a small benchmark for the new userptr functionality.
>
> Apart from basic surface creation and destruction, also tested is the
> impact of having userptr surfaces in the process address space. Re
For use by get_plane_config.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4d4a0d9..e2f1db6 100644
---
Allocate this struct instead, so we can re-use another allocated
elsewhere if needed.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 27 +++
3 files
On Wed, Feb 05, 2014 at 05:30:48PM +, Jesse Barnes wrote:
> +static bool intel_fbdev_init_bios(struct drm_device *dev,
> + struct intel_fbdev *ifbdev)
> +{
> + struct intel_framebuffer *fb = NULL;
> + struct drm_crtc *crtc;
> + struct intel_crtc *intel_c
On Wed, Feb 05, 2014 at 10:18:44AM -0800, Volkin, Bradley D wrote:
> On Wed, Feb 05, 2014 at 02:28:29AM -0800, Chris Wilson wrote:
> > On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
> > > From: Brad Volkin
> > >
> > > Certain OpenGL features (e.g. transform feedback,
On Wed, Feb 05, 2014 at 02:28:29AM -0800, Chris Wilson wrote:
> On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > Certain OpenGL features (e.g. transform feedback, performance monitoring)
> > require userspace code to submit batches containi
On Wed, Feb 5, 2014 at 7:18 PM, Volkin, Bradley D
wrote:
> On Wed, Feb 05, 2014 at 02:28:29AM -0800, Chris Wilson wrote:
>> On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
>> > From: Brad Volkin
>> >
>> > Certain OpenGL features (e.g. transform feedback, performance mo
On Wed, Feb 05, 2014 at 07:15:35AM -0800, Jani Nikula wrote:
> On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > The command parser scans batch buffers submitted via execbuffer ioctls
> > before
> > the driver submits them to hardware. At a high level, it looks
[snip]
On Wed, Feb 05, 2014 at 07:22:33AM -0800, Jani Nikula wrote:
> On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 13ed6ed..2b7c26e 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b
On Wed, Feb 05, 2014 at 07:29:12AM -0800, Jani Nikula wrote:
> On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > These registers are currently used by mesa for blitting,
> > transform feedback extensions, and performance monitoring
> > extensions.
> >
> > Signed-
On Wed, Feb 05, 2014 at 07:33:28AM -0800, Jani Nikula wrote:
> On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM, and MI_LOAD_REGISTER_IMM
> > commands allow userspace access to registers. Only certain registers
> > sho
Atm we call the handlers for pending pipestat interrupt events even if
they aren't explicitly enabled by i915_enable_pipestat(). This isn't an
issue for events other than the vblank start event, since those are
always enabled anyways. Otoh, we enable the vblank start event
on-demand, so we'll end u
There isn't any PSR interrupt enable bit for pipe A, so we couldn't
enable it through the current API. Passing the corresponding status bits
solves this and also makes the mapping between enable and status bits
simpler on VLV (addressed in an upcoming patch).
Except of checking for invalid status
At least on VLV we can't get at the pipestat status bits by simply right
shifting the corresponding enable bits. The mapping between enable and
status bits for the sprite0,1 flip done and the PSR events don't follow
this rule, so we need to map them separately.
The PSR enable for pipe A is DPFLIPS
[snip]
On Wed, Feb 05, 2014 at 07:37:51AM -0800, Jani Nikula wrote:
> On Wed, 29 Jan 2014, bradley.d.vol...@intel.com wrote:
> > int i915_needs_cmd_parser(struct intel_ring_buffer *ring)
> > {
> > + drm_i915_private_t *dev_priv =
> > + (drm_i915_private_t *)ring->dev->dev_private;
>
On Wed, Feb 05, 2014 at 10:30:00AM -0800, Daniel Vetter wrote:
> On Wed, Feb 5, 2014 at 7:18 PM, Volkin, Bradley D
> wrote:
> > On Wed, Feb 05, 2014 at 02:28:29AM -0800, Chris Wilson wrote:
> >> On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
> >> > From: Brad Volkin
>
This patch adds PSR Support to Baytrail.
Baytrail cannot easily detect screen updates and force PSR exit.
So we inactivate it on {busy_ioctl, set_domain, sw_finish and mark_busy}
and update to enable it back on next display mark_idle.
v2: Also inactivate PSR on cursor update.
v3: Inactivate PSR o
Since now on update is also been called out of set_base let's use
a mutex to protec psr state changes.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_suspend.c | 4
drivers/gpu/drm/i915/intel_dp.c | 17 ++---
3 files ch
v2: Wait psr enable with timeout and more subtest added.
v3: Add wait for v_blank leeting test more reliable and preparing to
add Baytrail per-pipe tests.
v4: Call busy_ioctl on mmap_gtt to match the real usage and remove the need
of inactivate on set_domain, what was semantically wrong.
v5
On Wed, Feb 05, 2014 at 08:55:07PM +0200, Imre Deak wrote:
> At least on VLV we can't get at the pipestat status bits by simply right
> shifting the corresponding enable bits. The mapping between enable and
> status bits for the sprite0,1 flip done and the PSR events don't follow
> this rule, so we
Gentle ping on this patch set for igt.
Thanks,
Jeff
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Gentle ping on this patch set for igt.
Thanks,
Jeff
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Feb 5, 2014 at 8:00 PM, Volkin, Bradley D
wrote:
> To test/merge, we'd have to change the series to take out the part where
> patch 02/13 sets I915_DISPATCH_SECURE to avoid a BUG_ON() when
> i915.enable_cmd_parser=1.
> But yes, otherwise the parsing works and I think should be sufficient
At least on VLV we can't get at the pipestat status bits by simply right
shifting the corresponding enable bits. The mapping between enable and
status bits for the sprite0,1 flip done and the PSR events don't follow
this rule, so we need to map them separately.
The PSR enable for pipe A is DPFLIPS
On Wed, Feb 05, 2014 at 11:17:25AM -0800, Daniel Vetter wrote:
> On Wed, Feb 5, 2014 at 8:00 PM, Volkin, Bradley D
> wrote:
> > To test/merge, we'd have to change the series to take out the part where
> > patch 02/13 sets I915_DISPATCH_SECURE to avoid a BUG_ON() when
> > i915.enable_cmd_parser=1.
On Wed, Feb 05, 2014 at 01:21:34PM -0600, Jeff McGee wrote:
> Gentle ping on this patch set for igt.
Both series pulled in, sorry for slacking off a bit.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_
On 2/5/2014 10:18 PM, Ville Syrjälä wrote:
On Wed, Feb 05, 2014 at 09:25:36PM +0530, Vijay Purushothaman wrote:
On 2/5/2014 8:43 PM, Ville Syrjälä wrote:
On Wed, Feb 05, 2014 at 08:35:11PM +0530, Vijay Purushothaman wrote:
Hello,
In our current driver implementation we support flip notificati
On Wed, 05 Feb 2014, Daniel Vetter wrote:
> On Tue, Feb 04, 2014 at 09:35:46PM +0200, Imre Deak wrote:
>> This will be used by other platforms too, so factor it out.
>>
>> The only functional change is the reordeing of gmbus_irq_handler() wrt.
>> the hotplug handling, but since it only schedules
86 matches
Mail list logo
