I hope this email finds you well. I apologize as I'm not a graphics kernel
developer. I hope we don't discover that this email is a complete newbie
email.
Problem: External HDMI display is unreadable. You can make out edges of
windows and other stuff. Other than that it looks like a garbled mess o
== Series Details ==
Series: Add Automation Support for DP Compliance Testing (Rev 3)
URL : https://patchwork.freedesktop.org/series/16643/
State : warning
== Summary ==
Series 16643v1 Add Automation Support for DP Compliance Testing (Rev 3)
https://patchwork.freedesktop.org/api/1.0/series/166
Jani,
I have addressed all your review comments and using the proper
# defines from the header file for register and masks definitions.
Could you please review this patch?
Regards
Manasi
On Fri, Dec 09, 2016 at 04:33:00PM -0800, Manasi Navare wrote:
> The intel_dp_autotest_video_pattern() functi
Jani,
I have added the defs for all compliance video pattern test registers as
you had commented on previous version of this patch.
It also fixes the indentation. Could you please review this patch?
Regards
Manasi
On Fri, Dec 09, 2016 at 04:32:59PM -0800, Manasi Navare wrote:
> v2:
> * Add all
Jani,
This patch has just a few fixes to make the EDID tests follow the
DP CTS spec. where for the valid EDID it should set the EDID data to
PREFERRED Mode as opposed to STANDARD.
Also it sets the data to EDID if it is EDID test. Fairly simple and
is verified to be passing compliance with DPR-120.
Jani,
I have addressed few comments you had on the previous set of patches
about validating the test lane count so I am checking it against
min and max lane count values. Also made the debug prints
less verbose.
Could you please review this patch?
Regards
Manasi
On Fri, Dec 09, 2016 at 04:32:57P
merged to dinq, thanks for the patch.
On Fri, Dec 9, 2016 at 4:39 PM Rodrigo Vivi wrote:
>
>
> Reviewed-by: Rodrigo Vivi
>
> On Fri, Dec 09, 2016 at 11:42:09PM +0530, vathsala nagaraju wrote:
> > For PSR2 , as per spec, PSR2_CTL bit 31 to be set.
> > for psr1, bit 31 in SRD_CTL to be set. Repor
Reviewed-by: Rodrigo Vivi
On Fri, Dec 09, 2016 at 11:42:09PM +0530, vathsala nagaraju wrote:
> For PSR2 , as per spec, PSR2_CTL bit 31 to be set.
> for psr1, bit 31 in SRD_CTL to be set. Reporting
> "HW Enabled & Active bit" status for psr2 from SRD_CTL
> gives wrong status.
>
> Cc: Rodrigo V
v2:
* Add all the other DP Complianec TEST register defs (Jani Nikula)
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
include/drm/drm_dp_helper.h | 58 +
1 file changed, 58 ins
This patch does not change anything functionally, just cleans up
the DP compliance related variables and stores them all together
in a separate struct intel_dp_compliance. There is another struct
intel_dp_compliance_data to store all the test data. This makes it easy to
reset the compliance variabl
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is se
The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color v
This addresses all the review comments from the earlier patch series:
https://patchwork.freedesktop.org/series/16591/
DP 1.2 compliance testing can be acheived using DPR-120's CTS suite.
This compliance unit sends a short pulse to initiate link training
and video pattern generation compliance test
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
v2:
* Added read debugfs data from test_data.e
This patch does not change anything functionally, just cleans up
the DP compliance related variables and stores them all together
in a separate struct intel_dp_compliance. There is another struct
intel_dp_compliance_data to store all the test data. This makes it easy to
reset the compliance variabl
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
v2:
* Added read debugfs data from test_data.e
>-Original Message-
>From: Michal Wajdeczko [mailto:michal.wajdec...@linux.intel.com]
>Sent: Friday, December 9, 2016 4:18 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading supp
On Fri, Dec 09, 2016 at 09:47:56PM +, Chris Wilson wrote:
> On Fri, Dec 09, 2016 at 03:19:42PM +0100, Daniel Vetter wrote:
> > Looping when we keep track of this is silly. Only thing we have to
> > be careful is with sampling the connector count. To avoid inconsisten
> > results due to gcc re-c
== Series Details ==
Series: sphinxification for dma-buf docs (rev2)
URL : https://patchwork.freedesktop.org/series/16629/
State : success
== Summary ==
Series 16629v2 sphinxification for dma-buf docs
https://patchwork.freedesktop.org/api/1.0/series/16629/revisions/2/mbox/
fi-bdw-5557u t
On Fri, Dec 09, 2016 at 03:19:43PM +0100, Daniel Vetter wrote:
> We can be more clever than that and merge the 2 list walking loops.
> It's all under the one mutex critical section anyway, so nothing funny
> can happen.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_mode_config.c |
On Thu, Dec 08, 2016 at 11:53:07PM +0200, Jani Nikula wrote:
> On Thu, 08 Dec 2016, Daniel Vetter wrote:
> > It's been years since drm-intel had only one maintainer, and the
> > primary use-case for dim ub was only to sync between machines. Update
> > the docs to reflect this, to avoid misleading
- Put all the remaing bits of the old doc into suitable places in the
new sphinx world.
- Also document the poll support, we forgot to do that.
- Delete dma-buf-sharing.txt.
v2: Don't forget to update MAINTAINERS.
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet
Cc: Sumit Semwal
Signed-off-b
On Fri, Dec 09, 2016 at 03:19:42PM +0100, Daniel Vetter wrote:
> Looping when we keep track of this is silly. Only thing we have to
> be careful is with sampling the connector count. To avoid inconsisten
> results due to gcc re-computing this, use READ_ONCE.
Later on in the function we take the mu
>-Original Message-
>From: Michal Wajdeczko [mailto:michal.wajdec...@linux.intel.com]
>Sent: Friday, December 9, 2016 3:56 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header stru
I hope this email finds you well. I apologize as I'm not a graphics kernel
developer. I've tried to search for answers and indeed tried several things
before posting this. That doesn't mean I didn't miss something so I'm
happy to be pointed to what I missed.
Problem: External HDMI display is unrea
On Fri, 9 Dec 2016 19:53:04 +0100
Daniel Vetter wrote:
> Not yet everything in this area, I still want to sprinkle nice docs around all
> the fence code. Especially some text to explain implicit vs. explicit fencing
> and how it's all supposed to work.
>
> But just cleanup in the dma-buf part w
On Fri, Dec 09, 2016 at 03:19:44PM +0100, Daniel Vetter wrote:
> This was somehow lost between v3 and the merged version in Maarten's
> patch merged as:
>
> commit f2d580b9a8149735cbc4b59c4a8df60173658140
> Author: Maarten Lankhorst
> Date: Wed May 4 14:38:26 2016 +0200
>
> drm/core: Do no
On Fri, Dec 09, 2016 at 03:27:30PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/7] drm/hisilicon: Don't set
> drm_device->platformdev
> URL : https://patchwork.freedesktop.org/series/16619/
> State : failure
>
> == Summary ==
>
> Series 16619v1 Series wit
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Arkadiusz Hiler
>Sent: Friday, December 9, 2016 5:09 AM
>To: Michal Wajdeczko
>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i91
== Series Details ==
Series: sphinxification for dma-buf docs
URL : https://patchwork.freedesktop.org/series/16629/
State : success
== Summary ==
Series 16629v1 sphinxification for dma-buf docs
https://patchwork.freedesktop.org/api/1.0/series/16629/revisions/1/mbox/
fi-bdw-5557u total:24
This was missed when adding a dma_fence_get call. While at it also
remove the kerneldoc for the static inline helper - no point
documenting internals down to every detail.
Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when creating
sync_file")
Cc: Gustavo Padovan
Cc: Sean Paul
- Put all the remaing bits of the old doc into suitable places in the
new sphinx world.
- Also document the poll support, we forgot to do that.
- Delete dma-buf-sharing.txt.
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet
Cc: Sumit Semwal
Signed-off-by: Daniel Vetter
---
Documentation/dma-
- Again move the information relevant for driver writers next to the
callbacks.
- Put the overview and userspace interface documentation into a DOC:
section within the code.
- Remove the text that mmap needs to be coherent - since the
DMA_BUF_IOCTL_SYNC landed that's no longer the case. But k
Just prep work to polish and consolidate all the dma-buf related
documenation.
Unfortunately I didn't discover a way to both integrate this new file
into the overall toc while keeping it at the current place. Work
around that by moving it into the overall driver-api/index.rst.
Cc: linux-...@vger.
- Put the initial overview for dma-buf into dma-buf.rst.
- Put all the comments about detailed semantics into the right
kernel-doc comment for functions or ops structure member.
- To allow that detail, switch the reworked kerneldoc to inline style
for dma_buf_ops.
- Tie everything together into
Hi all,
Not yet everything in this area, I still want to sprinkle nice docs around all
the fence code. Especially some text to explain implicit vs. explicit fencing
and how it's all supposed to work.
But just cleanup in the dma-buf part was quite a bit of work, and I'd like to
get feedback on tha
== Series Details ==
Series: drm/i915/psr: report psr2 hw enabled from psr2_ctl
URL : https://patchwork.freedesktop.org/series/16628/
State : warning
== Summary ==
Series 16628v1 drm/i915/psr: report psr2 hw enabled from psr2_ctl
https://patchwork.freedesktop.org/api/1.0/series/16628/revisions
For PSR2 , as per spec, PSR2_CTL bit 31 to be set.
for psr1, bit 31 in SRD_CTL to be set. Reporting
"HW Enabled & Active bit" status for psr2 from SRD_CTL
gives wrong status.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: vathsala nagaraju
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 ++---
On Fri, Dec 9, 2016 at 9:19 AM, Daniel Vetter wrote:
> It's deprecated and only should be used by drivers which still use
> drm_platform_init, not by anyone else.
>
> And indeed it's entirely unused and can be nuked.
>
> This required a bit more fudging, but I guess kirin_dc_ops really
> wants to
== Series Details ==
Series: drm: Make each driver's struct_mutex its own subclass
URL : https://patchwork.freedesktop.org/series/16623/
State : failure
== Summary ==
Series 16623v1 drm: Make each driver's struct_mutex its own subclass
https://patchwork.freedesktop.org/api/1.0/series/16623/rev
With prime, we are running into false circular dependencies based on the
order in which two drivers may lock their own struct_mutex wrt to a
common lock (like the reservation->lock). Work around this by adding the
lock_class_key to the struct drm_driver such that each driver can have
its own subcla
On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote:
> Check that we can request alignment to any power-of-two or prime using a
> plain drm_mm_node_insert().
>
> Signed-off-by: Chris Wilson
> +static int igt_align(void *ignored)
> +{
> + struct drm_mm mm;
> + struct drm_mm_node *node,
On 07/12/2016 13:58, Chris Wilson wrote:
Do a quick selftest on in the interoperability of dma_fence_wait on a
i915_gem_request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 51 +
1 file changed, 51 insertions(+)
diff --git a/drive
On 07/12/2016 13:58, Chris Wilson wrote:
A trivial kselftest to submit a request and wait upon it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_reque
On 09/12/2016 15:25, Chris Wilson wrote:
On Fri, Dec 09, 2016 at 03:16:33PM +, Tvrtko Ursulin wrote:
On 07/12/2016 13:58, Chris Wilson wrote:
A fairly trivial move of a matching pair of routines (for preparing a
request for construction) onto an engine vfunc. The ulterior motive is
to be
On Fri, Dec 09, 2016 at 05:45:56PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-09 at 18:01 +0800, Wang Elaine wrote:
> > From: Elaine Wang
> >
> > Some platforms don't have display. To avoid accessing the
> > non-existent registers, check whether num_pipes isn't zero
> > before invoking dispal
On pe, 2016-12-09 at 18:01 +0800, Wang Elaine wrote:
> From: Elaine Wang
>
> Some platforms don't have display. To avoid accessing the
> non-existent registers, check whether num_pipes isn't zero
> before invoking dispaly IRQ install or reset function.
>
> Cc: Joonas Lahtinen
> Signed-off-by: E
On 07/12/2016 13:58, Chris Wilson wrote:
Simple starting point for adding seltests for i915_gem_request, first
mock a device (with engines and contexts) that allows us to construct
and execute a request, along with waiting for the request to complete.
Signed-off-by: Chris Wilson
---
drivers/g
On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote:
> Check that if we request top-down allocation with a particular alignment
> from drm_mm_insert_node() that the start of the node matches our
> request.
>
> Signed-off-by: Chris Wilson
> @@ -1038,6 +1038,98 @@ static int igt_topdown(void *i
On Fri, Dec 09, 2016 at 02:54:34PM +, Emil Velikov wrote:
> On 9 December 2016 at 14:19, Daniel Vetter wrote:
> > No one looks at the major/minor versions except the unique/busid
> > stuff. If we protect that with the master_mutex (since it also affects
> > the unique of each master, oh well)
== Series Details ==
Series: series starting with [1/7] drm/hisilicon: Don't set
drm_device->platformdev
URL : https://patchwork.freedesktop.org/series/16619/
State : failure
== Summary ==
Series 16619v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16619/revisi
On Fri, Dec 09, 2016 at 03:16:33PM +, Tvrtko Ursulin wrote:
>
> On 07/12/2016 13:58, Chris Wilson wrote:
> >A fairly trivial move of a matching pair of routines (for preparing a
> >request for construction) onto an engine vfunc. The ulterior motive is
> >to be able to create a mock request imp
On 07/12/2016 13:58, Chris Wilson wrote:
A fairly trivial move of a matching pair of routines (for preparing a
request for construction) onto an engine vfunc. The ulterior motive is
to be able to create a mock request implementation.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_g
On 07/12/2016 13:58, Chris Wilson wrote:
PIN_HIGH is an expensive operation (in comparison to allocating from the
hole stack) unsuitable for frequent use (such as switching between
contexts). However, the kernel context should be pinned just once for
the lifetime of the driver, and here it is ap
On 07/12/2016 13:58, Chris Wilson wrote:
As the shadow gvt is not user accessible and does not have an associated
vm, we can mark it as closed during its construction. This saves leaking
the internal knowledge of i915_gem_context into gvt/.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915
Some object retain an extra pin whilst they are active (e.g. contexts).
This excludes them from being considered for eviction unless we idle the
GPU. If before we look at the active list, before we retire we can
hopefully remove a few excess pins and reduce the amount of searching
required.
v2: Si
On 07/12/2016 13:58, Chris Wilson wrote:
A few users only take the struct_mutex in order to release a reference
to a context. We can expose a kref_put_mutex() wrapper in order to
simplify these users, and optimise taking of the mutex to the final
unref.
Signed-off-by: Chris Wilson
---
drivers
On 9 December 2016 at 14:19, Daniel Vetter wrote:
> No one looks at the major/minor versions except the unique/busid
> stuff. If we protect that with the master_mutex (since it also affects
> the unique of each master, oh well) we can mark these two IOCTL with
> DRM_UNLOCKED.
>
> While doing this
== Series Details ==
Series: drm: Add fake controlD* symlinks for backwards compat (rev2)
URL : https://patchwork.freedesktop.org/series/16605/
State : success
== Summary ==
Series 16605v2 drm: Add fake controlD* symlinks for backwards compat
https://patchwork.freedesktop.org/api/1.0/series/16
On Fri, Dec 09, 2016 at 04:31:50PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote:
> > +static int igt_reserve(void *ignored)
> > +{
> > + int n, ret;
> > +
> > + for (n = 1; n < 50; n++) {
>
> The right amount of loops might be something to discuss.
The
On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote:
> Exercise drm_mm_reserve_node(), check that we can't reserve an already
> occupied range and that the lists are correct after reserving/removing.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_mm_selftests.h | 1 +
> drivers/g
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied from Maarten's patch, b
Looping when we keep track of this is silly. Only thing we have to
be careful is with sampling the connector count. To avoid inconsisten
results due to gcc re-computing this, use READ_ONCE.
And to avoid surprising userspace, make sure we don't copy more
connectors than planned, and report the actu
On Fri, Dec 09, 2016 at 02:56:56PM +0100, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus poi
It only updates per-file feature flags. And all the ioctl which change
behaviour depending upon these flags (they're all kms features) do
_not_ hold the BKL. Therefor this is pure cargo-cult and can be
removed.
Note that there's a risk that the ioctl will behave inconsistently,
but that's ok. The
With the last round of changes all ioctls called by modern drivers now
have their own locking. Everything else is only allowed for legacy
drivers and hence the lack of locking doesn't matter.
One exception is nouveau, due to the DRIVER_KMS_LEGACY_CONTEXT flag.
But that only works its magic on the
No one looks at the major/minor versions except the unique/busid
stuff. If we protect that with the master_mutex (since it also affects
the unique of each master, oh well) we can mark these two IOCTL with
DRM_UNLOCKED.
While doing this I realized that the comment for the magic_map is
outdated, I'v
We can be more clever than that and merge the 2 list walking loops.
It's all under the one mutex critical section anyway, so nothing funny
can happen.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 28 +++-
1 file changed, 11 insertions(+), 17 deleti
Hey
On Fri, Dec 9, 2016 at 2:56 PM, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter to
On 9 December 2016 at 13:56, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter to where we
We thought that no userspace is using them, but oops libdrm is using
them to figure out whether a driver supports modesetting. Check out
drmCheckModesettingSupported but maybe don't because it's horrible and
totally runs counter to where we want to go with libdrm device
handling. The function looks
== Series Details ==
Series: drm/i915: Use the MRU stack search after evicting
URL : https://patchwork.freedesktop.org/series/16613/
State : warning
== Summary ==
Series 16613v1 drm/i915: Use the MRU stack search after evicting
https://patchwork.freedesktop.org/api/1.0/series/16613/revisions/1
On Fri, Dec 09, 2016 at 11:57:34AM +0100, David Herrmann wrote:
> Hi Greg
>
> On Fri, Dec 9, 2016 at 11:53 AM, Greg Kroah-Hartman
> wrote:
> > On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote:
> >> We thought that no userspace is using them, but oops libdrm is using
> >> them to figu
On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote:
> Simple first test to just exercise initialisation of struct drm_mm.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_
Some object retain an extra pin whilst they are active (e.g. contexts).
This excludes them from being considered for eviction unless we idle the
GPU. If before we look at the active list, before we retire we can
hopefully remove a few excess pins and reduce the amount of searching
required..
Signe
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 16d98b31f807756269106f9a71b1a3dc0d19c629
commit: 16d98b31f807756269106f9a71b1a3dc0d19c629 [1/1] drm/i915/perf: More
documentation hooked to i915.rst
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
m
When we evict from the GTT to make room for an object, the hole we
create is put onto the MRU stack inside the drm_mm range manager. On the
next search pass, we can speed up a PIN_HIGH allocation by referencing
that stack for the new hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i91
Check that if we request top-down allocation with a particular alignment
from drm_mm_insert_node() that the start of the node matches our
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 92 ++
On Fri, Dec 09, 2016 at 02:06:29PM +0100, Michal Wajdeczko wrote:
> On Fri, Dec 09, 2016 at 12:49:02PM +0100, Arkadiusz Hiler wrote:
> > On Fri, Dec 09, 2016 at 12:28:52PM +0100, Michal Wajdeczko wrote:
> > > On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote:
> > > > From: Peter Antoine
> >
Check that we can request alignment to any power-of-two or prime using a
plain drm_mm_node_insert().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 3 +
drivers/gpu/drm/test-drm_mm.c | 113 +
2 files changed, 116 insertions(+)
dif
Check that after applying the driver's color adjustment, fitting of the
node and its alignment are still correct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 178 +
2 files changed, 179 inser
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 96 ++
2 files changed, 97 i
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 188 +
2 files changed, 189 insertions(+)
diff --git
Exercise drm_mm_insert_node(), check that we can't overfill a range and
that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 271 +
2 files changed
Exercise drm_mm_reserve_node(), check that we can't reserve an already
occupied range and that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 143
Check that we add arbitrary blocks to the eviction scanner in order to
find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 167 +
2 files changed
Simple first test to just exercise initialisation of struct drm_mm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 41 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_mm_se
On Fri, Dec 09, 2016 at 12:49:02PM +0100, Arkadiusz Hiler wrote:
> On Fri, Dec 09, 2016 at 12:28:52PM +0100, Michal Wajdeczko wrote:
> > On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote:
> > > From: Peter Antoine
> > >
> > > Rename some of the GuC fw loading code to make them more general
On Thu, Dec 08, 2016 at 03:02:19PM -0800, anushasr wrote:
> 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
On Thu, Dec 8, 2016 at 3:53 PM, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 09:40:33PM +, Robert Bragg wrote:
>> This adds a 'Perf' section to i915.rst with the following sub sections:
>> - Overview
>> - Comparison with Core Perf
>> - i915 Driver Entry Points
>> - i915 Perf Stream
>> - i915
On Thu, Dec 08, 2016 at 03:02:18PM -0800, anushasr wrote:
> 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 Fri, Dec 09, 2016 at 12:34:55PM +0100, Arkadiusz Hiler wrote:
> On Fri, Dec 09, 2016 at 11:10:03AM +, Chris Wilson wrote:
> > On Fri, Dec 09, 2016 at 11:56:10AM +0100, Arkadiusz Hiler wrote:
> > > On Thu, Dec 08, 2016 at 03:02:14PM -0800, anushasr wrote:
> > > > -static u32 guc_wopcm_size(st
On Thu, Dec 08, 2016 at 03:02:14PM -0800, anushasr wrote:
> From: Anusha Srivatsa
>
> 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.
>
On Fri, Dec 09, 2016 at 11:48:15AM +, Tvrtko Ursulin wrote:
>
> On 07/12/2016 13:58, Chris Wilson wrote:
> >The requests conversion introduced a nasty bug where we could generate a
> >new request in the middle of constructing a request. The new request
> >would be executed (and waited upon) be
On Thu, Dec 08, 2016 at 03:02:13PM -0800, anushasr wrote:
> 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 pu
On Fri, Dec 09, 2016 at 12:28:52PM +0100, Michal Wajdeczko wrote:
> On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote:
> > 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
On 07/12/2016 13:58, Chris Wilson wrote:
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request. The new request
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting. (Prio
On Fri, Dec 09, 2016 at 11:10:03AM +, Chris Wilson wrote:
> On Fri, Dec 09, 2016 at 11:56:10AM +0100, Arkadiusz Hiler wrote:
> > On Thu, Dec 08, 2016 at 03:02:14PM -0800, anushasr wrote:
> > > -static u32 guc_wopcm_size(struct drm_i915_private *dev_priv)
> > > +u32 guc_wopcm_size(struct drm_i91
On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote:
> 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
1 - 100 of 125 matches
Mail list logo
