On Fri, 2014-05-16 at 14:09 +0530, Naresh Kumar Kachhi wrote:
> On 04/30/2014 10:08 PM, Imre Deak wrote:
> > On Fri, 2014-04-25 at 10:45 +0200, Daniel Vetter wrote:
> >> Ok, review assignements. Please complain if you don't have the
> >> bandwidth so that I can find someone else.
> >>
> >> On Thu,
On 05/16/2014 04:29 PM, Michael H Nguyen wrote:
Hi,
I am trying to step through i-g-t & libdrm source w/ GDB but single
stepping seems erratic so I am guessing the build is optimized. Is
changing "CFLAGS = -g -O2" to "CFLAGS = -g -O0" the right thing to do?
If so, how can I do that globally
Hi,
I am trying to step through i-g-t & libdrm source w/ GDB but single
stepping seems erratic so I am guessing the build is optimized. Is
changing "CFLAGS = -g -O2" to "CFLAGS = -g -O0" the right thing to do?
If so, how can I do that globally one time versus touching every
Makefile inside th
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter. The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call
On Sat, May 17, 2014 at 12:38 AM, Matt Roper wrote:
> + if (ret) {
> + if (req->flags & DRM_MODE_CURSOR_BO)
> + drm_mode_rmfb(dev, &fb->base.id, file_priv);
> + return ret;
> + }
With the new refcount logic an unconditional
drm_framebu
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 a VT switch to restore the mode on
> > > > resume */
> > > > +
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 a VT switch to restore the mode on resume */
> > > + info->skip_vt_switch = true;
> > > +
> > > drm_fb_helper_fill_fix(info, fb->p
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition
Refactor DRM framebuffer creation into a new function that returns a
struct drm_framebuffer directly. The upcoming universal cursor support
will want to create framebuffers internally to wrap cursor buffers, so
we want to be able to share that framebuffer creation with the
drm_mode_addfb2 ioctl ha
Refactor DRM setplane code into a new setplane_internal() function that
takes DRM objects directly as parameters rather than looking them up by
ID. We'll use this in a future patch when we implement legacy cursor
ioctls on top of the universal plane interface.
Signed-off-by: Matt Roper
---
driv
On Sat, May 17, 2014 at 12:20 AM, Jesse Barnes wrote:
> On Mon, 21 Apr 2014 18:37:31 +0200
> Knut Petersen wrote:
>> > + /* This driver doesn't need a VT switch to restore the mode on resume
>> > */
>> > + info->skip_vt_switch = true;
>> > +
>> > drm_fb_helper_fill_fix(info, fb->pitches[
On Sat, 17 May 2014 00:19:09 +0200
Daniel Vetter wrote:
> On Fri, May 16, 2014 at 02:48:27PM -0700, Jesse Barnes wrote:
> > On Thu, 24 Apr 2014 23:55:42 +0200
> > Daniel Vetter wrote:
> >
> > > + if (enable) {
> > > + if (!intel_crtc->active) {
> > > + domains = get_crtc
On Mon, 21 Apr 2014 18:37:31 +0200
Knut Petersen wrote:
> > + /* This driver doesn't need a VT switch to restore the mode on resume */
> > + info->skip_vt_switch = true;
> > +
> > drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
> > drm_fb_helper_fill_var(info, &ifbdev->helper,
On Fri, May 16, 2014 at 02:48:27PM -0700, Jesse Barnes wrote:
> On Thu, 24 Apr 2014 23:55:42 +0200
> Daniel Vetter wrote:
>
> > + if (enable) {
> > + if (!intel_crtc->active) {
> > + domains = get_crtc_power_domains(crtc);
> > + for_each_power_domai
On Thu, 24 Apr 2014 23:55:42 +0200
Daniel Vetter wrote:
> + if (enable) {
> + if (!intel_crtc->active) {
> + domains = get_crtc_power_domains(crtc);
> + for_each_power_domain(domain, domains)
> + intel_display_pow
If it's a simple test, it needs to be in the simple lists. Tests with
subtests go into the _M tests.
Without that test enumeration is all screwed up.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
tests/Makefile.sources | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tes
From: Clint Taylor
The panel power sequencer on vlv doesn't appear to accept changes to its T12
power down duration during warm reboots. This change forces a delay for warm
reboots to the T12 panel timing as defined in the VBT table for the connected
panel.
Ver2: removed redundant pr_crit(),
On Thu, May 15, 2014 at 10:41:42AM +0100, Chris Wilson wrote:
> More fallout from
>
> commit c8725f3dc0911d4354315a65150aecd8b7d0d74a
> Author: Chris Wilson
> Date: Mon Mar 17 12:21:55 2014 +
>
> drm/i915: Do not call retire_requests from wait_for_rendering
>
> is that we can complete
On Fri, 16 May 2014 20:49:30 +0100
Chris Wilson wrote:
> On Fri, May 16, 2014 at 12:34:08PM -0700, Jesse Barnes wrote:
> > On Fri, 16 May 2014 20:20:50 +0100
> > Chris Wilson wrote:
> > > We haven't even fixed the major regression from enabling FBC. What's
> > > another massive slowdown?
> >
>
On Fri, 16 May 2014 13:12:27 -0700
"Volkin, Bradley D" wrote:
> On Fri, May 16, 2014 at 12:53:30PM -0700, Jesse Barnes wrote:
> > On Fri, 16 May 2014 12:34:08 -0700
> > Jesse Barnes wrote:
> >
> > > On Fri, 16 May 2014 20:20:50 +0100
> > > Chris Wilson wrote:
> > > > Yes, X only sets the secur
On Fri, May 16, 2014 at 12:53:30PM -0700, Jesse Barnes wrote:
> On Fri, 16 May 2014 12:34:08 -0700
> Jesse Barnes wrote:
>
> > On Fri, 16 May 2014 20:20:50 +0100
> > Chris Wilson wrote:
> > > Yes, X only sets the secure bit when it pokes the display registers, and
> > > those registers should be
On Fri, 16 May 2014 12:34:08 -0700
Jesse Barnes wrote:
> On Fri, 16 May 2014 20:20:50 +0100
> Chris Wilson wrote:
> > Yes, X only sets the secure bit when it pokes the display registers, and
> > those registers should be privileged even with a cmd parser in place
> > (which they are).
> >
> > D
On Fri, May 16, 2014 at 12:34:08PM -0700, Jesse Barnes wrote:
> On Fri, 16 May 2014 20:20:50 +0100
> Chris Wilson wrote:
> > We haven't even fixed the major regression from enabling FBC. What's
> > another massive slowdown?
>
> I thought you had that fixed in the X driver by avoiding front buffer
On Fri, May 16, 2014 at 06:59:00PM +0100, Chris Wilson wrote:
> Since commit 691e6415c891b8b2b082a120b896b443531c4d45
> Author: Chris Wilson
> Date: Wed Apr 9 09:07:36 2014 +0100
>
> drm/i915: Always use kref tracking for all contexts.
>
> we have contexts everywhere, and so we must be car
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson wrote:
> On Fri, May 16, 2014 at 12:05:45PM -0700, Jesse Barnes wrote:
> > On Thu, 27 Mar 2014 16:22:44 -0700
> > Kenneth Graunke wrote:
> >
> > > On 03/27/2014 03:44 PM, Daniel Vetter wrote:
> > > > On Thu, Mar 27, 2014 at 10:34 PM, Kenneth Graun
On Fri, May 16, 2014 at 12:05:45PM -0700, Jesse Barnes wrote:
> On Thu, 27 Mar 2014 16:22:44 -0700
> Kenneth Graunke wrote:
>
> > On 03/27/2014 03:44 PM, Daniel Vetter wrote:
> > > On Thu, Mar 27, 2014 at 10:34 PM, Kenneth Graunke
> > > wrote:
> > >> Why are we parsing batches with I915_EXEC_SE
On Thu, 27 Mar 2014 16:22:44 -0700
Kenneth Graunke wrote:
> On 03/27/2014 03:44 PM, Daniel Vetter wrote:
> > On Thu, Mar 27, 2014 at 10:34 PM, Kenneth Graunke
> > wrote:
> >> Why are we parsing batches with I915_EXEC_SECURE at all? Secure batches
> >> are only issued from trusted code which is
Since commit 691e6415c891b8b2b082a120b896b443531c4d45
Author: Chris Wilson
Date: Wed Apr 9 09:07:36 2014 +0100
drm/i915: Always use kref tracking for all contexts.
we have contexts everywhere, and so we must be careful to distinguish
fake contexts, which do not have an associated bo, and r
2014-05-16 13:53 GMT+02:00 Ville Syrjälä :
> On Tue, May 13, 2014 at 06:38:32PM +0200, Daniel Vetter wrote:
>> On Tue, May 13, 2014 at 05:21:49PM +0200, Jörg Otte wrote:
>> > 2014-05-13 15:22 GMT+02:00 Daniel Vetter :
>> > > On Tue, May 13, 2014 at 12:38:41PM +0200, Daniel Vetter wrote:
>> > >> On
On Fri, May 16, 2014 at 06:02:29PM +0100, Chris Wilson wrote:
> On Fri, May 16, 2014 at 06:53:52PM +0200, Daniel Vetter wrote:
> > On Fri, May 16, 2014 at 05:36:59PM +0100, Chris Wilson wrote:
> > > Extremely unlikely to ever be required, but BIOSes do like to attack in
> > > unexpected ways.
> > >
On Fri, May 16, 2014 at 06:53:52PM +0200, Daniel Vetter wrote:
> On Fri, May 16, 2014 at 05:36:59PM +0100, Chris Wilson wrote:
> > Extremely unlikely to ever be required, but BIOSes do like to attack in
> > unexpected ways.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/int
On Fri, May 16, 2014 at 07:40:23PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Some platforms have a shared error interrupt, so if FIFO underrun
> reporting gets disabled for one pipe/transcoder it gets disabled
> for all pipes/transcoders.
>
> When we disable FIFO unde
On Fri, May 16, 2014 at 05:36:59PM +0100, Chris Wilson wrote:
> Extremely unlikely to ever be required, but BIOSes do like to attack in
> unexpected ways.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/d
On Fri, May 16, 2014 at 07:04:54PM +0300, Ville Syrjälä wrote:
> On Fri, May 16, 2014 at 05:09:53PM +0200, Daniel Vetter wrote:
> > On Fri, May 16, 2014 at 03:41:05PM +0100, Chris Wilson wrote:
> > > On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter wrote:
> > > > It's not that I haven't had
Hi Dave,
drm-intel-next-2014-05-06:
- ring init improvements (Chris)
- vebox2 support (Zhao Yakui)
- more prep work for runtime pm on Baytrail (Imre)
- eDram support for BDW (Ben)
- prep work for userptr support (Chris)
- first parts of the encoder->mode_set callback removal (Daniel)
- 64b reloc f
On Fri, May 16, 2014 at 3:23 AM, Chris Wilson wrote:
> On Thu, May 15, 2014 at 08:13:05PM -0400, Rodrigo Vivi wrote:
> > The perfect solution for psr_exit is the hardware tracking the changes
> and
> > doing the psr exit by itself. This scenario works for HSW and BDW with
> some
> > environments l
From: Ville Syrjälä
FIFO underruns don't generate interrupts on gmch platforms, so
if we want to know whether a modeset triggered FIFO underruns we
need to explicitly check for them.
As a modeset on one pipe could cause underruns on other pipes,
check for underruns on all pipes.
Signed-off-by:
From: Ville Syrjälä
Gen2 reports FIFO underruns whenever no planes are enabled on the pipe.
So in order to avoid false positives we must enable the FIFO underrun
reporting only when at least one plane is enabled on the pipe. For
now just move the underrun reporting enable/disable points to the
ot
From: Ville Syrjälä
Some platforms have a shared error interrupt, so if FIFO underrun
reporting gets disabled for one pipe/transcoder it gets disabled
for all pipes/transcoders.
When we disable FIFO underrun reporting we check whether the
interrupt was enabled or not. If it wasn't we might have
From: Ville Syrjälä
Checking whether the error interrupt was enabled or not isn't really
necessary when we check for uncleared FIFO underruns. If it was enabled
we'll race with the interrupt handler a bit, but that seems OK as we
still claim the interrupt.
Signed-off-by: Ville Syrjälä
---
driv
From: Ville Syrjälä
FIFO underruns don't generate an interrupt on gmch platforms, so we
should check whether there were any that we failed to notice when
we're disabling FIFO underrun reporting.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 18 --
1 file ch
From: Ville Syrjälä
I was looking at FIFO underruns a bit and came up with a few improvements to
the FIFO underrun reporting code. Mainly this should lead to detecting FIFO
a bit more more reliably on gmch platforms.
I also promoted the IVB/CPT uncleared FIFO underrun messages to errors
since th
On Fri, May 16, 2014 at 3:21 AM, Chris Wilson wrote:
> On Thu, May 15, 2014 at 08:13:04PM -0400, Rodrigo Vivi wrote:
> > Also do not cache aux info. That info could be related to another panel.
>
> You should kill the bool sink_support then. There are other places that
> it used that could be inva
On Fri, May 16, 2014 at 08:34:52AM -0700, Volkin, Bradley D wrote:
> Reviewed-by: Brad Volkin
>
> On Fri, May 16, 2014 at 02:22:37PM +0100, Chris Wilson wrote:
> > By exporting the ability to map user address and inserting PTEs
> > representing their backing pages into the GTT, we can exploit UM
Extremely unlikely to ever be required, but BIOSes do like to attack in
unexpected ways.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
inde
On Thu, May 15, 2014 at 06:17:29PM -0700, Matt Roper wrote:
> The DRM core will translate calls to legacy cursor ioctls into universal
> cursor calls automatically, so there's no need to maintain the legacy
> cursor support. This greatly simplifies the transition since we don't
> have to handle re
On Fri, May 16, 2014 at 05:09:53PM +0200, Daniel Vetter wrote:
> On Fri, May 16, 2014 at 03:41:05PM +0100, Chris Wilson wrote:
> > On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter wrote:
> > > It's not that I haven't had a patch for it. Really trivial. I wonder
> > > what keeps you from add
On Thu, May 15, 2014 at 06:17:27PM -0700, Matt Roper wrote:
> Universal plane support had placeholders for cursor planes, but didn't
> actually do anything with them. Save the cursor plane reference inside
> the crtc and update the cursor plane parameter from void* to drm_plane.
>
> Signed-off-by
On Thu, May 15, 2014 at 06:17:28PM -0700, Matt Roper wrote:
> Refactor cursor buffer setting such that the code to actually update the
> cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
> a GEM object as a parameter. The existing legacy cursor ioctl handler,
> intel_crtc_curs
On Thu, May 15, 2014 at 06:17:26PM -0700, Matt Roper wrote:
> If drivers support universal planes and have registered a cursor plane
> with the DRM core, we should use that universal plane support when
> handling legacy cursor ioctls. Drivers that transition to universal
> planes won't have to mai
On Fri, May 16, 2014 at 10:51:44AM +0800, Lee, Chon Ming wrote:
...
> > +int drm_primary_helper_check_update(struct drm_plane *plane,
> > + struct drm_crtc *crtc,
> > + struct drm_framebuffer *fb,
> > + struct
Reviewed-by: Brad Volkin
On Fri, May 16, 2014 at 02:22:37PM +0100, Chris Wilson wrote:
> By exporting the ability to map user address and inserting PTEs
> representing their backing pages into the GTT, we can exploit UMA in order
> to utilize normal application data as a texture source or even a
On Fri, May 16, 2014 at 03:41:05PM +0100, Chris Wilson wrote:
> On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter wrote:
> > It's not that I haven't had a patch for it. Really trivial. I wonder
> > what keeps you from adding this to the kernel and just make things
> > working?
>
> You mean
On Fri, May 16, 2014 at 03:45:24PM +0100, Chris Wilson wrote:
> On Fri, May 16, 2014 at 04:27:34PM +0200, Daniel Vetter wrote:
> > On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
> > > On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> > > > I think as soon as we have th
On Fri, May 16, 2014 at 02:07:12PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> This is a "review by igt test" for a bug located in
> i915_gem_object_pin_to_display_plane and fixed by:
Thanks. Both patches pushed.
--
Ville Syrjälä
Intel OTC
__
deepa...@linux.intel.com writes:
> From: Deepak S
>
> Support to individually control Media/Render well based on the register
> access.
> Add CHV specific write function to habdle difference between registers
> that are sadowed vs those that need forcewake even for writes.
>
> v2: Drop write FIF
On Fri, May 16, 2014 at 04:27:34PM +0200, Daniel Vetter wrote:
> On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
> > On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> > > I think as soon as we have the golden context stuff from Mika we could
> > > drop our usage of rest
On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter wrote:
> It's not that I haven't had a patch for it. Really trivial. I wonder
> what keeps you from adding this to the kernel and just make things
> working?
You mean this patch?
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/dr
On Fri, 2014-05-16 at 11:06 +0200, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 10:46:50PM -0600, Alex Williamson wrote:
> > On Fri, 2014-05-16 at 00:50 +0200, Daniel Vetter wrote:
> > > On Thu, May 15, 2014 at 11:43 PM, Alex Williamson
> > > wrote:
> > > > I don't know what to do with this. It
On Fri, May 16, 2014 at 01:44:12PM +0300, Mika Kuoppala wrote:
> Bit 31 in GEN6_PMINTRMSK is not an interrupt disable bit with gen8.
>
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Mika Kuoppala
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporati
On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
> On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> > I think as soon as we have the golden context stuff from Mika we could
> > drop our usage of restore_inhibit. We only need that to avoid the hw
> > getting angry if the
On Fri, May 16, 2014 at 02:20:43PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we do a NULL pointer dereference.
>
> I've seen this happen while handling an error in
> i915_gem_object_pin_to_display_plane():
>
> If i915_gem_object_set_cache_level() fails, we call is_p
Hi Daniel, dear list,
just tried the latest nightly build of 3.15.0+, and I'm sorry to say
that the watermark configuration of the 830GM is still off.
This is what I get from the kernel: (not to be taken too serious, but
humor is the only thing that keeps me from getting seriously anoyed
afte
From: Oscar Mateo
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object is still not pinned
to GGTT
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, w
From: Oscar Mateo
This is a "review by igt test" for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
commit 392013bdd4b6128795e33c84bd6d6d3fd66ff0a3
Author: Oscar Mateo
Date: Fri May 16 11:23:12 2014 +0100
drm/i915: Gracefully handle obj not bound to GGTT in is_pin_di
From: Oscar Mateo
Useful for testing bigger/smaller fb-wrapped buffer objects.
Cc: Ville Syrjälä
Signed-off-by: Oscar Mateo
---
lib/igt_fb.c | 45 ++---
lib/igt_fb.h | 3 +++
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/lib/igt_fb.c
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Friday, May 16, 2014 1:14 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] tests/kms_flip: test a fb backed by a bo too
> big
> for its own good
>
On Fri, May 16, 2014 at 12:34:08PM +, Gupta, Sourab wrote:
> On Thu, 2014-05-15 at 12:27 +, Ville Syrjälä wrote:
> > On Thu, May 15, 2014 at 11:47:37AM +0530, sourab.gu...@intel.com wrote:
> > > From: Sourab Gupta
> > >
> > > Using MMIO based flips on Gen5+ for Media power well residency
On Thu, 2014-05-15 at 12:27 +, Ville Syrjälä wrote:
> On Thu, May 15, 2014 at 11:47:37AM +0530, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > Using MMIO based flips on Gen5+ for Media power well residency optimization.
> > The blitter ring is currently being used just for comma
On Fri, May 16, 2014 at 03:04:21PM +0300, Ville Syrjälä wrote:
> On Fri, May 16, 2014 at 12:08:51PM +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > This is a "review by igt test" for a bug located in
> > i915_gem_object_pin_to_display_plane and fixed by:
> >
> > commit 392013bd
On Fri, May 16, 2014 at 12:08:51PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> This is a "review by igt test" for a bug located in
> i915_gem_object_pin_to_display_plane and fixed by:
>
> commit 392013bdd4b6128795e33c84bd6d6d3fd66ff0a3
> Author: Oscar Mateo
> Date: Fri May 16
On Tue, May 13, 2014 at 06:38:32PM +0200, Daniel Vetter wrote:
> On Tue, May 13, 2014 at 05:21:49PM +0200, Jörg Otte wrote:
> > 2014-05-13 15:22 GMT+02:00 Daniel Vetter :
> > > On Tue, May 13, 2014 at 12:38:41PM +0200, Daniel Vetter wrote:
> > >> On Tue, May 13, 2014 at 12:29 PM, Jörg Otte wrote:
On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> I think as soon as we have the golden context stuff from Mika we could
> drop our usage of restore_inhibit. We only need that to avoid the hw
> getting angry if the context state is illegal afaik.
Apart from the contexts being over 1
On Fri, May 16, 2014 at 11:11:38AM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Friday, May 16, 2014 12:05 PM
> > To: Mateo Lozano, Oscar
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATC
On Fri, May 16, 2014 at 12:08:22PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we do a NULL pointer dereference.
>
> I've seen this happen while handling an error in
> i915_gem_object_pin_to_display_plane():
>
> If i915_gem_object_set_cache_level() fails, we call is_p
On Thu, May 15, 2014 at 05:48:57PM +0100, Damien Lespiau wrote:
> > +static struct gpio_table gtable[] = {
>
> const
>
Please, disregard this comment. It's being written to to track GPIO
initialization.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@l
From: Oscar Mateo
This is a "review by igt test" for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
commit 392013bdd4b6128795e33c84bd6d6d3fd66ff0a3
Author: Oscar Mateo
Date: Fri May 16 11:23:12 2014 +0100
drm/i915: Gracefully handle obj not bound to GGTT in is_pin_di
From: Oscar Mateo
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object is still not pinned
to GGTT
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, May 16, 2014 12:05 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 09/50] drm/i915: Plumb the context everywhere
> in the execbuffer path
>
> On
On Fri, May 09, 2014 at 01:08:39PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> The context are going to become very important pretty soon, and
> we need to be able to access them in a number of places inside
> the command submission path. The idea is that, when we need to
> place
On Thu, May 15, 2014 at 08:23:47PM +0530, akash goel wrote:
> Reviewed the patch & it looks good.
> Just to confirm, this patch tries to address the case of a tiny window of
> transition, i.e. from the 1st field (last half line) to 2nd field (first
> half line).
The hardware counts things so that
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, May 15, 2014 2:34 PM
> To: Mateo Lozano, Oscar
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Gracefully handle obj not bound to
> GGTT in i
Bit 31 in GEN6_PMINTRMSK is not an interrupt disable bit with gen8.
Reviewed-by: Ville Syrjälä
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.
On Thu, May 15, 2014 at 06:17:29PM -0700, Matt Roper wrote:
> The DRM core will translate calls to legacy cursor ioctls into universal
> cursor calls automatically, so there's no need to maintain the legacy
> cursor support. This greatly simplifies the transition since we don't
> have to handle re
On Thu, May 15, 2014 at 08:13:05PM -0400, Rodrigo Vivi wrote:
> The perfect solution for psr_exit is the hardware tracking the changes and
> doing the psr exit by itself. This scenario works for HSW and BDW with some
> environments like Gnome and Wayland.
>
> However there are many other scenarios
On Thu, May 15, 2014 at 08:13:05PM -0400, Rodrigo Vivi wrote:
> The perfect solution for psr_exit is the hardware tracking the changes and
> doing the psr exit by itself. This scenario works for HSW and BDW with some
> environments like Gnome and Wayland.
>
> However there are many other scenarios
On Thu, May 15, 2014 at 08:13:04PM -0400, Rodrigo Vivi wrote:
> Also do not cache aux info. That info could be related to another panel.
You should kill the bool sink_support then. There are other places that
it used that could be invalid.
I'm not sure though that we can cope with eDP panels bein
On Fri, May 16, 2014 at 12:46:00PM +0300, Ville Syrjälä wrote:
> On Fri, May 16, 2014 at 11:09:35AM +0200, Daniel Vetter wrote:
> > On Fri, May 16, 2014 at 01:38:18AM +, O'Rourke, Tom wrote:
> > > >+static void gen8_disable_rps_interrupts(struct drm_device *dev) {
> > > >+struct drm_i91
On Thu, Apr 17, 2014 at 03:18:48PM -0700, Volkin, Bradley D wrote:
> > + union {
> > + struct i915_gem_userptr {
>
> Out of curiosity, what's the point of using both a union and a
> struct here, given that everything is within the struct?
Because I stuff other things into this union i
On Thu, Apr 24, 2014 at 11:55:00PM +0200, Daniel Vetter wrote:
> All the callbacks are gone now.
>
> Signed-off-by: Daniel Vetter
Merged up to this patch here, thanks everyone for the reviews.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 33 ++---
> 1 file
On Fri, May 16, 2014 at 11:09:35AM +0200, Daniel Vetter wrote:
> On Fri, May 16, 2014 at 01:38:18AM +, O'Rourke, Tom wrote:
> > >+static void gen8_disable_rps_interrupts(struct drm_device *dev) {
> > >+ struct drm_i915_private *dev_priv = dev->dev_private;
> > >+
> > >+ I915_WRITE(GEN6_PMINTR
Thanks Damien for your review
On Thursday 15 May 2014 10:18 PM, Damien Lespiau wrote:
On Mon, Apr 14, 2014 at 11:18:27AM +0530, Shobhit Kumar wrote:
>This driver makes use of the generic panel information from the VBT.
>Panel information is classified into two - panel configuration and panel
>p
On Thu, May 15, 2014 at 06:17:25PM -0700, Matt Roper wrote:
> Cursor planes are a bit trickier to support via the universal plane interface
> than primary planes were. Legacy cursor ioctls take handles to driver buffers
> directly whereas the universal plane API takes drm_framebuffer's that
> rep
On Thu, May 15, 2014 at 08:13:57PM -0400, Rodrigo Vivi wrote:
> v2: rebase after a long time.
>
> Signed-off-by: Rodrigo Vivi
Oh dear, the basic test was completely lost when we've merged the sink_crc
debugfs support :( Applied now, thanks for the patch.
One comment below.
> ---
> tests/Andro
On Fri, May 16, 2014 at 01:38:18AM +, O'Rourke, Tom wrote:
> >+static void gen8_disable_rps_interrupts(struct drm_device *dev) {
> >+struct drm_i915_private *dev_priv = dev->dev_private;
> >+
> >+I915_WRITE(GEN6_PMINTRMSK, 0x);
>
> [TOR:] Please note that for Broadwell, bit 31
On Thu, May 15, 2014 at 10:46:50PM -0600, Alex Williamson wrote:
> On Fri, 2014-05-16 at 00:50 +0200, Daniel Vetter wrote:
> > On Thu, May 15, 2014 at 11:43 PM, Alex Williamson
> > wrote:
> > > I don't know what to do with this. It seems like a lot of wishful
> > > thinking that in the best case
On 04/30/2014 10:08 PM, Imre Deak wrote:
On Fri, 2014-04-25 at 10:45 +0200, Daniel Vetter wrote:
Ok, review assignements. Please complain if you don't have the
bandwidth so that I can find someone else.
On Thu, Apr 24, 2014 at 11:54 PM, Daniel Vetter wrote:
Daniel Vetter (66):
drm/i915: Ma
Hi Dave -
Intel fixes for regressions, black screens and hangs, for 3.15.
BR,
Jani.
The following changes since commit 2a1235e53bed8fa111e1c1ee2e7d8d91efa71ebc:
Merge branch 'drm-nouveau-next' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2014-05-07
09:06:21 +1000)
On Fri, May 16, 2014 at 7:25 AM, Lee, Chon Ming wrote:
>> > Cherryview display allow the primary plane to be position at any
>> > location similiar to sprite plane for certain port. So, this shouldn't
>> > need to
>> check here.
>> >
>> > And the width/height doesn't need to cover the whole scree
100 matches
Mail list logo
