Having called intel_gt_init_early() to setup the mock intel_gt, we need
to call the corresponding intel_gt_driver_late_release() to clean up.
References: dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on
unload")
References: 24635c5152af ("drm/i915: Move intel_gt initialization to a
== Series Details ==
Series: drm/i915/selftests: Add intel_gt_driver_late_release for mock device
URL : https://patchwork.freedesktop.org/series/69609/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ddc0fcd5661f drm/i915/selftests: Add intel_gt_driver_late_release for mock
On 11/18/19 12:35 PM, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Reviewed-by: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: Juergen
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the
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. This should be sufficient for kernel virtio
driver to work.
Only
Quoting Janusz Krzysztofik (2019-11-18 11:14:12)
> Hi Chris,
>
> Only some minor comments from me, mostly out of my curiosity.
>
> On Friday, November 15, 2019 5:05:45 PM CET Chris Wilson wrote:
> > No good reason why we must always use a static ringsize, so let
> > userspace select one during
== Series Details ==
Series: drm/i915/selftests: Add intel_gt_driver_late_release for mock device
URL : https://patchwork.freedesktop.org/series/69609/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7360 -> Patchwork_15310
On 2019/11/18 下午2:16, 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 done by introducing a new
On Mon, Nov 18, 2019 at 02:17:02PM +0800, Jason Wang wrote:
> This patch introduces a new mdev transport for virtio. This is used to
> use kernel virtio driver to drive the mediated device that is capable
> of populating virtqueue directly.
>
> A new virtio-mdev driver will be registered to the
On 18.11.19 11:35, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc:
Current mdev is tied to a VFIO specific "mdev" bus. This prevent mdev
from being used by other types of API/buses. So this patch tries to make
mdev bus agnostic through making a mdev core a thin module:
- decouple VFIO bus specific bits from mdev_core.c to mdev_vfio.c and
introduce mdev_vfio
Mdev now is nothing VFIO specific, let's move it to upper
directory.
Signed-off-by: Jason Wang
---
MAINTAINERS | 7 +--
drivers/Kconfig | 2 ++
drivers/Makefile | 1 +
drivers/mdev/Kconfig
The only thing left for generalizing mdev is the VFIO specific parent
ops. This is basically the open/release/read/write/ioctl/mmap.
To support this, mdev core is extend to support a specific size
of structure during create, this will allow to compose mdev structure
into mdev vfio structure and
This patch implements a mediated virtio bus over mdev framework. This
will be used by the future virtio-mdev and vhost-mdev on top to allow
driver from either userspace or kernel to control the device which is
capable of offloading virtio datapath.
Signed-off-by: Jason Wang
---
MAINTAINERS
Hi Chris,
Only some minor comments from me, mostly out of my curiosity.
On Friday, November 15, 2019 5:05:45 PM CET Chris Wilson wrote:
> 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
On Mon, Nov 18, 2019 at 11:35:35AM +0100, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
> Cc: Kirti Wankhede
> Cc: k...@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
Acked-by: Gerd Hoffmann
cheers,
Gerd
Hi all,
Way back when we created the dma-buf spec it made sense to have kmap/unmap
interfaces, since 32bit kernels with limited vmalloc space were still
rather ubiquitous. But that idea (like many others) never caught on, was
quickly replaced by vmaps covering the entire buffer for all real uses,
A few reasons to drop kmap:
- For native objects all we do is look at obj->vaddr anyway, so might
as well not call functions for every page.
- Reloc-processing on dma-buf is ... questionable.
- Plus most dma-buf that bother kernel cpu mmaps give you at least
vmap, much less kmaps. And all
It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
Delete it, before we start garbage-collecting the various
implementations.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Daniel Vetter
Cc: Mika Kuoppala
Cc: Dave Airlie
---
There's no in-tree users anymore.
Signed-off-by: Daniel Vetter
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Jens Wiklander
Cc: tee-...@lists.linaro.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/misc/fastrpc.c | 8
drivers/tee/tee_shm.c | 6
There's no callers in-tree anymore.
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
Signed-off-by: Daniel Vetter
Cc: Laura
No need for stubs, dma-buf.c takes care of that.
Aside, not having a ->release callback smelled like refcounting leak
somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
every export. But then I found that ttm_device_object_init overwrites
it. Overwriting const memory is not
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/gem.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index
It's a dummy anyway.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_gem.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 93cf8b8bfcff..976685f2939e 100644
---
No in-tree users left.
Note that this is one of the few (if only) implementations of dma-buf
that provided a kmap, but not a vmap implemenation. Given that the
only real user (in-tree at least) of kmap was tegra, and it's
impossible to buy a chip with tegra host1x and ompadrm on the same
SoC,
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: linux-me...@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
--
Ack for merging
It's unused.
10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.
Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode
No in-tree users left.
Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sam Ravnborg
Cc:
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Kirti Wankhede
Cc: k...@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
samples/vfio-mdev/mbochs.c | 16
1 file changed, 16 deletions(-)
diff --git
All implementations are gone now.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
include/linux/dma-buf.h | 25 -
1 file changed, 25 deletions(-)
diff --git a/include/linux/dma-buf.h
It doesn't have any callers anymore.
Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
do userspace mmaps, but a kernel vmap. I think most places use vmap
for this, except ttm, which uses kmap for vmap for added confusion.
mmap seems entirely for userspace mappings set up
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 done by introducing a new mdev transport for virtio
(virtio_mdev) and
On 11/18/19 11:35 AM, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
Acked-by: Hans Verkuil
Thanks!
Hans
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: linux-me...@vger.kernel.org
> --
> Ack for merging this
Am 18.11.19 um 11:35 schrieb Daniel Vetter:
No in-tree users left.
Good to know, thanks.
Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc:
On Fri, 15 Nov 2019, Matt Roper wrote:
> VBT revision 229 adds a new "Generic DTD" block 58 and deprecates the
> old LFP panel mode data in block 42. Let's start parsing this block to
> fill in the panel fixed mode on devices with a >=229 VBT.
>
> v2:
> * Update according to the recent updates:
== Series Details ==
Series: series starting with [1/3] drm/i915/bios: do not discard address space
(rev2)
URL : https://patchwork.freedesktop.org/series/69567/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7359_full -> Patchwork_15308_full
On Fri, 2019-11-15 at 22:19 +0200, Ville Syrjälä wrote:
> On Thu, Nov 14, 2019 at 02:24:49PM +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
Since igt now defaults to not enabling ftrace-on-oops, we need to
manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
GEM_BUG_ON panicking.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 18.11.2019 11:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: linux-me...@vger.kernel.org
Acked-by: Marek Szyprowski
> --
> Ack for merging this through drm trees
On 2019/11/18 下午6:44, Michael S. Tsirkin wrote:
+static const struct mdev_virtio_class_id virtio_id_table[] = {
+ { MDEV_VIRTIO_CLASS_ID_VIRTIO },
+ { 0 },
+};
+
Do we still need the class ID? It's a virtio mdev bus,
do we need a virtio class as well?
If we want to have auto
On Sat, 16 Nov 2019, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: fix accidental static variable use
> URL : https://patchwork.freedesktop.org/series/69525/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7352_full -> Patchwork_15280_full
>
On Mon, Nov 18, 2019 at 11:35:25AM +0100, Daniel Vetter wrote:
> There's no callers in-tree anymore.
>
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new
On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
>
> Signed-off-by: Daniel Vetter
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Jens Wiklander
> Cc: tee-...@lists.linaro.org
> --
> Ack for merging this through drm trees very much
On 18/11/2019 12:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Note that this is one of the few (if only) implementations of dma-buf
> that provided a kmap, but not a vmap implemenation. Given that the
> only real user (in-tree at least) of kmap was tegra, and it's
> impossible to buy a
Quoting Daniel Vetter (2019-11-18 10:35:27)
> No in-tree users left.
Fair enough then,
Reviewed-by: Chris Wilson
> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.
We've also started on some
== Series Details ==
Series: Retire dma_buf_k(un)map
URL : https://patchwork.freedesktop.org/series/69616/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7361 -> Patchwork_15311
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7361 -> Patchwork_15312
Summary
On 14/11/2019 21:21, Umesh Nerlige Ramappa wrote:
Gen12 supports saving/restoring render counters per context. Apply OAR
configuration only for the context that is passed in to perf.
v2:
- Fix OACTXCONTROL value to only stop/resume counters.
- Remove gen12_update_reg_state_unlocked as power
Quoting Daniel Vetter (2019-11-18 10:35:24)
> It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
> Delete it, before we start garbage-collecting the various
> implementations.
Ok then, I'm still mourning the loss of kmap. I definitely do not think
we should _only_ have a
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/69621/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
| | | i915.ko |<-> physical
== Series Details ==
Series: Retire dma_buf_k(un)map
URL : https://patchwork.freedesktop.org/series/69616/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4c6a4728b6b2 drm/tegra: Map cmdbuf once for reloc processing
-:73: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/69621/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
67f3ea3cda70 mdev: make mdev bus agnostic
-:648: CHECK:LINE_SPACING: Please don't use multiple blank
On Mon, 2019-11-18 at 16:22 +0200, Jani Nikula wrote:
> On Thu, 14 Nov 2019, Stanislav Lisovskiy <
> stanislav.lisovs...@intel.com> wrote:
> > Also implemented algorithm for choosing DBuf slice configuration
> > based on active pipes, pipe ratio as stated in BSpec 12716.
> >
> > Now pipe
== Series Details ==
Series: drm/i915/selftests: Add intel_gt_driver_late_release for mock device
URL : https://patchwork.freedesktop.org/series/69609/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7360_full -> Patchwork_15310_full
Quoting Tvrtko Ursulin (2019-11-18 15:12:17)
>
> On 18/11/2019 14:46, Chris Wilson wrote:
> > The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
> > corruption WA") is that it disables RC6 while Skylake (and friends) is
> > active, and we do not consider the GPU idle until
On Mon, Nov 18, 2019 at 06:59:23PM +0800, Jason Wang wrote:
> +static void mvnet_device_release(struct device *dev)
> +{
> + dev_dbg(dev, "mvnet: released\n");
> +}
We used to have documentation in the kernel source tree that said that
whenever anyone did this, I got to make fun of them.
' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-allmodconfig
On Mon, 18 Nov 2019 18:59:23 +0800
Jason Wang wrote:
[Note: I have not looked into the reworked architecture of this *at all*
so far; just something that I noted...]
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented
On Sat, Nov 16, 2019 at 05:13:17PM +0100, Peter Wu wrote:
> On Fri, Nov 15, 2019 at 08:14:05PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 15, 2019 at 04:32:47PM +0100, Peter Wu wrote:
> > > Since "Make PixmapDirtyUpdateRec::src a DrawablePtr" in xserver, the
> > > "src" pointer might point to the
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/69621/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7361 -> Patchwork_15313
Summary
---
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If
On 11/18/19 5:35 AM, Daniel Vetter wrote:
There's no callers in-tree anymore.
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
On 18/11/2019 14:46, Chris Wilson wrote:
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine
On Thu, 14 Nov 2019, 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 DBuf slice for this
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If
On 18/11/2019 09:43, Chris Wilson wrote:
Having called intel_gt_init_early() to setup the mock intel_gt, we need
to call the corresponding intel_gt_driver_late_release() to clean up.
References: dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on
unload")
References: 24635c5152af
On Mon, 18 Nov 2019, "Lisovskiy, Stanislav"
wrote:
> I'm fine with fixing checkpatch and sparse failures(even though
> most of those are about 80 line width limitation violation or line
> continuations, which tbh are anyway quite common in our code).
Please look through the warnings again.
On Mon, Nov 18, 2019 at 09:19:18AM +, Lisovskiy, Stanislav wrote:
> On Fri, 2019-11-15 at 22:19 +0200, Ville Syrjälä wrote:
> > On Thu, Nov 14, 2019 at 02:24:49PM +0200, Stanislav Lisovskiy wrote:
> > > Also implemented algorithm for choosing DBuf slice configuration
> > > based on active
On Tue, 12 Nov 2019, Imre Deak wrote:
> According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
This seems to be pushed already, but I'm just confused about difference
between the id here in the commit message vs. the one in the patch.
BR,
Jani.
> belongs to a CMP-V chipset.
Hello Daniel,
On Mon, 18 Nov 2019 at 16:05, Daniel Vetter wrote:
>
> Hi all,
>
> Way back when we created the dma-buf spec it made sense to have kmap/unmap
> interfaces, since 32bit kernels with limited vmalloc space were still
> rather ubiquitous. But that idea (like many others) never caught
On Wed, 13 Nov 2019, Bruce Chang wrote:
> below is the call trace when this issue is hit
>
> <3> [113.316247] BUG: sleeping function called from invalid context at
> mm/page_alloc.c:4653
> <3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name:
> debugfs_test
> <4> [113.319900] no
On Fri, 15 Nov 2019, Lucas De Marchi wrote:
> On Fri, Nov 15, 2019 at 12:52:49PM -0800, Matt Roper wrote:
>>On Mon, Nov 11, 2019 at 12:50:25PM -0800, Lucas De Marchi wrote:
>>> When we call intel_dsb_get(), the dsb initialization may fail for
>>> various reasons. We already log the error message
== Series Details ==
Series: drm/i915/gt: Schedule request retirement when submission idles (rev2)
URL : https://patchwork.freedesktop.org/series/69628/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a864196824b7 drm/i915/gt: Schedule request retirement when submission idles
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap
plementation. Also, the patch set will start to compile
once linux-next is open for 5.6.
Cheers, Daniel
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
>
From: Ville Syrjälä
Rebased for CI. All reviewed already.
Ville Syrjälä (10):
drm/i915: Change intel_encoders_() calling convention
drm/i915: Add intel_crtc_vblank_off()
drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on()
drm/i915: Move crtc_state to tighter scope
From: Ville Syrjälä
Switch to intel_crtc from drm_crtc.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
From: Ville Syrjälä
We already have intel_crtc_vblank_on(). Add a counterpart so we
don't have to inline the disable+assert all over.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 15 +--
1 file changed, 9
From: Ville Syrjälä
intel_modeset_setup_hw_state() doesn't need the crtc_state at the
top level scope. Move it to where it's needed.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +++
1 file changed, 7 insertions(+), 4
The bspec was recently updated with new cdclk -> voltage level tables to
accomodate the new 324/326.4 cdclk values.
Bspec: 21809
Cc: José Roberto de Souza
Cc: Vivek Kasireddy
Cc: Bob Paauwe
Signed-off-by: Matt Roper
---
There are some platform tagging issues on this bspec page and multiple
On Mon, Nov 18, 2019 at 08:44:12AM -0800, Matt Roper wrote:
> The bspec was recently updated with new cdclk -> voltage level tables to
> accomodate the new 324/326.4 cdclk values.
>
> Bspec: 21809
> Cc: José Roberto de Souza
> Cc: Vivek Kasireddy
> Cc: Bob Paauwe
> Signed-off-by: Matt Roper
On Mon, Nov 18, 2019 at 05:49:44PM +0200, Jani Nikula wrote:
> On Tue, 12 Nov 2019, Imre Deak wrote:
> > According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
>
> This seems to be pushed already, but I'm just confused about difference
> between the id here in the commit message
On Sun, Nov 17, 2019 at 04:59:01PM +, Patchwork wrote:
> == Series Details ==
>
> Series: VBT "generic DTD" block (rev3)
> URL : https://patchwork.freedesktop.org/series/69481/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7357_full -> Patchwork_15300_full
>
On Mon, Nov 18, 2019 at 05:53:37PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 18, 2019 at 05:49:44PM +0200, Jani Nikula wrote:
> > On Tue, 12 Nov 2019, Imre Deak wrote:
> > > According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
> >
> > This seems to be pushed already, but I'm
Putting down the AUX power domain reference count in
edp vdd off async sequence takes too much of time
(relative to panel power cycle delay) therefore it make sense
to expose the panel power cycle delay to i915_panel_timings
along with other delays.
It can be use by DC state IGT to wait for strict
== Series Details ==
Series: drm/i915/gt: Schedule request retirement when submission idles (rev2)
URL : https://patchwork.freedesktop.org/series/69628/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7363 -> Patchwork_15314
From: Ville Syrjälä
Just pass the atomic_state+crtc to the watermarks hooks. Eeasier
time for the caller when it doesn't have to think what to pass.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 32 +-
From: Ville Syrjälä
Rename pipe_config to new_crtc_state in the .crtc_enable() hooks.
The 'pipe_config' name is a zombie that we need to finally put down.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 173 +--
1
From: Ville Syrjälä
Just pass the atomic state and the crtc to intel_encoders_enable() & co.
Make life simpler when you don't have to think which state (old vs. new)
you have to pass in. Also constify the states while at it.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Get rid of the last 'dev' usage in ironlake_crtc_enable() by
passing dev_priv to cpt_verify_modeset().
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Ville Syrjälä
Get rid of the horrible aliasing drm_crtc and intel_crtc variables
in the crtc enable/disable hooks.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 142 +--
1 file changed, 65 insertions(+), 77
From: Ville Syrjälä
Move the assert_vblank_disabled() into intel_crtc_vblank_on()
so that we don't have to inline it all over.
This does mean we now assert_vblank_disabled() during readout as well
but that is totally fine as it happens after drm_crtc_vblank_reset().
One can even argue it's what
From: Ville Syrjälä
Just pass the atomic state+crtc to the .crtc_enable()
.crtc_disable(). Life is easier when you don't have to think
whether to pass the old or the new crtc state.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 58
Quoting Chris Wilson (2019-11-18 16:23:42)
> In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
> the backend"), I erroneously concluded that we last modify the engine
> inside __i915_request_commit() meaning that we could enable concurrent
> submission for userspace as we
On Mon, 2019-11-18 at 17:27 +0200, Ville Syrjälä wrote:
> On Mon, Nov 18, 2019 at 09:19:18AM +, Lisovskiy, Stanislav wrote:
> > On Fri, 2019-11-15 at 22:19 +0200, Ville Syrjälä wrote:
> > > On Thu, Nov 14, 2019 at 02:24:49PM +0200, Stanislav Lisovskiy
> > > wrote:
> > > > Also implemented
On Thu, Nov 14, 2019 at 05:05:13PM +0100, Maarten Lankhorst wrote:
> The members in hw.mode can be used from adjusted_mode as well,
> use that when available.
>
> Some places that use hw.mode can be converted to use adjusted_mode
> as well.
>
> Signed-off-by: Maarten Lankhorst
> ---
>
On 11/15/19 11:21 AM, Daniel Vetter wrote:
> The current code is a pretty good wtf moment, since we drop the
> reference before we use it. It's not a big deal, because a) we only
> use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
> already holds a full reference for us.
>
>
On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
>
> Signed-off-by: Daniel Vetter
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Jens Wiklander
> Cc: tee-...@lists.linaro.org
> --
> Ack for merging this through drm trees very much
On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
> +struct bus_type mdev_virtio_bus_type;
> +
> +struct mdev_virtio_device {
> + struct mdev_device mdev;
> + const struct mdev_virtio_ops *ops;
> + u16 class_id;
> +};
This seems to share nothing with mdev (ie mdev-vfio), why
1 - 100 of 197 matches
Mail list logo
