== Series Details ==
Series: Refactor to expand subslice mask (rev 2)
URL : https://patchwork.freedesktop.org/series/64858/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6649_full -> Patchwork_13905_full
Summary
---
Hi John,
john.hubb...@gmail.com writes:
> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
> b/arch/powerpc/mm/book3s64/iommu_api.c
> index b056cae3388b..e126193ba295 100644
> --- a/arch/powerpc/mm/book3s64/iommu_api.c
> +++ b/arch/powerpc/mm/book3s64/iommu_api.c
> @@ -203,6 +202,7 @@ static
== Series Details ==
Series: drm/i915/perf: Refactor oa object to better manage resources (rev6)
URL : https://patchwork.freedesktop.org/series/60176/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6649_full -> Patchwork_13904_full
000
bfe0: 0013
Code: e59f00a0 e1a09003 e1a08002 eb176e54 (e5955018)
---[ end trace f503b374936886c5 ]---
Bisect log attached.
Guenter
---
# bad: [3880be629e26f6c407593602398c6651860d5fae] Add linux-next specific files
for 201
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> > On Fri 02-08-19 12:14:09, John Hubbard wrote:
> > > On 8/2/19 7:52 AM, Jan Kara wrote:
> > > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > > > On Fri, Aug 02, 2019 at 02:41:46PM
== Series Details ==
Series: Display uncore (rev3)
URL : https://patchwork.freedesktop.org/series/61735/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6652 -> Patchwork_13910
Summary
---
**SUCCESS**
No
== Series Details ==
Series: Display uncore (rev3)
URL : https://patchwork.freedesktop.org/series/61735/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: split out uncore_mmio_debug
+drivers/gpu/drm/i915/intel_uncore.c:1231:1: warning: context
== Series Details ==
Series: Display uncore (rev3)
URL : https://patchwork.freedesktop.org/series/61735/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a5d4c467f066 drm/i915: split out uncore_mmio_debug
b11140f433d2 drm/i915: introduce display_uncore
-:21:
As an example of usage of the new accessors
Signed-off-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/display/intel_display_reg.h | 44 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 32 +++---
drivers/gpu/drm/i915/i915_reg.h | 44 ---
A forcewake-less uncore to be used to decouple GT accesses from display
ones to avoid serializing them when there is no need.
New accessors that implicitly use the new uncore have also been added.
To avoid accessing the same register from 2 different uncores (which
could cause hard hangs), the
Multiple uncore structures will share the debug infrastructure, so
move it to a common place and add extra locking around it.
Also, since we now have a separate object, it is cleaner to have
dedicated functions working on the object to stop and restart the
mmio debug. Apart from the cosmetic
I've been trying to identify MMIO ranges to clearly define what belongs
to display_uncore to do a check on access, but there are lots of
exceptions and differences across gens (with a few more coming with TGL),
so I don't think that's a viable way. The alternative option implemented
here is to
On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > Though personally I'm averse to managing "f"objects through
> > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > on the virtual address of
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> that mapping must have been decided previously). In Google we do use
> fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> one day I'll get to upstreaming those.
That'd be nice - we could kill the i915 wierd
== Series Details ==
Series: series starting with [v4,1/2] drm/i915: Get transcoder power domain
before reading its register
URL : https://patchwork.freedesktop.org/series/64877/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6652 -> Patchwork_13909
== Series Details ==
Series: drm/i915/vlv: allocate Gunit s0ix state on demand
URL : https://patchwork.freedesktop.org/series/64844/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6648_full -> Patchwork_13902_full
Summary
On Wed, Aug 07, 2019 at 05:49:35PM -0700, Jose Souza wrote:
On TGL this register do not map directly to port, it was already
handled when setting it(TGL_TRANS_DDI_SELECT_PORT()) but not when
reading it.
To make it consisntent adding a macro for the older gens too.
v2:
Adding
== Series Details ==
Series: series starting with [v4,1/2] drm/i915: Get transcoder power domain
before reading its register
URL : https://patchwork.freedesktop.org/series/64877/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d586d972be03 drm/i915: Get transcoder power domain
When getting the pipes attached to encoder if it is not a eDP encoder
it iterates over all pipes and read a transcoder register.
But it should not read a transcoder register before get its power
domain.
It was not a issue in gens older than 12 because if it only had
port A connected it would be
On TGL this register do not map directly to port, it was already
handled when setting it(TGL_TRANS_DDI_SELECT_PORT()) but not when
reading it.
To make it consisntent adding a macro for the older gens too.
v2:
Adding TGL_PORT_TRANS_DDI_SELECT() so all future users can reuse it
(Lucas)
v3:
Missed
== Series Details ==
Series: drm/i915: Isolate i915_getparam_ioctl()
URL : https://patchwork.freedesktop.org/series/64840/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6648_full -> Patchwork_13901_full
Summary
---
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.3-rc3 next-20190807]
[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-ci/linux
On Thu, 2019-08-08 at 00:12 +0100, Chris Wilson wrote:
> Quoting Stuart Summers (2019-08-08 00:00:17)
> > On Wed, 2019-08-07 at 23:01 +0100, Chris Wilson wrote:
> > > Quoting Stuart Summers (2019-08-07 22:48:55)
> > > > On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote:
> > > > > Quoting
Quoting Stuart Summers (2019-08-08 00:00:17)
> On Wed, 2019-08-07 at 23:01 +0100, Chris Wilson wrote:
> > Quoting Stuart Summers (2019-08-07 22:48:55)
> > > On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote:
> > > > Quoting Stuart Summers (2019-08-07 21:55:55)
> > > > > User applications might
On Wed, 2019-08-07 at 23:01 +0100, Chris Wilson wrote:
> Quoting Stuart Summers (2019-08-07 22:48:55)
> > On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote:
> > > Quoting Stuart Summers (2019-08-07 21:55:55)
> > > > User applications might need to verify hardware configuration
> > > > of the
Quoting Stuart Summers (2019-08-07 17:58:29)
> Add a new function to determine whether a particular slice
> has a given subslice.
> +static inline bool
> +intel_sseu_has_subslice(const struct sseu_dev_info *sseu, int slice,
> + int subslice)
> +{
> + u8 mask =
Quoting Stuart Summers (2019-08-07 22:48:55)
> On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote:
> > Quoting Stuart Summers (2019-08-07 21:55:55)
> > > User applications might need to verify hardware configuration
> > > of the MOCS entries. To facilitate this debug, add a new debugfs
> > >
On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote:
> Quoting Stuart Summers (2019-08-07 21:55:55)
> > User applications might need to verify hardware configuration
> > of the MOCS entries. To facilitate this debug, add a new debugfs
> > entry to allow a dump of the MOCS state to verify
On Wed, Aug 07, 2019 at 01:55:55PM -0700, Stuart Summers wrote:
> User applications might need to verify hardware configuration
> of the MOCS entries. To facilitate this debug, add a new debugfs
> entry to allow a dump of the MOCS state to verify expected values
> are set by i915.
>
>
Quoting Stuart Summers (2019-08-07 21:55:55)
> User applications might need to verify hardware configuration
> of the MOCS entries. To facilitate this debug, add a new debugfs
> entry to allow a dump of the MOCS state to verify expected values
> are set by i915.
User applications + debugfs? It's
== Series Details ==
Series: series starting with [1/2] drm/i915: Add MOCS state dump to debugfs
URL : https://patchwork.freedesktop.org/series/64868/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6651 -> Patchwork_13908
== Series Details ==
Series: drm/i915: split out intel_pch.[ch] from i915_drv.[ch]
URL : https://patchwork.freedesktop.org/series/64833/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6646_full -> Patchwork_13899_full
On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> > Hi Daniel,
> >
> > those fails look like something random to me and not related to my patch
> > set. Correct?
>
> First one I looked at has the reservation_obj
On Wed, Aug 07, 2019 at 03:01:59PM +0100, Chris Wilson wrote:
> Quoting Christian König (2019-08-07 14:54:05)
> > The ruc and cb_list are never used at the same time.
> > This smal change is actually making the structure 16% smaller.
> (Trivial pair of typos)
>
> Yes. We clear the callback list
On Wed, Aug 07, 2019 at 07:43:18AM +, Lisovskiy, Stanislav wrote:
> On Tue, 2019-08-06 at 19:43 +0200, Daniel Vetter wrote:
> > On Tue, Aug 6, 2019 at 4:06 PM Lisovskiy, Stanislav
> > wrote:
> > >
> > > On Tue, 2019-08-06 at 15:51 +0200, Daniel Vetter wrote:
> > > > On Tue, Aug 06, 2019 at
Reduce code by defaulting to true in the MOCS settings
initialization function. Set to false for unexpected
platforms.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
User applications might need to verify hardware configuration
of the MOCS entries. To facilitate this debug, add a new debugfs
entry to allow a dump of the MOCS state to verify expected values
are set by i915.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 50
On Fri, Jun 14, 2019 at 08:10:20AM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
Not sure this works, 2 thoughts way down ...
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 27 +--
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 -
>
Quoting Patchwork (2019-08-07 20:42:47)
> == Series Details ==
>
> Series: Hardening firmware fetch (rev2)
> URL : https://patchwork.freedesktop.org/series/64856/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13907
>
== Series Details ==
Series: drm/i915: Include the DRIVER_DATE in the error state
URL : https://patchwork.freedesktop.org/series/64832/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6646_full -> Patchwork_13898_full
On Wed, 07 Aug 2019 22:21:29 +0200, Kumar Valsan, Prathap
wrote:
On Wed, Aug 07, 2019 at 05:00:29PM +, Michal Wajdeczko wrote:
There is no point in selecting HuC firmware if GuC is unsupported
or it was already disabled, as we need GuC to authenticate HuC.
We are calling
On Wed, Aug 07, 2019 at 05:00:29PM +, Michal Wajdeczko wrote:
> There is no point in selecting HuC firmware if GuC is unsupported
> or it was already disabled, as we need GuC to authenticate HuC.
>
We are calling intel_uc_init() irrespctive of intel_uc_fetch_firmwares() is
successful. Is
== Series Details ==
Series: Hardening firmware fetch (rev2)
URL : https://patchwork.freedesktop.org/series/64856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13907
Summary
---
**SUCCESS**
No
Quoting Umesh Nerlige Ramappa (2019-08-07 00:30:02)
> The oa object manages the oa buffer and must be allocated when the user
> intends to read performance counter snapshots. This can be achieved by
> making the oa object part of the stream object which is allocated when a
> stream is opened by
== Series Details ==
Series: drm/i915/execlists: Always request completion before marking an error
URL : https://patchwork.freedesktop.org/series/64859/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13906
== Series Details ==
Series: series starting with [v3] drm/i915: Rename engines to match their user
interface (rev3)
URL : https://patchwork.freedesktop.org/series/64824/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6646_full -> Patchwork_13897_full
== Series Details ==
Series: Refactor to expand subslice mask (rev 2)
URL : https://patchwork.freedesktop.org/series/64858/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13905
Summary
---
Quoting Michal Wajdeczko (2019-08-07 19:37:59)
> Insert few more failure points into firmware fetch procedure to check
> use of the wrong blob name or use of the mismatched firmware versions.
>
> Also update some messages (remove ptr, duplicated infos) and stop
> treating all fetch errors as
Insert few more failure points into firmware fetch procedure to check
use of the wrong blob name or use of the mismatched firmware versions.
Also update some messages (remove ptr, duplicated infos) and stop
treating all fetch errors as missing firmware case.
v2: update log levels (Chris)
== Series Details ==
Series: drm/i915/perf: Refactor oa object to better manage resources (rev6)
URL : https://patchwork.freedesktop.org/series/60176/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13904
== Series Details ==
Series: Hardening firmware fetch
URL : https://patchwork.freedesktop.org/series/64856/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13903
Summary
---
**FAILURE**
Serious
== Series Details ==
Series: Refactor to expand subslice mask (rev 2)
URL : https://patchwork.freedesktop.org/series/64858/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
98fa1b8ef9ca drm/i915: Use variable for debugfs device status
73dd1f518679 drm/i915: Add function to set
On Wed, 2019-08-07 at 15:04 +0300, Jani Nikula wrote:
> Abstract the rather self-contained piece of code from i915_drv.[ch].
> No
> functional changes.
>
Reviewed-by: José Roberto de Souza
> Cc: José Roberto de Souza
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Jani Nikula
> ---
>
== Series Details ==
Series: drm/i915/perf: Refactor oa object to better manage resources (rev6)
URL : https://patchwork.freedesktop.org/series/60176/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: Refactor oa object to better manage
== Series Details ==
Series: drm/i915/perf: Refactor oa object to better manage resources (rev6)
URL : https://patchwork.freedesktop.org/series/60176/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ae33771060e0 drm/i915/perf: Refactor oa object to better manage resources
-:523:
Quoting Michal Wajdeczko (2019-08-07 18:00:34)
> Insert few more failure points into firmware fetch procedure to check
> use of the wrong blob name or use of the mismatched firmware versions.
>
> Also update some messages (remove ptr, duplicated infos) and stop
> treating all fetch errors as
Quoting Michal Wajdeczko (2019-08-07 18:00:33)
> WOPCM programming error might be due to inserted earlier probe
> failure that could affects HuC firmware loading and thus impacts
> result of WOPCM partitioning that would be now incompatible with
> previously programmed values.
>
> Signed-off-by:
Quoting Michal Wajdeczko (2019-08-07 18:00:32)
> No need to define it globally as we're only using it in wopcm.c
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx
Quoting Michal Wajdeczko (2019-08-07 18:00:31)
> For meaningful WOPCM partitioning we need GuC (and optionally HuC)
> firmware size(s) and we shouldn't just rely on GuC support flag,
> as we might fail to fetch GuC firmware and it's size will be 0
> and all calculations will be just wrong/useless.
Quoting Michal Wajdeczko (2019-08-07 18:00:30)
> When we failed to fetch GuC firmware there is no point in fetching
> HuC firmware as we will not be able to use it without working GuC.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> ---
>
Quoting Michal Wajdeczko (2019-08-07 18:00:29)
> There is no point in selecting HuC firmware if GuC is unsupported
> or it was already disabled, as we need GuC to authenticate HuC.
Makes sense.
> While around, make uc_fw_init_early work without direct access
> to whole i915, pass only needed
Quoting Michal Wajdeczko (2019-08-07 18:00:28)
> While modparams are global for the i915 module, we are reporting
> status of the params applied against specific device instance.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> ---
>
Due to fun and games in our preempt-to-busy, it is possible for a
request to be completed in the background. Be vigilant and avoid setting
an error on already signaled request, as dma_fence_set_error() throws a
warning.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 21
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, August 7, 2019 9:51 AM
> To: Bloomfield, Jon ; intel-
> g...@lists.freedesktop.org
> Cc: Joonas Lahtinen ; Winiarski, Michal
>
> Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
>
> Quoting
Add a new SSEU runtime parameter, eu_stride, which is
used to mirror the userspace concept of a range of EUs
per subslice.
This patch simply adds the parameter and updates usage
in the QUERY_TOPOLOGY_INFO handler.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 1 +
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice
Add a new function to determine whether a particular slice
has a given subslice.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.h | 10 ++
drivers/gpu/drm/i915/intel_device_info.c | 9 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git
Add a new function to allow each platform to set maximum
slice, subslice, and EU information to reduce code duplication.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 8 +
drivers/gpu/drm/i915/gt/intel_sseu.h | 3 ++
drivers/gpu/drm/i915/i915_debugfs.c
Add a new function to set a range of subslices for a
specified slice based on a given mask.
v2: Use local variable for subslice_mask on HSW and
clean up a few other subslice_mask local variable
changes
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 10
Add a new parameter, ss_stride, to the runtime info
structure. This is used to mirror the userspace concept
of subslice stride, which is a range of subslices per slice.
This patch simply adds the definition and updates usage
in the QUERY_TOPOLOGY_INFO handler.
Signed-off-by: Stuart Summers
---
Refactor instdone loops to use the new intel_sseu_has_subslice
function.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 31 ++--
drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +-
Use a local variable to find SSEU runtime information
in various debugfs functions.
v2: Remove extra line breaks per feedback from Chris
Signed-off-by: Stuart Summers
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 +++---
1 file changed, 11
Add a new function to copy subslices for a specified slice
between intel_sseu structures for the purpose of determining
power-gate status.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git
Insert few more failure points into firmware fetch procedure to check
use of the wrong blob name or use of the mismatched firmware versions.
Also update some messages (remove ptr, duplicated infos) and stop
treating all fetch errors as missing firmware case.
Signed-off-by: Michal Wajdeczko
Cc:
No need to define it globally as we're only using it in wopcm.c
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 5 -
drivers/gpu/drm/i915/intel_wopcm.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff
For meaningful WOPCM partitioning we need GuC (and optionally HuC)
firmware size(s) and we shouldn't just rely on GuC support flag,
as we might fail to fetch GuC firmware and it's size will be 0
and all calculations will be just wrong/useless.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo
There is no point in selecting HuC firmware if GuC is unsupported
or it was already disabled, as we need GuC to authenticate HuC.
While around, make uc_fw_init_early work without direct access
to whole i915, pass only needed platform/rev info.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo
WOPCM programming error might be due to inserted earlier probe
failure that could affects HuC firmware loading and thus impacts
result of WOPCM partitioning that would be now incompatible with
previously programmed values.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris
While modparams are global for the i915 module, we are reporting
status of the params applied against specific device instance.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 25 -
1 file changed,
When we failed to fetch GuC firmware there is no point in fetching
HuC firmware as we will not be able to use it without working GuC.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 5 -
More probe failures inside uc loading path.
Michal Wajdeczko (7):
drm/i915/uc: Prefer dev_info for reporting options
drm/i915/uc: HuC firmware can't be supported without GuC
drm/i915/uc: Don't fetch HuC fw if GuC fw fetch already failed
drm/i915: Don't try to partition WOPCM without GuC
== Series Details ==
Series: drm/i915: Drop expectations of VM_IO from our GGTT mmappings
URL : https://patchwork.freedesktop.org/series/64828/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6644_full -> Patchwork_13896_full
Quoting Bloomfield, Jon (2019-08-07 16:29:55)
> > -Original Message-
> > From: Chris Wilson
> > Sent: Wednesday, August 7, 2019 8:08 AM
> > To: Bloomfield, Jon ; intel-
> > g...@lists.freedesktop.org
> > Cc: Joonas Lahtinen ; Winiarski, Michal
> >
> > Subject: RE: [PATCH 5/5] drm/i915:
Quoting Christian König (2019-08-07 14:53:11)
> Other cores don't busy wait any more and we removed the last user of checking
> the seqno for changes. Drop updating the number for shared fences altogether.
>
> Signed-off-by: Christian König
Reviewed-by: Chris Wilson
> ---
>
Quoting Christian König (2019-08-07 14:53:10)
> Instead of open coding the sequence loop use the new helper.
>
> Signed-off-by: Christian König
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Quoting Christian König (2019-08-07 14:53:09)
> Add a new helper to get a consistent set of pointers from the reservation
> object. While at it group all access helpers together in the header file.
>
> v2: correctly return shared_count as well
>
> Signed-off-by: Christian König
Reviewed-by:
== Series Details ==
Series: drm/i915/vlv: allocate Gunit s0ix state on demand
URL : https://patchwork.freedesktop.org/series/64844/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6648 -> Patchwork_13902
Summary
---
== Series Details ==
Series: drm/i915: Isolate i915_getparam_ioctl()
URL : https://patchwork.freedesktop.org/series/64840/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6648 -> Patchwork_13901
Summary
---
Quoting Bloomfield, Jon (2019-08-07 16:29:55)
> > -Original Message-
> > From: Chris Wilson
> > Sent: Wednesday, August 7, 2019 8:08 AM
> > To: Bloomfield, Jon ; intel-
> > g...@lists.freedesktop.org
> > Cc: Joonas Lahtinen ; Winiarski, Michal
> >
> > Subject: RE: [PATCH 5/5] drm/i915:
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, August 7, 2019 8:08 AM
> To: Bloomfield, Jon ; intel-
> g...@lists.freedesktop.org
> Cc: Joonas Lahtinen ; Winiarski, Michal
>
> Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
>
> Quoting
Quoting Mika Kuoppala (2019-08-07 16:04:56)
> Chris Wilson writes:
> > -static int intel_gt_park(struct intel_wakeref *wf)
> > +static int __gt_park(struct intel_wakeref *wf)
> > {
> > struct drm_i915_private *i915 =
> > container_of(wf, typeof(*i915), gt.wakeref);
> > @@
Quoting Bloomfield, Jon (2019-08-07 15:33:51)
[skip to end]
> We didn't explore the idea of terminating orphaned contexts though (where
> none of their resources are referenced by any other contexts). Is there a
> reason why this is not feasible? In the case of compute (certainly HPC)
>
Chris Wilson writes:
> As we need to acquire a mutex to serialise the final
> intel_wakeref_put, we need to ensure that we are in process context at
> that time. However, we want to allow operation on the intel_wakeref from
> inside timer and other hardirq context, which means that need to defer
== Series Details ==
Series: drm/i915: Isolate i915_getparam_ioctl()
URL : https://patchwork.freedesktop.org/series/64840/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
73c89b65070d drm/i915: Isolate i915_getparam_ioctl()
-:232: WARNING:FILE_PATH_CHANGES: added, moved or
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v5.3-rc3 next-20190807]
[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-ci
Valleyview is the only platform that requires the Gunit s0ix save
state. Allocate it dynamically instead of burdening all platforms with
it in drm_i915_private.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 79 -
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, August 7, 2019 7:14 AM
> To: Bloomfield, Jon ; intel-
> g...@lists.freedesktop.org
> Cc: Joonas Lahtinen ; Winiarski, Michal
>
> Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
>
> Quoting
On Wed, Aug 07, 2019 at 03:20:41PM +0100, Chris Wilson wrote:
> This giant switch has tendrils all other the struct and does not fit
> into the rest of the driver bring up and control of i915_drv.c. Push it
> to one side so that it can grow in peace.
>
> Signed-off-by: Chris Wilson
> Acked-by:
On Wed, Aug 07, 2019 at 03:04:15PM +0300, Jani Nikula wrote:
> Abstract the rather self-contained piece of code from i915_drv.[ch]. No
> functional changes.
>
> Cc: José Roberto de Souza
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Jani Nikula
Acked-by: Rodrigo Vivi
> ---
>
1 - 100 of 155 matches
Mail list logo
