On Fri, Jan 29, 2016 at 02:52:29PM +0200, Imre Deak wrote:
> Caught by Coverity.
>
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_tv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.
On Fri, Jan 29, 2016 at 02:52:28PM +0200, Imre Deak wrote:
> While not being able to enable MSI interrupts may be a normal
> circumstance, for debugging it may still be a useful information, so
> emit an info about this.
>
> Caught by Coverity.
>
> Signed-off-by: Imre Deak
On Fri, Jan 29, 2016 at 02:52:27PM +0200, Imre Deak wrote:
> Atm we wouldn't catch these errors or on the error path we would end up
> with a division-by-zero, fix this up.
>
> Caught by Coverity.
>
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
> -
's
> or the kernel's documentation of the function and can't imagine what it
> would do with the NULL ptr. To better document this use of the
> parameters it still make sense to add an explicit check for this to the
> code.
>
> Caught by Coverity.
>
&
resources with no or little dependencies on
> other device specific resources towards the beginning of the init
> sequence.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
___
Intel-gfx mailing
earlier in an upcoming patch, so this is also a preparation for that.
>
> Factor out the init/clean-up code to separate functions to make things
> clearer in the i915_driver_load()/unload() functions.
>
> Suggested-by: Chris Wilson
> Signed-off-by:
Also factor out things to separate init/cleanup functions to make
> i915_driver_load()/unload() clearer, atm it's somewhat difficult to
> follow there in what order resources are inited/cleaned-up.
>
> Suggested-by: Chris Wilson
> Signed-off
ned-off-by: Imre Deak
Reviewed-by: David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
nker and OOM registration calls.
>
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jan 19, 2016 at 03:26:27PM +0200, Imre Deak wrote:
> Clarify the name of the label on the error path, making it clear what's
> being cleaned up. The kmem_cache_destroy() calls are NOPs on the
> corresponding error path.
>
> Signed-off-by: Imre Deak
Reviewed
during driver loading, but didn't
> move the cleanup earlier correspondingly during unloading. Fix this up.
>
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lis
save the previous settings,
to allow for resetting the values after we've finished testing.
Signed-off-by: David Weinehall
---
.../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 +
lib/Makefile.sources | 2 +
lib/igt.h
this lib would probably make sense too.
v2: Change name of library to igt_pm
Namespace all exported functions with igt_pm_
v3: Various fixes based on feedback from Thomas Wood
David Weinehall (1):
lib/igt_pm: Lib for power management
.../intel-gpu-tools/intel-gpu-tools-docs.xml | 1
_autosuspend(device);
> + } else {
> + pm_runtime_use_autosuspend(device);
> + }
>
> /*
>* The core calls the driver load handler with an RPM reference held.
Reviewed-by: David Weinehall
Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
save the previous settings,
to allow for resetting the values after we've finished testing.
Signed-off-by: David Weinehall
---
lib/Makefile.sources | 2 +
lib/igt.h| 1 +
lib/igt_aux.c| 15 +---
lib/igt_pm.c | 233 ++
this lib would probably make sense too.
v2: Change name of library to igt_pm
Namespace all exported functions with igt_pm_
David Weinehall (1):
lib/igt_pm: Lib for power management
lib/Makefile.sources | 2 +
lib/igt.h| 1 +
lib/igt_aux.c| 15 +---
lib/igt_pm.c
On Tue, Dec 08, 2015 at 01:22:14PM +, Zanoni, Paulo R wrote:
> Em Ter, 2015-12-08 às 10:50 +0200, David Weinehall escreveu:
> > Since the defaults for some external power management related
> > settings
> > prevents us from testing our power management functionality pro
On Tue, Dec 08, 2015 at 03:42:27PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 08, 2015 at 10:50:39AM +0200, David Weinehall wrote:
> > Since the defaults for some external power management related settings
> > prevents us from testing our power management functionality properly,
>
On Thu, Dec 10, 2015 at 11:09:42AM +0100, Daniel Vetter wrote:
> On Tue, Dec 08, 2015 at 05:05:12PM -0200, Paulo Zanoni wrote:
> > 2015-12-08 11:42 GMT-02:00 Ville Syrjälä :
> > > On Tue, Dec 08, 2015 at 10:50:39AM +0200, David Weinehall wrote:
> > >> Since the de
power management it might be better to
choose a different name for the library.
David Weinehall (1):
lib/pm_workarounds: Lib for PM workarounds
lib/Makefile.sources | 2 +
lib/igt.h| 1 +
lib/igt_aux.c| 15 +---
lib/pm_workarounds.c
allow for resetting the values after
we've finished testing.
Signed-off-by: David Weinehall
---
lib/Makefile.sources | 2 +
lib/igt.h| 1 +
lib/igt_aux.c| 15 +---
lib/pm_workarounds.c | 233 +++
lib/pm_workaroun
On Tue, Nov 17, 2015 at 01:49:06PM -0200, Paulo Zanoni wrote:
> 2015-11-17 13:34 GMT-02:00 Daniel Vetter :
[snip]
> > I thought the hidden tests in kms_frontbuffer_tracking would be useful,
> > just really slow, but seems I'm mistaken. In general we have a bunch of
> > stress tests which we want to
On Fri, Oct 30, 2015 at 01:52:48PM +, Chris Wilson wrote:
> On Fri, Oct 30, 2015 at 03:18:30PM +0200, David Weinehall wrote:
> > @@ -931,16 +930,20 @@ run_basic_modes(const struct access_mode *mode,
> > struct buffers buffers;
> >
> > f
t_subtest_flags() / ugt_subtest_flags_f() functions and
pass the subtest types as part of the flags parameter.
v2: Incorporate various suggestions from reviewers.
v3: Rewrite to provide a generic mechanism for categorising
the subtests
David Weinehall (3):
Copy gem_concurrent_all to gem_concurre
runs/lists all
subtests instead of just the default set.
Signed-off-by: David Weinehall
---
lib/igt_core.c | 43 ++--
lib/igt_core.h | 42
tests/gem_concurrent_blit.c | 50 +-
tests/kms_frontbuffer_tracki
When gem_concurrent_blit was converted to use the new common framework
for choosing whether or not to include slow/combinatorial tests,
gem_concurrent_all became superfluous. This patch removes it.
Signed-off-by: David Weinehall
---
tests/.gitignore |1 -
tests/Makefile.sources
We'll both rename gem_concurrent_all over gem_concurrent_blit
and change gem_concurrent_blit in this changeset. To make
this easier to follow we first do the the rename.
Signed-off-by: David Weinehall
---
tests/gem_concurrent_blit.c | 1116 ++-
1
On Wed, Oct 28, 2015 at 02:12:15PM -0200, Paulo Zanoni wrote:
> 2015-10-28 9:29 GMT-02:00 David Weinehall :
> > Some tests should not be run by default, due to their slow,
> > and sometimes superfluous, nature.
> >
> > We still want to be able to run these tests i
On Wed, Oct 28, 2015 at 05:14:28PM +, Thomas Wood wrote:
> If this is intended to be documented and used in tests, then it should
> be included in the public API (i.e. without the underscore prefix).
True. Will fix.
> > + *
> > + * This is used to skip subtests that should only be included
>
When gem_concurrent_blit was converted to use the new common framework
for choosing whether or not to include slow/combinatorial tests,
gem_concurrent_all became superfluous. This patch removes it.
Signed-off-by: David Weinehall
---
tests/.gitignore |1 -
tests/Makefile.sources
it in gem_concurrent_blit & kms_frontbuffer_tracking.
Signed-off-by: David Weinehall
---
lib/igt_core.c | 24 +
lib/igt_core.h | 7 ++
tests/gem_concurrent_blit.c | 44 -
tests/kms_frontbuffer_tracking.c | 208 ++-
ll command line option to igt_core, changes
gem_concurrent_blit and kms_frontbuffer_tracking to use this instead of
their own methods, and removes gem_concurrent_all in the process, since
it's now unnecessary.
v2: Incorporate various suggestions from reviewers.
David Weinehall (3):
Copy gem_co
We'll both rename gem_concurrent_all over gem_concurrent_blit
and change gem_concurrent_blit in this changeset. To make
this easier to follow we first do the the rename.
Signed-off-by: David Weinehall
---
tests/gem_concurrent_blit.c | 1116 ++-
1
On Tue, Oct 27, 2015 at 07:29:39PM +0200, Ville Syrjälä wrote:
> On Tue, Oct 27, 2015 at 08:58:17AM +0200, David Weinehall wrote:
> > On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote:
> > > On 10/22/2015 01:35 PM, ville.syrj...@linux.intel.com wrote:
> >
On Tue, Oct 27, 2015 at 10:02:09AM -0700, Jesse Barnes wrote:
> > Depending on what the hardware supports, for hibernate to disk there's ipmi
> > power-on.
> >
> > ipmi-power -h $hostname --stat will show the status of the machine,
> > ipmi-power -h $hostname --on will power it on.
> >
> > Maybe
On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote:
> On 10/22/2015 01:35 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Do a dry run with rtcwake first to determine if the system even supports
> > the intended suspend state. If not, skip the test.
> >
> > Fix
On Mon, Oct 26, 2015 at 03:59:24PM -0200, Paulo Zanoni wrote:
> 2015-10-26 15:30 GMT-02:00 David Weinehall :
> > On Mon, Oct 26, 2015 at 02:44:18PM -0200, Paulo Zanoni wrote:
> >> 2015-10-26 12:59 GMT-02:00 David Weinehall
> >> :
> >> > On Fri, Oct 23, 2015
On Mon, Oct 26, 2015 at 04:28:15PM +, Thomas Wood wrote:
> On 26 October 2015 at 15:28, David Weinehall
> wrote:
> > On Fri, Oct 23, 2015 at 03:55:23PM +0100, Thomas Wood wrote:
> >> On 23 October 2015 at 12:42, David Weinehall
> >> wrote:
> >> > So
On Mon, Oct 26, 2015 at 02:44:18PM -0200, Paulo Zanoni wrote:
> 2015-10-26 12:59 GMT-02:00 David Weinehall :
> > On Fri, Oct 23, 2015 at 11:50:46AM -0200, Paulo Zanoni wrote:
> >
> > [snip]
> >
> >> It's not clear to me, please clarify: now the tests th
On Fri, Oct 23, 2015 at 03:55:23PM +0100, Thomas Wood wrote:
> On 23 October 2015 at 12:42, David Weinehall
> wrote:
> > Some tests should not be run by default, due to their slow,
> > and sometimes superfluous, nature.
> >
> > We still want to be able to run th
On Fri, Oct 23, 2015 at 03:32:08PM +0100, Thomas Wood wrote:
> gem_concurrent_all is misspelled in the subject.
>
> On 23 October 2015 at 12:42, David Weinehall
> wrote:
> > We'll both rename gem_concurrent_all over gem_concurrent_blit
> > and change gem_concurre
On Fri, Oct 23, 2015 at 11:50:46AM -0200, Paulo Zanoni wrote:
[snip]
> It's not clear to me, please clarify: now the tests that were
> previously completely hidden will be listed in --list-subtests and
> will be shown as skipped during normal runs?
Yes. Daniel and I discussed this and he though
On Fri, Oct 23, 2015 at 02:47:57PM +0200, Daniel Vetter wrote:
> On Fri, Oct 23, 2015 at 12:58:45PM +0100, Chris Wilson wrote:
> > On Fri, Oct 23, 2015 at 02:42:33PM +0300, David Weinehall wrote:
> > > Until now we've had no unified way to handle slow/combinatorial tests.
&g
With the addition of unified command-line handling for
slow/combinatorial tests we no longer need the
gem_concurrent_blit/gem_concurrent_all magic. Delete the latter,
since the former has a more descriptive file name.
---
tests/Makefile.sources |1 -
tests/gem_concurrent_all.c | 1108 -
_concurrent_all to gem_concurrent_blit.
David Weinehall (3):
Rename gem_concurren_all over gem_concurrent_blit
Unify handling of slow/combinatorial tests
Remove gem_concurrent_all, since it is now superfluous
lib/igt_core.c | 19 +
lib/igt_core.h
Some tests should not be run by default, due to their slow,
and sometimes superfluous, nature.
We still want to be able to run these tests though in some cases.
Until now there's been no unified way of handling this. Remedy
this by introducing the --with-slow-combinatorial option to
igt_core, and
We'll both rename gem_concurrent_all over gem_concurrent_blit
and change gem_concurrent_blit in this changeset. To make
this easier to follow we first do the the rename.
---
tests/gem_concurrent_blit.c | 1116 ++-
1 file changed, 1108 insertions(+), 8 deleti
On Wed, Aug 12, 2015 at 05:19:35PM +0300, Jani Nikula wrote:
> On Wed, 12 Aug 2015, David Weinehall wrote:
> > Some more fixup is needed; the bits from Antti's patch
> > that actually expanded the struct to fully fit the newer
> > versions of the child_device_con
On Wed, Aug 12, 2015 at 03:13:35PM +0300, Jani Nikula wrote:
> On Wed, 12 Aug 2015, David Weinehall wrote:
> > Some more fixup is needed; the bits from Antti's patch
> > that actually expanded the struct to fully fit the newer
> > versions of the child_device_con
On Tue, Aug 11, 2015 at 11:41:42AM +0200, Daniel Vetter wrote:
> On Mon, Aug 10, 2015 at 02:05:47PM +0530, Jindal, Sonika wrote:
> >
> >
> > On 8/10/2015 1:38 PM, Daniel Vetter wrote:
> > >On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote:
> > >>Hi Daniel,
> > >>
> > >>That patch was
erged
(the Iboost patch will need corresponding adjustment to
remove the changes I split out):
Expand common_child_dev_config to be able to fit all information
defined by the latest VBT specification.
Signed-off-by: David Weinehall
CC: Antti Koskipaa
---
intel_bios.c |7 ++-
intel_bio
On Thu, Aug 06, 2015 at 11:30:00PM +0200, Daniel Vetter wrote:
[snip]
> Update version of this patch is still missing. I'll need to revert the
> kernel side if this one doesn't show up soonish.
>
> Also you're breaking the invalid-flags testcase (did you bother to run
> them all and check for regr
On Thu, Aug 06, 2015 at 02:33:31PM -0700, Jesse Barnes wrote:
> On 08/06/2015 02:30 PM, Daniel Vetter wrote:
> > On Fri, May 29, 2015 at 09:52:52AM +0200, Daniel Vetter wrote:
> >> On Thu, May 28, 2015 at 05:53:17PM +0300, David Weinehall wrote:
> >>> On Wed, Ma
re if the testcase don't show up within a few days.
> >
> > Cc: David Weinehall
> > Cc: Jesse Barnes
> > Signed-off-by: Daniel Vetter
> > ---
> > tests/gem_ctx_param_basic.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > dif
as probably because of Chris's strong
opposition to the feature in the first place; I've had the testcase
laying around on my computer for quite a while.
Anyhow, here's a slightly modified version of that test -- hopefully
not breaking anything.
Signed-off-by: David Weinehall
diff
On Thu, Aug 06, 2015 at 02:18:35PM +0200, Daniel Vetter wrote:
> On Wed, Aug 05, 2015 at 06:32:01PM +0300, David Weinehall wrote:
> > On Wed, Aug 05, 2015 at 10:59:00AM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote:
>
d remove unused iboost_bit variable
>
> Issue: VIZ-5676
> Signed-off-by: Antti Koskipaa
Now that patch 1/2 has been updated, I'm ready to give this:
Reviewed-by: David Weinehall
Kind regards, David
___
Intel-gfx mailing list
Intel-g
On Thu, Aug 06, 2015 at 02:59:10PM +0100, Michel Thierry wrote:
> On 8/5/2015 9:59 AM, Daniel Vetter wrote:
> >On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote:
> >>VBT version 196 increased the size of common_child_dev_config. The parser
> >>code as
On Wed, Aug 05, 2015 at 10:59:00AM +0200, Daniel Vetter wrote:
> On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote:
> > VBT version 196 increased the size of common_child_dev_config. The parser
> > code assumed that the size of this structure would not change.
> &
ather than hardcoding things like this,
but for now the variants are fairly managable.
v2: Stricter size checks
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/intel_bios.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gp
On Mon, Jul 13, 2015 at 11:24:46AM +0200, Daniel Vetter wrote:
> On Fri, Jul 10, 2015 at 02:10:54PM +0300, Antti Koskipaa wrote:
> > VBT version 196 increased the size of common_child_dev_config. The parser
> > code assumed that the size of this structure would not change.
> >
> > So now, instead
On Fri, Jul 10, 2015 at 02:10:54PM +0300, Antti Koskipaa wrote:
> VBT version 196 increased the size of common_child_dev_config. The parser
> code assumed that the size of this structure would not change.
>
> So now, instead of checking for smaller size, check that the VBT entry is
> not too large
On Fri, Jul 10, 2015 at 04:02:53PM +0530, Dhanya Pillai wrote:
> From: Dhanya
>
> This patch will verify color correction capability of a display driver.
> Gamma/CSC/De-gamma supported.
>
> Signed-off-by: Dhanya
> ---
> tests/Makefile.sources | 3 +
> tests/kms_color.c | 639
>
On Wed, Jul 01, 2015 at 05:23:51PM +0200, Daniel Vetter wrote:
> On Wed, Jul 1, 2015 at 2:21 PM, David Weinehall
> wrote:
> > On Tue, Jun 30, 2015 at 03:01:06PM +0100, Chris Wilson wrote:
> >> On Tue, Jun 30, 2015 at 04:36:55PM +0300, David Weinehall wrote:
> >> &
On Fri, Jul 03, 2015 at 12:31:30PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_prepare_ddi’:
> drivers/gpu/drm/i915/intel_ddi.c:517:6: warning:
> ‘ddi_translations_fdi’ may be used uninitialized in this function
> [-Wmaybe-uninitialized
On Wed, Jul 01, 2015 at 02:35:24PM +0200, Pavel Machek wrote:
> On Wed 2015-07-01 13:53:31, Ville Syrjälä wrote:
> > Sure it does. Eventually we'll want to avoid resuming runtime suspended
> > devices when entering system suspend. For broken machines we'd need to
> > resume the GPU at that point.
>
On Mon, Jun 29, 2015 at 06:12:54PM +0200, Daniel Vetter wrote:
> On Mon, Jun 29, 2015 at 01:35:06PM +0300, Antti Koskipää wrote:
> > Looks fine to me.
> >
> > Reviewed-by: Antti Koskipää
> >
> >
> > On 06/25/2015 11:11 AM, David Weinehall wrote:
> >
On Thu, Jun 25, 2015 at 04:22:38PM +0800, Raymond Yau wrote:
> > >
> > > Shall we move or cc this discussion on audio driver side to ALSA ML?
> >
> > Oops I thought I had cc'ed these patches to alsa-devel as well when I
> sent them.
> >
> > > I think we also need to decide how to manage PCM devices
On Thu, Jun 25, 2015 at 09:37:22AM +0200, Daniel Vetter wrote:
> On Thu, Jun 25, 2015 at 09:14:09AM +0300, David Weinehall wrote:
> > Looks good.
> >
> > Reviewed-by: David Weinehall
> >
> > On Thu, Jun 18, 2015 at 02:23:37PM +0300, Antti Koskipaa wrote:
&
On Wed, Jun 24, 2015 at 10:17:34AM +0530, Jindal, Sonika wrote:
>
>
> On 6/23/2015 4:42 PM, David Weinehall wrote:
> >On Thu, Jun 18, 2015 at 05:05:21PM +0200, Daniel Vetter wrote:
> >>On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:
This patch adds support for 0.85V VccIO on Skylake Y,
separate buffer translation tables for Skylake U,
and support for I_boost for the entries that needs this.
Changes in v2:
* Refactored the code a bit to move all DDI signal level setup to
intel_ddi.c
Issue: VIZ-5677
Signed-off-by: David
On Thu, Jun 18, 2015 at 11:10:13AM +0100, Chris Wilson wrote:
> These are static routing, but called fairly often. (Often enough that
> you care to only read the register once.) Any reason not to preserve
> these routing tables in dev_priv or, slightly more preferrable, intel_dp?
Looking over this
Looks good.
Reviewed-by: David Weinehall
On Thu, Jun 18, 2015 at 02:23:37PM +0300, Antti Koskipaa wrote:
> An OEM may request increased I_boost beyond the recommended values
> by specifying an I_boost value to be applied to all swing entries for
> a port. These override values are spe
On Thu, Jun 18, 2015 at 05:05:21PM +0200, Daniel Vetter wrote:
> On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:
> > @@ -3520,6 +3545,9 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> > uint32_t *DP)
> > } else if (HAS_DDI(dev)) {
> >
On Thu, Jun 18, 2015 at 05:05:21PM +0200, Daniel Vetter wrote:
> On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:
> > @@ -3520,6 +3545,9 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> > uint32_t *DP)
> > } else if (HAS_DDI(dev)) {
> >
On Thu, Jun 18, 2015 at 11:59:34AM +0100, Chris Wilson wrote:
> On Thu, Jun 18, 2015 at 01:47:30PM +0300, David Weinehall wrote:
> > On Thu, Jun 18, 2015 at 11:10:13AM +0100, Chris Wilson wrote:
> > > On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:
> >
On Thu, Jun 18, 2015 at 11:10:13AM +0100, Chris Wilson wrote:
> On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:
> > +static const struct ddi_buf_trans *skl_get_buf_trans_dp(struct drm_device
> > *dev,
>
> struct drm_i915_private not struct drm_device!
The
This patch adds support for 0.85V VccIO on Skylake Y,
separate buffer translation tables for Skylake U,
and support for I_boost for the entries that needs this.
Issue: VIZ-5677
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.h | 8 +
drivers/gpu/drm/i915/i915_reg.h | 12
On Thu, May 28, 2015 at 05:56:25PM +0100, Chris Wilson wrote:
> On Thu, May 28, 2015 at 05:52:21PM +0200, Daniel Vetter wrote:
> > On Thu, May 28, 2015 at 03:39:26PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 05:00:13PM +0300, David Weinehall wrote:
> >
On Wed, May 27, 2015 at 01:32:10PM +0200, Daniel Vetter wrote:
> A simple functional test here which does:
> a) an execbuf with just 1 batch. With full ppgtt you should get that one
> at offset 0. If not, skip the testcase.
> b) set the NO_ZEROMAP property.
> c) re-run the same batch, assert that n
On Wed, May 27, 2015 at 01:32:10PM +0200, Daniel Vetter wrote:
> On Thu, May 21, 2015 at 12:44:53PM +0300, David Weinehall wrote:
> > tests/gem_ctx_param_basic: Expand ctx_param tests
> >
> > Expand the context parameter tests to cover the
> > no-zeromap parameter.
&g
On Thu, May 21, 2015 at 10:50:37AM +0100, Chris Wilson wrote:
> It also have just as much risk as reporting EBUSY due to the CL client
> trying to use a pinned buffer.
>
> However, it is a security hole because the same process can arrange to
> have whatever buffer it likes at 0 then access it thr
tests/gem_ctx_param_basic: Expand ctx_param tests
Expand the context parameter tests to cover the
no-zeromap parameter.
Signed-off-by: David Weinehall
---
gem_ctx_param_basic.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/tests
On Thu, May 21, 2015 at 09:43:00AM +0100, Chris Wilson wrote:
> On Thu, May 21, 2015 at 11:08:42AM +0300, David Weinehall wrote:
[snip]
> > Not exactly sure what you suggest here?
>
> That you have an unmitigated security hole in your design.
No, I meant what you suggest as a
On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > > > > This patch series (one patch each for libdrm, the kernel, and beignet)
> > > > > aims to provide a means to add a context-specific means to prevent
> > > > > a mapping to GPU vi
On Wed, May 20, 2015 at 06:00:43PM +0200, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> > On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > &g
Set the I915_CONTEXT_PARAM_NO_ZEROMAP context parameter to disable
zero mappings if libdrm is new enough to expose such functionality.
Signed-off-by: David Weinehall
---
CMakeLists.txt |6 ++
src/CMakeLists.txt |5 +
src/intel/intel_driver.c |4
3 files
Provide helper functions for the context_{get,set}param ioctls,
as well as the I915_CONTEXT_PARAM_NO_ZEROMAP parameter.
Signed-off-by: David Weinehall
---
configure.ac |2 -
include/drm/i915_drm.h |1
intel/intel_bufmgr.h |4 +++
intel/intel_bufmgr_gem.c | 57
Export a new context parameter that can be set/queried through the
context_{get,set}param ioctls. This parameter is passed as a context
flag and decides whether or not a GPU address mapping is allowed to
be made at address zero. The default is to allow such mappings.
Signed-off-by: David
n
and exports the context parameter.
The beignet patch uses the new libdrm function to disable zero
mappings if that functionality is available.
David Weinehall (3):
drm/i915: add a context parameter to {en,dis}able zero address mapping
libdrm: export context_{get,set}para
On Mon, May 18, 2015 at 04:01:45PM +0300, Jani Nikula wrote:
> Turn
>
> [drm:intel_dp_print_rates] source rates: 162000,27,54,
> [drm:intel_dp_print_rates] sink rates: 162000,27,
> [drm:intel_dp_print_rates] common rates: 162000,27,
>
> into
>
> [drm:intel_dp_prin
On Wed, May 06, 2015 at 03:33:44PM +0300, Jani Nikula wrote:
> Do no expose invalid gmbus pins as i2c devices to userspace.
"Do not", perchance?
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org
.
I think you mean "less typo-prone" here :)
Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
(PCH_PP_DIVISOR);
In case some future products also lack this register this will quickly
end up messy. Maybe it'd be better to add a HAS_PP_DIVISOR(dev) macro
or something like that?
Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@l
On Tue, Apr 28, 2015 at 03:46:46PM +0100, Chris Wilson wrote:
> On Tue, Apr 28, 2015 at 02:38:25PM +, Antoine, Peter wrote:
> > So is the plan to push these patches and have follow-on work to cover the
> > other paths?
> > As this fixes the Bugzilla issue that has been raised.
>
> You've iden
probably make sense to fix all code that uses
drm_atomic_state_free() at the same time.
Regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
release load detect pipe.\n");
> 9118drm_atomic_state_free(state);
> ^
> Dereferenced inside function call.
>
> 9119}
> 9120
Wouldn't it make more sense to make drm_atomic_state_free() follow
the same semantics as *free() functions typically do
(no operation performed)?
Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote:
>
>
> On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
> >On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
> >>From: Deepak S
> >>
> >>Unfortunately WaGsvRC0Res
27;s OK to use on,
or to identif what Baytrail systems it isn't OK to use on?
Just reverting this completely seems overly broad if it's possible to
tell the difference between working and non-working systems.
Kind regards, David Weinehall
___
I
On Thu, Mar 19, 2015 at 03:22:42AM +, Song, Ruiling wrote:
>
> > Yeah, MAP_FIXED sounds a bit more ambitious and though I think it would
> > work for OCL 2.0 pointer sharing, it's a little different than we were
> > planning.
> > To summarize, we have three possible approaches, each with its
301 - 400 of 405 matches
Mail list logo
