Hi Sumit,
Today's linux-next merge of the dma-buf tree got a conflict in
drivers/gpu/drm/i915/i915_gem_dmabuf.c between commit 5cc9ed4b9a7a
("drm/i915: Introduce mapping of user pages into video memory (userptr)
ioctl") from the drm-intel tree and commit 8dfb1f0f8103 ("dma-buf: use
reservation obj
On Tue, May 20, 2014 at 11:44:04AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> While fixing up UXA for MST I eventually fell over this bug.
>
> Signed-off-by: Dave Airlie
Oops, that's bad - sorry for sending you on that chase.
I amended the commit to use MAX_PIPES so hopefully it is eas
Add a simple test to exercise universal plane support.
v4:
- Test disabling the primary plane explicitly when it has previously
been implicitly disabled due to clipping.
- Skip test if igt_pipe_crc_new() fails
v3:
- For testing while crtc is off, switch between several different
primary p
From: Dave Airlie
While fixing up UXA for MST I eventually fell over this bug.
Signed-off-by: Dave Airlie
---
src/uxa/intel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/uxa/intel.h b/src/uxa/intel.h
index 6ac770e..f9dbd96 100644
--- a/src/uxa/intel.h
+++ b/src/uxa/
(respinning the whole patch series to pull the entire set back together now
that a couple patches have been added at the beginning)
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
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 reference counting differently depending on which cursor
interface was
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
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
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.
This probably should be CC: stable - but I'll let the powers that be
decide t
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)
> > + drm_mode_rmfb(dev, &fb->base.id, file_priv);
> > + retur
On Mon, May 19, 2014 at 7:20 PM, Knut Petersen
wrote:
> Still missing in git master ...
It's in drm-intel-fixes and waiting for Dave to forward the pull
request to Linus.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
v8:
- Pin/unpin properly when clipping causes the primary plane to be
disabled when it has previously been enabled.
- s/drm_primary_helper_check_update/drm_p
Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.
A few of the checks here were also updated based on suggestions by
V
On Sun, May 18, 2014 at 11:53:13PM +0800, Lee, Chon Ming wrote:
> On 05/15 12:21, Matt Roper wrote:
> > Intel hardware allows the primary plane to be disabled independently of
> > the CRTC. Provide custom primary plane handling to allow this.
> >
> > v7:
> > - Clip primary plane to invisible whe
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/i915/i915_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/
From: Ville Syrjälä
On pre-ctg the reset bit directly controls the reset signal. We must
assert it for >=20usec and then deassert it. Bit 1 is a RO status bit
which should also go down when the reset is no longer asserted.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h |
From: Ville Syrjälä
g33 seems to sit somewhere between the 915/945/965 style and the
g4x style. The bits look like g4x, but we still need to do a full
reset including display.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 3 +--
drivers/gpu/drm/i915/intel_uncore.c | 1
From: Ville Syrjälä
915/945 have the same reset registers as 965, so share the code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 26 ++
3 files changed,
From: Ville Syrjälä
I went ahead and quckly fixed the GPU reset for my 946gz. I had to add
a bit of code to restore the display side since that too gets clobbered.
I then noticed that according to the specs gen3 should work with the exact
same code, so I added the missing bits. g33 is slightly s
On Mon, May 19, 2014 at 6:22 PM, David Herrmann wrote:
>
> On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter wrote:
>> On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
>>> On Mon, May 19, 2014 at 4:41 PM, Thomas Wood wrote:
>>> > It was intended as a debug/testing feature to allow te
On 15.05.2014 10:19, Chris Wilson wrote:
On Thu, May 15, 2014 at 11:13:01AM +0300, Jani Nikula wrote:
On Wed, 14 May 2014, Knut Petersen wrote:
On 13.05.2014 22:24, Jesse Barnes wrote:
On Tue, 13 May 2014 16:50:12 +0100
Chris Wilson wrote:
On Tue, May 13, 2014 at 04:07:37PM +0100, Chris Wi
On Mon, May 19, 2014 at 09:49:31AM -0700, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Volkin, Bradley D
> > Sent: Monday, May 19, 2014 5:41 PM
> > To: Mateo Lozano, Oscar
> > Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i9
> -Original Message-
> From: Volkin, Bradley D
> Sent: Monday, May 19, 2014 5:41 PM
> To: Mateo Lozano, Oscar
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
> s/intel_ring_buffer/intel_engine
>
> On Mon, May 19, 2014 at 09:33:37AM -0
On Mon, May 19, 2014 at 09:33:37AM -0700, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Volkin, Bradley D
> > Sent: Monday, May 19, 2014 5:24 PM
> > To: Mateo Lozano, Oscar
> > Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i9
> -Original Message-
> From: Volkin, Bradley D
> Sent: Monday, May 19, 2014 5:34 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org; Ben Widawsky; Widawsky, Benjamin
> Subject: Re: [Intel-gfx] [PATCH 02/50] drm/i915: for_each_ring
>
> On Fri, May 09, 2014 at 05:08:32AM -070
> -Original Message-
> From: Volkin, Bradley D
> Sent: Monday, May 19, 2014 5:24 PM
> To: Mateo Lozano, Oscar
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
> s/intel_ring_buffer/intel_engine
>
> On Mon, May 19, 2014 at 09:12:26AM -0
On Mon, 19 May 2014 18:13:22 +0200
Daniel Vetter wrote:
> This reverts commit f00efff326610fdba92dbc91d951790a3320052e.
>
> This is a temporary revert since I want QA to first test with the
> original testcase whether it got faster again. This is to test the
> effects of
Yeah this is fine as lo
On Mon, 19 May 2014 19:23:24 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We're using the reset domains bits for g4x on ilk. But on ilk those bits
> actually shifted by one bit. Fix it up so that we use the correct bits.
>
> We were actually always writing 0x2 to the res
On Fri, May 09, 2014 at 05:08:32AM -0700, oscar.ma...@intel.com wrote:
> From: Ben Widawsky
>
> for_each_ring() iterates over all rings supported by the hardware, not
> just those which have been initialized as in for_each_active_ring()
I think we should give this a new name; something like for_
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/gpu/drm/i915/intel_uncore.c | 6 --
> 1 file changed, 4 insertions(+), 2 dele
On Mon, 19 May 2014 19:23:22 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There are comments in the gen4-5 reset functions stating that we can't
> reset render and media without also doing a display reset. But that's
> exactly what the code does, ie. we don't perform a di
From: Ville Syrjälä
There are comments in the gen4-5 reset functions stating that we can't
reset render and media without also doing a display reset. But that's
exactly what the code does, ie. we don't perform a display reset. Drop
the bogus comments.
Signed-off-by: Ville Syrjälä
---
drivers/g
From: Ville Syrjälä
We should be waiting for the reset bit to clear, not remain set.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_uncore.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_
From: Ville Syrjälä
I was looking through the docs and spotted all kinds of nonsense in our
reset code. The ilk code was totally bonkers. g4x just missed one
workaround. The rest of gen4 looks rather wrong too, but I didn't want
to touch that yet.
Quickly tested on elk and ilk, and both seem qui
From: Ville Syrjälä
All the other bits in the GDSR register are read-only, so we don't have
to preserve them when we perform a GPU reset.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_uncore.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gp
On Mon, May 19, 2014 at 09:12:26AM -0700, Mateo Lozano, Oscar wrote:
> BTW: do you want me to kill private_default_ctx as well? It doesn´t look very
> useful...
Isn't private_default_ctx the one that's actually used when userspace
specifies DEFAULT_CONTEXT_ID?
Brad
> ___
From: Ville Syrjälä
Clear the reset domain after a succesful GPU reset on ilk. We already
do that on gen4, so let's try to be a bit more consistent. And if
ether render or media reset fails, we might use the leftover value
in the register to pinpoint the culprit.
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
Apparently we need to disable VCP unit clock gating around media reset
on g4x.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_uncore.c | 36 +++-
2 files changed, 39 insertions(+), 1
From: Ville Syrjälä
We're using the reset domains bits for g4x on ilk. But on ilk those bits
actually shifted by one bit. Fix it up so that we use the correct bits.
We were actually always writing 0x2 to the reset domain bits, which
is a reserved value. In practice it looks like the hardware ign
Hi
On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
>> On Mon, May 19, 2014 at 4:41 PM, Thomas Wood wrote:
>> > It was intended as a debug/testing feature to allow tests in
>> > intel-gpu-tools to enable or disable connectors
This reverts commit f00efff326610fdba92dbc91d951790a3320052e.
This is a temporary revert since I want QA to first test with the
original testcase whether it got faster again. This is to test the
effects of
commit 227f782e4667fc622810bce8be8ccdeee45f89c2
Author: Chris Wilson
Date: Thu May 15 10
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf O
On Mon, May 19, 2014 at 08:54:04PM +0530, Shashank Sharma wrote:
> Re-define MIPI register definitions in such a way that most of
> the existing DSI code can be re-used for future platforms. Register
> definitions are re-written using MMIO offset variable, so that without
> changing the existing se
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Tuesday, March 25, 2014 1:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hugh Dickins
> Subject: [Intel-gfx] [PATCH 3/4] drm/i915: Refactor common lock handling
>
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Tuesday, March 25, 2014 1:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hugh Dickins
> Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Invalidate our pages under
> memo
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Tuesday, March 25, 2014 1:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hugh Dickins
> Subject: [Intel-gfx] [PATCH 2/4] drm/i915: Include bound and active pages in
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Tuesday, March 25, 2014 1:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hugh Dickins
> Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Translate ENOSPC from
> shmem_get
On Mon, May 19, 2014 at 04:45:26PM +0100, Damien Lespiau wrote:
> On Mon, May 19, 2014 at 08:54:03PM +0530, Shashank Sharma wrote:
> > This patch adds a mmio base address variable for DSI display,
> > to make the DSI code generic, so that, if required, the same code
> > can be re-used for future pl
On Mon, May 19, 2014 at 04:45:26PM +0100, Damien Lespiau wrote:
> On Mon, May 19, 2014 at 08:54:03PM +0530, Shashank Sharma wrote:
> > This patch adds a mmio base address variable for DSI display,
> > to make the DSI code generic, so that, if required, the same code
> > can be re-used for future pl
On Mon, May 19, 2014 at 04:41:31PM +0100, Chris Wilson wrote:
> On Mon, May 19, 2014 at 08:35:27AM -0700, Jesse Barnes wrote:
> > On Mon, 19 May 2014 17:18:40 +0200
> > Daniel Vetter wrote:
> >
> > > On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
> > > > On Mon, 19 May 2014 16:09:3
On Mon, May 19, 2014 at 08:33:16AM -0700, Jesse Barnes wrote:
> On Mon, 19 May 2014 18:10:18 +0300
> Imre Deak wrote:
>
> > On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
> > > On Mon, 19 May 2014 11:41:18 +0300
> > > Imre Deak wrote:
> > >
> > > > So far we used the wrong opcodes to ac
On Mon, May 19, 2014 at 03:26:09PM +, Mateo Lozano, Oscar wrote:
> > I think special-casing the i915_gem_context_get function for the default
> > context and using private_default_ctx a bit more sounds good. We need to
> > adjust the idr allocator a bit though to reserve 0, and a bit of frobbin
On Mon, May 19, 2014 at 08:54:03PM +0530, Shashank Sharma wrote:
> This patch adds a mmio base address variable for DSI display,
> to make the DSI code generic, so that, if required, the same code
> can be re-used for future platforms with different mmio base.
>
> Signed-off-by: Shashank Sharma
On Mon, May 19, 2014 at 08:35:27AM -0700, Jesse Barnes wrote:
> On Mon, 19 May 2014 17:18:40 +0200
> Daniel Vetter wrote:
>
> > On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
> > > On Mon, 19 May 2014 16:09:35 +0200
> > > Daniel Vetter wrote:
> > >
> > > > We can apperently miss
On Mon, 19 May 2014 17:18:40 +0200
Daniel Vetter wrote:
> On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
> > On Mon, 19 May 2014 16:09:35 +0200
> > Daniel Vetter wrote:
> >
> > > We can apperently miss them, but breaking the entire driver hampers
> > > testing. So bail out after
On Mon, 19 May 2014 18:10:18 +0300
Imre Deak wrote:
> On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
> > On Mon, 19 May 2014 11:41:18 +0300
> > Imre Deak wrote:
> >
> > > So far we used the wrong opcodes to access the DSI registers, so the
> > > register writes during DSI programming di
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Monday, May 19, 2014 4:12 PM
> To: Mateo Lozano, Oscar
> Cc: Daniel Vetter; Lespiau, Damien; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
> s/i
Re-define MIPI register definitions in such a way that most of
the existing DSI code can be re-used for future platforms. Register
definitions are re-written using MMIO offset variable, so that without
changing the existing sequence, same code can be generically applied.
Signed-off-by: Shashank Sh
This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future platforms with different mmio base.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/i915_
This patchset contains 2 patches, which slightly change the DSI register
definitions in such a way, that the same definition can be used for future
platforms also.
1. drm/i915: Add MIPI mmio reg base
This patch adds a variable mipi_mmio_base in dev_private, and initializes
it for VLV. The
On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
> On Mon, 19 May 2014 16:09:35 +0200
> Daniel Vetter wrote:
>
> > We can apperently miss them, but breaking the entire driver hampers
> > testing. So bail out after one minute, our customerary "this is a lost
> > cause" timeout.
> >
>
On Mon, May 19, 2014 at 03:57:36PM +0100, Thomas Wood wrote:
> On 19 May 2014 15:28, Daniel Vetter wrote:
> > On Mon, May 19, 2014 at 02:42:07PM +0100, Thomas Wood wrote:
> >> Add a function to force a particular state on a connector and a
> >> convenience function to find and set the state on the
On Tue, 13 May 2014 10:41:58 +0300
Jani Nikula wrote:
> On Thu, 08 May 2014, Ben Widawsky wrote:
> > 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
On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
> On Mon, 19 May 2014 11:41:18 +0300
> Imre Deak wrote:
>
> > So far we used the wrong opcodes to access the DSI registers, so the
> > register writes during DSI programming didn't actually succeed and left
> > the registers unchanged. This w
On Mon, May 19, 2014 at 02:43:05PM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > Daniel Vetter
> > Sent: Monday, May 19, 2014 2:53 PM
> > To: Mateo Lozano, Oscar
> > Cc: Lespiau, Damien; intel-gfx@l
On Mon, 2014-05-19 at 08:03 -0700, Jesse Barnes wrote:
> On Mon, 19 May 2014 16:48:31 +0300
> Imre Deak wrote:
>
> > These opcodes are not specific for an endpoint, but are the same for all
> > endpoints. So rename them accordingly, using the name the VLV2 sideband
> > HAS uses. Also move the mac
On Mon, 19 May 2014 16:09:35 +0200
Daniel Vetter wrote:
> We can apperently miss them, but breaking the entire driver hampers
> testing. So bail out after one minute, our customerary "this is a lost
> cause" timeout.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=78383
> Signed-off
On Mon, 19 May 2014 16:48:31 +0300
Imre Deak wrote:
> These opcodes are not specific for an endpoint, but are the same for all
> endpoints. So rename them accordingly, using the name the VLV2 sideband
> HAS uses. Also move the macros to the .c file, since they aren't used
> anywhere else.
>
> Si
On Mon, 19 May 2014 11:41:18 +0300
Imre Deak wrote:
> So far we used the wrong opcodes to access the DSI registers, so the
> register writes during DSI programming didn't actually succeed and left
> the registers unchanged. This wasn't a problem for the initial modeset,
> where the BIOS-programme
On Mon, 19 May 2014 11:41:17 +0300
Imre Deak wrote:
> These opcodes are not specific for an endpoint, but are the same for all
> endpoints. So rename them accordingly, using the name the VLV2 sideband
> HAS uses. Also move the macros to the .c file, since they aren't used
> anywhere else.
>
> Si
On 19 May 2014 15:28, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 02:42:07PM +0100, Thomas Wood wrote:
>> Add a function to force a particular state on a connector and a
>> convenience function to find and set the state on the VGA connector.
>>
>> Signed-off-by: Thomas Wood
>> ---
>> lib/igt_
On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
> Hi
>
> On Mon, May 19, 2014 at 4:41 PM, Thomas Wood wrote:
> > On 19 May 2014 15:13, David Herrmann wrote:
> >> Hi
> >>
> >> On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
> >>> Signed-off-by: Thomas Wood
> >>
> >> The comm
On Mon, May 19, 2014 at 04:29:57PM +0200, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 05:19:09PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On pre-HSW we have two encoders per digital port: one HDMI, one DP.
> > However they are the same physical port in hardwa
Hi
On Mon, May 19, 2014 at 4:41 PM, Thomas Wood wrote:
> On 19 May 2014 15:13, David Herrmann wrote:
>> Hi
>>
>> On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
>>> Signed-off-by: Thomas Wood
>>
>> The commit-msg lacks any discussion why this change is done. What is
>> the reason to do tha
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Monday, May 19, 2014 2:53 PM
> To: Mateo Lozano, Oscar
> Cc: Lespiau, Damien; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
> s/intel
On 19 May 2014 15:13, David Herrmann wrote:
> Hi
>
> On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
>> Signed-off-by: Thomas Wood
>
> The commit-msg lacks any discussion why this change is done. What is
> the reason to do that? Isn't the kernel-command-line enough? Why is
> this a regular f
On Mon, May 19, 2014 at 02:42:07PM +0100, Thomas Wood wrote:
> Add a function to force a particular state on a connector and a
> convenience function to find and set the state on the VGA connector.
>
> Signed-off-by: Thomas Wood
> ---
> lib/igt_kms.c | 78 ++
On Mon, May 19, 2014 at 05:19:09PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On pre-HSW we have two encoders per digital port: one HDMI, one DP.
> However they are the same physical port in hardware and we can't enable
> both at the same time. Reject the modeset if the
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*10^6 [f in Mhz] -> 10^3/f(Mhz)
ui(ns) = 10^9/(f*10^6)
From: Ville Syrjälä
On pre-HSW we have two encoders per digital port: one HDMI, one DP.
However they are the same physical port in hardware and we can't enable
both at the same time. Reject the modeset if the user attempts this.
So far we've been saved by the fact that we never see both HDMI and
Hi
On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
The commit-msg lacks any discussion why this change is done. What is
the reason to do that? Isn't the kernel-command-line enough? Why is
this a regular feature instead of a debugfs attribute?
> ---
> drivers/g
We can apperently miss them, but breaking the entire driver hampers
testing. So bail out after one minute, our customerary "this is a lost
cause" timeout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=78383
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 5 +++-
On Mon, May 19, 2014 at 3:41 PM, Mateo Lozano, Oscar
wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h index 108e1ec2fa4b..e34db43dead3
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1825,7 +1825,9 @@ str
Signed-off-by: Imre Deak
---
lib/intel_io.h | 2 ++
lib/intel_iosf.c | 14 ++
tools/quick_dump/chipset.i | 2 ++
tools/quick_dump/quick_dump.py | 2 ++
tools/quick_dump/reg_access.py | 6 ++
tools/quick_dump/valleyview | 1 +
t
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: Imre Deak
---
lib/intel_iosf.c | 24 +++
Add a function to force a particular state on a connector and a
convenience function to find and set the state on the VGA connector.
Signed-off-by: Thomas Wood
---
lib/igt_kms.c | 78
lib/igt_kms.h | 12 +++
tests/Makefile.
This series makes use of:
http://lists.freedesktop.org/archives/intel-gfx/2014-May/045553.html
to allow tests to enable or disable connectors as required.
Thomas Wood (2):
lib: add functions to change connector states
tests: enable the VGA connector in the kms flip and pipe crc tests
lib/i
Signed-off-by: Thomas Wood
---
tests/kms_flip.c | 7 +++
tests/kms_pipe_crc_basic.c | 5 +
2 files changed, 12 insertions(+)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index f2ec9ef..7d6e102 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1566,6 +1566,8 @@ int ma
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Monday, May 19, 2014 1:21 PM
> To: Mateo Lozano, Oscar
> Cc: Daniel Vetter; Lespiau, Damien; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
> s/i
On Mon, May 19, 2014 at 3:06 PM, Ville Syrjälä
wrote:
>> So why can't we just latch a work item which uses all the established
>> seqno waiting stuff and so avoids all these issues
>
> I hate blocking and waiting for stuff. It usually means all kinds of lock
> dropping tricks, and extra hurdles if
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_sysfs.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index c22c309..257816e 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu
On Mon, May 19, 2014 at 02:29:09PM +0200, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 02:47:20PM +0300, Ville Syrjälä wrote:
> > On Mon, May 19, 2014 at 04:28:58PM +0530, sourab.gu...@intel.com wrote:
> > > From: Sourab Gupta
> > >
> > > Using MMIO based flips on Gen5+ for Media power well res
On Mon, May 19, 2014 at 01:45:37PM +0200, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 05:00:14PM +0530, Vandana Kannan wrote:
> > Please let me know your inputs on this..
> > Given that making changes to avoid DRRS related checks in
> > pipe_config_compare affects the overall design and future
>
On Mon, May 19, 2014 at 02:47:20PM +0300, Ville Syrjälä wrote:
> On Mon, May 19, 2014 at 04:28:58PM +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 fo
On Mon, May 19, 2014 at 10:02:07AM +, Mateo Lozano, Oscar wrote:
> Hi Daniel,
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Thursday, May 15, 2014 9:52 PM
> > To: Mateo Lozano, Oscar
> > Cc: Lespiau, Damien; D
On Mon, May 19, 2014 at 04:28:58PM +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 command streamer based
> flip calls. For pure 3D workloads, with MMIO f
Hello!
I'm developing some openCL application with Beignet in Ubuntu 14.04 x64
Desktop upon Bay Trail E3825.
And I found that reading data from GPU memory through whatever drm_intel
gem_bo_map or drm_intel_gem_bo_get subdata cost about 0.002 ~ 0.003 second to
fetch a 7MiB array, whic
Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: Robin Schroer
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm
On Mon, May 19, 2014 at 4:19 PM, Ville Syrjälä
wrote:
> On Mon, May 19, 2014 at 04:08:09PM +0530, Arun Murthy wrote:
>> > Add a mechanism by which we can evade the leading edge of vblank. This
>> > guarantees that no two sprite register writes will straddle on either
>> > side of the vblank start,
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
Here only one sprite update followed by the primar
1 - 100 of 121 matches
Mail list logo
