== Series Details ==
Series: drm/i915: Implement PSF GV point support (rev3)
URL : https://patchwork.freedesktop.org/series/90361/
State : failure
== Summary ==
Applying: drm/i915: Implement PSF GV point support
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_reg.h).
e
On Thu, May 20, 2021 at 4:28 PM Daniel Vetter wrote:
>
> On Thu, May 20, 2021 at 08:35:14AM +0100, Matthew Auld wrote:
> > From: Chris Wilson
> >
> > The first tracepoint for a request is trace_dma_fence_init called before
> > we have associated the request with a device. The tracepoint uses
> >
On Thu, May 27, 2021 at 4:19 PM Matthew Brost wrote:
>
> On Thu, May 27, 2021 at 10:41:10AM +0100, Tvrtko Ursulin wrote:
> >
> > On 26/05/2021 21:03, Matthew Brost wrote:
> > > Introduce i915_sched_engine object which is lower level data structure
> > > that i915_scheduler / generic code can opera
On Thu, May 27, 2021 at 11:26:37AM -0500, Jason Ekstrand wrote:
> The current context uAPI allows for two methods of setting context
> parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
> former is allowed to be called at any time while the later happens as
> part of GEM_CONTEXT_CR
On Thu, May 27, 2021 at 11:26:39AM -0500, Jason Ekstrand wrote:
> For now this is a no-op because everyone passes in a null SSEU but it
> lets us get some of the error handling and selftest refactoring plumbed
> through.
>
> Signed-off-by: Jason Ekstrand
I've reviewed this one already in the pre
== Series Details ==
Series: series starting with [1/2] drm/i915: Extend QGV point restrict mask to
0x3
URL : https://patchwork.freedesktop.org/series/90776/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a12e5c83304a drm/i915: Extend QGV point restrict mask to 0x3
603bd832dcc5
On Thu, May 27, 2021 at 11:26:42AM -0500, Jason Ekstrand wrote:
> This means that the proto-context needs to grow support for engine
> configuration information as well as setparam logic. Fortunately, we'll
> be deleting a lot of setparam logic on the primary context shortly so it
> will hopefully
== Series Details ==
Series: series starting with [1/2] drm/i915: Extend QGV point restrict mask to
0x3
URL : https://patchwork.freedesktop.org/series/90776/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10151 -> Patchwork_20236
===
On Thu, May 27, 2021 at 11:26:45AM -0500, Jason Ekstrand wrote:
> The current context uAPI allows for two methods of setting context
> parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
> former is allowed to be called at any time while the later happens as
> part of GEM_CONTEXT_CR
On Fri, 28 May 2021, "Leizhen (ThunderTown)" wrote:
> On 2021/5/27 18:04, Jani Nikula wrote:
>> On Thu, 27 May 2021, Zhen Lei wrote:
>>> If intel_hdcp_validate_v_prime() has been successful within the allowed
>>> number of tries, we can directly call drm_dbg_kms() and "goto out" without
>>> jumpi
Adding Y_TILED modifier which is needed to support DRM_FORMAT_NV12
during framebuffer initialization.
Signed-off-by: Sodhi, Vunny
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
This is an initial patch series to move discrete memory management over to
TTM. It will be followed up shortly with adding more functionality.
The buddy allocator is temporarily removed along with its selftests and
It is replaced with the TTM range manager and some selftests are adjusted
to accoun
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 29 +
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add
All users of this function actually want the dma segment sizes, but that's
not what's calculated. Fix that and rename the function to
i915_sg_dma_sizes to reflect what's calculated.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other ba
Use fast wc memcpy for reading out of wc memory for TTM bo moves.
Cc: Dave Airlie
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König #v4
--
v4:
- Clarify when we try drm_memcpy_from_wc_dbm (Reported by Matthew Auld)
- Be paranoid about when drm_
Temporarily remove the buddy allocator and related selftests
and hook up the TTM range manager for i915 regions.
Also modify the mock region selftests somewhat to account for a
fragmenting manager.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld #v2
---
v2:
- Fix an error unwind in lm
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-buf-map pointer
arguments that attempts to use a fast prefetching memcpy and
otherwise falls b
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call al
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.
Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the c
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYSTEM
(which in this case means evicted LMEM objects
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-b
From: Maarten Lankhorst
The platform should exclusively use mmap_offset, one less path to worry
about for discrete.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gp
Since objects can be migrated or evicted when not pinned or locked,
update the checks for lmem residency or future residency so that
the value returned is not immediately stale.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2: Simplify i915_gem_object_migratable() (Reported by M
From: Maarten Lankhorst
Use the ttm handlers for servicing page faults, and vm_access.
We do our own validation of read-only access, otherwise use the
ttm handlers as much as possible.
Because the ttm handlers expect the vma_node at vma->base, we slightly
need to massage the mmap handlers to lo
From: Maarten Lankhorst
This allows drivers to distinguish between different types of vma_node's.
The readonly flag was unused and is thus removed.
This is a temporary solution, until i915 is converted completely to
use ttm for bo's.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellstr
== Series Details ==
Series: drm/i915/display: Add support of MOD_Y_TILED during fb init
URL : https://patchwork.freedesktop.org/series/90785/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10152 -> Patchwork_20237
Summary
-
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev3)
URL : https://patchwork.freedesktop.org/series/90681/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
784db4b4d61c drm/i915: Untangle the vma pages_mutex
57182bbc1668 drm/i915: Don't free shared locks whi
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev3)
URL : https://patchwork.freedesktop.org/series/90681/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./drivers/gpu/drm/
Am 31.05.21 um 14:19 schrieb Thomas Hellström:
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fa
Am 31.05.21 um 14:19 schrieb Thomas Hellström:
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-buf-map pointer
arguments that attempts to
== Series Details ==
Series: series starting with [1/2] drm/i915: Extend QGV point restrict mask to
0x3
URL : https://patchwork.freedesktop.org/series/90776/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10151_full -> Patchwork_20236_full
=
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev3)
URL : https://patchwork.freedesktop.org/series/90681/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10152 -> Patchwork_20238
Summary
---
**S
On 5/31/21 2:36 PM, Christian König wrote:
Am 31.05.21 um 14:19 schrieb Thomas Hellström:
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
On Thu, May 27, 2021 at 11:26:47AM -0500, Jason Ekstrand wrote:
> When the APIs were added to manage the engine set on a GEM context
> directly from userspace, the questionable choice was made to allow
> changing the engine set on a context at any time. This is horribly racy
> and there's absolute
On Mon, May 31, 2021 at 07:32:17PM +0800, Sodhi, Vunny wrote:
> Adding Y_TILED modifier which is needed to support DRM_FORMAT_NV12
> during framebuffer initialization.
>
> Signed-off-by: Sodhi, Vunny
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> 1 file changed, 3 insertions(+)
On Thu, May 27, 2021 at 11:26:46AM -0500, Jason Ekstrand wrote:
> When the APIs were added to manage VMs more directly from userspace, the
> questionable choice was made to allow changing out the VM on a context
> at any time. This is horribly racy and there's absolutely no reason why
> any usersp
We need to make the BSW workaround actually work. We correctly fixed
the mutex nesting, but forgot to kill the worker.
The worker is killed by clearing async_flags, and just running bind_vma
synchronously. This still needs the stash, because we cannot allocate
and pin with vm->mutex already held.
On Fri, May 28, 2021 at 02:15:46PM -0400, Adam Chasen wrote:
> Any further advice on tracing what is triggering what appears to be the
> limitation of the clock? My guess is it is imposing a DVI Single-Link speed
> (165000) limitation on the dual-link DVI adapter.
>
> > TMDS clock 25000-165000
>
On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> For Intel platforms, pitch needs to be 64 byte aligned.
> Kernel code vgem_gem_dumb_create which is platform generic code
> doesnt do the alignment. This causes frame buffer creation to fail
> on Intel platforms where the pitch is no
On Thu, May 27, 2021 at 11:26:50AM -0500, Jason Ekstrand wrote:
> Now that we have the whole engine set and VM at context creation time,
> we can just assign those fields instead of creating first and handling
> the VM and engines later. This lets us avoid creating useless VMs and
> engine sets an
Hello Ville,
Thank you very much.
Before reaching our i915's i915_gem_dumb_create, it goes to
vgem_gem_dumb_create for kms_prime.
The pitch gets calculated there and it is not 64 byte aligned. Due to this,
intel_framebuffer_init reports "pitch must be 64 byte aligned"
and framebuffer creation f
> -Original Message-
> From: Intel-gfx On Behalf Of
> Stanislav
> Lisovskiy
> Sent: Thursday, May 27, 2021 4:31 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/adl_p: Same slices mask is not same Dbuf
> state
>
> We currently treat same slice mask as a
On Fri, May 28, 2021 at 12:32 AM Tom Lendacky wrote:
>
> On 5/27/21 9:41 AM, Tom Lendacky wrote:
> > On 5/27/21 8:02 AM, Christoph Hellwig wrote:
> >> On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote:
> >>> You convert this call site with swiotlb_init_io_tlb_mem() which did not
> >
== Series Details ==
Series: drm/i915: Only set bind_async_flags when concurrent access wa is not
active, v2.
URL : https://patchwork.freedesktop.org/series/90795/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
498a33865b2e drm/i915: Only set bind_async_flags when concurrent ac
Got SIGSEGV fault while running kms_dp_dsc test but did not
connect DP DSC capable monitor on eDP/DP port. This test daemon
should "SKIP" test without any problem. We found kms_dp_dsc
can't get proper drmModeConnector and caused this SIGSEGV fault
when release it. Make sure drmModeConnector is avai
== Series Details ==
Series: drm/i915: Only set bind_async_flags when concurrent access wa is not
active, v2.
URL : https://patchwork.freedesktop.org/series/90795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10152 -> Patchwork_20239
=
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev3)
URL : https://patchwork.freedesktop.org/series/90681/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10152_full -> Patchwork_20238_full
Summary
On Wed, May 19, 2021 at 07:48:21PM +0530, Tejas Upadhyay wrote:
> When pipe A is disabled and MIPI DSI is enabled on pipe B,
> the AMT KVMR feature will incorrectly see pipe A as enabled.
> Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave
> it set while DSI is enabled on pipe B. No impa
This is an initial patch series to move discrete memory management over to
TTM. It will be followed up shortly with adding more functionality.
The buddy allocator is temporarily removed along with its selftests and
It is replaced with the TTM range manager and some selftests are adjusted
to accoun
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 29 +
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add
All users of this function actually want the dma segment sizes, but that's
not what's calculated. Fix that and rename the function to
i915_sg_dma_sizes to reflect what's calculated.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
Temporarily remove the buddy allocator and related selftests
and hook up the TTM range manager for i915 regions.
Also modify the mock region selftests somewhat to account for a
fragmenting manager.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld #v2
---
v2:
- Fix an error unwind in lm
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other ba
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-b
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-buf-map pointer
arguments that attempts to use a fast prefetching memcpy and
otherwise falls b
Use fast wc memcpy for reading out of wc memory for TTM bo moves.
Cc: Dave Airlie
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König #v4
--
v4:
- Clarify when we try drm_memcpy_from_wc_dbm (Reported by Matthew Auld)
- Be paranoid about when drm_
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.
Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the c
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call al
Since objects can be migrated or evicted when not pinned or locked,
update the checks for lmem residency or future residency so that
the value returned is not immediately stale.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2: Simplify i915_gem_object_migratable() (Reported by M
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYSTEM
(which in this case means evicted LMEM objects
From: Maarten Lankhorst
The platform should exclusively use mmap_offset, one less path to worry
about for discrete.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gp
From: Maarten Lankhorst
This allows drivers to distinguish between different types of vma_node's.
The readonly flag was unused and is thus removed.
This is a temporary solution, until i915 is converted completely to
use ttm for bo's.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellstr
From: Maarten Lankhorst
Use the ttm handlers for servicing page faults, and vm_access.
We do our own validation of read-only access, otherwise use the
ttm handlers as much as possible.
Because the ttm handlers expect the vma_node at vma->base, we slightly
need to massage the mmap handlers to lo
Am 12.05.21 um 19:59 schrieb Alex Deucher:
> On Wed, May 12, 2021 at 9:04 AM Ville Syrjälä
> wrote:
>> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
>>> Hello,
>>>
>>> In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm
>>> properties I propose 4 new proper
Am 19.05.21 um 15:49 schrieb Ville Syrjälä:
> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
>> On Wed, 12 May 2021 16:04:16 +0300
>> Ville Syrjälä wrote:
>>
>>> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
Hello,
In addition to the existing "max
Ville,
Thanks for the additional detail!
I looked up HPD and understand it is hot plug detection, but I didn't find much
for "one byte caps format". I assume this is short hand for "capability format".
Is the "one byte" format a limitation from the monitor, the dongle, the
motherboard, or the c
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev4)
URL : https://patchwork.freedesktop.org/series/90681/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6de8c27efb29 drm/i915: Untangle the vma pages_mutex
8736b0670431 drm/i915: Don't free shared locks whi
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev4)
URL : https://patchwork.freedesktop.org/series/90681/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./drivers/gpu/drm/
== Series Details ==
Series: drm/i915: Only set bind_async_flags when concurrent access wa is not
active, v2.
URL : https://patchwork.freedesktop.org/series/90795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10152_full -> Patchwork_20239_full
===
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev4)
URL : https://patchwork.freedesktop.org/series/90681/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10153 -> Patchwork_20240
Summary
---
**S
This patch series is for making the GPD Win Max display usable with
Linux.
The GPD Win Max is a small laptop, and its eDP panel does not send an
EDID over DPCD; the EDID is instead available in the intel opregion, in
mailbox #5 [1]
The first patch is based on Jani's patch series [2] adding suppor
Panel is 800x1280, but mounted on a laptop form factor, sideways.
Reviewed-by: Hans de Goede
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/dr
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.
If a panel's EDID is broken, there may be an override EDID set in
== Series Details ==
Series: GPD Win Max display fixes (rev2)
URL : https://patchwork.freedesktop.org/series/90483/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8d4543be1dff drm/i915/opregion: add support for mailbox #5 EDID
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapp
== Series Details ==
Series: GPD Win Max display fixes (rev2)
URL : https://patchwork.freedesktop.org/series/90483/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/i
== Series Details ==
Series: GPD Win Max display fixes (rev2)
URL : https://patchwork.freedesktop.org/series/90483/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10153 -> Patchwork_20241
Summary
---
**SUCCESS**
No
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev4)
URL : https://patchwork.freedesktop.org/series/90681/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10153_full -> Patchwork_20240_full
Summary
== Series Details ==
Series: GPD Win Max display fixes (rev2)
URL : https://patchwork.freedesktop.org/series/90483/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10153_full -> Patchwork_20241_full
Summary
---
**FAILU
Hi all,
After merging the i2c tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from drivers/gpu/drm/i915/i915_gem.c:1250:
drivers/gpu/drm/i915/selftests/i915_gem.c:97:13: error: conflicting types for
'pm_suspend'
97 | static void pm_suspend(struct drm_i9
== Series Details ==
Series: linux-next: build failure after merge of the i2c tree
URL : https://patchwork.freedesktop.org/series/90804/
State : failure
== Summary ==
Applying: linux-next: build failure after merge of the i2c tree
Using index info to reconstruct a base tree...
M drivers/
1. Pass one more parameter (current drmModeConnector) when
call "run_test()". Use it to retrieve proper connector_type.
2. SIGSEGV fault would happen due to "igt_output" did not
store properly in "data->output". Main funciton already
pass "igt_output" pointer into "run_test()" function.
84 matches
Mail list logo
