On Fri, 05 Apr 2019, Jani Nikula wrote:
> v2 of [1] with:
>
> - each foo.c now includes the corresponding new foo.h to avoid sparse warnings
>
> - minor sparse/checkpatch/whitespace fixes
>
> - commit message tab screwup fixed
>
> I didn't add changelog to each patch for the first two.
>
> Took th
On Friday, April 5, 2019 7:37:04 PM CEST Chris Wilson wrote:
> Quoting Chris Wilson (2019-04-05 17:26:46)
>
> > Quoting Patchwork (2019-04-05 17:20:39)
> >
> > > == Series Details ==
> > >
> > > Series: Stop users from using the device on driver unbind
> > > URL : https://patchwork.freedesktop
Quoting Chris Wilson (2019-03-25 08:07:33)
> When one of the array of fences is signaled, propagate its errors to the
> parent fence-array (keeping the first error to be raised).
>
> v2: Opencode cmpxchg_local to avoid compiler freakout.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc:
On Fri, Apr 05, 2019 at 04:33:30PM -0700, Vivek Kasireddy wrote:
> On Fri, 5 Apr 2019 21:39:11 +0300
> Ville Syrjälä wrote:
> Hi Ville,
>
> > On Fri, Apr 05, 2019 at 09:33:56PM +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 05, 2019 at 10:59:53AM -0700, Vivek Kasireddy wrote:
> > > > This patch
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with a
We switched to a tree of per-engine HW context to accommodate the
introduction of virtual engines. However, we plan to also support
multiple instances of the same engine within the GEM context, defeating
our use of the engine as a key to looking up the HW context. Just
allocate a logical per-engine
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the h
It was noted that we made the same mistake for VM_ID as for object
handles, whereby we ensured that we only allocated a single handle for
one ppgtt. This has the unfortunate consequence for userspace that they
need to reference count the handles to avoid destroying an active ID. If
we allow multipl
We wish to start segregating the power management into different control
domains, both with respect to the hardware and the user interface. The
first step is that at the lowest level flow of requests, we want to
process a context event (and not a global GEM operation). In this patch,
we introduce t
In order to separate the reservation phase of building a request from
its emission phase, we need to pull some of the request alloc activities
from deep inside i915_request to the surface, GEM_EXECBUFFER.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 110 ++
Split out the powermanagement portion (GT wakeref, suspend/resume) of
GEM from i915_gem.c into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/Makefile.header-test | 1 +
drivers/gpu/drm/i915/i915_debugfs.c
As we push for better compartmentalisation, it is more convenient to
copy the default sseu configuration from the engine into the derived
logical context, than it is to dig it out from i915->runtime_info.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
driv
In the next patch, we require the engine vfuncs setup prior to
initialising the pinned kernel contexts, so split the vfunc setup from
the engine initialisation and call it earlier.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h| 8 +-
drivers/gpu/drm/i915/gt/int
Replace the WARN with a simple if() + error message to squech the sparse
warning that entire wait_for() macro was being stringified:
drivers/gpu/drm/i915/intel_guc_submission.c:658:9: error: too long token
expansion
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c |
For controlling runtime pm of the GT and engines, we would like to have
a callback to do extra work the first time we wake up and the last time
we drop the wakeref. This first/last access needs serialisation and so
we encompass a mutex with the regular intel_wakeref_t tracker.
Signed-off-by: Chris
Circumvent the dance we currently perform to find the preempt_client and
lookup its HW context for this engine, as we know we have already pinned
the preempt_context on the engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+),
OUr eventual goal is to rid request construction of struct_mutex, with
the short term step of lifting the struct_mutex requirements into the
higher levels (i.e. the caller must ensure that the context is already
pinned into the GTT). In this patch, we pin GVT's shadow context upon
allocation and so
We want to pass in a intel_context into intel_context_pin() and that
requires us to first be able to lookup the intel_context!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c| 37 +++---
drivers/gpu/drm/i915/gt/intel_context.h| 19 +++
driv
drivers/gpu/drm/i915/intel_pm.c:8352:9: error: incompatible types in comparison
expression (different address spaces)
drivers/gpu/drm/i915/intel_pm.c:8359:9: error: incompatible types in comparison
expression (different address spaces)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel
Combine the (i915_gem_context, intel_engine) into a single parameter,
the intel_context for convenience and later simplification.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 74 +++
1 file changed, 44 insertions(+), 30 deletions(-)
diff --git
Simply the setup slightly for the sseu selftests to use the actual
kernel_context.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_contex
Start partitioning off the code that talks to the hardware (GT) from the
uapi layers and move the device facing code under gt/
One casualty is s/intel_ringbuffer.h/intel_engine.h/ with the plan to
subdivide that header and body further (and split out the submission
code from the ringbuffer and log
The timeline is strictly ordered, so by inserting the timeline->barrier
request into the timeline->last_request it naturally provides the same
barrier. Consolidate the pair of barriers into one as they serve the
same purpose.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.
In order to avoid the malloc inside i915_globals_park() occurring
underneath a lock connected to the shrinker (thus causing circular
lockdeps warnings), move the rcu_worker to a global.
<4> [39.085073] ==
<4> [39.085273] WARNING: possible circula
Move the intel_context_instance() to the caller so that we can decouple
ourselves from one context instance per engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 26 --
drivers/gpu/drm/i915/gt/intel_context.h | 14 ++-
drivers/gpu/drm/i915/i915_gem
On resume, we know that the only pinned contexts in danger of seeing
corruption are the kernel context, and so we do not need to walk the
list of all GEM contexts as we tracked them on each engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
drivers/gpu/
Start acquiring the logical intel_context and using that as our primary
means for request allocation. This is the initial step to allow us to
avoid requiring struct_mutex for request allocation along the
perma-pinned kernel context, but it also provides a foundation for
breaking up the complex requ
Hello Uma,
V7 looks good to me, please feel free to use for the whole series:
Reviewed-by: Shashank Sharma
Regards
Shashank
On 4/3/2019 1:50 AM, Uma Shankar wrote:
This patch series enables HDR support in drm. It basically defines
HDR metadata structures, property to pass content (after ble
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient i
Having hid the partially exposed new ABI from the PR, put it back again
for completion of context recovery. A significant part of context
recovery is the ability to reuse as much of the old context as is
feasible (to avoid expensive reconstruction). The biggest chunk kept
hidden at the moment is fi
We no longer need to track the active intel_contexts within each engine,
allowing us to drop a tricky mutex_lock from inside unpin (which may
occur inside fs_reclaim).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 11 +---
drivers/gpu/drm/i915/gt/intel_conte
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load.
Having transitioned GEM over to using intel_context as its primary means
of tracking the GEM context and engine combined and using
i915_request_create(), we can move the older i915_request_alloc()
helper function into selftests/
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile
The SINGLE_TIMELINE flag can be used to create a context such that all
engine instances within that context share a common timeline. This can
be useful for mixing operations between real and virtual engines, or
when using a composite context for a single client API context.
Signed-off-by: Chris Wi
<4> [265.019572] Unmatched wakeref (tracking 3), count 3
<4> [265.019680] WARNING: CPU: 1 PID: 163 at
drivers/gpu/drm/i915/intel_runtime_pm.c:162
cancel_intel_runtime_pm_wakeref+0x87/0x160 [i915]
<4> [265.019682] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi
snd_hda_codec_realtek
On Fri, Apr 05, 2019 at 03:48:21PM -0700, Manasi Navare wrote:
> Currently we use force_dsc_enable to force DSC from IGT, but
> we dont expose this value to userspace through debugfs.
> This patch exposes this through the same dsc_fec_support
> debugfs node per connector so that we can restore its
== Series Details ==
Series: series starting with [01/29] drm/i915: Mark up ips for RCU protection
URL : https://patchwork.freedesktop.org/series/59155/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
17875d38d33a drm/i915: Mark up ips for RCU protection
bb6133046abe drm/i915/guc
On Mon, Apr 01, 2019 at 11:00:06PM +0530, Uma Shankar wrote:
> From: Ville Syrjälä
>
> This defines the color lut ranges for 10bit and multi
> segmented gamma range for ICL.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_color.c | 301
> +
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
lib/igt_dummyload.c | 39 +--
lib/igt_gt.c| 14 --
lib/igt_gt.h| 2 --
tests/perf_pmu.c| 44
4 files changed, 73 insertions(+)
== Series Details ==
Series: series starting with [01/29] drm/i915: Mark up ips for RCU protection
URL : https://patchwork.freedesktop.org/series/59155/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Mark up ips for RCU protection
-drivers/gp
On Mon, Apr 01, 2019 at 11:00:09PM +0530, Uma Shankar wrote:
> Gen11 introduced a new gamma mode i.e, multi segmented
> gamma mode. Added support for the same.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_color.c | 161
> -
> include/drm/
On 2019-04-02 22:20, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> It also implements get() and set() functions for HDR output
> metadata property.The blob data is received from users
== Series Details ==
Series: series starting with [01/29] drm/i915: Mark up ips for RCU protection
URL : https://patchwork.freedesktop.org/series/59155/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5887 -> Patchwork_12723
Quoting Patchwork (2019-04-08 11:28:00)
> == Series Details ==
>
> Series: series starting with [01/29] drm/i915: Mark up ips for RCU protection
> URL : https://patchwork.freedesktop.org/series/59155/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5887 -> Patchwork_12
== Series Details ==
Series: snd/hda: Detangle unwind to avoid double release of display powerwell
URL : https://patchwork.freedesktop.org/series/59158/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include
<4> [265.019572] Unmatched wakeref (tracking 3), count 3
<4> [265.019680] WARNING: CPU: 1 PID: 163 at
drivers/gpu/drm/i915/intel_runtime_pm.c:162
cancel_intel_runtime_pm_wakeref+0x87/0x160 [i915]
<4> [265.019682] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi
snd_hda_codec_realtek
On Mon, Apr 08, 2019 at 09:16:34AM +0300, Jani Nikula wrote:
> On Fri, 05 Apr 2019, Imre Deak wrote:
> > On Fri, Apr 05, 2019 at 05:13:49PM +0300, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> The only bpc information in pipe registers for BXT/GLK DSI
> >> is the PIPEMISC dither bpc. L
From: Ville Syrjälä
I like my functions simple, so split up the low level bits from
cherryview_load_luts() into separate functions. Also rename the
whole thing to chv_load_luts() to match the new world order.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 98
== Series Details ==
Series: snd/hda: Detangle unwind to avoid double release of display powerwell
(rev2)
URL : https://patchwork.freedesktop.org/series/59158/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c354dafa354d snd/hda: Detangle unwind to avoid double release of displa
There were system hung observed while running i915_pm_rpm test.
FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
Root cause is believed to due to page fault in ACPI idle (FDO comment 18)
driver, it has been suggested by Daniel to disable ACPI idle
driver for CI system, this patch only meant
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Friday, April 5, 2019 9:42 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.or
/commits/Chris-Wilson/snd-hda-Detangle-unwind-to-avoid-double-release-of-display-powerwell/20190408-185235
base: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-next
config: i386-randconfig-x012-201914 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, April 8, 2019 3:39 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; emil.l.veli...@gmai
On Mon, Apr 08, 2019 at 12:26:23PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Friday, April 5, 2019 9:42 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; intel-gf
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, April 8, 2019 3:50 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; seanp...@chromium.org; Syrjala, Ville
>; harry.wentl...@a
== Series Details ==
Series: snd/hda: Detangle unwind to avoid double release of display powerwell
(rev2)
URL : https://patchwork.freedesktop.org/series/59158/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5887 -> Patchwork_12725
==
Quoting Patchwork (2019-04-08 13:51:08)
> Warnings
>
> * igt@i915_pm_rpm@module-reload:
> - fi-glk-dsi: DMESG-WARN [fdo#105538] / [fdo#107732] /
> [fdo#109513] -> INCOMPLETE [fdo#103359] / [k.org#198133]
In other words, no that wasn't the fix it purported to be.
-Chris
__
+ Rafael, Mika.
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Anshuman Gupta
> Sent: maanantai 8. huhtikuuta 2019 15.22
> To: intel-gfx@lists.freedesktop.org
> Cc: Peres, Martin ; Vetter, Daniel
>
> Subject: [Intel-gfx] [PATCH] Cor
During reset, we try and stop the active ring. This has the consequence
that we often clobber the RING registers within the context image. When
we find an active request, we update the context image to rerun that
request (if it was guilty, we replace the hanging user payload with
NOPs). However, we
During reset, we try and stop the active ring. This has the consequence
that we often clobber the RING registers within the context image. When
we find an active request, we update the context image to rerun that
request (if it was guilty, we replace the hanging user payload with
NOPs). However, we
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj
On 08/04/2019 10:17, Chris Wilson wrote:
Replace the WARN with a simple if() + error message to squech the sparse
warning that entire wait_for() macro was being stringified:
drivers/gpu/drm/i915/intel_guc_submission.c:658:9: error: too long token
expansion
Signed-off-by: Chris Wilson
---
d
On 08/04/2019 10:17, Chris Wilson wrote:
In order to avoid the malloc inside i915_globals_park() occurring
underneath a lock connected to the shrinker (thus causing circular
lockdeps warnings), move the rcu_worker to a global.
<4> [39.085073]
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, April 8, 2019 6:01 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville
>; Lankhorst, Maar
On 08/04/2019 10:17, Chris Wilson wrote:
The timeline is strictly ordered, so by inserting the timeline->barrier
request into the timeline->last_request it naturally provides the same
barrier. Consolidate the pair of barriers into one as they serve the
same purpose.
Signed-off-by: Chris Wilson
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sam
>Ravnborg
>Sent: Tuesday, April 2, 2019 12:03 AM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-de...@lists.freedesktop
== Series Details ==
Series: drm/i915: Clean up cherryview_load_luts()
URL : https://patchwork.freedesktop.org/series/59169/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5888 -> Patchwork_12726
Summary
---
**FAILURE
On Thu, 04 Apr 2019, Jim Zhang wrote:
> Dear Sir/Madam:
>
> I am having an issue with intel Baytrail GPU DRM driver.
>
> Description:
> Linux kernel version 3.10.61:
> Afer calling function
> properties = drmModeObjectGetProperties(drmfd, plane_id,
> DRM_MODE_OBJECT_PLANE);
> it only returns onl
>-Original Message-
>From: Sam Ravnborg [mailto:s...@ravnborg.org]
>Sent: Tuesday, April 2, 2019 12:07 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
>Syrjala, Ville ; L
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 7769db588384 drm/i915/dp: optimize eDP 1.4+ link config fast and
narrow.
The bot has tested the following trees: v5.0.7.
v5.0.7: Failed to apply! Possible dependencies:
204474
On 08/04/2019 10:17, Chris Wilson wrote:
As we push for better compartmentalisation, it is more convenient to
copy the default sseu configuration from the engine into the derived
logical context, than it is to dig it out from i915->runtime_info.
Why it is more convenient?
Signed-off-by: Chr
On 08/04/2019 10:17, Chris Wilson wrote:
Split out the powermanagement portion (GT wakeref, suspend/resume) of
GEM from i915_gem.c into its own file.
This is the same patch I gave r-b on before? Judging from the title and
commit message I'd say yes. But I know it is not, don't worry.
Regard
On Mon, Apr 08, 2019 at 02:40:51PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Monday, April 8, 2019 6:01 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
> >de...@l
On 08/04/2019 10:17, Chris Wilson wrote:
Circumvent the dance we currently perform to find the preempt_client and
lookup its HW context for this engine, as we know we have already pinned
the preempt_context on the engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submiss
On Thu, Apr 04, 2019 at 09:38:03PM +, Jim Zhang wrote:
> Dear Sir/Madam:
>
> I am having an issue with intel Baytrail GPU DRM driver.
>
> Description:
> Linux kernel version 3.10.61:
> Afer calling function
> properties = drmModeObjectGetProperties(drmfd, plane_id,
> DRM_MODE_OBJECT_PLANE);
On 08/04/2019 10:17, Chris Wilson wrote:
Simply the setup slightly for the sseu selftests to use the actual
kernel_context.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/
== Series Details ==
Series: snd/hda: Detangle unwind to avoid double release of display powerwell
(rev2)
URL : https://patchwork.freedesktop.org/series/59158/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5887_full -> Patchwork_12725_full
== Series Details ==
Series: Core-for-CI:ICL_only Disable ACPI idle driver
URL : https://patchwork.freedesktop.org/series/59170/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5888 -> Patchwork_12727
Summary
---
**SUC
== Series Details ==
Series: drm/i915/execlists: Always reset the context's RING registers (rev2)
URL : https://patchwork.freedesktop.org/series/59174/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
032a44d4e5e1 drm/i915/execlists: Always reset the context's RING registers
-:17:
On 08/04/2019 10:17, Chris Wilson wrote:
In order to separate the reservation phase of building a request from
its emission phase, we need to pull some of the request alloc activities
from deep inside i915_request to the surface, GEM_EXECBUFFER.
I had some comments and gave conditional r-b on
From: Ville Syrjälä
We have a lot of '(u64)foo * bar' everywhere. Replace with
mul_u32_u32() to avoid gcc failing to use a regular 32x32->64
multiply for this.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_fixed.h | 6 +++---
drivers/gpu/drm/i915/intel_display.c | 10 +--
From: Ville Syrjälä
Write some icl pll calculations in a more straightforward way.
We have just enough bits for the full divisor.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 15 ---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
2 files changed, 5 inser
== Series Details ==
Series: drm/i915/execlists: Always reset the context's RING registers (rev2)
URL : https://patchwork.freedesktop.org/series/59174/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5888 -> Patchwork_12728
S
Quoting Chris Wilson (2019-04-08 14:40:25)
> During reset, we try and stop the active ring. This has the consequence
> that we often clobber the RING registers within the context image. When
> we find an active request, we update the context image to rerun that
> request (if it was guilty, we repla
== Series Details ==
Series: series starting with [1/2] drm/i915: Use mul_u32_u32() more
URL : https://patchwork.freedesktop.org/series/59180/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Use mul_u32_u32() more
-O:drivers/gpu/drm/i915/intel
On Sun, Apr 07, 2019 at 02:40:18PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/i915: Get power refs in
> encoder->get_power_domains() (rev2)
> URL : https://patchwork.freedesktop.org/series/59071/
> State : failure
Thanks for the review, pushed
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, April 8, 2019 8:27 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville
>; Lankhorst, Maar
Quoting Ville Syrjala (2019-04-08 16:27:01)
> From: Ville Syrjälä
>
> We have a lot of '(u64)foo * bar' everywhere. Replace with
> mul_u32_u32() to avoid gcc failing to use a regular 32x32->64
> multiply for this.
>
> Signed-off-by: Ville Syrjälä
As a purely mechanical translation,
Reviewed-by
On Mon, Apr 08, 2019 at 03:40:39PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Monday, April 8, 2019 8:27 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
> >de...@l
During reset, we try and stop the active ring. This has the consequence
that we often clobber the RING registers within the context image. When
we find an active request, we update the context image to rerun that
request (if it was guilty, we replace the hanging user payload with
NOPs). However, we
Quoting Ville Syrjala (2019-04-08 16:27:02)
> - /*
> -* Adjust the original formula to delay the division by 2^22 in order
> to
> -* minimize possible rounding errors.
> -*/
> - tmp = (u64)m1 * m2_int * ref_clock +
> - (((u64)m1 * m2_frac * ref_clock
Quoting Tvrtko Ursulin (2019-04-08 15:54:01)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > As we push for better compartmentalisation, it is more convenient to
> > copy the default sseu configuration from the engine into the derived
> > logical context, than it is to dig it out from i915->runti
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Monday, April 8, 2019 9:15 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.or
Quoting Tvrtko Ursulin (2019-04-08 15:56:39)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > Split out the powermanagement portion (GT wakeref, suspend/resume) of
> > GEM from i915_gem.c into its own file.
>
> This is the same patch I gave r-b on before? Judging from the title and
> commit mess
On 08/04/2019 16:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-08 15:54:01)
On 08/04/2019 10:17, Chris Wilson wrote:
As we push for better compartmentalisation, it is more convenient to
copy the default sseu configuration from the engine into the derived
logical context, than it is
On Mon, Apr 08, 2019 at 04:49:13PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-04-08 16:27:02)
> > - /*
> > -* Adjust the original formula to delay the division by 2^22 in
> > order to
> > -* minimize possible rounding errors.
> > -*/
> > - tmp = (u
On Mon, Apr 08, 2019 at 03:59:51PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Monday, April 8, 2019 9:15 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; intel-gf
Quoting Ville Syrjälä (2019-04-08 17:06:01)
> On Mon, Apr 08, 2019 at 04:49:13PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2019-04-08 16:27:02)
> > > - /*
> > > -* Adjust the original formula to delay the division by 2^22 in
> > > order to
> > > -* minimize possib
== Series Details ==
Series: series starting with [1/2] drm/i915: Use mul_u32_u32() more
URL : https://patchwork.freedesktop.org/series/59180/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5888 -> Patchwork_12729
Summary
--
On Fri, Apr 05, 2019 at 09:34:42AM -0700, Clinton Taylor wrote:
> What happened to the reset of the patch?
It should have been a separate patch. Also I think this [1] oneliner
might be all we need.
[1] https://lists.freedesktop.org/archives/intel-gfx/2019-April/194708.html
>
> -Clint
>
>
> On
1 - 100 of 134 matches
Mail list logo
