On Fri, Jun 19, 2020 at 8:58 AM Jason Gunthorpe wrote:
>
> On Thu, Jun 18, 2020 at 05:00:51PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 17, 2020 at 12:28:35PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Jun 17, 2020 at 08:48:50AM +0200, Daniel Vetter wrote:
> > >
> > > > Now my understanding for
Quoting Daniel Stone (2020-06-11 10:01:46)
> Hi,
>
> On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote:
> > On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote:
> > > Introducing a global lockmap that cannot capture the rules correctly,
> >
> > Can you document the rules all drivers should be followi
On Thu, Jun 18, 2020 at 01:27:00PM -0700, Rodrigo Vivi wrote:
> From: Swathi Dhanavanthri
>
> commit 63d0f3ea8ebb67160eca281320d255c72b0cb51a upstream.
>
> This workaround now applies to all steppings, not just A0.
> Wa_1409085225 is a temporary A0-only W/A however it is
> identical to Wa_140102
On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson wrote:
>
> Quoting Daniel Stone (2020-06-11 10:01:46)
> > Hi,
> >
> > On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote:
> > > On Thu, 11 Jun 2020 at 18:01, Chris Wilson
> > > wrote:
> > > > Introducing a global lockmap that cannot capture the rules c
Quoting Daniel Vetter (2020-06-19 09:51:59)
> On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> wrote:
> > Forcing a generic primitive to always be part of the same global map is
> > horrible.
>
> And no concrete example or reason for why that's not possible.
> Because frankly it's not horrible,
On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-06-19 09:51:59)
> > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> > wrote:
> > > Forcing a generic primitive to always be part of the same global map is
> > > horrible.
> >
> > And no concrete example
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Quoting Daniel Vetter (2020-06-19 10:43:09)
> On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2020-06-19 09:51:59)
> > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> > > wrote:
> > > > Forcing a generic primitive to always be part of the same global map
This is an initial set of patches for enabling VRR support in i915.
This series has patches for:
1. adding a drm dpcd helper to read ignore MSA
bit in sink's DPCD indicating sink support for VRR
2. Attach and set VRR capable connector prop for Intel DP conn
3. Expose VRR min and max through debu
From: Manasi Navare
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v2:
* Fix the typo in max_vfreq (Manasi)
* Change the name of node
From: Manasi Navare
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for
This is an initial set of patches for enabling VRR support in i915.
This series has patches for:
1. Adding a drm dpcd helper to read ignore MSA
bit in sink's DPCD indicating sink support for VRR
2. Attach and set VRR capable connector prop for Intel DP conn
3. Expose VRR min and max through debu
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v2:
* Fix the typo in max_vfreq (Manasi)
* Change the name of node
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect
Rearrange the allocation of the mm_struct registration to avoid
allocating underneath the i915->mm_lock, so that we avoid tainting the
lock (and in turn many other locks that may be held as i915->mm_lock is
taken, and those locks we may want on the free [shrinker] paths). In
doing so, we convert th
Since gvt calls pin_map for the shadow batch buffer, this makes the
action of prepare_write [+pin_pages] redundant. We can write into the
obj->mm.mapping directory and the flush_map routine knows when it has to
flush the cpu cache afterwards.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
We only emit the renderstate once now during module load, it is no
longer a concern that we are delaying context creation and so do not
need to so eagerly optimise. Since the last time we have looked at the
renderstate, we have a pin_map / flush_map facility that supports simple
single mappings, re
== Series Details ==
Series: VRR capable attach prop in i915, DPCD helper, VRR debugfs (rev3)
URL : https://patchwork.freedesktop.org/series/78278/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d029f13253a7 drm/dp: DRM DP helper for reading Ignore MSA from DPCD
8ab5efcf7756 drm
== Series Details ==
Series: VRR capable attach prop in i915, DPCD helper, VRR debugfs (rev3)
URL : https://patchwork.freedesktop.org/series/78278/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
On Fri, Jun 19, 2020 at 1:39 PM Jason Gunthorpe wrote:
>
> On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > > As I've understood GPU that means you need to show that the commands
> > > associated with the buffer have completed. This is all local stuff
> > > within the driver, rig
== Series Details ==
Series: VRR capable attach prop in i915, DPCD helper, VRR debugfs (rev3)
URL : https://patchwork.freedesktop.org/series/78278/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8645 -> Patchwork_17994
Summa
Smatch warns that we may iterate over an empty array of gt->engines[].
One hopes that this is impossible, but nevertheless we can simply
appease smatch by initialising the timestamp to zero before we starting
probing the engines.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_rps.
drm-misc-next-2020-06-19:
drm-misc-next for v5.9:
UAPI Changes:
- Add DRM_MODE_TYPE_USERDEF for video modes specified in cmdline.
Cross-subsystem Changes:
- Assorted devicetree binding updates.
- Add might_sleep() to dma_fence_wait().
- Fix fbdev's get_user_pages_fast() handling, and use pin_user
== Series Details ==
Series: series starting with [1/3] drm/i915/gem: Avoid kmalloc under
i915->mm_lock
URL : https://patchwork.freedesktop.org/series/78643/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e219e0a60e23 drm/i915/gem: Avoid kmalloc under i915->mm_lock
-:143: CHECK
== Series Details ==
Series: series starting with [1/3] drm/i915/gem: Avoid kmalloc under
i915->mm_lock
URL : https://patchwork.freedesktop.org/series/78643/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked se
On Fri, Jun 19, 2020 at 5:15 PM Jason Gunthorpe wrote:
>
> On Fri, Jun 19, 2020 at 05:06:04PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 19, 2020 at 1:39 PM Jason Gunthorpe wrote:
> > >
> > > On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > > > > As I've understood GPU that mea
== Series Details ==
Series: drm/i915/gt: Initialise rps timestamp
URL : https://patchwork.freedesktop.org/series/78645/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8645 -> Patchwork_17996
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/gt: Initialise rps timestamp
URL : https://patchwork.freedesktop.org/series/78645/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8645_full -> Patchwork_17996_full
Summary
---
**F
On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>
> > The madness is only that device B's mmu notifier might need to wait
> > for fence_B so that the dma operation finishes. Which in turn has to
> > wait for device A
On Thu, Jun 11, 2020 at 07:35:35PM -0400, Felix Kuehling wrote:
> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> >>> I still have my doubts about allowing fence waiting from within shrinkers.
> >>> IMO ideally they should us
On Fri, 19 Jun 2020 at 16:19, Chris Wilson wrote:
>
> Smatch warns that we may iterate over an empty array of gt->engines[].
> One hopes that this is impossible, but nevertheless we can simply
> appease smatch by initialising the timestamp to zero before we starting
> probing the engines.
>
> Sign
Hi Bhanu,
Thanks for the patch, functionality wise looks good. Have you tested this
with kms_vrr IGT, do we see the vrr_range properly exposed?
Also please find some comments below
On Sat, Jun 20, 2020 at 02:53:56AM +0530, Bhanuprakash Modem wrote:
> [Why]
> It's useful to know the min and max v
Since we always enable the busy-stats, the culmulative runtime should be
accurate, and might be useful for diagnosing issues with the engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt
On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote:
>
> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> >
> > > The madness is only that device B's mmu notifier might need to wait
> > > for fence_B so that the d
On Fri, 19 Jun 2020 at 15:31, Chris Wilson wrote:
>
> Rearrange the allocation of the mm_struct registration to avoid
> allocating underneath the i915->mm_lock, so that we avoid tainting the
> lock (and in turn many other locks that may be held as i915->mm_lock is
> taken, and those locks we may w
Am 2020-06-19 um 3:11 p.m. schrieb Alex Deucher:
> On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote:
>> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
>>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>>>
The madness is only that device B's mmu notifier
Quoting Matthew Auld (2020-06-19 20:29:15)
> On Fri, 19 Jun 2020 at 15:31, Chris Wilson wrote:
> >
> > Rearrange the allocation of the mm_struct registration to avoid
> > allocating underneath the i915->mm_lock, so that we avoid tainting the
> > lock (and in turn many other locks that may be held
On Fri, 19 Jun 2020 at 15:31, Chris Wilson wrote:
>
> We only emit the renderstate once now during module load, it is no
> longer a concern that we are delaying context creation and so do not
> need to so eagerly optimise. Since the last time we have looked at the
> renderstate, we have a pin_map
Rearrange the allocation of the mm_struct registration to avoid
allocating underneath the i915->mm_lock, so that we avoid tainting the
lock (and in turn many other locks that may be held as i915->mm_lock is
taken, and those locks we may want on the free [shrinker] paths). In
doing so, we convert th
On Fri, Jun 19, 2020 at 03:30:32PM -0400, Felix Kuehling wrote:
>
> Am 2020-06-19 um 3:11 p.m. schrieb Alex Deucher:
> > On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote:
> >> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> >>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Danie
On Fri, 19 Jun 2020 at 15:31, Chris Wilson wrote:
>
> Since gvt calls pin_map for the shadow batch buffer, this makes the
> action of prepare_write [+pin_pages] redundant. We can write into the
> obj->mm.mapping directory and the flush_map routine knows when it has to
> flush the cpu cache afterwa
Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
>> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
>>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>>>
The madness is only that device B's mm
On Fri, 19 Jun 2020 at 20:11, Chris Wilson wrote:
>
> Since we always enable the busy-stats, the culmulative runtime should be
> accurate, and might be useful for diagnosing issues with the engine.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Thanks for the review, pushed to drm-misc
Manasi
On Sat, Jun 20, 2020 at 02:53:54AM +0530, Bhanuprakash Modem wrote:
> From: Manasi Navare
>
> DP sink device sets the Ignore MSA bit in its
> DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
> ignore the MSA video timing parameters an
Am 2020-06-19 um 3:55 p.m. schrieb Jason Gunthorpe:
> On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote:
>> Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
>>> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunth
On Fri, Jun 19, 2020 at 03:18:49PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> > On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> > > On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> > >
> > > > The madness is o
On Fri, Jun 19, 2020 at 10:09:00AM +0200, Greg KH wrote:
> On Thu, Jun 18, 2020 at 01:27:00PM -0700, Rodrigo Vivi wrote:
> > From: Swathi Dhanavanthri
> >
> > commit 63d0f3ea8ebb67160eca281320d255c72b0cb51a upstream.
> >
> > This workaround now applies to all steppings, not just A0.
> > Wa_14090
== Series Details ==
Series: drm/i915/gt: Show the culmative runtime as part of the engine info
URL : https://patchwork.freedesktop.org/series/78648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8646 -> Patchwork_17997
Sum
On Fri, Jun 19, 2020 at 04:55:38PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote:
> > Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
> > > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> > >> On Fri, Jun 19, 2020 at 02:23:08PM -
On Fri, Jun 19, 2020 at 10:10 PM Jerome Glisse wrote:
>
> On Fri, Jun 19, 2020 at 03:18:49PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> > > On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> > > > On Fri, Jun 19, 2020 at 06:19
== Series Details ==
Series: drm/i915/gem: Avoid kmalloc under i915->mm_lock
URL : https://patchwork.freedesktop.org/series/78650/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
04218f2bd97e drm/i915/gem: Avoid kmalloc under i915->mm_lock
-:240: CHECK:UNCOMMENTED_DEFINITION: spi
On Fri, Jun 19, 2020 at 10:43:20PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 10:10 PM Jerome Glisse wrote:
> >
> > On Fri, Jun 19, 2020 at 03:18:49PM -0300, Jason Gunthorpe wrote:
> > > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> > > > On Fri, Jun 19, 2020 at 02:23
== Series Details ==
Series: drm/i915/gem: Avoid kmalloc under i915->mm_lock
URL : https://patchwork.freedesktop.org/series/78650/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8647 -> Patchwork_17998
Summary
---
**S
== Series Details ==
Series: drm/i915/gt: Show the culmative runtime as part of the engine info
URL : https://patchwork.freedesktop.org/series/78648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8646_full -> Patchwork_17997_full
===
== Series Details ==
Series: drm/i915/gem: Avoid kmalloc under i915->mm_lock
URL : https://patchwork.freedesktop.org/series/78650/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8647_full -> Patchwork_17998_full
Summary
We only emit the renderstate once now during module load, it is no
longer a concern that we are delaying context creation and so do not
need to so eagerly optimise. Since the last time we have looked at the
renderstate, we have a pin_map / flush_map facility that supports simple
single mappings, re
Since gvt calls pin_map for the shadow batch buffer, this makes the
action of prepare_write [+pin_pages] redundant. We can write into the
obj->mm.mapping directory and the flush_map routine knows when it has to
flush the cpu cache afterwards.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 7baab4e528ef38546a32f0a368285289aa2c981f
commit: 11be607ccb68a1604ce6768a3cfb1fb528cc401a [17/21] Revert "drm/i915:
Don't select BROKEN"
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gvt: Drop redundant
prepare_write/pin_pages
URL : https://patchwork.freedesktop.org/series/78655/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be ch
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gvt: Drop redundant
prepare_write/pin_pages
URL : https://patchwork.freedesktop.org/series/78655/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8647 -> Patchwork_17999
62 matches
Mail list logo
