On Thu, 2019-11-07 at 14:44 -0800, Lucas De Marchi wrote:
> On Thu, Nov 07, 2019 at 01:45:59PM -0800, Jose Souza wrote:
> > This register was being enabled after enable TRANS_DDI_FUNC_CTL and
> > PIPECONF/TRANS_CONF while BSpec states that it should be set when
> > enabling TRANS_DDI_FUNC_CTL.
> >
On 8/28/2019 11:50 PM, Daniel Vetter wrote:
> On Wed, Aug 28, 2019 at 08:31:27PM +, Souza, Jose wrote:
>> On Wed, 2019-08-28 at 21:13 +0100, Chris Wilson wrote:
>>> Quoting Souza, Jose (2019-08-28 21:11:53)
Reviewed-by: José Roberto de Souza
>>>
>>> It's using a non-standard for i915 er
== Series Details ==
Series: drm/i915: Don't oops in dumb_create ioctl if we have no crtcs
URL : https://patchwork.freedesktop.org/series/69081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7275_full -> Patchwork_15160_full
On Thu, Nov 07, 2019 at 10:56:09PM +, Jose Souza wrote:
On Thu, 2019-11-07 at 14:44 -0800, Lucas De Marchi wrote:
On Thu, Nov 07, 2019 at 01:45:59PM -0800, Jose Souza wrote:
> This register was being enabled after enable TRANS_DDI_FUNC_CTL and
> PIPECONF/TRANS_CONF while BSpec states that it
== Series Details ==
Series: drm/i915: Don't test plane stride with !INTEL_DISPLAY_ENABLED
URL : https://patchwork.freedesktop.org/series/69155/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7290 -> Patchwork_15184
Summary
On Thu, 2019-11-07 at 15:10 -0800, Lucas De Marchi wrote:
> On Thu, Nov 07, 2019 at 10:56:09PM +, Jose Souza wrote:
> > On Thu, 2019-11-07 at 14:44 -0800, Lucas De Marchi wrote:
> > > On Thu, Nov 07, 2019 at 01:45:59PM -0800, Jose Souza wrote:
> > > > This register was being enabled after enabl
It turns out that the OAR CONTROL register is not getting configured
correctly in conjunction with the context save/restore bit. When
measuring work for a single context, the OAR counters do not increment.
Configure OAR format and enable OAR counters at the same time as
enabling context save/resto
On Wed, Nov 06, 2019 at 11:26:36PM +0200, Gwan-gyeong Mun wrote:
The setting of MSA is done by the DDI .pre_enable() hook. And when we are
using MST, the MSA is only set to first mst stream by calling of
DDI .pre_eanble() hook. It raies issues to non-first mst streams.
Wrong MSA or missed MSA pac
Quoting Umesh Nerlige Ramappa (2019-11-07 23:22:34)
> It turns out that the OAR CONTROL register is not getting configured
> correctly in conjunction with the context save/restore bit. When
> measuring work for a single context, the OAR counters do not increment.
>
> Configure OAR format and enabl
It turns out that the OAR CONTROL register is not getting configured
correctly in conjunction with the context save/restore bit. When
measuring work for a single context, the OAR counters do not increment.
- Configure OAR format and enable OAR counters at the same time as
enabling context save/r
On Thu, Nov 07, 2019 at 11:30:51PM +, Chris Wilson wrote:
Quoting Umesh Nerlige Ramappa (2019-11-07 23:22:34)
It turns out that the OAR CONTROL register is not getting configured
correctly in conjunction with the context save/restore bit. When
measuring work for a single context, the OAR cou
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev2)
URL : https://patchwork.freedesktop.org/series/69124/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f9ab97f3257e drm/i915: Enable second dbuf slice for ICL and TGL
-:260: WARNING:SUSPECT_CODE
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev2)
URL : https://patchwork.freedesktop.org/series/69124/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Enable second dbuf slice for ICL and TGL
+drivers/gpu/
== Series Details ==
Series: drm/i915/gvt: fix dropping obj reference twice
URL : https://patchwork.freedesktop.org/series/69084/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7275_full -> Patchwork_15162_full
Summary
-
== Series Details ==
Series: drm/i915/selftests: Complete transition to a real struct file mock
URL : https://patchwork.freedesktop.org/series/69159/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7013ed43c85d drm/i915/selftests: Complete transition to a real struct file mock
-:
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev2)
URL : https://patchwork.freedesktop.org/series/69124/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7290 -> Patchwork_15185
Summary
19. 8. 1. 오전 1:58에 Andrzej Pietrasiewicz 이(가) 쓴 글:
> Switch to using the ddc provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Sam Ravnborg
> Reviewed-by: Emil Velikov
Acked-by: Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |
== Series Details ==
Series: drm/i915/selftests: Complete transition to a real struct file mock
URL : https://patchwork.freedesktop.org/series/69159/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7290 -> Patchwork_15186
Sum
When we are mapping the VBT through pci_map_rom() we may not be allowed
to simply discard the address space and go on reading the memory. After
checking on my test system that dumping the rom via sysfs I could
actually get the correct vbt, I decided to change the implementation to
use the same appr
When we call intel_bios_is_valid_vbt(), size may not actually be the
size of the VBT, but rather the size of the blob the VBT is contained
in. For example, when mapping the PCI oprom, size will be the entire
oprom size. We don't want to read beyond what is reported to be the
VBT. So make sure we vb
Convert the code to return-early style and fix missing calls
to release_firmware() if vbt is not valid.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_opregion.c | 28 +++
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/
oprom is actually a better name to use when using
pci_map_rom(). "bios" is way too generic and confusing.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_bios.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/disp
Hi all,
This is now a conflict between the drm tree and Linus' tree.
On Thu, 31 Oct 2019 11:33:15 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_drv.h
>
> between commit:
>
> 59cd826fb5e7 ("drm/i915: Fix PCH ref
On Thu, Nov 07, 2019 at 11:22:34PM +0200, Stanislav Lisovskiy wrote:
> Also implemented algorithm for choosing DBuf slice configuration
> based on active pipes, pipe ratio as stated in BSpec 12716.
>
> Now pipe allocation still stays proportional to pipe width as before,
> however within allowed D
== Series Details ==
Series: series starting with [1/3] drm/i915/display: Fix
TRANS_DDI_MST_TRANSPORT_SELECT definition
URL : https://patchwork.freedesktop.org/series/69160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7290 -> Patchwork_15187
== Series Details ==
Series: drm/i915/selftests: Mark up sole accessor to ctx->vm as being protected
URL : https://patchwork.freedesktop.org/series/69161/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7290 -> Patchwork_15188
== Series Details ==
Series: drm/i915/perf: Configure OAR controls for specific context (rev2)
URL : https://patchwork.freedesktop.org/series/69165/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
351573b952cc drm/i915/perf: Configure OAR controls for specific context
-:65: CHECK
== Series Details ==
Series: series starting with [1/2] drm/i915/guc: Add GuC method to determine if
submission is active.
URL : https://patchwork.freedesktop.org/series/69086/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7276_full -> Patchwork_15163_full
===
== Series Details ==
Series: drm/i915/perf: Configure OAR controls for specific context (rev2)
URL : https://patchwork.freedesktop.org/series/69165/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7290 -> Patchwork_15189
Summ
== Series Details ==
Series: series starting with [1/4] drm/i915/opregion: fix leaking fw on error
path
URL : https://patchwork.freedesktop.org/series/69167/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/opregion: fix leaking fw on error pat
== Series Details ==
Series: series starting with [1/4] drm/i915/opregion: fix leaking fw on error
path
URL : https://patchwork.freedesktop.org/series/69167/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7290 -> Patchwork_15190
== Series Details ==
Series: drm/i915: Leave the aliasing-ppgtt size alone
URL : https://patchwork.freedesktop.org/series/69093/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7276_full -> Patchwork_15165_full
Summary
--
== Series Details ==
Series: Start removing legacy guc code
URL : https://patchwork.freedesktop.org/series/69094/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7277_full -> Patchwork_15166_full
Summary
---
**SUCCESS*
The headers in the gem/selftests/, gt/selftests, gvt/, selftests/
directories have never been compile-tested, but it would be possible
to make them self-contained.
This commit only addresses missing and forward
struct declarations.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/i915/gem/s
Since this function is defined in a header file, it should be
'static inline' instead of 'static'.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmab
== Series Details ==
Series: drm/i915/gt: Cleanup heartbeat systole first
URL : https://patchwork.freedesktop.org/series/69095/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7277_full -> Patchwork_15167_full
Summary
---
== Series Details ==
Series: series starting with [1/2] drm/i915: change to_mock() to an inline
function
URL : https://patchwork.freedesktop.org/series/69169/
State : failure
== Summary ==
Applying: drm/i915: change to_mock() to an inline function
Applying: drm/i915: make more headers self-co
Commit a096883dda2c ("drm/i915/dsb: Remove PIN_MAPPABLE from the DSB object
VMA")
fixed it, remove the hack.
---
baseline: f681b0ac20073c08e34f5987800b35f45fb69e29
pile-commit: 3f2a85eed3a5be81b1ab3e02426c368f20e5be82
range-diff:
156: 31c4b0cc66c6 < -: INTEL_DII: drm/i915/dg1: H
d forward
> struct declarations.
>
> Signed-off-by: Masahiro Yamada
> ---
I confirmed this patch is applicable to next-20191107
but CI fails to apply it.
Which branch should I base my patch on?
>
> drivers/gpu/drm/i915/gem/selftests/mock_context.h | 3 +++
> drivers/gpu/dr
Hi Jani,
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, November 07, 2019 5:46 PM
> To: Linus Torvalds ; Yamada, Masahiro/山田
> 真弘 ; linux-kbu...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/2] kbuild: remove header
On 08/11/2019 01:34, Umesh Nerlige Ramappa wrote:
It turns out that the OAR CONTROL register is not getting configured
correctly in conjunction with the context save/restore bit. When
measuring work for a single context, the OAR counters do not increment.
- Configure OAR format and enable OAR co
Instead of rummaging through the intel_context to peek at the GEM
context in the middle of request submission to decide whether to use
semaphores, store that information on the intel_context itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 52 +-
Now that we don't need to create GEM contexts in the middle of engine
construction, we can pull the engine init/setup loops together.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 118 +++---
drivers/gpu/drm/i915/gt/intel_gt.c| 5 -
dri
Make sure that our code is robust enough to handle multiple threads
trying to clear objects for a single client context. This brings the joy
of a shared GGTT to all!
References: https://bugs.freedesktop.org/show_bug.cgi?id=112176
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
.../i915/gem/sel
Currently, we only export symbols for drm-selftests which are either
compiled as modules or into the main drm builtin. However, if we want to
export symbols from drm.ko for the drivers' selftests, we require a
means of controlling that export separately. So we add a new Kconfig to
determine whether
As we read the ctx->vm unlocked before cloning/exporting, we should
validate our reference is correct before returning it. We already do for
clone_vm() but were not so strict around get_ppgtt().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 80 +++-
Use the per-engine sysfs directory to let userspace discover the
mmio_base of each engine. Prior to recent generations, the user
accessible registers on each engine are at a fixed offset relative to
each engine -- but require absolute addressing. As the absolute address
depends on the actual physic
Execlists uses a scheduling quantum (a timeslice) to alternate execution
between ready-to-run contexts of equal priority. This ensures that all
users (though only if they of equal importance) have the opportunity to
run and prevents livelocks where contexts may have implicit ordering due
to userspa
When we allow ourselves to sleep before a GPU reset after disabling
submission, even for a few milliseconds, gives an innocent context the
opportunity to clear the GPU before the reset occurs. However, how long
to sleep depends on the typical non-preemptible duration (a similar
problem to determini
As drm now exports a method to create an anonymous struct file around a
drm_device for internal use, make use of it to avoid our horrible hacks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug| 2 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../drm/i9
Only add the engine to the available set of uabi engines once it has
been fully initialised and we know we want it in the public set.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Wajdeczko
Cc: Andi Shyti
Acked-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++-
To make exploration of different sorting orders and presentation of the
engines via the uabi easier, wrap the basic engine registration into a
mock (aka standalone) selftest.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 4 +
.../gpu/drm/i91
Some basic information that is useful to know, such as how many cycles
is a MI_NOOP.
Signed-off-by: Chris Wilson
Cc: Anna Karas
Cc: Tvrtko Ursulin
---
.../i915/gem/selftests/i915_gem_object_blt.c | 15 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 339 +-
drivers/gpu/drm
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure. Later
set_page_dirty says:
For pages with a mapping this should be done under the page lock
for the benefit of asynchronous memory errors who prefer a
consistent dirty state. This rule can be broken in some special
cases, but should be better not to.
Under those rules, i
Begin pulling the GT setup underneath a single GT umbrella; let intel_gt
take ownership of its engines! As hinted, the complication is the
lifetime of the probed engine versus the active lifetime of the GT
backends. We need to detect the engine layout early and keep it until
the end so that we can
Keep the intel_context as being the primary state for i915_request, with
the GEM context a backpointer from the low level state for the rarer
cases we need client information. Our goal is to remove such references
to clients from the backend, and leave the HW submission agnostic to
client interface
Sometimes we need to create a struct file to wrap a drm_device, as it
the user were to have opened /dev/dri/card0 but to do so anonymously
(i.e. for internal use). Provide a utility method to create a struct
file with the drm_device->driver.fops, that wrap the drm_device.
v2: Restrict usage to sel
Whenever, we unbind (or change fence registers) on an object, we must
revoke any and all mmap_gtt using the previous bindings. Those user PTEs
point at the GGTT which know points into a new object, the wrong object.
Ergo, those PTEs must be cleared so that any user access provokes a new
page fault.
After initialising a preemption request, we give the current resident a
small amount of time to vacate the GPU. The preemption request is for a
higher priority context and should be immediate to maintain high
quality of service (and avoid priority inversion). However, the
preemption granularity of
The hidden aliasing-ppgtt's size is never revealed, as we only inspect
the front GTT when engaged. However, we were "fixing" the hidden ppgtt
to match, with the net result that we ended up leaking the unused
portion (on Braswell were we preallocated the entire range).
[ 26.025364] DMA-API: pci 0
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 21 -
drivers/gpu/drm/i915/selftests/i915_active.c | 46 +
We monitor the health of the system via periodic heartbeat pulses. The
pulses also provide the opportunity to perform garbage collection.
However, we interpret an incomplete pulse (a missed heartbeat) as an
indication that the system is no longer responsive, i.e. hung, and
perform an engine or full
Allocate only an internal intel_context for the kernel_context, forgoing
a global GEM context for internal use as we only require a separate
address space (for our own protection).
Now having weaned GT from requiring ce->gem_context, we can stop
referencing it entirely. This also means we no longe
Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/g
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas Lahtinen
Signed-off-by: Chris Wilson
Cc:
No good reason why we must always use a static ringsize, so let
userspace select one during construction.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 143 +++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
include/uapi
As the GEM global context setup is now independent of the GT state
(although GT does currently still depending upon the global
i915->kernel_context), we can move its init earlier, leaving the gt init
ready to extracted.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c
As we start peeking into requests for longer and longer, e.g.
incorporating use of spinlocks when only protected by an
rcu_read_lock(), we need to be careful in how we reset the request when
recycling and need to preserve any barriers that may still be in use as
the request is reset for reuse.
Sig
Quoting Daniele Ceraolo Spurio (2019-11-06 22:25:47)
> Remove unused enums and ctx_save_restore_disabled() function, leftover
> from the legacy preemption removal.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Michal Wajdeczko
> Cc: John Harrison
> Cc: Matthew Brost
Reviewed-by: Chris Wilson
Quoting Daniele Ceraolo Spurio (2019-11-06 22:25:48)
> We already have a couple of use-cases in the code and another one will
> come in one of the later patches in the series.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Michal Wajdeczko
> Cc: John Harrison
> Cc: Matthew Brost
Reviewed-by:
Hi Dave, Daniel,
Here's this week PR for drm-misc-fixes.
Thanks!
Maxime
drm-misc-fixes-2019-11-07-1:
- Some new documentation for GEM shmem madvise helpers
- Fix for a state dereference in atomic self-refresh helpers
- One compilation fix for c2p fbdev helpers
The following changes since comm
On Wed, 06 Nov 2019, Ville Syrjälä wrote:
> On Wed, Nov 06, 2019 at 06:45:31PM +0200, Jani Nikula wrote:
>> Using the array is getting clumsy. Make things a bit more dynamic.
>>
>> In code, start migrating towards calling the new struct child_device
>> "child" and the VBT-originating struct child
Chris Wilson writes:
> The hidden aliasing-ppgtt's size is never revealed, as we only inspect
> the front GTT when engaged. However, we were "fixing" the hidden ppgtt
> to match, with the net result that we ended up leaking the unused
> portion (on Braswell were we preallocated the entire range).
Quoting Mika Kuoppala (2019-11-07 08:32:47)
> Chris Wilson writes:
>
> > The hidden aliasing-ppgtt's size is never revealed, as we only inspect
> > the front GTT when engaged. However, we were "fixing" the hidden ppgtt
> > to match, with the net result that we ended up leaking the unused
> > port
On Wed, Nov 06, 2019 at 02:24:28PM +, Chris Wilson wrote:
> Currently, we only export symbols for drm-selftests which are either
> compiled as modules or into the main drm builtin. However, if we want to
> export symbols from drm.ko for the drivers' selftests, we require a
> means of controllin
On Wed, Nov 06, 2019 at 02:24:29PM +, Chris Wilson wrote:
> Sometimes we need to create a struct file to wrap a drm_device, as it
> the user were to have opened /dev/dri/card0 but to do so anonymously
> (i.e. for internal use). Provide a utility method to create a struct
> file with the drm_dev
Chris Wilson writes:
> Some basic information that is useful to know, such as how many cycles
> is a MI_NOOP.
>
> Signed-off-by: Chris Wilson
> Cc: Anna Karas
> Cc: Tvrtko Ursulin
> ---
> .../i915/gem/selftests/i915_gem_object_blt.c | 15 +-
> drivers/gpu/drm/i915/gt/selftest_engine_cs.c |
On Wed, Nov 06, 2019 at 02:24:30PM +, Chris Wilson wrote:
> As drm now exports a method to create an anonymous struct file around a
> drm_device for internal use, make use of it to avoid our horrible hacks.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/Kconfig.debug
== Series Details ==
Series: series starting with [1/3] drm: Expose a method for creating anonymous
struct file around drm_minor
URL : https://patchwork.freedesktop.org/series/69048/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7266_full -> Patchwork_15149_full
=
On Thu, 07 Nov 2019, Masahiro Yamada wrote:
> There are both positive and negative options about this feature.
> At first, I thought it was a good idea, but actually Linus stated a
> negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it
> is ugly and annoying.
Linus, we used to have
Quoting Mika Kuoppala (2019-11-07 08:39:00)
> Chris Wilson writes:
>
> > Some basic information that is useful to know, such as how many cycles
> > is a MI_NOOP.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Anna Karas
> > Cc: Tvrtko Ursulin
> > ---
> > .../i915/gem/selftests/i915_gem_object_bl
On 06/11/2019 10.26, Chris Wilson wrote:
> Provide a utility function to create a vma corresponding to an mmap() of
> our device. And use it to exercise the equivalent of userspace
> performing a GTT mmap of our objects.
>
> Signed-off-by: Chris Wilson
> Cc: Abdiel Janulgue
Reviewed-by: Abdie
On Wed, Nov 06, 2019 at 03:05:42PM +0800, Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is
On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented through vringh
> and workqueue. A device specific dma ops is to make sure HVA is used
> directly as the IOVA.
On Wed, Nov 06, 2019 at 09:35:25PM +0800, Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is
Quoting Ramalingam C (2019-11-06 16:08:19)
> When LMEM is supported, dumb buffer preferred to be created from LMEM.
Please extend igt/gem_create to also cover dumb buffer creation, in
particular the always_clear check.
-Chris
___
Intel-gfx mailing list
I
Quoting Niranjan Vishwanathapura (2019-11-07 05:05:26)
> On Wed, Nov 06, 2019 at 08:52:58AM +, Chris Wilson wrote:
> >Sure, for correctness see clone_vm().
>
> Ok, I can put a common helper function like vm_get_rcu_safe(ctx).
https://patchwork.freedesktop.org/patch/339110/?series=69044&rev=1
Quoting Ramalingam C (2019-11-05 14:44:14)
> If Local memory is supported by hardware, we want framebuffer backing
> gem objects from local memory.
>
> if the backing obj is not from LMEM, pin_to_display is failed.
>
> v2:
> memory regions are correctly assigned to obj->memory_regions [tvrtko]
On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to m
For Gen11+ platforms BSpec suggests disabling specific
QGV points separately, depending on bandwidth limitations
and current display configuration. Thus it required adding
a new PCode request for disabling QGV points and some
refactoring of already existing SAGV code.
Also had to refactor intel_can
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with ad
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
The pre-initialized magic value is a bit silly, switch to a flag
instead.
v2: Reduce paranoia to a single sanity check (Ville)
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 10 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 13 +++-
On Thu, Nov 07, 2019 at 10:22:10AM +0200, Jani Nikula wrote:
> On Wed, 06 Nov 2019, Ville Syrjälä wrote:
> > On Wed, Nov 06, 2019 at 06:45:31PM +0200, Jani Nikula wrote:
> >> Using the array is getting clumsy. Make things a bit more dynamic.
> >>
> >> In code, start migrating towards calling the
Inside the constructor, while cloning, we need to replace the
dst->engines. Having forgotten that dst->engines is marked as RCU
protected, we need to add the appropriate annotations to make sparse
happy.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_contex
On Tue, 29 Oct 2019, Manasi Navare wrote:
> On Tue, Oct 29, 2019 at 12:39:47PM +0200, Jani Nikula wrote:
>> The intel_dp_link_training.h include has no need or place in
>> intel_display.h. Include it in intel_display.c instead.
>>
>> Cc:
>>
>> Cc: Manasi Navare
>> Fixes: eadf6f9170d5 ("drm/i915
On Thu, Nov 07, 2019 at 12:32:30PM +0200, Jani Nikula wrote:
> The pre-initialized magic value is a bit silly, switch to a flag
> instead.
>
> v2: Reduce paranoia to a single sanity check (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
stands
> ---
> dr
== Series Details ==
Series: series starting with [01/28] drm/i915: Leave the aliasing-ppgtt size
alone
URL : https://patchwork.freedesktop.org/series/69111/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e71bdbad4df9 drm/i915: Leave the aliasing-ppgtt size alone
d9b14a009b12 d
On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
> > On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
> > > This sample driver creates mdev device that simulate virtio net device
> > > over virtio mdev transport. The device i
1 - 100 of 219 matches
Mail list logo
