On 4/8/2015 10:02 AM, Paulo Zanoni wrote:
2015-03-31 14:15 GMT-03:00 Todd Previte :
Updates the EDID compliance test function to perform the EDID read as
required by the tests. This read needs to take place in the kernel for
reasons of speed and efficiency. The results of the EDID read operati
On 4/8/2015 11:53 AM, Paulo Zanoni wrote:
2015-04-01 15:00 GMT-03:00 Todd Previte :
Update the hot plug function to handle the SST case. Instead of placing
the SST case within the long/short pulse block, it is now handled after
determining that MST mode is not in use. This way, the topology ma
On 04/09/2015 01:20 PM, Ville Syrjälä wrote:
On Thu, Apr 09, 2015 at 10:17:05AM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Latest version of the "CHV DPIO programming notes" no longer requires writes
to TX DW 11 to fix a +2UI interpair skew issue. The current code from
April 2
From: Clint Taylor
Latest version of the "CHV DPIO programming notes" no longer requires writes
to TX DW 11 to fix a +2UI interpair skew issue. The current code from
April 2014 was actually causing additional skew issues between all
TMDS pairs.
ver2: added same treatment to intel_dp.c based on V
On Thu, Apr 09, 2015 at 10:17:05AM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Latest version of the "CHV DPIO programming notes" no longer requires writes
> to TX DW 11 to fix a +2UI interpair skew issue. The current code from
> April 2014 was actually causing additional sk
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6138
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Fixed the commit message. That will be in V5 of the patch set to be
posted today.
On 4/7/2015 6:57 AM, Paulo Zanoni wrote:
2015-04-06 23:09 GMT-03:00 Todd Previte :
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that repeated AUX transactions after a failure
I've put this patchset on top of current Linus git. Switching to fbcon
tends to result in rolling graphics, and turning the screen back on
often gives me a static display or one that only updates every few
seconds. This is with a Dell XPS 13 with Broadwell-U and a 3200x1800
display.
--
Matthe
On Thu, Apr 09, 2015 at 02:46:19PM +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2015 at 06:56:53PM -0700, Matt Roper wrote:
> > Switch from our plane update/disable entrypoints to use the full atomic
> > helpers (which generate a top-level atomic transaction) rather than the
> > transitional helpe
Once we have full atomic modeset, these kind of flags should be in a
real intel_crtc_state that's tracked properly. In the meantime, make
sure we clear out any old flags at the beginning of a transaction so
that we don't wind up seeing leftover flags from old transactions that
were checked, but ne
From: Clint Taylor
Latest version of the "CHV DPIO programming notes" no longer requires writes
to TX DW 11 to fix a +2UI interpair skew issue. The current code from
April 2014 was actually causing additional skew issues between all
TMDS pairs.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i
Hi Sivakumar,
On Tue, 2015-03-24 at 14:49 +0530, Sivakumar Thulasimani wrote:
> On 3/17/2015 3:10 PM, Imre Deak wrote:
>
> > From: Vandana Kannan
> >
> > VSwing programming sequence as specified in the updated BXT BSpec
> > ...
> > ...
> >
> > +void bxt_ddi_vswing_sequence(struct drm_device
On Thu, Apr 09, 2015 at 04:44:16PM +0200, Daniel Vetter wrote:
> It's not needed since the worker rechecks that it didn't race. We only
> need to cancel synchronously after disabling drrs to make sure the
> worker really is gone (e.g. for driver unload). But for normal
> operation the stall is just
On Thu, Apr 09, 2015 at 04:44:15PM +0200, Daniel Vetter wrote:
> We must acquire the mutex before we can check drrs.dp, otherwise
> someone might sneak in with a modeset, clear the pointer after we've
> checked it and then the code will Oops.
>
> This issue has been introduced in
>
> commit a93fa
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6131
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Cc: Joonas Lahtinen
Signed-off-by: Thomas Wood
---
tests/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 11f7f96..d5fb4fd 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -5,8 +5,6 @@ if HAVE_NOUVEAU
endif
All tests now respond in a consistent way such that separate lists for
tests with and without subtests are no longer necessary.
v2: fix other references to the test list
Signed-off-by: Thomas Wood
---
docs/reference/intel-gpu-tools/Makefile.am | 2 +-
lib/tests/igt_command_line.sh
On 9 April 2015 at 07:45, Joonas Lahtinen
wrote:
> On ke, 2015-04-08 at 14:56 +0100, Thomas Wood wrote:
>> Use the pkglibexec and pkgdata prefixes rather than setting bindir and
>> datadir. This also removes the extra 'tests' directory from within the
>> package libexec and data directories.
>>
>>
On Thu, Apr 09, 2015 at 08:03:35AM -0700, Matt Roper wrote:
> On Thu, Apr 09, 2015 at 02:48:43PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 08, 2015 at 06:56:54PM -0700, Matt Roper wrote:
> > > Once we have full atomic modeset, these kind of flags should be in a
> > > real intel_crtc_state that's
On Thu, Apr 09, 2015 at 04:24:53PM +0100, Chris Wilson wrote:
> On Thu, Apr 09, 2015 at 05:02:36PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 07, 2015 at 04:20:51PM +0100, Chris Wilson wrote:
> > > @@ -640,7 +641,7 @@ static int logical_ring_wait_request(struct
> > > intel_ringbuffer *ringbuf,
>
On Thu, Apr 09, 2015 at 05:02:36PM +0200, Daniel Vetter wrote:
> On Tue, Apr 07, 2015 at 04:20:51PM +0100, Chris Wilson wrote:
> > @@ -640,7 +641,7 @@ static int logical_ring_wait_request(struct
> > intel_ringbuffer *ringbuf,
> > break;
> > }
> >
> > - if (&request->lis
At Thu, 9 Apr 2015 15:51:27 +0200,
Daniel Vetter wrote:
>
> On Thu, Apr 09, 2015 at 04:41:26PM +0300, Mika Kahola wrote:
> > On Thu, 2015-04-09 at 11:32 +0200, Daniel Vetter wrote:
> > > On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
> > > > I did some testing on audio part with HDMI
On Thu, Apr 09, 2015 at 02:48:43PM +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2015 at 06:56:54PM -0700, Matt Roper wrote:
> > Once we have full atomic modeset, these kind of flags should be in a
> > real intel_crtc_state that's tracked properly. In the meantime, make
> > sure we clear out any o
On Tue, Apr 07, 2015 at 04:20:51PM +0100, Chris Wilson wrote:
> @@ -640,7 +641,7 @@ static int logical_ring_wait_request(struct
> intel_ringbuffer *ringbuf,
> break;
> }
>
> - if (&request->list == &ring->request_list)
> + if (WARN_ON(&request->list == &ring->
On Thu, Apr 09, 2015 at 05:46:30PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 09, 2015 at 07:10:57AM -0700, Matt Roper wrote:
> > On Thu, Apr 09, 2015 at 04:18:56PM +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
> > > > Our atomic plane code currently u
On Thu, Apr 09, 2015 at 04:45:04PM +0200, Daniel Vetter wrote:
> On Thu, Apr 09, 2015 at 07:00:31AM -0700, Matt Roper wrote:
> > On Thu, Apr 09, 2015 at 02:42:36PM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
> > > > Our atomic plane code currently u
On Thu, Apr 09, 2015 at 07:10:57AM -0700, Matt Roper wrote:
> On Thu, Apr 09, 2015 at 04:18:56PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
> > > Our atomic plane code currently uses intel_crtc->active to determine
> > > how/when to update some deriv
It's not needed since the worker rechecks that it didn't race. We only
need to cancel synchronously after disabling drrs to make sure the
worker really is gone (e.g. for driver unload). But for normal
operation the stall is just wasted time.
Reported-by: Chris Wilson
Cc: Chris Wilson
Cc: Ville S
We must acquire the mutex before we can check drrs.dp, otherwise
someone might sneak in with a modeset, clear the pointer after we've
checked it and then the code will Oops.
This issue has been introduced in
commit a93fad0f7fb8a3ff12e8814b630648f6d187954c
Author: Vandana Kannan
Date: Sat Jan 1
On Thu, Apr 09, 2015 at 07:00:31AM -0700, Matt Roper wrote:
> On Thu, Apr 09, 2015 at 02:42:36PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
> > > Our atomic plane code currently uses intel_crtc->active to determine
> > > how/when to update some deriv
On Thu, Apr 09, 2015 at 02:44:05PM +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2015 at 06:56:52PM -0700, Matt Roper wrote:
> > Various places in the atomic plane code obtain the CRTC via
> > plane_state->crtc. But plane_state->crtc is NULL when disabling the
> > plane, so the code will fall back
From: Thierry Reding
Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.
Cc: Rob Clark
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/msm_gem.c | 9 +
2
From: Thierry Reding
Add implementations for drm_clflush_*() on 64-bit ARM. This shares a lot
of code with the 32-bit ARM implementation.
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_cache.c | 15 +--
1 file changed, 13 insertions(+),
From: Thierry Reding
Add implementations for drm_clflush_*() on ARM by borrowing code from
the DMA mapping API implementation. Unfortunately ARM doesn't export an
API to flush caches on a page by page basis, so this replicates most of
the code.
Reviewed-by: Rob Clark
Tested-by: Rob Clark
Signe
From: Thierry Reding
Irrespective of whether or not the DRM core is built as a module, build
the cache flush functions into the kernel. This is required because the
implementation may require functions that shouldn't be exported to most
drivers. DRM is somewhat of a special case here because it r
From: Thierry Reding
Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.
Cc: Russell King
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/Kconfig | 1 +
drivers/gpu/drm/armada/armada_gem.c |
From: Thierry Reding
Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/gem.c | 42 +++---
On Thu, Apr 09, 2015 at 04:18:56PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
> > Our atomic plane code currently uses intel_crtc->active to determine
> > how/when to update some derived state values. This works fine for pure
> > plane updates at the
On Thu, 09 Apr 2015, Lampersperger Andreas
wrote:
> Hello Gajanan,
>
> I'm trying to run linux on a
> valleyview hardware, which was made by my company.
>
> On this hardware, the display panel is connected via
> eDP, but the panel timings / resolution is not available
> in the EDID of the eDP
On Thu, Apr 09, 2015 at 02:42:36PM +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
> > Our atomic plane code currently uses intel_crtc->active to determine
> > how/when to update some derived state values. This works fine for pure
> > plane updates at the
On Thu, Apr 09, 2015 at 04:26:19PM +0300, Imre Deak wrote:
> On Fri, 2015-04-03 at 18:13 -0700, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > Modify the Gen9 SSEU info initialization logic to support
> > Broxton. Broxton reuses the SKL fuse registers but has at most
> > 1 slice and 6 E
On Thu, Apr 09, 2015 at 04:41:26PM +0300, Mika Kahola wrote:
> On Thu, 2015-04-09 at 11:32 +0200, Daniel Vetter wrote:
> > On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
> > > I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
> > > connected to my Haswell box. Before
On Thu, Apr 09, 2015 at 09:17:33PM +0800, liu,lei wrote:
> From: "liu,lei"
>
> Debugfs i915_fbc_status shows "FBC unsupported on this chipset"
> not "unsupported by this chipset" if the platform doesn't support
> FBC feature. That typo will cause case fail on some platforms such
> as byt, bsw.
>
On Thu, 2015-04-09 at 11:32 +0200, Daniel Vetter wrote:
> On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
> > I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
> > connected to my Haswell box. Before applying the patch I tested as a
> > reference with the latest -night
I resend that patch. Forgive me that I forgot to add you in cc list. Pardon my
original disordered commit message.
Really appreciate your guidance.
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Thursday, April 09, 2015 8:24 PM
To:
On Fri, 2015-04-03 at 18:13 -0700, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Modify the Gen9 SSEU info initialization logic to support
> Broxton. Broxton reuses the SKL fuse registers but has at most
> 1 slice and 6 EU per subslice.
>
> Signed-off-by: Jeff McGee
> ---
> drivers/gpu/dr
On Thu, Apr 09, 2015 at 06:24:01AM -0700, shuang...@intel.com wrote:
> Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> Task id: 6129
> -Summary-
> Platform Delta
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6129
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1
On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
> Our atomic plane code currently uses intel_crtc->active to determine
> how/when to update some derived state values. This works fine for pure
> plane updates at the moment since the CRTC state itself isn't changed as
> part of the opera
From: "liu,lei"
Debugfs i915_fbc_status shows "FBC unsupported on this chipset"
not "unsupported by this chipset" if the platform doesn't support
FBC feature. That typo will cause case fail on some platforms such
as byt, bsw.
Signed-off-by: Lei Liu
---
tests/kms_fbc_crc.c | 2 +-
1 file change
Hello Gajanan,
I'm trying to run linux on a
valleyview hardware, which was made by my company.
On this hardware, the display panel is connected via
eDP, but the panel timings / resolution is not available
in the EDID of the eDP. It is only available via VBT.
You added once eDP support to VL
On Wed, Apr 08, 2015 at 06:56:54PM -0700, Matt Roper wrote:
> Once we have full atomic modeset, these kind of flags should be in a
> real intel_crtc_state that's tracked properly. In the meantime, make
> sure we clear out any old flags at the beginning of a transaction so
> that we don't wind up s
On Wed, Apr 08, 2015 at 06:56:53PM -0700, Matt Roper wrote:
> Switch from our plane update/disable entrypoints to use the full atomic
> helpers (which generate a top-level atomic transaction) rather than the
> transitional helpers (which only create/manipulate orphaned plane states
> independent of
On Wed, Apr 08, 2015 at 06:56:52PM -0700, Matt Roper wrote:
> Various places in the atomic plane code obtain the CRTC via
> plane_state->crtc. But plane_state->crtc is NULL when disabling the
> plane, so the code will fall back to looking at the old CRTC value in
> plane->crtc in that case. This
On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
> Our atomic plane code currently uses intel_crtc->active to determine
> how/when to update some derived state values. This works fine for pure
> plane updates at the moment since the CRTC state itself isn't changed as
> part of the opera
On Thu, Apr 09, 2015 at 12:52:19PM +0300, Jani Nikula wrote:
> On Thu, 09 Apr 2015, Daniel Vetter wrote:
> > We must acquire the mutex before we can check drrs.dp, otherwise
> > someone might sneak in with a modeset, clear the pointer after we've
> > checked it and then the code will Oops.
> >
> >
On Thu, Apr 09, 2015 at 11:56:36AM +0100, Damien Lespiau wrote:
> On Thu, Apr 09, 2015 at 01:37:10PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 09, 2015 at 09:49:25AM +0100, Damien Lespiau wrote:
> > > On Wed, Mar 25, 2015 at 06:45:58PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > +s
On Thu, Apr 09, 2015 at 12:14:29PM +0100, Thomas Wood wrote:
> Use a failure status code for timeout to avoid confusion between tests
> that take too long to execute versus a failure due to an operation
> taking longer than expected.
>
> Signed-off-by: Thomas Wood
> ---
> lib/igt_core.c | 6 +++-
On Thu, Apr 09, 2015 at 01:51:24PM +0800, liu,lei wrote:
> From: "liu,lei"
In igt we follow the kernel conventions for patch commit messages:
- First line (subject) summarizes the patch in at most 70 chars
- After an empty line comes the extended commit message (you have that in
the first line
On Thu, Apr 09, 2015 at 09:45:13AM +0300, Joonas Lahtinen wrote:
> On ke, 2015-04-08 at 14:56 +0100, Thomas Wood wrote:
> > Use the pkglibexec and pkgdata prefixes rather than setting bindir and
> > datadir. This also removes the extra 'tests' directory from within the
> > package libexec and data
On Thu, Apr 09, 2015 at 10:14:49AM +0300, Mika Kuoppala wrote:
> Michel Thierry writes:
>
> > These are the last remining patches to enable dynamic allocation in gen8+.
> > All credit to Ben's original design and Mika's extensive reviews.
> >
> > During stress testing, the light restore context c
On Wed, Apr 08, 2015 at 12:13:26PM +0100, Michel Thierry wrote:
> +static inline uint32_t gen8_pml4e_index(uint64_t address)
> +{
> + BUG(); /* For 64B */
Please never use BUG where a WARN would do too. Fixed while applying.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http:/
Use a failure status code for timeout to avoid confusion between tests
that take too long to execute versus a failure due to an operation
taking longer than expected.
Signed-off-by: Thomas Wood
---
lib/igt_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/igt_c
Signed-off-by: Thomas Wood
---
lib/igt.cocci | 2 +-
lib/igt_core.c | 6 +++---
lib/igt_core.h | 18 --
lib/intel_batchbuffer.c| 2 +-
tests/gem_ring_sync_copy.c | 2 +-
tests/kms_sink_crc_basic.c | 2 +-
6 files changed, 19 insertions
On Wed, 2015-04-01 at 10:58 +0300, Jani Nikula wrote:
> For BXT gmbus is pulled from PCH to CPU. From implementation point of
> view only pin pair configuration will change. The existing
> implementation supports all platforms previous to GEN8 and also SKL. But
> for BXT pin pair configuration is c
On Thu, Apr 09, 2015 at 01:37:10PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 09, 2015 at 09:49:25AM +0100, Damien Lespiau wrote:
> > On Wed, Mar 25, 2015 at 06:45:58PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > +static union child_device_config *
> > > +child_device_ptr(struct bdb_gener
On Wed, Apr 08, 2015 at 01:57:35PM +0200, Olivier Fourdan wrote:
> When using Xinerama, RandR is automatically disabled, and calling RR
> routines will trigger an assert() because the RR keys/resources are
> not set, leading to an Xserver abort.
>
> Hotplug makes little sense without RandR, so no
On Thu, Apr 09, 2015 at 09:49:25AM +0100, Damien Lespiau wrote:
> On Wed, Mar 25, 2015 at 06:45:58PM +0200, ville.syrj...@linux.intel.com wrote:
> > +static union child_device_config *
> > +child_device_ptr(struct bdb_general_definitions *p_defs, int i)
> > +{
> > + return (void *) &p_defs->devic
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6110
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Thu, 09 Apr 2015, Daniel Vetter wrote:
> We must acquire the mutex before we can check drrs.dp, otherwise
> someone might sneak in with a modeset, clear the pointer after we've
> checked it and then the code will Oops.
>
> This issue has been introduced in
>
> commit a93fad0f7fb8a3ff12e8814b630
On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
> I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
> connected to my Haswell box. Before applying the patch I tested as a
> reference with the latest -nightly (04-08-2015), 4.0-rc7. Unfortunately,
> I failed to get any a
On Thu, Apr 09, 2015 at 01:04:28AM +, He, Shuang wrote:
> > -Original Message-
> > From: He, Shuang
> > Sent: Wednesday, April 8, 2015 4:16 PM
> > To: Daniel Vetter
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: RE: [Intel-gfx] [PATCH] tests: Fix duplicate 'kms_flip_event_leak'
>
We must acquire the mutex before we can check drrs.dp, otherwise
someone might sneak in with a modeset, clear the pointer after we've
checked it and then the code will Oops.
This issue has been introduced in
commit a93fad0f7fb8a3ff12e8814b630648f6d187954c
Author: Vandana Kannan
Date: Sat Jan 1
On Wed, Mar 25, 2015 at 06:45:58PM +0200, ville.syrj...@linux.intel.com wrote:
> +static union child_device_config *
> +child_device_ptr(struct bdb_general_definitions *p_defs, int i)
> +{
> + return (void *) &p_defs->devices[i * p_defs->child_dev_size];
> +}
Actually this looks wrong. We're d
On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
> Hi Joonas,
>
> since you were looking at extending the GTT fault capabilities, I
> thought you might like to revivew these patches, as they may prove
> beneficial for your use case as well.
Did so, sent a couple cosmical comments.
Regards
On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
> In preparation for exporting very similar functionality through another
> interface, gut the current remap_pfn_range(). The motivating factor here
> is to reuse the PGB/PUD/PMD/PTE walker, but allow back progation of
> errors rather than BUG_O
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6105
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
> This is similar to remap_pfn_range(), and uses the recently refactor
> code to do the page table walking. The key difference is that is back
> propagates its error as this is required for use from within a pagefault
> handler. The other differ
Connector states were being allocated in intel_setup_outputs() in a loop
over all connectors. That meant hot-added connectors would have a NULL
state. Since the change to use a struct drm_atomic_state for the legacy
modeset, connector states are necessary for the i915 driver to function
properly, s
On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
> On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
> Upload rate for 2 linear surfaces: 8134MiB/s -> 8154MiB/s
> Upload rate for 2 tiled surfaces: 8625MiB/s -> 8632MiB/s
> Upload rate for 4 linear surfaces: 8127MiB/s -> 8134MiB/s
On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
> Currently, we only allocate a structure to hold metadata if we need to
> allocate an ioremap for every access, such as on x86-32. However, it
> would be useful to store basic information about the io-mapping, such as
> its page protection, on
Hi,
On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
> In i915, we have a big mutex around our device struct - every time before
> we attempt to communicate with the GPU, we acquire the mutex. This makes
> it a convenient juncture to place our GPU error handling - before we take
> the mutex w
I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
connected to my Haswell box. Before applying the patch I tested as a
reference with the latest -nightly (04-08-2015), 4.0-rc7. Unfortunately,
I failed to get any audio over HDMI cable. For a reference I tested with
the very same set
Michel Thierry writes:
> These are the last remining patches to enable dynamic allocation in gen8+.
> All credit to Ben's original design and Mika's extensive reviews.
>
> During stress testing, the light restore context corruption problem was
> observed in some systems (resubmission with HEAD==T
84 matches
Mail list logo
