I have been working on getting the instrumentation in the kernel so that we
run the DP compliance tests using DPR 120. After adding the necessary code
in the kernel, I am able to run the DP Compliance test suite against our driver.
According to the DP Spec 1.2 and the Compliance tests, for link tr
We've been looking recently at some changes that we can make to allow for
DP MST to be more reliable on i915. The things that we are looking at
are the following.
* Change intel_dp_mst_mode_valid() to validate modes against available
link bandwidth rather than maximum link bandwidth. This is n
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 5ee4c8f064719f5c62ea53f304845f75f87f2804
commit: d25bcfb8c2e18b9b36f037f38be4d4792ebf8d57 [10/25] drm/hisilicon: Don't
set drm_device->platformdev
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc
On Tue, Aug 16, 2016 at 08:04:35PM +0100, Matthew Auld wrote:
> > + if (dst_needs_clflush & CLFLUSH_BEFORE)
> > + batch_len = roundup(batch_len,
> > boot_cpu_data.x86_clflush_size);
> hmm, this bit doesn't seem obvious to me. What am I missing?
The code is optimized to work on
> + if (dst_needs_clflush & CLFLUSH_BEFORE)
> + batch_len = roundup(batch_len,
> boot_cpu_data.x86_clflush_size);
hmm, this bit doesn't seem obvious to me. What am I missing?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Manasi Navare
> Sent: Wednesday, August 10, 2016 12:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 9/9] drm/i915: Enable upfront link training
> support for HSW/
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Manasi Navare
> Sent: Wednesday, August 10, 2016 12:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 8/9] drm/i915: Split hsw_get_dpll()
>
> Split out the Displa
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Manasi Navare
> Sent: Wednesday, August 10, 2016 12:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 7/9] drm/i915/dp: Enable upfront link training on
> SKL
>
> F
On Tue, Aug 16, 2016 at 04:49:26PM +, Zanoni, Paulo R wrote:
> Em Ter, 2016-08-16 às 08:43 +0100, Chris Wilson escreveu:
> > intel_fbc_pre_update() depends upon the new state being already
> > pinned
> > in place in the Global GTT (primarily for both fencing which wants
> > both
> > an offset a
== Series Details ==
Series: Enable lspcon support for GEN9 devices (rev4)
URL : https://patchwork.freedesktop.org/series/8024/
State : warning
== Summary ==
Series 8024v4 Enable lspcon support for GEN9 devices
http://patchwork.freedesktop.org/api/1.0/series/8024/revisions/4/mbox
Test kms_cur
Em Ter, 2016-08-16 às 08:43 +0100, Chris Wilson escreveu:
> intel_fbc_pre_update() depends upon the new state being already
> pinned
> in place in the Global GTT (primarily for both fencing which wants
> both
> an offset and a fence register, if assigned). This requires the call
> to
> intel_fbc_pr
This patch adds lspcon support in dp_dual_mode helper.
lspcon is essentially a dp->hdmi dongle with dual personality.
LS mode: It works as a passive dongle, by level shifting DP++
signals to HDMI signals, in LS mode.
PCON mode: It works as a protocol converter active dongle
in pcon mode, by conver
This patch adds a new file, to accommodate lspcon support
for I915 driver. These functions probe, detect, initialize
and configure an on-board lspcon device during the driver
init time.
Also, this patch adds a small structure for lspcon device,
which will provide the runtime status of the device.
This patch adds initialization code for lspcon.
What we are doing here is:
- Check if lspcon is configured in VBT for this port
- If lspcon is configured, initialize it and configure it
as DP port.
V2: Addressed Ville's review comments:
- Not adding AVI IF functions for L
LSPCON is essentially a dp++->hdmi adapter with dual mode of operation.
These modes are:
- Level Shifter mode: In LS mode, this device works as a type2 dp->hdmi
passive dongle, which steps up DP++ output to appropriate HDMI 1.4 signal.
This mode doesn't do any conversion at the protocol level.
-
Many GEN9 boards come with on-board lspcon cards.
Fot these boards, VBT configuration should properly point out
if a particular port contains lspcon device, so that driver can
initialize it properly.
This patch adds a utility function, which checks the VBT flag
for lspcon bit, and tells us if a po
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Add enum for hardware engine
identifiers
URL : https://patchwork.freedesktop.org/series/11172/
State : failure
== Summary ==
Series 11172v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/11172/re
On Tue, Aug 16, 2016 at 05:04:21PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Build the legacy semaphore initialisation array using the engine
> hardware ids instead of driver internal ones. This makes the
> static array size dependent only on the number of gen6 semaphore
> engines.
From: Tvrtko Ursulin
Put the engine hardware id in the common header so they are
not only associated with the GuC since they are needed for
the legacy semaphores implementation.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 14 +++---
From: Tvrtko Ursulin
Build the legacy semaphore initialisation array using the engine
hardware ids instead of driver internal ones. This makes the
static array size dependent only on the number of gen6 semaphore
engines.
Also makes the per-engine semaphore wait and signal tables
hardware id inde
== Series Details ==
Series: drm/i915: Tidy reporting busy status during i915_gem_retire_requests()
URL : https://patchwork.freedesktop.org/series/11170/
State : failure
== Summary ==
Series 11170v1 drm/i915: Tidy reporting busy status during
i915_gem_retire_requests()
http://patchwork.freede
As we know by inspection whether any engine is still busy as we retire
all the requests, we can pass that information back via return value
rather than check again afterwards.
v2: A little more polish missed in patch splitting
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i
Rather than walk the full array of engines checking whether each is in
the mask in turn, we can use the mask to jump to the right engines. This
should quicker for a sparse array of engines or mask, whilst generating
smaller code:
textdata bss dec hex filename
12510104579
As we know by inspection whether any engine is still busy as we retire
all the requests, we can pass that information back via return value
rather than check again afterwards.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_request.c | 9 +
1 file changed
On Tue, Aug 16, 2016 at 03:59:24PM +0100, Robert Bragg wrote:
>On Mon, Aug 15, 2016 at 3:57 PM, Chris Wilson
> Alternatively you could follow the standard pattern for read. Dare I ask
> what is going to go into state that needs the obfuscation?
>
>I had dug around a bit when I wa
On Mon, Aug 15, 2016 at 3:57 PM, Chris Wilson
wrote:
> On Mon, Aug 15, 2016 at 03:41:18PM +0100, 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 s
Chris Wilson writes:
> If userspace is asynchronously streaming into the batch or other
> execobjects, we may not flush those writes along with a change in cache
> domain (as there is no change). Therefore those writes may end up in
> internal chipset buffers and not visible to the GPU upon execu
== Series Details ==
Series: agp/intel: Flush chipset writes after updating a single PTE
URL : https://patchwork.freedesktop.org/series/11164/
State : failure
== Summary ==
Series 11164v1 agp/intel: Flush chipset writes after updating a single PTE
http://patchwork.freedesktop.org/api/1.0/serie
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> Now that we have WC vmapping available, we can bind our rings anywhere
> in the GGTT and do not need to restrict them to the mappable region.
> Except for stolen objects, for which direct access is verbatim and we
> must use the mappable apert
After we update one PTE for a page, the caller expects to be able to
immediately use that through a GGTT read/write. To comply with the
callers expectations we therefore need to flush the chipset buffers
before returning.
Reported-by: Matti Hämäläinen
Fixes: d6473f566417 ("drm/i915: Add support f
On ti, 2016-08-16 at 13:02 +0100, Chris Wilson wrote:
> On Tue, Aug 16, 2016 at 02:57:15PM +0300, Joonas Lahtinen wrote:
> >
> > On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> > >
> > > @@ -622,6 +622,12 @@ int i915_gem_obj_prepare_shmem_read(struct
> > > drm_i915_gem_object *obj,
> > >
== Series Details ==
Series: drm/i915: Unconditionally flush any chipset buffers before execbuf
URL : https://patchwork.freedesktop.org/series/11160/
State : failure
== Summary ==
Series 11160v1 drm/i915: Unconditionally flush any chipset buffers before
execbuf
http://patchwork.freedesktop.or
On 8/16/2016 4:57 PM, Tvrtko Ursulin wrote:
On 15/08/16 15:49, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
Before capturing the GuC logs as a part of error state, there should be a
force log buffer flush action sent to GuC before proceeding with GPU
reset
and re-initializing GUC. Th
If userspace is asynchronously streaming into the batch or other
execobjects, we may not flush those writes along with a change in cache
domain (as there is no change). Therefore those writes may end up in
internal chipset buffers and not visible to the GPU upon execution. We
must issue a flush com
Matthew Auld writes:
> But in the bug report the pciid=0x5916 and rev=0x0, which makes it KBL
> A0, right? So something else must be going on here.
You are right. This patch can't affect the bug in question.
I haven't yet found a similar machine so it is still mystery why the
write doesn't stick
On Tue, Aug 16, 2016 at 02:04:21PM +0300, Jani Nikula wrote:
>
> Reviewed-by: Jani Nikula
Applied to drm-misc, thanks.
-Daniel
>
>
> On Mon, 15 Aug 2016, Eric Engestrom wrote:
> > Signed-off-by: Eric Engestrom
> > ---
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
> > drivers/
On Tue, Aug 16, 2016 at 02:57:15PM +0300, Joonas Lahtinen wrote:
> On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> > @@ -622,6 +622,12 @@ int i915_gem_obj_prepare_shmem_read(struct
> > drm_i915_gem_object *obj,
> > if (ret)
> > return ret;
> >
> > + ret = i915_gem_objec
On Tue, 16 Aug 2016, Tvrtko Ursulin wrote:
On 16/08/16 12:18, Peter Antoine wrote:
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 us
== Series Details ==
Series: HuC/GuC status to Get Params.
URL : https://patchwork.freedesktop.org/series/11158/
State : failure
== Summary ==
Applying: drm/i915/get_params: Add GuC status to getparams
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/i915_drv.c
M
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> @@ -622,6 +622,12 @@ int i915_gem_obj_prepare_shmem_read(struct
> drm_i915_gem_object *obj,
> if (ret)
> return ret;
>
> + ret = i915_gem_object_get_pages(obj);
> + if (ret)
> + return ret;
> +
> +
== Series Details ==
Series: HuC Loading Patches
URL : https://patchwork.freedesktop.org/series/11157/
State : failure
== Summary ==
Series 11157v1 HuC Loading Patches
http://patchwork.freedesktop.org/api/1.0/series/11157/revisions/1/mbox
Test drv_module_reload_basic:
pass
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> As we cannot access the backing pages behind stolen objects, we should
> not attempt to do so for relocations.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> @@ -1949,10 +1949,8 @@ intel_ring_create_vma(struct drm_i915_private
> *dev_priv, int size)
> struct drm_i915_gem_object *obj;
> struct i915_vma *vma;
>
> - obj = ERR_PTR(-ENODEV);
> - if (!HAS_LLC(dev_priv))
> -
On Tue, Aug 16, 2016 at 02:31:00PM +0300, Joonas Lahtinen wrote:
> On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> > @@ -1751,6 +1759,12 @@ int i915_gem_fault(struct vm_area_struct *area,
> > struct vm_fault *vmf)
> > (area->vm_end - area->vm_start) / PAGE_SIZE -
On Mon, 15 Aug 2016 08:39:29 +0200
Daniel Vetter wrote:
> On Sun, Aug 14, 2016 at 11:01:35PM +0900, Masami Hiramatsu wrote:
> > Hello,
> >
> > I've found a suspicious circular locking dependency in i915 by lockdep.
> > It seems main driver initialization thread and sub fbdev configuration
> > th
On Mon, 2016-08-15 at 15:34 +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> >
> > On Mon, Aug 15, 2016 at 02:48:06PM +0300, Mika Kuoppala wrote:
> > >
> > > From: Jesse Barnes
> > >
> > > We just need to pass in an address to execute and some flags,
> > > since we
> > > don't have to w
Hello,
I've found a suspicious circular locking dependency in i915 by lockdep.
It seems main driver initialization thread and sub fbdev configuration
thread take locks in different order implicitly. Please check it.
The lockdep report is here.
[4.254984] =
On Mon, 2016-08-15 at 13:56 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 03:25:43PM +0300, Mika Kuoppala wrote:
> >
> > Chris Wilson writes:
> >
> > >
> > > On Mon, Aug 15, 2016 at 02:48:04PM +0300, Mika Kuoppala wrote:
> > > >
> > > > From: Jesse Barnes
> > > >
> > > > Add i915_gem_
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> Our current practice is to only name the actual list (here
> dev_priv->fence_list) using "list", and elements upon that list are
> referred to as "link". Further, the lru nature is of the list and not of
> the node and including in the name do
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> In order to handle tiled partial GTT mmappings, we need to associate the
> fence with an individual vma.
>
> v2: A couple of silly drops replaced spotted by Joonas
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Sourc
On 16/08/16 12:18, Peter Antoine wrote:
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 Hu
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> @@ -1751,6 +1759,12 @@ int i915_gem_fault(struct vm_area_struct *area, struct
> vm_fault *vmf)
> (area->vm_end - area->vm_start) / PAGE_SIZE -
> partial.params.partial.offset);
>
> +
On 15/08/16 15:49, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
Before capturing the GuC logs as a part of error state, there should be a
force log buffer flush action sent to GuC before proceeding with GPU reset
and re-initializing GUC. There could be some data in the log buffer which
== Series Details ==
Series: series starting with [01/22] drm/i915: Cache kmap between relocations
URL : https://patchwork.freedesktop.org/series/11156/
State : failure
== Summary ==
Series 11156v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/11156/revisions/1/mb
On Sat, 13 Aug 2016, Anusha Srivatsa wrote:
> Validate the modes against available link bandwidth rather than
> maximum link bandwidth so that we have a better idea as to whether
> a proposed mode can truly run beside existing stream.
But if the existing link was trained for the existing stream,
On Sat, 13 Aug 2016, kbuild test robot wrote:
> Hi Anusha,
>
> [auto build test ERROR on drm/drm-next]
> [also build test ERROR on v4.8-rc1 next-20160812]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> We track the LRU access for eviction and bump the last access for the
> user GGTT on set-to-gtt. When we do so we need to not only bump the
> primary GGTT VMA but all partials as well. Similarly we want to
> bump the last access tracking for w
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 it is
loaded and is not
This patch returns the GuC status to the caller. It is used so
that the userspace knows if the GuC has been loaded.
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/intel_guc.h| 2 +-
drivers/gpu/drm/i915/intel_guc_loader.c | 19 ++
As it states on the tin. Add the HuC/GuC patches to the Get params so
that they can be accessed from userspace. This is a requirement for the
opensourcing of media codecs that require the HuC/GuC.
These patches require the HuC enabling patches. patchset: HuC Loading Patches.
Peter Antoine (2):
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-nightly
v3: rebased on-top
This patch series enables the HuC loading. These patches are a port of the
patches that were created by Yu Dai (Alex) and have been ported to work with
the new GuC patches.
The series include a patch to enable the HuC on BXT. This is a separate patch
as the state of the BXT HuC firmware is still i
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 the guc call. (D.Gordon
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: rebased.
Signed-off-b
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' either is renamed to '
Add debugfs entry for HuC loading status check.
v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 +
1 file changed, 33 insertion
This patch adds the HuC Loading for the BXT.
Version 1.7 of the HuC firmware.
v2: rebased.
v3: rebased.
changed file name to match the install package format.
Signed-off-by: Peter Antoine
Reviewed-by: David Gordon
---
drivers/gpu/drm/i915/intel_huc_loader.c | 7 +++
1 file changed, 7 i
Reviewed-by: Jani Nikula
On Mon, 15 Aug 2016, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gp
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Aug 16, 2016 at 11:50:29AM +0100, Matthew Auld wrote:
> > + if (dst_needs_clflush & CLFLUSH_BEFORE)
> > + batch_len = roundup(batch_len,
> > boot_cpu_data.x86_clflush_size);
> > +
> > memcpy(dst, src, batch_len);
> >
> > + /* dst_obj is returned with vmap
> + if (dst_needs_clflush & CLFLUSH_BEFORE)
> + batch_len = roundup(batch_len,
> boot_cpu_data.x86_clflush_size);
> +
> memcpy(dst, src, batch_len);
>
> + /* dst_obj is returned with vmap pinned */
> + *needs_clflush_after = dst_needs_clflush & CLFLUSH_AFTER
There is an improbable, but not impossible, case that if we leave the
pages unpin as we operate on the object, then somebody via the shrinker
may steal the lock (which lock? right now, it is struct_mutex, THE lock)
and change the cache domains after we have already inspected them.
(Whilst here, av
By moving map-and-fenceable tracking from the object to the VMA, we gain
fine-grained tracking and the ability to track individual fences on the VMA
(subsequent patch).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 6 -
drivers/gp
The existing ABI says that scanouts are pinned into the mappable region
so that legacy clients (e.g. old Xorg or plymouthd) can write directly
into the scanout through a GTT mapping. However if the surface does not
fit into the mappable region, we are better off just trying to fit it
anywhere and h
If we want to read the pages directly via the CPU, we have to be sure
that we have to flush the writes via the GTT (as the CPU can not see
the address aliasing).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+
If we cannot pin the entire object into the mappable region of the GTT,
try to pin a single page instead. This is much more likely to succeed,
and prevents us falling back to the clflush slow path.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 61 ++
If we quickly switch from writing through the GTT to a read of the
physical page directly with the CPU (e.g. performing relocations through
the GTT and then running the command parser), we can observe that the
writes are not visible to the CPU. It is not a coherency problem, as
extensive investigat
This is a companion to i915_gem_obj_prepare_shmem_read() that prepares
the backing storage for direct writes. It first serialises with the GPU,
pins the backing storage and then indicates what clfushes are required in
order for the writes to be coherent.
Whilst here, fix support for ancient CPUs w
In order to support setting up fences for partial mappings of an object,
we have to align those mappings with the fence. The minimum chunksize we
choose is at least the size of a single tile row.
v2: Make minimum chunk size a define for later use
Signed-off-by: Chris Wilson
Reviewed-by: Joonas L
Often times we do not want to evict mapped objects from the GGTT as
these are quite expensive to teardown and frequently reused (causing an
equally, if not more so, expensive setup). In particular, when faulting
in a new object we want to avoid evicting an active object, or else we
may trigger a pa
We want to always use the partial VMA as a fallback for a failure to
bind the object into the GGTT. This extends the support partial objects
in the GGTT to cover everything, not just objects too large.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c
Since we know the write domain, we can drop the local variable and make
the code look a tiny bit simpler.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu
Since commit 43566dedde54 ("drm/i915: Broaden application of
set-domain(GTT)") we allowed objects to be in the GTT domain, but unbound.
Therefore removing the GTT cache domain when removing the GGTT vma is no
longer semantically correct.
An unfortunate side-effect is we lose the wondrously named
i
If we have stolen available, make use of it for ringbuffer allocation.
Previously this was restricted to !llc platforms, as writing to stolen
requires a GGTT mapping - but now that we have partial mappable support,
the mappable aperture isn't quite so precious so we can use it more
freely and ringb
In order to handle tiled partial GTT mmappings, we need to associate the
fence with an individual vma.
v2: A couple of silly drops replaced spotted by Joonas
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 16 +-
drivers/gpu/drm/i915/i915_drv.h| 82 +++
We track the LRU access for eviction and bump the last access for the
user GGTT on set-to-gtt. When we do so we need to not only bump the
primary GGTT VMA but all partials as well. Similarly we want to
bump the last access tracking for when unpinning an object from the
scanout so that they do not g
Our current practice is to only name the actual list (here
dev_priv->fence_list) using "list", and elements upon that list are
referred to as "link". Further, the lru nature is of the list and not of
the node and including in the name does not disambiguate the link from
anything else.
Signed-off-b
When using the aliasing ppgtt and pageflipping with the shrinker/eviction
active, we note that we often have to rebind the backbuffer before
flipping onto the scanout because it has an invalid alignment. If we
store the worst-case alignment required for a VMA, we can avoid having
to rebind at criti
With the introduction of the reloc page cache, we are just one step away
from refactoring the relocation write functions into one. Not only does
it tidy the code (slightly), but it greatly simplifies the control logic
much to gcc's satisfaction.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i9
Now that we have WC vmapping available, we can bind our rings anywhere
in the GGTT and do not need to restrict them to the mappable region.
Except for stolen objects, for which direct access is verbatim and we
must use the mappable aperture.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i
When doing relocations, we have to obtain a mapping to the page
containing the target address. This is either a kmap or iomap depending
on GPU and its cache coherency. Neighbouring relocation entries are
typically within the same page and so we can cache our kmapping between
them and avoid those pe
As we cannot access the backing pages behind stolen objects, we should
not attempt to do so for relocations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu
Keep any error reported by the gup_worker until we are notified that the
arena has changed (via the mmu-notifier). This has the importance of
making two consecutive calls to i915_gem_object_get_pages() reporting
the same error, and curtailing a loop of detecting a fault and requeueing
a gup_worker.
And fixing up the execbuf incoherency issue, which gets us to the
starting point for cmdparser and execbuf regressions which impact yet
again on how we lookup/store the VMA.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.
On ma, 2016-08-15 at 19:06 +0100, Chris Wilson wrote:
> Just make the logic simple enough for even GCC to understand (and
> foolproof against random changes):
>
> drivers/gpu/drm/i915/intel_runtime_pm.c: warning: 'cmn_a_well' may be
> used uninitialized in this function [-Wuninitialized]: => 871:
On 16/08/16 10:39, Goel, Akash wrote:
On 8/16/2016 2:55 PM, Tvrtko Ursulin wrote:
On 16/08/16 06:25, Goel, Akash wrote:
On 8/15/2016 9:18 PM, Tvrtko Ursulin wrote:
On 15/08/16 15:49, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
Before capturing the GuC logs as a part of error sta
On 8/16/2016 2:55 PM, Tvrtko Ursulin wrote:
On 16/08/16 06:25, Goel, Akash wrote:
On 8/15/2016 9:18 PM, Tvrtko Ursulin wrote:
On 15/08/16 15:49, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
Before capturing the GuC logs as a part of error state, there should
be a
force log buffer f
On 16/08/16 06:25, Goel, Akash wrote:
On 8/15/2016 9:18 PM, Tvrtko Ursulin wrote:
On 15/08/16 15:49, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
Before capturing the GuC logs as a part of error state, there should
be a
force log buffer flush action sent to GuC before proceeding with
== Series Details ==
Series: drm/i915: Embrace the race in busy-ioctl (rev2)
URL : https://patchwork.freedesktop.org/series/11034/
State : failure
== Summary ==
Series 11034v2 drm/i915: Embrace the race in busy-ioctl
http://patchwork.freedesktop.org/api/1.0/series/11034/revisions/2/mbox
Test
Daniel Vetter proposed a new challenge to the serialisation inside the
busy-ioctl that exposed a flaw that could result in us reporting the
wrong engine as being busy. If the request is reallocated as we test
its busyness and then reassigned to this object by another thread, we
would not notice tha
1 - 100 of 105 matches
Mail list logo
