Am Dienstag, 8. November 2016, 16:17:59 CET schrieb Martin Steigerwald:
> Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> > Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > > On Mon, 07 Nov 2016, Martin Steigerwald wrote:
> > > > It is also the same kind
From: Libin Yang
This issue is caused by:
6014ac12: drm/i915/audio: set proper N/M in modeset
Some special monitors will have noise or even no sound after
applying the patch 6014ac12.
In patch 6014ac12, it will reset the cts value to 0 for HDMI.
However, we need disable Enable CTS or M Prog bit
== Series Details ==
Series: drm/i915/audio: fix hdmi audio noise issue
URL : https://patchwork.freedesktop.org/series/15012/
State : success
== Summary ==
Series 15012v1 drm/i915/audio: fix hdmi audio noise issue
https://patchwork.freedesktop.org/api/1.0/series/15012/revisions/1/mbox/
fi-bd
On Wed, 09 Nov 2016, Matt Roper wrote:
> On Tue, Nov 08, 2016 at 03:21:22PM -0200, Paulo Zanoni wrote:
>> One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB
>> partitioning for multi-screen cases"), and the other was added by
>> 01c72d6c17 ("drm/i915/gen9: fix DDB partitioning f
On Wed, 09 Nov 2016, Martin Steigerwald wrote:
> Also no graphics glitches with external DisplayPort connected display.
Thanks for confirming this. The fix should make it to -rc5.
> *However*, I got a soft freeze and a hard freeze (well after about a
> minute I gave up and rebooted by pressing p
Am Mittwoch, 9. November 2016, 11:42:36 CET schrieb Jani Nikula:
> > *However*, I got a soft freeze and a hard freeze (well after about a
> > minute I gave up and rebooted by pressing power button long enough to
> > forcefully switch off the laptop) when playing PlaneShift using
> > drm-intel-fixes
On Fri, Nov 04, 2016 at 02:42:44PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A small selection of macros which can only accept dev_priv from
> now on and a resulting trickle of fixups.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/
On Fri, Nov 04, 2016 at 02:42:47PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> After this patch only conversion of INTEL_INFO(p)->gen to
> INTEL_GEN(dev_priv) remains before the __I915__ macro can
> be removed.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_drv
On Fri, Nov 04, 2016 at 02:42:46PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A small selection of macros which can only accept dev_priv from
> now on and a resulting trickle of fixups.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/
On Mon, Nov 07, 2016 at 09:29:20AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A small selection of macros which can only accept dev_priv from
> now on and a resulting trickle of fixups.
>
> v2: Keep original order. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Ville Syrj
On Fri, Nov 04, 2016 at 02:42:48PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/d
Explicitly disable stolen memory when running as a guest in a virtual
machine, since the memory is not mediated between clients and reserved
entirely for the host. The actual size should be reported as zero, but
like every other quirk we want to tell the user what is happening.
Signed-off-by: Chri
We use DRM_DEBUG() when reporting on user actions, to try and keep
intentional errors out of the CI dmesg. Demote the debug from
i915_gem_open() similarly so that it is only apparent with drm.debug & 1
like its brethren.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 f
Hi Dave -
Fixes for i915, in particular includes the fix for [1].
BR,
Jani.
[1] http://lkml.kernel.org/r/2656903.keIazZlQoI@merkaba
The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository a
On Wed, 09 Nov 2016, libin.y...@intel.com wrote:
> From: Libin Yang
>
> This issue is caused by:
> 6014ac12: drm/i915/audio: set proper N/M in modeset
>
> Some special monitors will have noise or even no sound after
> applying the patch 6014ac12.
>
> In patch 6014ac12, it will reset the cts value
On ke, 2016-11-09 at 10:39 +, Chris Wilson wrote:
> Explicitly disable stolen memory when running as a guest in a virtual
> machine, since the memory is not mediated between clients and reserved
> entirely for the host.
I'd kind of expect it to get sliced down just like the aperture, what's
t
On Sat, Oct 29, 2016 at 09:47:24AM -0400, Greg KH wrote:
> On Sat, Oct 29, 2016 at 10:13:25AM -0300, Gaston Gonzalez wrote:
> > On Fri, Oct 28, 2016 at 07:23:24PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 28, 2016 at 11:53:40AM -0400, Greg KH wrote:
> > > > On Fri, Oct 07, 2016 at 10:38:17AM -0
On Mon, Oct 31, 2016 at 07:37:29PM +0200, Jani Nikula wrote:
> On Mon, 31 Oct 2016, "Vivi, Rodrigo" wrote:
> > I was about to put my rv-b here. I do believe we need to find a better
> > name and the patch was clear and correct. And indeed in a good timing.
> >
> > However right before clicking the
On Fri, Nov 04, 2016 at 08:32:56PM +0530, akash.g...@intel.com wrote:
> From: Chris Wilson
>
> On a long run of more than 2-3 days, physical memory tends to get
> fragmented severely, which considerably slows down the system. In such a
> scenario, the shrinker is also unable to help as lack of me
From: Tvrtko Ursulin
After this patch only conversion of INTEL_INFO(p)->gen to
INTEL_GEN(dev_priv) remains before the __I915__ macro can
be removed.
v2: Tidy vlv_compute_wm. (David Weinehall)
Signed-off-by: Tvrtko Ursulin
Cc: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
On Wednesday, 2016-11-09 02:13:25 +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote:
> > > The function's behaviour was changed in 90844f00049e, without changing
> > > its signature, causin
On Wed, Nov 09, 2016 at 11:30:45AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> After this patch only conversion of INTEL_INFO(p)->gen to
> INTEL_GEN(dev_priv) remains before the __I915__ macro can
> be removed.
>
> v2: Tidy vlv_compute_wm. (David Weinehall)
>
> Signed-off-by: Tvrtko
== Series Details ==
Series: drm/i915/gvt: Disable access to stolen memory as a guest
URL : https://patchwork.freedesktop.org/series/15022/
State : warning
== Summary ==
Series 15022v1 drm/i915/gvt: Disable access to stolen memory as a guest
https://patchwork.freedesktop.org/api/1.0/series/150
== Series Details ==
Series: drm/i915: Demote i915_gem_open() debugging from DRIVER to USER
URL : https://patchwork.freedesktop.org/series/15023/
State : success
== Summary ==
Series 15023v1 drm/i915: Demote i915_gem_open() debugging from DRIVER to USER
https://patchwork.freedesktop.org/api/1.
Rodrigo recently asked me about this, and I totally failed to properly
document it!
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
qf | 19 +++
1 file changed, 19 insertions(+)
diff --git a/qf b/qf
index 31b9f3bae0a2..883dda0a1668 100755
--- a/qf
+++ b/qf
@@ -540,6 +540,25 @
Op 08-11-16 om 15:11 schreef Ville Syrjälä:
> On Tue, Nov 08, 2016 at 01:55:36PM +0100, Maarten Lankhorst wrote:
>> This is a hack and not needed. Use the right mask by checking
>> intel_state->modeset. This works for watermark sanitization too.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> dr
== Series Details ==
Series: dev_priv cleanup continuation (rev3)
URL : https://patchwork.freedesktop.org/series/14844/
State : success
== Summary ==
Series 14844v3 dev_priv cleanup continuation
https://patchwork.freedesktop.org/api/1.0/series/14844/revisions/3/mbox/
fi-bdw-5557u total:2
On Wed, 02 Nov 2016, Manasi Navare wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
>
On Mon, 07 Nov 2016, Manasi Navare wrote:
> Jani, could you please take a look at this patch?
> I have addressed your comments on the previous revision.
> The common_rates array can be moved into Intel dp
> structure in a follow up patch since that would require changes
> in a lot of places other
On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom
wrote:
>> Well, had to drop it again since it didn't compile:
>>
>>
>> CC [M] drivers/gpu/drm/drm_blend.o
>> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
>> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments
On Tue, Nov 08, 2016 at 04:53:20PM -0800, Matt Roper wrote:
> On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > As I told people in [1] we really should not be confusing enum plane
> > as a per-pipe plane identifier. Looks like that hap
On Mon, 31 Oct 2016, Manasi Navare wrote:
> A new default connector property is added for keeping
> track of whether the link is good (link training passed) or
> link is bad (link training failed). If the link status property
> is not good, then userspace should fire off a new modeset at the curr
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 77d150b90d58ae6a43bf67af28feb26384d06cd6
commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict stackdepot
usage to builtin drm.ko
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9
On Sun, Nov 06, 2016 at 11:42:31PM -0700, Pierre-Louis Bossart wrote:
> I am all for convergence when it makes sense but I don't see how
> hdmi-codec.h provides equivalent functionality for BYT/CHT with what was
> suggested in this patchset -derived from VED patches- and discussed earlier
> with i
On Wed, Nov 09, 2016 at 10:01:37PM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
> head: 77d150b90d58ae6a43bf67af28feb26384d06cd6
> commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict
> stackdepot usage to builtin drm.ko
> confi
On 09/11/2016 03:03, Zhenyu Wang wrote:
> On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote:
Paolo, for this case, do you think it's feasible we pick them through
drm/i915 merge path? As currently initial KVMGT patch sets require these
exported symbols, that's why I ask how we shou
Daniel,
The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e:
kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02
21:31:53 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt
for you to fetch
On 9 November 2016 at 14:12, Chris Wilson wrote:
> On Wed, Nov 09, 2016 at 10:01:37PM +0800, kbuild test robot wrote:
>> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
>> head: 77d150b90d58ae6a43bf67af28feb26384d06cd6
>> commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm:
From: Tvrtko Ursulin
At the moment we allocate enough sg table entries assuming we
will not be able to do any coallescing. But since in practice
we most often can, and more so very effectively, this ends up
wasting a lot of memory.
A simple and effective way of trimming the over-allocated
entrie
Reviewed-by: Robert Foss
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Nov 09, 2016 at 02:30:02PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> At the moment we allocate enough sg table entries assuming we
> will not be able to do any coallescing. But since in practice
> we most often can, and more so very effectively, this ends up
> wasting a lot
On 08/11/2016 14:37, Chris Wilson wrote:
When we need to reset the global seqno on wraparound, we have to wait
until the current rbtrees are drained (or otherwise the next waiter will
be out of sequence). The current mechanism to kick and spin until
complete, may exit too early as it would break
Hi,
On Monday 31 October 2016 11:33 PM, Paulo Zanoni wrote:
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
This patch make changes to use linetime latency instead of allocated
DDB size during plane watermark calculation in switch case, This is
required to implement new DDB allocati
From: Ville Syrjälä
Nuke skl_wm_plane_id() and just use the new intel_plane->id.
v2: Convert skl_write_plane_wm() as well
v3: Convert skl_pipe_wm_get_hw_state() correctly
Cc: Matt Roper
Cc: Paulo Zanoni
Cc: Maarten Lankhorst
Cc: Lyude
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/
On 09/11/2016 14:44, Chris Wilson wrote:
On Wed, Nov 09, 2016 at 02:30:02PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
At the moment we allocate enough sg table entries assuming we
will not be able to do any coallescing. But since in practice
we most often can, and more so very effecti
Hi Lyude,
I think this looks very good.
On 8 November 2016 at 01:05, Lyude wrote:
>
> - While writing this patch series, I found that quite a few of the RPC calls
>for chameleond don't work as expected. For instance, I have had absolutely
>no luck getting CRCs from any of the display ty
On Wed, Nov 09, 2016 at 03:07:38PM +, Tvrtko Ursulin wrote:
>
> On 09/11/2016 14:44, Chris Wilson wrote:
> >Reviewed-by: Chris Wilson
> > ^ I remembered it this time!
> >Took a couple of attempts to spell my name right though.
>
> Thanks! I assume I can keep it for the above little
From: Tvrtko Ursulin
At the moment we allocate enough sg table entries assuming we
will not be able to do any coalescing. But since in practice
we most often can, and more so very effectively, this ends up
wasting a lot of memory.
A simple and effective way of trimming the over-allocated
entries
On Wed, Nov 09, 2016 at 03:25:19PM +0100, Paolo Bonzini wrote:
> Daniel,
>
> The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e:
>
> kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02
> 21:31:53 +0100)
>
> are available in the git repository at:
>
On Wed, Nov 09, 2016 at 02:53:34PM +, Tvrtko Ursulin wrote:
> Looks OK. Side note to myself - catch up on the rcu waiter business.
>
> Reviewed-by: Tvrtko Ursulin
Ta, pushed to have one less wart.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On 09/11/2016 16:15, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 03:25:19PM +0100, Paolo Bonzini wrote:
>> Daniel,
>>
>> The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e:
>>
>> kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02
>> 21:31:53 +0100
On 8 November 2016 at 01:05, Lyude wrote:
> For the purpose of testing things such as hotplugging and bad monitors,
> the ChromeOS team ended up designing a neat little device known as the
> Chamelium. More information on this can be found here:
>
> https://www.chromium.org/chromium-os/tes
The i915-perf series affects the command parser and itself includes new uapi
which these i-g-t changes try to cover.
As well as splitting up the gem_exec_parse changes this version maintains
support for testing version 7 of the command parser.
- Robert
Robert Bragg (6):
igt/perf: add i915 perf
This normalizes the execbuf utilities in this file to all use memset to
clear obj, reloc and execbuf structures and set them up in the same
order. As I was debugging some unpredictable test failures I was getting
unsure that all these structures were being fully initialized.
The same I915_GEM_DOMA
Signed-off-by: Robert Bragg
---
tests/Makefile.sources |1 +
tests/perf.c | 2220
2 files changed, 2221 insertions(+)
create mode 100644 tests/perf.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..7c6de2
This generalises hsw_load_register_reg to loop through an array of
allowed and disallowed registers and to use the exec_batch[_patched]
utilities.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 139 +++--
1 file changed, 66 insertions(+), 73
This limits testing the oacontrol tracking (required pairing of oa
enable/disable per batch buffer) to version <= 8 of the command parser.
Version 9 of the command parser removes all special handling for
OACONTROL which is now going to be managed by i915-perf and not
programmed from userspace.
Si
No functional change, just moving hsw_load_regster_reg test code down
below the execbuf utilities in preparation for updating to use them.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 182 -
1 file changed, 91 insertions(+), 91 deletion
This adapts the basic-rejected test to focus on invalid commands that
will result in an EINVAL errno being returned to userspace even with the
upcoming version 8 parser change to stop reporting access violations as
EINVAL errors.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 28 ++
With v8 of the command parser (where we won't get an EINVAL for an
access violation) this updates the bitmasks test to explicitly confirm
that the command became a NOOP by reading back from where the QW_WRITE
would have otherwise landed.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 1
Since an access violation won't return an error to userspace for v >= 8
of the command parser this updates the cmd-crossing-page test to
explicitly read back from SO_WRITE_OFFSET[0] to see that the command
wasn't squashed to a NOOP.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 15 +++
This combines some parts of the recently added store_lri test with the
registers test to be able to first load a distinguishable value before
the LRI and explicitly read back the register to determine if the
command succeeded or was a NOOP.
For now though we won't look at OACONTROL without checkin
This updates the checking of disallowed loads to set a distinguishable
value before the load and explicitly check the load was a NOOP by
reading back the final value.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-
OACONTROL is no longer white listed in the command parser so this checks
at attempted LRI will be disallowed and (more importantly) checks that
userspace doesn't get an EINVAL error for an attempted OACONTROL LRI.
This is important becase Mesa application attempt OACONTROL LRIs while
initializing a
== Series Details ==
Series: drm/i915: Add a per-pipe plane identifier enum (rev4)
URL : https://patchwork.freedesktop.org/series/14978/
State : warning
== Summary ==
Series 14978v4 drm/i915: Add a per-pipe plane identifier enum
https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/
On Wed, Nov 09, 2016 at 04:15:52PM +, Robert Bragg wrote:
> +static void
> +test_i915_ref_count(void)
> +{
> +int oa_exponent = 13; /* 1 millisecond */
> +uint64_t properties[] = {
> +/* Include OA reports in samples */
> +DRM_I915_PERF_PROP_SAMPL
== Series Details ==
Series: drm/i915: Trim the object sg table (rev2)
URL : https://patchwork.freedesktop.org/series/15036/
State : warning
== Summary ==
Series 15036v2 drm/i915: Trim the object sg table
https://patchwork.freedesktop.org/api/1.0/series/15036/revisions/2/mbox/
Test drv_module
On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote:
> On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom
> wrote:
> >> Well, had to drop it again since it didn't compile:
> >>
> >>
> >> CC [M] drivers/gpu/drm/drm_blend.o
> >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_pr
Em Qua, 2016-11-09 às 20:28 +0530, Mahesh Kumar escreveu:
> Hi,
>
>
> On Monday 31 October 2016 11:33 PM, Paulo Zanoni wrote:
> >
> > Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> > >
> > > This patch make changes to use linetime latency instead of
> > > allocated
> > > DDB size
On Wed, Nov 09, 2016 at 11:27:37AM +0200, Jani Nikula wrote:
> On Wed, 09 Nov 2016, Matt Roper wrote:
> > On Tue, Nov 08, 2016 at 03:21:22PM -0200, Paulo Zanoni wrote:
> >> One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB
> >> partitioning for multi-screen cases"), and the oth
On Wed, 9 Nov 2016, Daniel Vetter wrote:
>
> Hi all -mm folks!
>
> Any feedback on these two? It's kinda an intermediate step towards a
> full-blown gemfs, and I think useful for that. Or do we need to go
> directly to our own backing storage thing? Aside from ack/nack from -mm I
> think this is
From: Peter Antoine
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before t
From: Peter Antoine
Add debugfs entry for HuC loading status check.
v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Rev
From: Peter Antoine
Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw'
From: Peter Antoine
HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.
v2: rebased on-top of drm-intel-nigh
This patch adds the support to load HuC on KBL
Version 2.0
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_huc_loader.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
b/drivers/gpu/drm/i915/intel_huc_loader
From: Peter Antoine
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5:
From: Peter Antoine
This patch adds the HuC Loading for the BXT.
Version 1.7 of the HuC firmware.
It also updates the file construction and specifying the
required version similar to that of GuC for both SKL and BXT.
Add an extra field for the build number. Adopted the approach used in-
https://
From: Peter Antoine
This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after i
Replace i915.enable_guc_loading and i915.enable_guc_submission
with a single parameter - i915.enable_guc. Where:
-1 : Platform default (Only load GuC)
0 : Do not use GuC
1 : Load GuC, do not use Command Submission through GuC
2 : Load and use GuC for Command Submission
Cc: Tvrtko Ursulin
Cc: Jef
== Series Details ==
Series: series starting with [1/8] drm/i915/guc: Make the GuC fw loading helper
functions general
URL : https://patchwork.freedesktop.org/series/15061/
State : success
== Summary ==
Series 15061v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/serie
On 7 November 2016 at 19:49, Robert Bragg wrote:
> The maximum OA sampling frequency is now configurable via a
> dev.i915.oa_max_sample_rate sysctl parameter.
>
> Following the precedent set by perf's similar
> kernel.perf_event_max_sample_rate the default maximum rate is 10Hz
>
> Signed-off-b
On 7 November 2016 at 19:49, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system calls
I am currently not sure what the way forward should be.
We are successfully implementing this patch in e.g. LibreELEC an embedded
distribution for home theater pcs. But through current bug reports - I am
not sure, if we should give such functionality to the user, that is
overwritten on a lower lev
On Wed, Nov 09, 2016 at 10:51:35AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch adds the HuC Loading for the BXT.
> Version 1.7 of the HuC firmware.
>
> It also updates the file construction and specifying the
> required version similar to that of GuC for both SKL and BXT.
On Wed, Nov 09, 2016 at 09:11:58PM +0100, Peter Frühberger wrote:
> I am currently not sure what the way forward should be.
>
> We are successfully implementing this patch in e.g. LibreELEC an embedded
> distribution for home theater pcs. But through current bug reports - I am
> not sure, if we sh
When updating a patch set on the mailing list with new revisions
it is preferred to send those new patches as a reply to the patch
being revised and also to include the V2, V3, etc. in the subject.
If you have massive changes then it is OK to submit a new set but
it helps to include cover letter a
Currently we only clflush the scanout if it is in the CPU domain. Also
flush if we have a pending CPU clflush. We also want to treat the
dirtyfb path similar, and flush any pending writes there as well.
v2: Only send the frontbuffer flush if we have CPU dirt.
Signed-off-by: Chris Wilson
Reviewed
We do not need to hold struct_mutex for destroying drm_i915_gem_objects
any longer, and with a little care taken over tracking
obj->framebuffer_references, we can relinquish BKL locking around the
destroy of intel_framebuffer.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h
We do not need the BKL struct_mutex in order to allocate a GEM object,
nor to create the framebuffer, so resist the temptation to take the BKL
willy nilly. As this changes the locking contract around internal API
calls, the patch is a little larger than a plain removal of a pair of
mutex_lock/unloc
Currently, we may skip the clflush on an object if the object has not
yet allocated any pages. However, the object may still be polluting the
CPU cache and may now be in a coherent uncached domain - and so no
longer generating clflushing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915
Since the frontbuffer has self-contained locking, it does not require us
to hold the BKL struct_mutex as we send invalidate and flush messages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fbdev.c | 43 +++---
1 file changed, 17 insertions(+), 26 del
>-Original Message-
>From: Mcgee, Jeff
>Sent: Wednesday, November 9, 2016 12:43 PM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading
>helper functions general
>
>When updating
We no longer need to take the struct_mutex for freeing objects, and on
the finalisation paths here the mutex is not been used for serialisation
of the pointer access, so remove the BKL wart.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_loader.c | 14 ++
1 file chang
On Wed, Nov 09, 2016 at 03:04:05PM +0200, Jani Nikula wrote:
> On Wed, 02 Nov 2016, Manasi Navare wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> >
== Series Details ==
Series: series starting with [1/5] drm/i915: Always flush the dirty CPU cache
when pinning the scanout
URL : https://patchwork.freedesktop.org/series/15069/
State : failure
== Summary ==
Series 15069v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/
== Series Details ==
Series: drm/i915/guc: Don't take struct_mutex for object unreference
URL : https://patchwork.freedesktop.org/series/15071/
State : success
== Summary ==
Series 15071v1 drm/i915/guc: Don't take struct_mutex for object unreference
https://patchwork.freedesktop.org/api/1.0/se
On Tue, Nov 08, 2016 at 01:55:32PM +0100, Maarten Lankhorst wrote:
> Allow the driver to write watermarks during atomic evasion.
> This will make it possible to write the watermarks in a cleaner
> way on gen9+.
>
> intel_atomic_state is not used here yet, but will be used when
> we program all wat
On Tue, Nov 08, 2016 at 01:55:34PM +0100, Maarten Lankhorst wrote:
> This is the last bit required for making nonblocking modesets work
> correctly. The state in intel_crtc->hw_ddb is not updated until
> somewhere in atomic commit, while the previous crtc state should be
> accurate if the ddb hasn'
On Tue, Nov 08, 2016 at 01:55:35PM +0100, Maarten Lankhorst wrote:
> This member is only used in skl_update_crtcs now. It's easy to remove it
> by keeping track of which ddb entries in an array, and update them after
I'm having trouble parsing this line...not sure if you have an extra
word or are
1 - 100 of 122 matches
Mail list logo