== Series Details ==
Series: drm/i915: Remove unecessary check for unsupported modifiers for NV12
URL : https://patchwork.freedesktop.org/series/45548/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ba24b4784bad drm/i915: Remove unecessary check for unsupported modifiers for
NV
This interface is deprecated, and has been replaced by the upstream
drm crc interface.
Signed-off-by: Maarten Lankhorst
Cc: Tomi Sarvela
Cc: Petri Latvala
Cc: Jani Nikula
Cc: Ville Syrjälä
Acked-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 +-
drivers/gpu/drm/i915/i915_
pipe_crc->lock only protects pipe_crc->skipped. Replace the lock with
atomic operations instead, it should work just as well, without the
spinlock. In the case we don't skip CRC in the irq, the fastpath is
only a single atomic_read().
Signed-off-by: Maarten Lankhorst
Cc: Ville Syrjälä
---
drive
== Series Details ==
Series: drm/i915: Remove unecessary check for unsupported modifiers for NV12
URL : https://patchwork.freedesktop.org/series/45548/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4395 -> Patchwork_9458 =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: series starting with [1/2] drm/i915: Remove support for legacy debugfs
crc interface
URL : https://patchwork.freedesktop.org/series/45553/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6428445ab929 drm/i915: Remove support for legacy debugfs crc in
== Series Details ==
Series: series starting with [1/2] drm/i915: Remove support for legacy debugfs
crc interface
URL : https://patchwork.freedesktop.org/series/45553/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Remove support for legacy debugfs crc interface
-
== Series Details ==
Series: series starting with [1/2] drm/i915: Remove support for legacy debugfs
crc interface
URL : https://patchwork.freedesktop.org/series/45553/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9459 =
== Summary - SUCCESS ==
No regr
Chris Wilson writes:
> By taking advantage of the RCU protection of the task struct, we can find
> the appropriate signaler under the spinlock and then release the spinlock
> before waking the task and signaling the fence.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika K
Chris Wilson writes:
> If we have more interrupts pending (because we know there are more
> breadcrumb signals before the completion), then we do not need to
> trigger an irq_seqno_barrier or even wakeup the task on this interrupt
> as there will be another. To allow some margin of error (we are
At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 45
Op 28-06-18 om 08:18 schreef Dhinakaran Pandiyan:
> There is already a check to allow only RGB formats with CCS
> modifiers.
>
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/in
On Thu, 28 Jun 2018, Maarten Lankhorst
wrote:
> This interface is deprecated, and has been replaced by the upstream
> drm crc interface.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Tomi Sarvela
> Cc: Petri Latvala
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Acked-by: Ville Syrjälä
Acked-by: Jan
== Series Details ==
Series: drm/i915: Show vma allocator stack when in doubt
URL : https://patchwork.freedesktop.org/series/45562/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9460 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwor
Quoting Patchwork (2018-06-28 09:55:21)
> == Series Details ==
>
> Series: drm/i915: Show vma allocator stack when in doubt
> URL : https://patchwork.freedesktop.org/series/45562/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9460 =
>
> == Summar
At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.
v2: We cannot allocate inside the printer (as it may be on an fs-reclaim
path), so hope
== Series Details ==
Series: drm/i915: Remove unecessary check for unsupported modifiers for NV12
URL : https://patchwork.freedesktop.org/series/45548/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4395_full -> Patchwork_9458_full =
== Summary - WARNING ==
Minor unknown
On Thu, 28 Jun 2018, Daniel Vetter wrote:
> On Wed, Jun 27, 2018 at 02:49:40PM +0300, Jani Nikula wrote:
>> On Thu, 21 Jun 2018, Ville Syrjälä wrote:
>> > On Thu, Jun 21, 2018 at 04:03:30PM +0300, Jani Nikula wrote:
>> >> Commit 9504a8924759 ("drm/i915/vlv: Reset the ADPA in
>> >> vlv_display_pow
== Series Details ==
Series: drm/i915: Show vma allocator stack when in doubt (rev2)
URL : https://patchwork.freedesktop.org/series/45562/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9461 =
== Summary - SUCCESS ==
No regressions found.
External URL
At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.
v2: We cannot allocate inside the printer (as it may be on an fs-reclaim
path), so hope
On 06/22/2018 10:11 PM, Christian König wrote:
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 57 +++
drm-misc-fixes-2018-06-28:
drm-misc-fixes for v4.18-rc3:
- A single fix in meson for an unhandled error path in meson_drv_bind_master().
The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819:
Linux 4.18-rc2 (2018-06-24 20:54:29 +0800)
are available in the Git repository at
On 06/22/2018 10:11 PM, Christian König wrote:
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 57 +++
On 06/22/2018 10:11 PM, Christian König wrote:
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
v2: reordered
Signed-off-by: Chr
On 06/22/2018 10:11 PM, Christian König wrote:
The caching of SGT's done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handl
On 27/06/2018 22:07, Chris Wilson wrote:
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access
On Wed, Jun 27, 2018 at 03:26:54PM -0700, Clint Taylor wrote:
>
>
> On 06/25/2018 03:33 AM, Imre Deak wrote:
> > On Wed, Jun 13, 2018 at 02:48:49PM -0700, clinton.a.tay...@intel.com wrote:
> > > From: Clint Taylor
> > >
> > > On GLK NUC platforms the HDMI retiming buffer needs additional disabl
On 27/06/2018 22:07, Chris Wilson wrote:
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we tr
On 27/06/2018 22:07, Chris Wilson wrote:
As we now never read back our current head position from the CSB
pointers register, and the HW itself doesn't use it to prevent
overwriting unread CSB entries, we do not need to keep updating the
register. As it turns out this register is not listed as be
Quoting Tvrtko Ursulin (2018-06-28 11:02:17)
>
> On 27/06/2018 22:07, Chris Wilson wrote:
> > Following the removal of the last workarounds, the only CSB mmio access
> > is for the old vGPU interface. The mmio registers presented by vGPU do
> > not require forcewake and can be treated as ordinary
== Series Details ==
Series: drm/i915: Show vma allocator stack when in doubt (rev3)
URL : https://patchwork.freedesktop.org/series/45562/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9462 =
== Summary - FAILURE ==
Serious unknown changes coming with P
Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
>
> On 27/06/2018 22:07, Chris Wilson wrote:
> > On HW reset, the HW clears the write pointer (to 0). But since it also
> > writes its first CSB entry to slot 0, we need to reset the write pointer
> > back to the element before (so the first entry we re
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
v2: Use _MASKED_FIE
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts (rev2)
URL : https://patchwork.freedesktop.org/series/45531/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6d78246fb880 drm/i915: Drop posting reads to flush master
== Series Details ==
Series: series starting with [1/2] drm/i915: Remove support for legacy debugfs
crc interface
URL : https://patchwork.freedesktop.org/series/45553/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4396_full -> Patchwork_9459_full =
== Summary - FAILURE ==
drm_atomic_helper allows for up to one outstanding cleanup task to be in
flight before a new modeset (see stall_commit in stall_checks()), In
lieu of hooking up a debugfs to force flushing of the outstanding work,
submit enough blocking modesets to ensure that the pending work is
completed before c
On 28/06/2018 11:10, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 11:02:17)
On 27/06/2018 22:07, Chris Wilson wrote:
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake a
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts (rev2)
URL : https://patchwork.freedesktop.org/series/45531/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9463 =
== Summary - SUCCESS ==
No
On 28/06/2018 11:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
On 27/06/2018 22:07, Chris Wilson wrote:
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element be
Quoting Tvrtko Ursulin (2018-06-28 11:58:26)
> On 28/06/2018 11:10, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-28 11:02:17)
> >>
> >> On 27/06/2018 22:07, Chris Wilson wrote:
> >>> + GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
> >>> + if (unlikely(head
Op 28-06-18 om 12:51 schreef Chris Wilson:
> drm_atomic_helper allows for up to one outstanding cleanup task to be in
> flight before a new modeset (see stall_commit in stall_checks()), In
> lieu of hooking up a debugfs to force flushing of the outstanding work,
> submit enough blocking modesets to
Op 28-06-18 om 12:41 schreef Patchwork:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Remove support for legacy
> debugfs crc interface
> URL : https://patchwork.freedesktop.org/series/45553/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_439
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce
Quoting Maarten Lankhorst (2018-06-28 12:06:35)
> Op 28-06-18 om 12:51 schreef Chris Wilson:
> > drm_atomic_helper allows for up to one outstanding cleanup task to be in
> > flight before a new modeset (see stall_commit in stall_checks()), In
> > lieu of hooking up a debugfs to force flushing of th
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts (rev3)
URL : https://patchwork.freedesktop.org/series/45531/
State : failure
== Summary ==
Applying: drm/i915: Drop posting reads to flush master interrupts
Applying: drm/i915/execl
On 28/06/2018 12:13, Chris Wilson wrote:
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access
Op 28-06-18 om 13:16 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-06-28 12:06:35)
>> Op 28-06-18 om 12:51 schreef Chris Wilson:
>>> drm_atomic_helper allows for up to one outstanding cleanup task to be in
>>> flight before a new modeset (see stall_commit in stall_checks()), In
>>> lieu o
On 27/06/2018 22:07, Chris Wilson wrote:
Now that we use the CSB stored in the CPU friendly HWSP, we do not need
to track interrupts for when the mmio CSB registers are valid and can
just check where we read up to last from the cached HWSP. This means we
can forgo the atomic bit tracking from in
Quoting Tvrtko Ursulin (2018-06-28 12:02:30)
>
> On 28/06/2018 11:17, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
> >>
> >> On 27/06/2018 22:07, Chris Wilson wrote:
> >>> On HW reset, the HW clears the write pointer (to 0). But since it also
> >>> writes its first CSB entr
Quoting Maarten Lankhorst (2018-06-28 12:25:18)
> Op 28-06-18 om 13:16 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-06-28 12:06:35)
> >> Op 28-06-18 om 12:51 schreef Chris Wilson:
> >>> drm_atomic_helper allows for up to one outstanding cleanup task to be in
> >>> flight before a new m
On 28/06/2018 12:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 12:02:30)
On 28/06/2018 11:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
On 27/06/2018 22:07, Chris Wilson wrote:
On HW reset, the HW clears the write pointer (to 0). But since it also
writes
Op 28-06-18 om 13:34 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-06-28 12:25:18)
>> Op 28-06-18 om 13:16 schreef Chris Wilson:
>>> Quoting Maarten Lankhorst (2018-06-28 12:06:35)
Op 28-06-18 om 12:51 schreef Chris Wilson:
> drm_atomic_helper allows for up to one outstanding cle
[ The bot has a bug where it doesn't copy the error messages so I just
guess what the issue is. - dan ]
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180627-174219
base: git:/
On 27/06/2018 16:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 16:21:24)
On 27/06/2018 14:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 14:15:22)
On 27/06/2018 11:58, Chris Wilson wrote:
That tasklets get kicked randomly, I think was the culprit.
What do you mea
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
v2: Use _MASKED_FIE
Quoting Tvrtko Ursulin (2018-06-28 12:29:41)
>
> On 27/06/2018 22:07, Chris Wilson wrote:
> > @@ -1881,6 +1861,7 @@ execlists_reset_prepare(struct intel_engine_cs
> > *engine)
> > {
> > struct intel_engine_execlists * const execlists = &engine->execlists;
> > struct i915_request *re
On Wed, 27 Jun 2018, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2018-06-27 16:51:42)
>> On Wed, 27 Jun 2018 16:41:13 +0200, Jani Nikula
>> wrote:
>>
>> > There's already some BIT() usage here and there, embrace it.
>> >
>> > Cc: Paulo Zanoni
>> > Signed-off-by: Jani Nikula
>> > ---
>> >
Quoting Tvrtko Ursulin (2018-06-28 12:56:56)
>
> On 27/06/2018 16:28, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-27 16:21:24)
> >>
> >> On 27/06/2018 14:29, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-06-27 14:15:22)
>
> On 27/06/2018 11:58, Chris Wilson wrote:
>
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts (rev4)
URL : https://patchwork.freedesktop.org/series/45531/
State : failure
== Summary ==
Applying: drm/i915: Drop posting reads to flush master interrupts
Applying: drm/i915/execl
Quoting Chris Wilson (2018-06-28 13:07:51)
> Quoting Tvrtko Ursulin (2018-06-28 12:56:56)
> > And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't
> > taking the timeline lock around active state reconstruction solve that
> > simpler?
>
> Can you? We probably can. (That one was
On 28/06/2018 12:59, Chris Wilson wrote:
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we tr
Quoting Tvrtko Ursulin (2018-06-28 13:15:07)
>
> On 28/06/2018 12:59, Chris Wilson wrote:
> > On HW reset, the HW clears the write pointer (to 0). But since it also
> > writes its first CSB entry to slot 0, we need to reset the write pointer
> > back to the element before (so the first entry we re
On 28/06/2018 13:11, Chris Wilson wrote:
Quoting Chris Wilson (2018-06-28 13:07:51)
Quoting Tvrtko Ursulin (2018-06-28 12:56:56)
And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't
taking the timeline lock around active state reconstruction solve that
simpler?
Can you? We p
In the next patch, we will process the CSB events directly from the
submission path, rather than only after a CS interrupt. Hence, we will
no longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
v2: Tvrtko pointed out it was
We do not need to do a posting read of our uncached mmio write to
re-enable the master interrupt lines after handling an interrupt, so
don't. This saves us a slow UC read before we can process the interrupt,
most noticeable in execlists where any stalls imposes extra latency on
GPU command executio
In the next patch, we will begin processing the CSB from inside the
submission path (underneath an irqsoff section, and even from inside
interrupt handlers). This means that updating the execlists->port[] will
no longer be serialised by the tasklet but needs to be locked by the
engine->timeline.loc
Now that we use the CSB stored in the CPU friendly HWSP, we do not need
to track interrupts for when the mmio CSB registers are valid and can
just check where we read up to last from the cached HWSP. This means we
can forgo the atomic bit tracking from interrupt, and in the next patch
it means we c
In the following patch, we will process the CSB events under the
timeline.lock and not serialised by the tasklet. This also means that we
will need to protect access to common variables such as
execlists->csb_head with the timeline.lock during reset.
v2: Move sync_irq to avoid deadlocks between ta
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
v2: Use _MASKED_FIE
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on av
As we now never read back our current head position from the CSB
pointers register, and the HW itself doesn't use it to prevent
overwriting unread CSB entries, we do not need to keep updating the
register. As it turns out this register is not listed as being shadowed,
and so requires forcewake -- b
Quoting Tvrtko Ursulin (2018-06-28 13:29:32)
>
> On 28/06/2018 13:11, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-06-28 13:07:51)
> >> Quoting Tvrtko Ursulin (2018-06-28 12:56:56)
> >>> And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't
> >>> taking the timeline lock arou
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts
URL : https://patchwork.freedesktop.org/series/45574/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c25ca2aa7052 drm/i915: Drop posting reads to flush master interru
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the
GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of
enabling the 511Bytes per RD/WR cycle on legacy platforms for no
absolute ROIs, this change allows the max bytes per op upto 511Bytes
from Gen9 onwards.
v2:
No Change.
v3:
Inline function for max_xfer_size and renaming of
On 28/06/2018 13:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 13:29:32)
On 28/06/2018 13:11, Chris Wilson wrote:
Quoting Chris Wilson (2018-06-28 13:07:51)
Quoting Tvrtko Ursulin (2018-06-28 12:56:56)
And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't
taking
On 28/06/2018 13:33, Chris Wilson wrote:
Now that we use the CSB stored in the CPU friendly HWSP, we do not need
to track interrupts for when the mmio CSB registers are valid and can
just check where we read up to last from the cached HWSP. This means we
can forgo the atomic bit tracking from in
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts
URL : https://patchwork.freedesktop.org/series/45574/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9466 =
== Summary - SUCCESS ==
No regres
On Thu, Jun 28, 2018 at 01:33:43PM +0100, Chris Wilson wrote:
> We do not need to do a posting read of our uncached mmio write to
> re-enable the master interrupt lines after handling an interrupt, so
> don't. This saves us a slow UC read before we can process the interrupt,
> most noticeable in ex
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per
Rd/Wr Op
URL : https://patchwork.freedesktop.org/series/45576/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3065ccd37dd8 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
968b33b77
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per
Rd/Wr Op
URL : https://patchwork.freedesktop.org/series/45576/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
-O:drivers/gpu/drm
Quoting Ville Syrjälä (2018-06-28 14:06:40)
> On Thu, Jun 28, 2018 at 01:33:43PM +0100, Chris Wilson wrote:
> > We do not need to do a posting read of our uncached mmio write to
> > re-enable the master interrupt lines after handling an interrupt, so
> > don't. This saves us a slow UC read before w
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on av
This is to exercise DDB algorithm corner case where
DDB allocation was not happening properly for varying size plane.
Current DDB algorithm uses datarate based DDB division among
planes, but planes with same width require same DDB allocation
irrespective of their height.
To address this a Multipl
From: Ville Syrjälä
With the fb-helper no longer relying on the non-atomic .best_encoder()
we can eliminate the hook from the MST encoder.
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
Reviewed-by: Daniel Vetter
Reviewed-by: Alex Deucher
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/in
From: Ville Syrjälä
Instead of using the .best_encoder() hook to figure out whether a given
connector+crtc combo will work, let's instead do what userspace does and
just iterate over all the encoders for the connector, and then check
each crtc against each encoder's possible_crtcs bitmask.
v2: A
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc: Da
From: Ville Syrjälä
Changes from the previous version mainly involve Danoie's suggestion
of hiding the drm_encoder_find() in the iterator macro. I also polished
the msm and tilcdc cases a bit more with another small helper.
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: Ben Skeggs
Cc:
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc: Da
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc: Da
From: Ville Syrjälä
Add a small helper for checking whether a connector and
encoder are associated with each other.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 23 +++
include/drm/drm_connector.h | 3 +++
2 files changed, 26 insertions(+)
diff -
From: Ville Syrjälä
Add a convenience macro for iterating connector->encoder_ids[].
Isolates the users from the implementation details.
Note that we don't seem to pass the file_priv down to drm_encoder_find()
because encoders apparently don't get leased. No idea why
drm_encoder_finc() even takes
From: Ville Syrjälä
Use drm_connector_has_possible_encoder() for checking
whether the encoder has an associated connector.
v2: Replace the drm_for_each_connector_encoder_ids() loop
with a simple drm_connector_has_possible_encoder() call
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: f
From: Ville Syrjälä
Use drm_connector_has_possible_encoder() for checking
whether the encoder has an associated connector.
v2: Replace the drm_for_each_connector_encoder_ids() loop
with a simple drm_connector_has_possible_encoder() call
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Signed-off-by: Vil
On 28/06/2018 14:11, Chris Wilson wrote:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s
At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.
v2: We cannot allocate inside the printer (as it may be on an fs-reclaim
path), so hope
Op 28-06-18 om 15:03 schreef Karthik B S:
> This is to exercise DDB algorithm corner case where
> DDB allocation was not happening properly for varying size plane.
>
> Current DDB algorithm uses datarate based DDB division among
> planes, but planes with same width require same DDB allocation
> irr
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per
Rd/Wr Op
URL : https://patchwork.freedesktop.org/series/45576/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9467 =
== Summary - SUCCESS ==
No regressions
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts (rev2)
URL : https://patchwork.freedesktop.org/series/45574/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
Quoting Tvrtko Ursulin (2018-06-28 14:21:06)
>
> On 28/06/2018 14:11, Chris Wilson wrote:
> > +/*
> > + * Check the unread Context Status Buffers and manage the submission of new
> > + * contexts to the ELSP accordingly.
> > + */
> > +static void execlists_submission_tasklet(unsigned long data)
>
1 - 100 of 197 matches
Mail list logo
