> On Wed, 12 Apr 2017 20:20:00 +0800
> Xiong Zhang wrote:
>
> > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > identity mapping in iommu table, IGD could access stolen memory in host
> OS.
> > While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices
> us
After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
intel_fbc_can_choose()"), no_fbc_reason will be updated to a new error
message if we don't have a plane in the new state, which should make the
test skip, but the test code doesn't catch that message and tries to
execute the test, triggering a
> + Kevin and David
>
> On ke, 2017-04-12 at 20:20 +0800, Xiong Zhang wrote:
> > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > identity mapping in iommu table, IGD could access stolen memory in host
> OS.
> > While according to 'commit c875d2c1b808 ("iommu/vt-d: Excl
== Series Details ==
Series: drm/i915/gvt: return the actual aperture size under gvt environment
(rev2)
URL : https://patchwork.freedesktop.org/series/22910/
State : success
== Summary ==
Series 22910v2 drm/i915/gvt: return the actual aperture size under gvt
environment
https://patchwork.fre
I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
In gvt environment, each vm only use the ballooned part of aperture, so we
should return the actual aperture size exclude the reserved part by
balloon.
I915_GEM_CONTEXT_GETPARAM ioctl query the I915_CONTEXT_PARAM_GTT_SIZE,
Hi,
First off, sorry for introducing the problem and thanks for taking care
of it!
On 4/11/2017 7:09 PM, Imre Deak wrote:
On Tue, Apr 11, 2017 at 05:54:07PM +0100, Chris Wilson wrote:
On Tue, Apr 11, 2017 at 07:12:35PM +0300, Imre Deak wrote:
+static int i915_pm_prepare(struct device *kdev)
On 04/07, Paulo Zanoni wrote:
>Em Sáb, 2017-04-08 às 03:21 +0800, kbuild test robot escreveu:
>> Hi Paulo,
>>
>> [auto build test ERROR on next-20170405]
>> [cannot apply to tip/x86/core v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc5]
>> [if your patch is applied to the wrong git tree, please drop us a
>> n
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, April 12, 2017 6:19 PM
> To: Chris Wilson ; Li, Weinan Z
>
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: re
Hi Dave,
Sending this pull a bit early so you can pick up the get_property fix. There are
reports that X fails to start as a result of the bug. The dw-hdmi change gets to
come along for the ride, it's not mission critical, but nice to have for
dw-hdmi platforms with ambitious monitors.
drm-misc-ne
On Wed, Apr 12, 2017 at 10:19:01PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 12, 2017 at 01:42:36PM +0200, Takashi Iwai wrote:
> > On Wed, 12 Apr 2017 10:02:51 +0200,
> > Chris Wilson wrote:
> > > v2: Just leak the memory (8 bytes) as freeing it ourselves is not safe,
> > > and we need to coordinat
On Wed, Mar 29, 2017 at 04:56:24PM +0100, Chris Wilson wrote:
> Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
> use to indicate that it wants the contents of this buffer preserved in
> the error state (/sys/class/drm/cardN/error) following a GPU hang
> involving this batc
== Series Details ==
Series: drm/i915: Fix DisplayPort Hotplug (rev4)
URL : https://patchwork.freedesktop.org/series/19601/
State : success
== Summary ==
Series 19601v4 drm/i915: Fix DisplayPort Hotplug
https://patchwork.freedesktop.org/api/1.0/series/19601/revisions/4/mbox/
Test gem_exec_flu
From: Ville Syrjälä
Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore t
On Wed, Apr 12, 2017 at 01:42:36PM +0200, Takashi Iwai wrote:
> On Wed, 12 Apr 2017 10:02:51 +0200,
> Chris Wilson wrote:
> >
> > [31908.547136] BUG: KASAN: use-after-free in
> > intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358
> > [31908.547297] Read of size 8 by task drv_selft
On Wed, Apr 12, 2017 at 01:41:05PM +0200, Takashi Iwai wrote:
> On Wed, 12 Apr 2017 10:52:54 +0200,
> Ville Syrjälä wrote:
> >
> > On Wed, Apr 12, 2017 at 09:31:39AM +0100, Chris Wilson wrote:
> > > [31908.547136] BUG: KASAN: use-after-free in
> > > intel_lpe_audio_teardown+0x78/0xb0 [i915] at ad
On Wed, 12 Apr 2017 20:20:00 +0800
Xiong Zhang wrote:
> Stolen memory isn't a standard pci resource and exists in RMRR which has
> identity mapping in iommu table, IGD could access stolen memory in host OS.
> While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices using
> RMRRs from
On 12 April 2017 at 16:55, Robert Bragg wrote:
> Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
> share (more-or-less) the same OA unit design.
>
> Of particular note in comparison to Haswell: some OA unit HW config
> state has become per-context state and as a consequence i
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Thursday, April 6, 2017 12:15 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Pandiyan, Dhinakaran ; Vivi, Rodrigo
>
>Subject: [Intel-gfx] [PATCH 02/67] drm/i915/cnp: Add P
== Series Details ==
Series: Enable OA unit for Gen 8 and 9 in i915 perf (rev6)
URL : https://patchwork.freedesktop.org/series/20084/
State : success
== Summary ==
Series 20084v6 Enable OA unit for Gen 8 and 9 in i915 perf
https://patchwork.freedesktop.org/api/1.0/series/20084/revisions/6/mbox
== Series Details ==
Series: series starting with [1/2] drm/i915/guc: Fix sleep under spinlock
during reset
URL : https://patchwork.freedesktop.org/series/22937/
State : failure
== Summary ==
Series 22937v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22937/rev
== Series Details ==
Series: series starting with [v2,1/9] drm/i915: Mark up clflushes as belonging
to an unordered timeline (rev3)
URL : https://patchwork.freedesktop.org/series/22924/
State : failure
== Summary ==
scripts/Makefile.build:294: recipe for target
'drivers/gpu/drm/i915/gvt/cfg_
On Wed, Apr 12, 2017 at 01:48:24PM +0100, Chris Wilson wrote:
> As we may unwind the requests, even though the request we are awaiting
> has a global_seqno that seqno may be revoked during the await and so we
> can not reliably use it as a barrier for all future awaits on the same
> timeline.
>
>
Thanks Ville for the review and thanks Jani for pushing
this patch. Now we are down to 1 patch to get merged!
Regards
Manasi
On Wed, 12 Apr 2017, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 02:00:12PM -0700, Manasi Navare wrote:
>> Currently intel_dp_check_link_status() tries to retrain the
On Wed, Apr 12, 2017 at 01:48:23PM +0100, Chris Wilson wrote:
> Although we do check the completion-status of the request before
> actually adding a wait on it (either to its submit fence or its
> completion dma-fence), we currently do not check before adding it to the
> dependency lists.
>
> Sign
On 12/04/17 08:58, Chris Wilson wrote:
On Wed, Apr 12, 2017 at 04:48:42PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Looks like intel_guc_reset had the ability to sleep under the
uncore spinlock since forever but it wasn't detected until the
recent changes annotated the wait for registe
On Wed, Apr 12, 2017 at 04:48:42PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Looks like intel_guc_reset had the ability to sleep under the
> uncore spinlock since forever but it wasn't detected until the
> recent changes annotated the wait for register with might_sleep.
>
> I have
In earlier iterations of the i915-perf driver we had a number of
callbacks/hooks from other parts of the i915 driver to e.g. notify us
when a legacy context was pinned and these could run asynchronously with
respect to the stream file operations and might also run in atomic
context.
dev_priv->perf
An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5MHz
timebase as we did for
Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.
Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous stat
Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scr
Assuming a uniform mask across all slices, this enables userspace to
determine the specific sub slices enabled. This information is required,
for example, to be able to analyse some OA counter reports where the
counter configuration depends on the HW sub slice configuration.
Signed-off-by: Robert
Enables userspace to determine the number of slices enabled and also
know what specific slices are enabled. This information is required, for
example, to be able to analyse some OA counter reports where the counter
configuration depends on the HW slice configuration.
Signed-off-by: Robert Bragg
R
This change is pre-emptively aiming to avoid a potential cause of kernel
logging noise in case some condition were to result in us seeing invalid
OA reports.
The workaround for the OA unit's tail pointer race condition is what
avoids the primary known cause of invalid reports being seen and with
t
This avoids redundantly passing an (inout) head and tail pointer to
gen7_append_oa_reports() from gen7_oa_read which doesn't need to
reference either itself.
Moving the head/tail reads and writes into gen7_append_oa_reports should
have no functional effect except to avoid some redundant head point
This updates the tail pointer race workaround handling to updating the
'aged' pointer before looking to start aging a new one. There's the
possibility that there is already new data available and so we can
immediately start aging a new pointer without having to first wait for a
later hrtimer callba
If I'm going to complain about a back-to-front convention then the least
I can do is not muddle the comment up too.
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
A minor improvement to debugging output
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_perf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 18734e1926b9..08
There's a HW race condition between OA unit tail pointer register
updates and writes to memory whereby the tail pointer can sometimes get
ahead of what's been written out to the OA buffer so far (in terms of
what's visible to the CPU).
Although this can be observed explicitly while copying reports
If the function for checking whether there is OA buffer data available
(during a poll or blocking read) has false positives then we want to
avoid a situation where the subsequent read() returns EAGAIN (after
a more accurate check) followed by a poll() immediately reporting
the same false positive P
Updates based on latest review feedback from Matthew and Lionel and includes an
update to the TestOa register config for SKL GT2 compared the last series (based
on the latest XML files from VPG)
Although the _[SUB]SLICE_MASK GETPARM patches were reviewed, it's worth
mentioning there was a TODO com
There's no need for the driver to keep reading back the head pointer
from hardware since the hardware doesn't update it automatically. This
way we can treat any invalid head pointer value as a software/driver
bug instead of spurious hardware behaviour.
This change is also a small stepping stone to
On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
>
>
> On 12/04/17 17:32, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 04:40:11PM +0300, Martin Peres wrote:
> >
> > > > > So, why is this only affecting the Core 2 Duo?
> > > >
> > > > Core2 doesn't have a usable TSC and would r
On Wed, Apr 12, 2017 at 05:21:49PM +0200, Daniel Vetter wrote:
> I've broken this accidentally. Let's make sure this doesn't happen
> anymore. Testcases suggested by Chris.
>
> Acked-by: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> tests/kms_properties.c | 60
> +
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..84ee4c11dfaa 100644
--- a/drivers/gpu/dr
From: Tvrtko Ursulin
Looks like intel_guc_reset had the ability to sleep under the
uncore spinlock since forever but it wasn't detected until the
recent changes annotated the wait for register with might_sleep.
I have fixed it by removing holding of the uncore spinlock over
the call to gen6_hw_d
On Wed, Apr 12, 2017 at 04:40:11PM +0300, Martin Peres wrote:
> > > So, why is this only affecting the Core 2 Duo?
> >
> > Core2 doesn't have a usable TSC and would revert to the slow path. I'll
> > have another look at that patch.
> >
>
> So, by default, it is using the hpet clock source. FYI,
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal iden
== Series Details ==
Series: drm/doc: Interlink color manager docs better
URL : https://patchwork.freedesktop.org/series/22935/
State : success
== Summary ==
Series 22935v1 drm/doc: Interlink color manager docs better
https://patchwork.freedesktop.org/api/1.0/series/22935/revisions/1/mbox/
Te
I've broken this accidentally. Let's make sure this doesn't happen
anymore. Testcases suggested by Chris.
Acked-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
tests/kms_properties.c | 60 ++
1 file changed, 60 insertions(+)
diff --git a/tests/
Motivated by a request from Eric.
Cc: Eric Anholt
Cc: Lionel Landwerlin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
drivers/gpu/drm/drm_color_mgmt.c| 9 ++---
include/drm/drm_crtc.h | 31 +--
3 files changed,
On Mon, Apr 10, 2017 at 01:37:01PM +0100, Chris Wilson wrote:
> On Mon, Apr 10, 2017 at 01:54:45PM +0200, Daniel Vetter wrote:
> > Yet again I've proven that I can't negate conditions :(
> >
> > Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
> > ioctl")
>
> You also get to
On Wed, Apr 12, 2017 at 1:34 PM, Matthew Auld <
matthew.william.a...@gmail.com> wrote:
> On 5 April 2017 at 20:05, Robert Bragg wrote:
> > An oa_exponent_to_ns() utility and per-gen timebase constants where
> were
>
> > recently removed when updating the tail pointer race condition WA, and
> > th
Hi Ander,
Thanks for review
On Wednesday 12 April 2017 02:47 PM, Ander Conselvan De Oliveira wrote:
On Tue, 2017-02-28 at 17:01 +0530, Mahesh Kumar wrote:
DDB minimum requirement may also exceed the allocated DDB for CRTC.
Instead of directly deducting from alloc_size, check against
total_min_
== Series Details ==
Series: series starting with [v2,1/9] drm/i915: Mark up clflushes as belonging
to an unordered timeline (rev2)
URL : https://patchwork.freedesktop.org/series/22924/
State : failure
== Summary ==
scripts/Makefile.build:294: recipe for target
'drivers/gpu/drm/i915/i915_per
On Wed, Apr 12, 2017 at 12:33 PM, Matthew Auld wrote:
> On 04/05, Robert Bragg wrote:
> > Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
> > share (more-or-less) the same OA unit design.
> >
> > Of particular note in comparison to Haswell: some OA unit HW config
> > state h
On 12/04/17 17:32, Peter Zijlstra wrote:
On Wed, Apr 12, 2017 at 04:40:11PM +0300, Martin Peres wrote:
So, why is this only affecting the Core 2 Duo?
Core2 doesn't have a usable TSC and would revert to the slow path. I'll
have another look at that patch.
So, by default, it is using the h
On ke, 2017-04-12 at 13:48 +0100, Chris Wilson wrote:
> Rather than use a global modparam, we can just check to see if the
> engine has semaphores configured upon it.
>
> Signed-off-by: Chris Wilson
Should be good.
Reviewed-by: Joonas Lahtinen
Regars, Joonas
--
Joonas Lahtinen
Open Source Te
On Wed, Apr 12, 2017 at 04:30:32PM +0300, Jani Nikula wrote:
> On Wed, 12 Apr 2017, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote:
> >> The issue is describe more in detail here:
> >> https://bugs.freedesktop.org/show_bug.cgi?id=100548
> >
> > I don't c
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal iden
On Wed, Apr 12, 2017 at 04:08:15PM +0200, Daniel Vetter wrote:
> On Wed, Apr 12, 2017 at 4:06 PM, Jani Nikula wrote:
> >
> > Hi Dave, I've had most of these ready for more than a week now, but
> > there was no use sending them as you were away. Fixes all around, except
> > not so much display stuf
On Wed, 12 Apr 2017, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 02:00:12PM -0700, Manasi Navare wrote:
>> Currently intel_dp_check_link_status() tries to retrain the link if
>> Clock recovery or Channel EQ for any of the lanes indicated by
>> intel_dp->lane_count is not set. However these valu
On Wed, Apr 12, 2017 at 4:06 PM, Jani Nikula wrote:
>
> Hi Dave, I've had most of these ready for more than a week now, but
> there was no use sending them as you were away. Fixes all around, except
> not so much display stuff this time. Hopefully winding down for this
> cycle now.
The rcu fix fr
Hi Dave, I've had most of these ready for more than a week now, but
there was no use sending them as you were away. Fixes all around, except
not so much display stuff this time. Hopefully winding down for this
cycle now.
BR,
Jani.
The following changes since commit 0abfe7e2570d7c729a7662e82c09a2
On 31/03/17 12:37, Martin Peres wrote:
On 30/03/17 08:39, Zhang, Xiong Y wrote:
On Wed, Mar 29, 2017 at 05:02:47PM +0800, Xiong Zhang wrote:
In a virtual passthrough environment, the ISA bridge isn't able to
be passed through. So pch_id couldn't be gotten from ISA bridge, but
pch_id is used t
On Thu, Apr 06, 2017 at 02:00:12PM -0700, Manasi Navare wrote:
> Currently intel_dp_check_link_status() tries to retrain the link if
> Clock recovery or Channel EQ for any of the lanes indicated by
> intel_dp->lane_count is not set. However these values cached in intel_dp
> structure can be stale i
On Wed, Apr 12, 2017 at 04:35:47PM +0300, Jani Nikula wrote:
> On Wed, 12 Apr 2017, Greg Kroah-Hartman wrote:
> > On Mon, Mar 20, 2017 at 11:24:38AM -0400, Eric Blau wrote:
> >> On Mon, Mar 20, 2017 at 11:13 AM, Greg Kroah-Hartman
> >> wrote:
> >> > On Mon, Mar 20, 2017 at 05:01:34PM +0200, Jani
On 12/04/17 15:31, Peter Zijlstra wrote:
On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote:
Hi,
We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up to
our i915 pre-merge CI system, that has started to give unstable results after commit:
commit 7b09cc5a9
On Wed, 12 Apr 2017, Greg Kroah-Hartman wrote:
> On Mon, Mar 20, 2017 at 11:24:38AM -0400, Eric Blau wrote:
>> On Mon, Mar 20, 2017 at 11:13 AM, Greg Kroah-Hartman
>> wrote:
>> > On Mon, Mar 20, 2017 at 05:01:34PM +0200, Jani Nikula wrote:
>> >> On Tue, 14 Mar 2017, Eric Blau wrote:
>> >> > That
Daniel Vetter writes:
> freedesktop.org has adopted a formal&enforced code of conduct:
Acked-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.
On Wed, 12 Apr 2017, Peter Zijlstra wrote:
> On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote:
>> Hi,
>>
>> We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up
>> to our i915 pre-merge CI system, that has started to give unstable results
>> after commit:
>
+ Kevin and David
On ke, 2017-04-12 at 20:20 +0800, Xiong Zhang wrote:
> Stolen memory isn't a standard pci resource and exists in RMRR which has
> identity mapping in iommu table, IGD could access stolen memory in host OS.
> While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices us
== Series Details ==
Series: series starting with [v2,1/9] drm/i915: Mark up clflushes as belonging
to an unordered timeline
URL : https://patchwork.freedesktop.org/series/22924/
State : success
== Summary ==
Series 22924v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
Hi Daniel,
On 11 April 2017 at 13:03, Sumit Semwal wrote:
> On 11 April 2017 at 12:38, Daniel Stone wrote:
>> Hi,
>>
>> On 11 April 2017 at 07:48, Daniel Vetter wrote:
>>> Note: As Daniel Stone mentioned in the announcement fd.o admins
>>> started chatting with the communities their hosting, wh
On Wed, Apr 12, 2017 at 12:13:51PM +0100, Tvrtko Ursulin wrote:
>
> On 11/04/2017 14:57, Michal Wajdeczko wrote:
> > This is slightly weaker version of MAYBE_BUILD_BUG_ON that allows
> > us to avoid adding implicit BUG but still detect as much as possible
> > during the build. With this new macro
On Wed, Apr 12, 2017 at 02:48:55PM +0200, Greg KH wrote:
> On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote:
> > On Sun, Mar 12, 2017 at 10:52 PM, Greg KH
> > wrote:
> > > Why don't the maintainers know which tree to put them in when they are
> > > submitted? As an example, if I get
On Mon, Mar 20, 2017 at 11:24:38AM -0400, Eric Blau wrote:
> On Mon, Mar 20, 2017 at 11:13 AM, Greg Kroah-Hartman
> wrote:
> > On Mon, Mar 20, 2017 at 05:01:34PM +0200, Jani Nikula wrote:
> >> On Tue, 14 Mar 2017, Eric Blau wrote:
> >> > That's funny. I have a MacBook Pro 12,1 from late 2015. Hib
On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote:
> On Sun, Mar 12, 2017 at 10:52 PM, Greg KH wrote:
> > Why don't the maintainers know which tree to put them in when they are
> > submitted? As an example, if I get a patch that needs to go to Linus, I
> > put it in my usb-linus branc
Rebrand the current (pointer | bits) pack/unpack utility macros as
explicit bit twiddling for PAGE_SIZE so that we can use the more
flexible underlying macros for different bits.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
drivers
Rather than use a global modparam, we can just check to see if the
engine has semaphores configured upon it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/d
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal iden
Currently we filter out repeated use of the same timeline in the low
level i915_gem_request_await_request(), after having added the
dependency on the old request. However, we can lift this to
i915_gem_request_await_dma_fence() (before the dependency is added)
using the observation that requests alo
As we may unwind the requests, even though the request we are awaiting
has a global_seqno that seqno may be revoked during the await and so we
can not reliably use it as a barrier for all future awaits on the same
timeline.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
---
drivers/gpu/drm/i9
ptr_unpack_bits() is a function-like macro, as such it is meant to be
replaceable by a function. In this case, we should be passing in the
out-param as a pointer.
Bizarrely this does affect code generation:
function old new delta
i915_gem_object_pin_map
With the addition of the inter-context intel_time.sync map, having a
very similar sync_seqno[] is confusing. Aide the reader by denoting that
this a pre-allocated array for storing semaphore sync points wrt to the
global seqno.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_reques
2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special global context to mean unordered.
Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to
have the same semanti
Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 3
On Wed, Apr 12, 2017 at 10:30:10AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2] drm/i915: Add stub mmio read/write routines
> to mock device (rev2)
> URL : https://patchwork.freedesktop.org/series/22891/
> State : success
>
> == Summary ==
>
> Series 22
On 5 April 2017 at 20:05, Robert Bragg wrote:
> An oa_exponent_to_ns() utility and per-gen timebase constants where
were
> recently removed when updating the tail pointer race condition WA, and
> this restores those so we can update the _PROP_OA_EXPONENT validation
> done in read_properties_unloc
On Tue, Apr 11, 2017 at 08:09:17PM +0300, Imre Deak wrote:
> On Tue, Apr 11, 2017 at 05:54:07PM +0100, Chris Wilson wrote:
> > On Tue, Apr 11, 2017 at 07:12:35PM +0300, Imre Deak wrote:
> > > +static int i915_pm_prepare(struct device *kdev)
> > > +{
> > > + /*
> > > + * Get a reference to disable
== Series Details ==
Series: drm/i915: Enhanced disable access to stolen memory as a guest (rev5)
URL : https://patchwork.freedesktop.org/series/21818/
State : success
== Summary ==
Series 21818v5 drm/i915: Enhanced disable access to stolen memory as a guest
https://patchwork.freedesktop.org/a
On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote:
> Hi,
>
> We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up
> to our i915 pre-merge CI system, that has started to give unstable results
> after commit:
>
> commit 7b09cc5a9debc86c903c2eff8f8a1fdef773c649
On ke, 2017-04-12 at 10:21 +0100, Chris Wilson wrote:
> Provide dummy function pointers for the mock device in case we do hit
> mmio during testing.
>
> v2: Use ASSIGN_READ/WRITE_MMIO_FUNCS macros
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen #v1
Reviewed-by: Joonas Lahtinen
Stolen memory isn't a standard pci resource and exists in RMRR which has
identity mapping in iommu table, IGD could access stolen memory in host OS.
While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices using
RMRRs from IOMMU API domains")',RMRR isn't supported by kvm, then both EPT
Hi,
We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up to
our i915 pre-merge CI system, that has started to give unstable results after
commit:
commit 7b09cc5a9debc86c903c2eff8f8a1fdef773c649
Author: Pavel Tatashin
Date: Wed Mar 22 16:24:17 2017 -0400
sched/cloc
On Wed, Apr 12, 2017 at 11:29:21AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/2] drm/i915: Combine write_domain flushes
> to a single function
> URL : https://patchwork.freedesktop.org/series/22921/
> State : success
>
> == Summary ==
>
> Series 2292
On Wed, 12 Apr 2017 10:02:51 +0200,
Chris Wilson wrote:
>
> [31908.547136] BUG: KASAN: use-after-free in
> intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358
> [31908.547297] Read of size 8 by task drv_selftest/3781
> [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G
On Wed, 12 Apr 2017 10:52:54 +0200,
Ville Syrjälä wrote:
>
> On Wed, Apr 12, 2017 at 09:31:39AM +0100, Chris Wilson wrote:
> > [31908.547136] BUG: KASAN: use-after-free in
> > intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358
> > [31908.547297] Read of size 8 by task drv_selftest
On pe, 2017-04-07 at 22:36 +0100, Chris Wilson wrote:
> Since kmap allows us to block we can pin the pages and use our normal
> page lookup routine making the implementation simple.
>
> Testcase: igt/drv_selftest/dmabuf
> Testcase: igt/prime_rw
> Signed-off-by: Chris Wilson
> +static int igt_d
On 04/05, Robert Bragg wrote:
> In earlier iterations of the i915-perf driver we had a number of
> callbacks/hooks from other parts of the i915 driver to e.g. notify us
> when a legacy context was pinned and these could run asynchronously with
> respect to the stream file operations and might also
On 04/05, Robert Bragg wrote:
> Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
> share (more-or-less) the same OA unit design.
>
> Of particular note in comparison to Haswell: some OA unit HW config
> state has become per-context state and as a consequence it is somewhat
> m
1 - 100 of 166 matches
Mail list logo
