As only GGTT vma may be permanently pinned and are always at the head of
the object's vma list, as soon as we seen a ppGTT vma we can stop
searching for any_vma_pinned().
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 10 +-
1 file changed
gem_execbuf_wr was duplicated in multiple places.
Moving everything to lib/
Signed-off-by: Lukasz Fiedorowicz
---
benchmarks/gem_busy.c| 16
benchmarks/gem_latency.c | 16
benchmarks/gem_wsim.c| 16
lib/ioctl_wrappers.c | 33
== Series Details ==
Series: drm/i915: Only GGTT vma may be pinned and prevent shrinking
URL : https://patchwork.freedesktop.org/series/24906/
State : failure
== Summary ==
Series 24906v1 drm/i915: Only GGTT vma may be pinned and prevent shrinking
https://patchwork.freedesktop.org/api/1.0/seri
On 2017-05-24 07:51, Daniel Vetter wrote:
> Pull a (much shorter) overview into drm_irq.c, and instead put the
> callback documentation into in-line comments in drm_drv.h.
Looks good and just found all I needed to know to fix IRQ registration
in fsl dcu.
Reviewed-by: Stefan Agner
>
> Signed-of
Hi,
On Wednesday 24 May 2017 05:08 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-05-24 at 13:57 +0530, Mahesh Kumar wrote:
Hi,
On Monday 08 May 2017 02:20 PM, Ander Conselvan de Oliveira wrote:
In Geminilake, a FIFO underrun happens the first time a pipe scaler is
enabled after boot/r
On 2017-05-24 07:51, Daniel Vetter wrote:
> Again cleanup before irq disabling doesn't really stop the races,
> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown
> before everything gets cleaned up.
Hm, I already use the non-atomic drm_crtc_force_disable_all before, I
think th
Hey,
Op 25-05-17 om 08:28 schreef Mahesh Kumar:
> From: "Kumar, Mahesh"
>
> This patch implements new DDB allocation algorithm as per HW team
> recommendation. This algo takecare of scenario where we allocate less DDB
> for the planes with lower relative pixel rate, but they require more DDB
> to
Hi,
Please pull these two gvt fixes for 4.12, one to fix
vGPU workload cleanup in destroy and another one is
important to fix vGPU hang in stress test.
Thanks.
--
The following changes since commit 2f720aac936dc7a301b757d3b197d86c333d59b8:
drm/i915: don't do allocate_va_range again on PIN_UPD
On 25/05/2017 08:40, Lukasz Fiedorowicz wrote:
gem_execbuf_wr was duplicated in multiple places.
Moving everything to lib/
Signed-off-by: Lukasz Fiedorowicz
---
benchmarks/gem_busy.c| 16
benchmarks/gem_latency.c | 16
benchmarks/gem_wsim.c| 16 --
On 24/05/2017 16:54, Jon Bloomfield wrote:
BXT has a H/W issue with IOMMU which can lead to system hangs when
Aperture accesses are queued within the GAM behind GTT Accesses.
This patch avoids the condition by wrapping all GTT updates in stop_machine
and using a flushing read prior to restartin
From: Jon Bloomfield
BXT has a H/W issue with IOMMU which can lead to system hangs when
Aperture accesses are queued within the GAM behind GTT Accesses.
This patch avoids the condition by wrapping all GTT updates in stop_machine
and using a flushing read prior to restarting the machine.
The sto
On Wed, May 24, 2017 at 11:35:15AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> > +
> > +static int ctch_init(struct intel_guc *guc,
> > +struct intel_guc_ct_channel *ctch)
> > +{
> > + struct i915_vma *vma;
> > + void *blob;
> > + int err;
> > + int i;
> > +
> > + GEM_BUG
== Series Details ==
Series: drm/i915: Serialize GTT/Aperture accesses on BXT (rev2)
URL : https://patchwork.freedesktop.org/series/24882/
State : success
== Summary ==
Series 24882v2 drm/i915: Serialize GTT/Aperture accesses on BXT
https://patchwork.freedesktop.org/api/1.0/series/24882/revisi
Buffer based command transport can replace MMIO based mechanism.
It may be used to perform host-2-guc and guc-to-host communication.
v3: using static owner id (Daniele)
v4: but keep channel initialization generic (Daniele)
and introduce owner_sub_id (Daniele)
Michal Wajdeczko (3):
drm/i915/
In earlier patch 789a625 we were enabling send function only
after successful init. For completeness, we should make sure
that we disable it on fini.
v2: don't group steps by submission flag (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
This is just for CI testing, *** DO NOT MERGE ***
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..abd2894 100
Buffer based command transport can replace MMIO based mechanism.
It may be used to perform host-2-guc and guc-to-host communication.
Portions of this patch are based on work by:
Michel Thierry
Robert Beckett
Daniele Ceraolo Spurio
v2: use gem_object_pin_map (Chris)
don't use DEBUG_RATEL
On Thu, May 25, 2017 at 11:54:03AM +0100, Tvrtko Ursulin wrote:
>
> On 24/05/2017 16:54, Jon Bloomfield wrote:
> >BXT has a H/W issue with IOMMU which can lead to system hangs when
> >Aperture accesses are queued within the GAM behind GTT Accesses.
> >
> >This patch avoids the condition by wrappin
== Series Details ==
Series: Introduce buffer based cmd transport (rev2)
URL : https://patchwork.freedesktop.org/series/24786/
State : success
== Summary ==
Series 24786v2 Introduce buffer based cmd transport
https://patchwork.freedesktop.org/api/1.0/series/24786/revisions/2/mbox/
fi-bdw-5557
We depend on intel_iommu_gfx_mapped for various workarounds, but that is
only available under an #ifdef CONFIG_INTEL_IOMMU. Refactor all the
cut-and-paste ifdefs to a common routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 15 ---
drivers/gpu/drm/i915
== Series Details ==
Series: drm/i915: Consolidate #ifdef CONFIG_INTEL_IOMMU
URL : https://patchwork.freedesktop.org/series/24913/
State : success
== Summary ==
Series 24913v1 drm/i915: Consolidate #ifdef CONFIG_INTEL_IOMMU
https://patchwork.freedesktop.org/api/1.0/series/24913/revisions/1/mbo
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, May 24, 2017 11:57 PM
To: Wang, Zhi A
Cc: Dong, Chuanxiao ; Daniel Vetter
; Zhang, Xiong Y ; Joonas
Lahtinen ; Chris Wilson
; Lv, Zhiyuan ; Zhenyu Wang
; Tian, Kevin
Subject: Re: Deal with
On Tue, May 23, 2017 at 06:32:00PM +0800, Xiaoguang Chen wrote:
> dmabuf for GVT-g can be exported to users who can use the dmabuf to show
> the desktop of vm which use intel vgpu.
>
> Currently we provide query and create new dmabuf operations.
>
> Users of dmabuf can cache some created dmabufs
On to, 2017-05-25 at 08:25 +0100, Chris Wilson wrote:
> As only GGTT vma may be permanently pinned and are always at the head of
> the object's vma list, as soon as we seen a ppGTT vma we can stop
> searching for any_vma_pinned().
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Is this in
On 25/05/2017 13:16, Chris Wilson wrote:
We depend on intel_iommu_gfx_mapped for various workarounds, but that is
only available under an #ifdef CONFIG_INTEL_IOMMU. Refactor all the
cut-and-paste ifdefs to a common routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h
On Wed, May 24, 2017 at 12:28:07PM +0100, Tvrtko Ursulin wrote:
>
> On 18/05/2017 18:00, Chris Wilson wrote:
> >On Thu, May 18, 2017 at 05:20:38PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 18/05/2017 14:37, Chris Wilson wrote:
> >>>On Thu, May 18, 2017 at 02:06:35PM +0100, Tvrtko Ursulin wrote:
> >
On Thu, May 25, 2017 at 04:49:56PM +0300, Joonas Lahtinen wrote:
> On to, 2017-05-25 at 08:25 +0100, Chris Wilson wrote:
> > As only GGTT vma may be permanently pinned and are always at the head of
> > the object's vma list, as soon as we seen a ppGTT vma we can stop
> > searching for any_vma_pinne
On 05/17, Lionel Landwerlin wrote:
> Signed-off-by: Lionel Landwerlin
With some kind of commit message:
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On ke, 2017-05-24 at 17:26 +0100, Chris Wilson wrote:
> I have a plan to write a quick test to exercise concurrent usage of
> i915_gem_shrink(), the simplest way looks to be to have multiple threads
> using debugfs/i915_drop_caches. However, we currently take one lock over
> the entire function, se
On Thu, May 25, 2017 at 05:58:33PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-05-24 at 17:26 +0100, Chris Wilson wrote:
> > I have a plan to write a quick test to exercise concurrent usage of
> > i915_gem_shrink(), the simplest way looks to be to have multiple threads
> > using debugfs/i915_drop_c
From: Hans Verkuil
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
protocol.
This patch series is based on v4.12-rc2.
The first four patches add support for a new CEC capability which is
needed for these devices and for two helper functions.
Then the DP CEC registers
From: Clint Taylor
Adding DPCD register definitions from the DP 1.3 specification for CEC
over AUX support.
V2: Add DP_ prefix to all defines.
V3: missed prefixes from the ESI1 defines
Cc: Jani Nikula
Reviewed-by: Jani Nikula
Signed-off-by: Clint Taylor
Signed-off-by: Jani Nikula
Link:
ht
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is create
From: Hans Verkuil
Add a new capability CEC_CAP_NEEDS_HPD. If this capability is set
then the hardware can only use CEC if the HDMI Hotplug Detect pin
is high. Such hardware cannot handle the corner case in the CEC specification
where it is possible to transmit messages even if no hotplug signal
From: Hans Verkuil
Simplifies setting the physical address to CEC_PHYS_ADDR_INVALID.
Signed-off-by: Hans Verkuil
---
include/media/cec.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/media/cec.h b/include/media/cec.h
index 9989cdb58bd8..6123a5eec540 100644
--- a/include/medi
From: Hans Verkuil
Document the new CEC_CAP_NEEDS_HPD capability.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
b/Documentation/media/uapi/ce
From: Hans Verkuil
Implement support for this DisplayPort feature.
The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the p
From: Hans Verkuil
This function simplifies the integration of CEC in DRM drivers.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c | 14 ++
include/media/cec.h | 9 +
2 files changed, 23 insertions(+)
diff --git a/drivers/media/cec/cec-adap.c b/drive
Hi
Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C
connector and no displayport
Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working
based on your testing?
I've been putting off buying one until I knew 4K@60Hz would work, CEC would
be nice to have too
On 22/05/17 12:56, Michal Wajdeczko wrote:
On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote:
We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Keeping the
object around allows us to access them
== Series Details ==
Series: drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
URL : https://patchwork.freedesktop.org/series/24918/
State : success
== Summary ==
Series 24918v1 drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
https://patchwork.freedesktop.org/api/1.0/se
On 05/25/2017 05:30 PM, Mike Lothian wrote:
> Hi
>
> Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C
> connector and no displayport
>
> Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working
> based on your testing?
>
> I've been putting off buying o
psr1 is also disabled for panel resolution greater than 32X20.
Added psr2 check to disable only for psr2 panels having resolution
greater than 32X20.
issue was introduced by
commit-id : "acf45d11050abd751dcec986ab121cb2367dcbba"
commit message: "PSR2 is restricted to work with panel resolutions
u
== Series Details ==
Series: drm/i915/psr: disable psr2 for resolution greater than 32X20 (rev3)
URL : https://patchwork.freedesktop.org/series/17737/
State : success
== Summary ==
Series 17737v3 drm/i915/psr: disable psr2 for resolution greater than 32X20
https://patchwork.freedesktop.org/api
Hi Dave,
A handful of fixes for you this week, nothing overly complex. The pull is noisy
because it includes -rc2.
Due to some process miscommunications, Lukas fast-forwarded -fixes and merged
the radeon patch without R-b. Patrik also merged the gma500 patch directly
without review. Daniel has add
On 25/05/17 04:36, Michal Wajdeczko wrote:
Buffer based command transport can replace MMIO based mechanism.
It may be used to perform host-2-guc and guc-to-host communication.
Portions of this patch are based on work by:
Michel Thierry
Robert Beckett
Daniele Ceraolo Spurio
v2: use gem_o
On 25/05/17 08:31, Daniele Ceraolo Spurio wrote:
On 22/05/17 12:56, Michal Wajdeczko wrote:
On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote:
We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. K
From: Gustavo Padovan
Hi,
Resending to include intel-gfx@ and get the patches picked up by CI.
New version of the patches after the comments from Archit. Full details
and the previous discussion can be found here:
https://www.spinics.net/lists/dri-devel/msg141337.html
I'm not including the uA
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
1 f
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v3: move size checks back to drivers (Ville Syrjälä)
v2: move fb setting to core and use new state (Eri
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.
v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)
v3: move si
From: Gustavo Padovan
In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 1 insertion(+), 12
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
v3:
- set correct vma to new state for cleanup
- move size checks back to driv
== Series Details ==
Series: drm/atomic: add async plane update
URL : https://patchwork.freedesktop.org/series/24926/
State : success
== Summary ==
Series 24926v1 drm/atomic: add async plane update
https://patchwork.freedesktop.org/api/1.0/series/24926/revisions/1/mbox/
Test kms_cursor_legacy
Add kerneldoc for the vma_list stored on the i915_gem_object, in
particular, documenting the expected ordering of elements -- i.e. that
we do expect GGTT VMA first followed by the ppGTT VMA.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_object.h | 17
On Thu, May 25, 2017 at 02:58:32PM +0100, Tvrtko Ursulin wrote:
>
> On 25/05/2017 13:16, Chris Wilson wrote:
> >We depend on intel_iommu_gfx_mapped for various workarounds, but that is
> >only available under an #ifdef CONFIG_INTEL_IOMMU. Refactor all the
> >cut-and-paste ifdefs to a common routin
== Series Details ==
Series: drm/i915: Add kerneldoc to describe i915_gem_object.vma_list
URL : https://patchwork.freedesktop.org/series/24928/
State : success
== Summary ==
Series 24928v1 drm/i915: Add kerneldoc to describe i915_gem_object.vma_list
https://patchwork.freedesktop.org/api/1.0/se
Sorry, I will have a new update based on your suggestion. And do more testing
on that. After that, I will resend the patch.
Quanxian
-Original Message-
From: Wang, Quanxian
Sent: Wednesday, May 17, 2017 10:45 AM
To: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org; Yang, Libin
Subject:
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 correct available aperture size exclude the reserved part
by balloon.
v2: add 'reserved' in struct i915_address_space to record th
== Series Details ==
Series: drm/i915: return the correct usable aperture size under gvt environment
URL : https://patchwork.freedesktop.org/series/24933/
State : failure
== Summary ==
Series 24933v1 drm/i915: return the correct usable aperture size under gvt
environment
https://patchwork.fre
In this series, options sanitize API is added for GVT-g, and GVT-g init
will fail with -EIO if detected incompatible i915 parameters.
Chuanxiao Dong (3):
drm/i915/gvt: Add gvt options sanitize function
drm/i915/gvt: Return -EIO if host enable_execlists not enabled when
loading GVT-g
drm/
Currently GVT-g cannot work properly when host GuC submission is
enabled, so make i915 driver loading failed in this case.
Suggested-by: Joonas Lahtinen
Suggested-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Zhenyu Wang
Signed-off-by: Chuanxiao Dong
---
drivers/gpu/drm/i915/int
The intel_gvt_sanitize_options will sanitize the GVT-g related
options before doing GVT-g init.
Suggested-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Signed-off-by: Chuanxiao Dong
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/intel_gvt.c | 36 ++
GVT-g relies on the enable_execlists parameter in i915. If this option
is not enabled for GVT-g, should return -EIO to make i915 driver loading
failed.
Suggested-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Signed-off-by: Chuanxiao Dong
---
drivers/gpu/drm/i915/intel_gvt.c | 2 +-
1 file changed, 1
== Series Details ==
Series: drm/i915/gvt: GVT-g options sanitize series
URL : https://patchwork.freedesktop.org/series/24934/
State : failure
== Summary ==
Series 24934v1 drm/i915/gvt: GVT-g options sanitize series
https://patchwork.freedesktop.org/api/1.0/series/24934/revisions/1/mbox/
Test
On Thu, May 25, 2017 at 01:44:04PM -0400, Sean Paul wrote:
> The pull is noisy because it includes -rc2.
Looks like I've caused another fine mess by fast-forwarding -fixes. :-(
I followed the docs in drm-misc.rst which say:
* Fast-forward (when possible) `-fixes` to each released -rc kernel tag,
On 26 May 2017 at 15:30, Lukas Wunner wrote:
> On Thu, May 25, 2017 at 01:44:04PM -0400, Sean Paul wrote:
>> The pull is noisy because it includes -rc2.
>
> Looks like I've caused another fine mess by fast-forwarding -fixes. :-(
>
> I followed the docs in drm-misc.rst which say:
>
> * Fast-forward
According to the bspec, when set N/M, should disable
and enable transcoder which attaching DP audio. However
with that implementation will affect performance more.
But with current implementation, KBL could not work with defined N/M.
By default, KBL will use automatic N/M.
Signed-off-by: Quanxian
== Series Details ==
Series: Defined NM doesn't work on KBL and uses automatic N/M.
URL : https://patchwork.freedesktop.org/series/24938/
State : success
== Summary ==
Series 24938v1 Defined NM doesn't work on KBL and uses automatic N/M.
https://patchwork.freedesktop.org/api/1.0/series/24938/r
On Thu, May 25, 2017 at 7:44 PM, Sean Paul wrote:
> The pull is noisy
> because it includes -rc2.
dim has you covered for this, in case you've rolled forward but Dave
hasn't yet, you can regenerate against linus upstream branch for a
cleaner pull (but still warn Dave ofc):
$ dim pull-request drm
On Thu, May 25, 2017 at 7:37 AM, Lukas Wunner wrote:
> On Wed, May 24, 2017 at 11:28:12AM +0200, Daniel Vetter wrote:
>> We can't check this when applying (since r-b/a-b tags often get added
>> afterwards), but we can check this when pushing. This only looks at
>> patches authored by the pusher.
>
On Thu, May 25, 2017 at 5:01 AM, Shawn Guo wrote:
> On Wed, May 24, 2017 at 04:52:11PM +0200, Daniel Vetter wrote:
>> It again looks all cargo-culted for no good reasons.
>
> drm_vblank_cleanup() is called to release the resources allocated by
> drm_vblank_init(). I think that's the reason, no?
73 matches
Mail list logo
