On Mon, 16 Aug 2021, Jackie Liu wrote:
> From: Jackie Liu
>
> When CONFIG_DRM_FBDEV_EMULATION is compiled to y and CONFIG_FB is m, the
> compilation will fail. we need make that dependency explicit.
What's the failure mode? Using select here is a bad idea.
BR,
Jani.
>
> Reported-by: k2ci
> Si
Hi,
On Fri, Mar 26, 2021 at 06:00:51PM -0400, Lyude Paul wrote:
> This patch series is:
>
> Reviewed-by: Lyude Paul
>
> Btw - in the future if you need to send a respin of multiple patches, you need
> to send it as it's own separate series instead of replying to the previous one
> (one-off resp
Hi Jani.
My CI report an randconfigs build failed. there are:
drm_fb_helper.c:(.text+0x302): undefined reference to `fb_set_suspend'
drm_fb_helper.c:(.text+0xaea): undefined reference to `register_framebuffer'
drm_fb_helper.c:(.text+0x1dcc): undefined reference to `framebuffer_alloc'
ld: drm_fb_
Am 15.08.21 um 21:29 schrieb Nathan Chancellor:
Clang + -Wimplicit-fallthrough warns:
drivers/gpu/drm/radeon/radeon_fb.c:170:2: warning: unannotated
fall-through between switch labels [-Wimplicit-fallthrough]
default:
^
drivers/gpu/drm/radeon/radeon_fb.c:170:2: note: insert 'br
Am 12.08.21 um 10:11 schrieb Michel Dänzer:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
Hi James,
Evan seems to have understood how this all works together.
See while any begin/end use critical section is active the work should not be
active.
When you handle only one ring you can just
Am 13.08.21 um 12:29 schrieb Michel Dänzer:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and re-ena
Am 10.08.21 um 21:59 schrieb Dan Moulding:
In 69de4421bb4c ("drm/ttm: Initialize debugfs from
ttm_global_init()"), ttm_global_init was changed so that if creation
of the debugfs global root directory fails, ttm_global_init will bail
out early and return an error, leading to initialization failure
After commit f611b1e7624c, we change select FB
to depends on FB.
How about this：
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7ff89690a976..cd129d96e649 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -98,7 +98,7 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_R
On Mon, 16 Aug 2021, Jackie Liu wrote:
> Hi Jani.
>
> My CI report an randconfigs build failed. there are:
>
> drm_fb_helper.c:(.text+0x302): undefined reference to `fb_set_suspend'
> drm_fb_helper.c:(.text+0xaea): undefined reference to `register_framebuffer'
> drm_fb_helper.c:(.text+0x1dcc): und
On Mon, 16 Aug 2021, Jackie Liu wrote:
> After commit f611b1e7624c, we change select FB
> to depends on FB.
And obviously you should cite the commit in the original patch and Cc
the author!
BR,
Jani.
>
> How about this：
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index
Hi, Jani.
Thanks, send V2 version immediately, and cc author.
--
Jackie Liu
在 2021/8/16 下午4:35, Jani Nikula 写道:
On Mon, 16 Aug 2021, Jackie Liu wrote:
After commit f611b1e7624c, we change select FB
to depends on FB.
And obviously you should cite the commit in the original patch and Cc
the
Hi Jani.
Your suggestion is that?
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7ff89690a976..ba179a539497 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -77,6 +77,7 @@ config DRM_DEBUG_SELFTEST
config DRM_KMS_HELPER
tristate
depends
It's only used by the for_i915_gem_ww() macro and we can use
the (typically) on-stack _err variable in its place.
While initially setting the _err variable to -EDEADLK to enter the
loop, we clear it before actually entering using fetch_and_zero() to
avoid empty loops or code not setting the _err v
From: Jackie Liu
When CONFIG_DRM_FBDEV_EMULATION is compiled to y and CONFIG_FB is m, the
compilation will fail. we need make that dependency explicit.
Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Reported-by: k2ci
Signed-off-by: Jackie Liu
---
drivers/gpu/drm/Kconfi
On 16/8/21 2:47 am, kernel test robot wrote:
Hi Desmond,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210813]
[also build test ERROR on v5.14-rc5]
[cannot apply to linus/master v5.14-rc5 v5.14-rc4 v5.14-rc3]
[If your patch is applied to the wrong git tree,
On Mon, 16 Aug 2021, Jackie Liu wrote:
> Hi Jani.
>
> Your suggestion is that?
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 7ff89690a976..ba179a539497 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -77,6 +77,7 @@ config DRM_DEBUG_SELFTEST
On Mon, 16 Aug 2021, Jani Nikula wrote:
> On Mon, 16 Aug 2021, Jackie Liu wrote:
>> Hi Jani.
>>
>> Your suggestion is that?
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 7ff89690a976..ba179a539497 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kco
On Mon, 16 Aug 2021, Jackie Liu wrote:
> From: Jackie Liu
>
> When CONFIG_DRM_FBDEV_EMULATION is compiled to y and CONFIG_FB is m, the
> compilation will fail. we need make that dependency explicit.
>
> Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
> Reported-by: k2ci
>
在 2021/8/16 下午4:58, Jani Nikula 写道:
On Mon, 16 Aug 2021, Jackie Liu wrote:
From: Jackie Liu
When CONFIG_DRM_FBDEV_EMULATION is compiled to y and CONFIG_FB is m, the
compilation will fail. we need make that dependency explicit.
Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CON
On Mon, Aug 16, 2021 at 10:53 AM Desmond Cheong Zhi Xi
wrote:
> On 16/8/21 2:47 am, kernel test robot wrote:
> > Hi Desmond,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on next-20210813]
> > [also build test ERROR on v5.14-rc5]
> > [cannot apply to lin
Duncan posted on Mon, 16 Aug 2021 07:58:37 + as excerpted:
> Mikael Pettersson posted on Tue, 03 Aug 2021 08:54:18 +0200 as
> excerpted:
>> On Mon, Aug 2, 2021 at 8:29 PM Duncan wrote:
>>> Mikael Pettersson wrote...
>>> > Booting 5.14.0-rc4 on my box with Radeon graphics breaks with
>>> >
>>
Hi Christoph,
Le sam., août 14 2021 at 09:30:19 +0200, Christoph Hellwig
a écrit :
On Fri, Aug 13, 2021 at 01:41:26PM +0200, Paul Cercueil wrote:
Hi,
A few months ago we (ADI) tried to upstream the interface we use
with our
high-speed ADCs and DACs. It is a system with custom ioctls on t
在 2021/8/16 下午4:56, Jani Nikula 写道:
On Mon, 16 Aug 2021, Jani Nikula wrote:
On Mon, 16 Aug 2021, Jackie Liu wrote:
Hi Jani.
Your suggestion is that?
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7ff89690a976..ba179a539497 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/
Am 07.08.21 um 20:37 schrieb Rob Clark:
From: Rob Clark
As the finished fence is the one that is exposed to userspace, and
therefore the one that other operations, like atomic update, would
block on, we need to propagate the deadline from from the finished
fence to the actual hw fence.
Signed-
Am 07.08.21 um 20:37 schrieb Rob Clark:
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is to aid
the fence signaler in making power management decisions, like boosting
frequency as the deadl
The general approach seems to make sense now I think.
One minor thing which I'm missing is adding support for this to the
dma_fence_array and dma_fence_chain containers.
Regards,
Christian.
Am 07.08.21 um 20:37 schrieb Rob Clark:
From: Rob Clark
Based on discussion from a previous series[1
[AMD Official Use Only]
Hi Michel,
The patch seems reasonable to me(especially the cancel_delayed_work_sync()
part).
However, can you explain more about the code below?
What's the race issue here exactly?
+ /* mutex_lock could deadlock with cancel_delayed_work_sync in
amdgpu_gfx_off_ctrl
On 16/8/21 5:04 pm, Daniel Vetter wrote:
On Mon, Aug 16, 2021 at 10:53 AM Desmond Cheong Zhi Xi
wrote:
On 16/8/21 2:47 am, kernel test robot wrote:
Hi Desmond,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210813]
[also build test ERROR on v5.14-rc5]
[ca
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and re-enabled again during those 100 ms.
This resulted
On Thu, Jun 10, 2021 at 01:12:34PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> When working with framebuffer modifiers, it can be useful to extract the
> vendor identifier or check a modifier against a given vendor identifier.
> Add one macro that extracts the vendor identifier and a
On 2021-08-16 9:38 a.m., Christian König wrote:
> Am 13.08.21 um 12:29 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> schedule_delayed_work does not push back the work if it was already
>> scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
>> after the first time GFXOFF was d
On 2021-08-16 12:20 p.m., Quan, Evan wrote:
> [AMD Official Use Only]
>
> Hi Michel,
>
> The patch seems reasonable to me(especially the cancel_delayed_work_sync()
> part).
> However, can you explain more about the code below?
> What's the race issue here exactly?
>
> + /* mutex_lock could
On 2021-08-16 6:13 a.m., Lazar, Lijo wrote:
> On 8/13/2021 9:30 PM, Michel Dänzer wrote:
>> On 2021-08-13 5:07 p.m., Lazar, Lijo wrote:
>>> On 8/13/2021 8:10 PM, Michel Dänzer wrote:
On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
> On 8/13/2021 7:04 PM, Michel Dänzer wrote:
>> On 2021-08-
On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
> Hello Brian,
> (+Uma in cc)
>
> Thanks for your comments, Let me try to fill-in for Harry to keep the design
> discussion going. Please find my comments inline.
>
> On 8/2/2021 10:00 PM, Brian Starkey wrote:
> >
-- snip --
> >
The return value of sp_tx_rst_aux() is stored, but never read.
This happens in the context EDID communication already failing,
which means that this additional failure doesn't necessarily
convey any additional inforamation.
This means that we can safely avoid storing the value.
Fixes: 8bdfc5dae4e
On 8/16/2021 4:05 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and re-e
Am 16.08.21 um 13:33 schrieb Lazar, Lijo:
On 8/16/2021 4:05 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabl
Am 16.08.21 um 08:20 schrieb Huang Rui:
On Sat, Aug 14, 2021 at 12:50:14AM +0800, Dan Moulding wrote:
Just a friendly reminder that this fix for a regression needs
review. It should be a quick review.
It would probably be good to ensure this gets in before the final 5.14
release, otherwise t
The 'obj' is tested by IS_ERR(), we should pass it to PTR_ERR().
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/
On 2021-08-16 7:10 a.m., Brian Starkey wrote:
> On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
>> Hello Brian,
>> (+Uma in cc)
>>
>> Thanks for your comments, Let me try to fill-in for Harry to keep the design
>> discussion going. Please find my comments inline.
>>
Thanks, Sh
Reviewed and pushed to drm-misc-next-fixes.
Thanks,
Christian.
Am 12.08.21 um 22:34 schrieb Jason Ekstrand:
These names were changed in
commit 8af8a109b34fa88b8b91f25d11485b37d37549c3
Author: Christian König
Date: Thu Oct 1 14:51:40 2020 +0200
drm/ttm: device naming cleanup
But he mi
On Fri, Aug 13, 2021 at 09:54:41AM +0900, David Stevens wrote:
> Implement virtgpu specific map_dma_buf callback to support mapping
> exported vram object dma-bufs. The dma-buf callback is used directly, as
> vram objects don't have backing pages and thus can't implement the
> drm_gem_object_funcs.
Am 13.08.21 um 17:03 schrieb Michel Dänzer:
On 2021-08-13 10:54 a.m., zhaoxiao wrote:
This patch fixes the following sparse errors:
drivers/gpu/drm/radeon/r600_dma.c:247:30: warning: incorrect type in assignment
(different base types)
drivers/gpu/drm/radeon/r600_dma.c:247:30:expected uns
This fixes an accidental partial revert of commit 94dfec48fca7
("drm/imx: Add 8 pixel alignment fix") during a rebase of
commit fc1e985b67f9 ("drm/imx: ipuv3-plane: add color encoding and range
properties").
Fixes: fc1e985b67f9 ("drm/imx: ipuv3-plane: add color encoding and range
properties")
Sig
On Mon, 16 Aug 2021 at 09:49, Thomas Hellström
wrote:
>
> It's only used by the for_i915_gem_ww() macro and we can use
> the (typically) on-stack _err variable in its place.
>
> While initially setting the _err variable to -EDEADLK to enter the
> loop, we clear it before actually entering using fe
On 8/16/21 3:25 PM, Matthew Auld wrote:
On Mon, 16 Aug 2021 at 09:49, Thomas Hellström
wrote:
It's only used by the for_i915_gem_ww() macro and we can use
the (typically) on-stack _err variable in its place.
While initially setting the _err variable to -EDEADLK to enter the
loop, we clear it
Op 16-08-2021 om 15:30 schreef Thomas Hellström:
>
> On 8/16/21 3:25 PM, Matthew Auld wrote:
>> On Mon, 16 Aug 2021 at 09:49, Thomas Hellström
>> wrote:
>>> It's only used by the for_i915_gem_ww() macro and we can use
>>> the (typically) on-stack _err variable in its place.
>>>
>>> While initially
On 2021-08-16 14:40, Harry Wentland wrote:
On 2021-08-16 7:10 a.m., Brian Starkey wrote:
On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
Hello Brian,
(+Uma in cc)
Thanks for your comments, Let me try to fill-in for Harry to keep the
design
discussion going. Please find my c
On 8/16/21 3:34 PM, Maarten Lankhorst wrote:
Op 16-08-2021 om 15:30 schreef Thomas Hellström:
On 8/16/21 3:25 PM, Matthew Auld wrote:
On Mon, 16 Aug 2021 at 09:49, Thomas Hellström
wrote:
It's only used by the for_i915_gem_ww() macro and we can use
the (typically) on-stack _err variable in
Prior to this patch the blocked context counter was cleared on
init_sched_state (used during registering a context & resets) which is
incorrect. This state needs to be persistent or the counter can read the
incorrect value resulting in scheduling never getting enabled again.
Fixes: 62eaf0ae217d ("
Daniel Vetter pointed out that locking in the GuC submission code was
overly complicated, let's clean this up a bit before introducing more
features in the GuC submission backend.
Also fix some CI failures, port fixes from our internal tree, and add a
few more selftests for coverage.
Lastly, add
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the context state had already been updated
to anticipate a
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc: R
A context can get destroyed after cancelling a request so take a
reference to context when cancelling a request.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 -
1 file changed, 4 inse
Progagating errors to dependent fences is wrong, don't do it. Selftest
in following patch exposes this bug.
Fixes: 8e9f84cf5cac ("drm/i915/gt: Propagate change in error status to children
on unhold")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4
GuC submission has exposed an existing memory corruption in
live_lrc_isolation. We believe that some writes to the watchdog offsets
in the LRC (0x178 & 0x17c) can result in trashing of portions of the
address space. With GuC submission there are additional objects which
can move the context redzone
Before we did some clever tricks to not use the a lock when touching
guc_state.sched_state in certain cases. Don't do that, enforce the use
of the lock.
Part of this is removing a dead code path from guc_lrc_desc_pin where a
context could be deregistered when the aforementioned function was
called
A subsequent patch will flip the locking hierarchy from
ce->guc_state.lock -> sched_engine->lock to sched_engine->lock ->
ce->guc_state.lock. As such we need to release the submit fence for a
request from an IRQ to break a lock inversion - i.e. the fence must be
release went holding ce->guc_state.l
When unblocking a context, do not enable scheduling if the context is
banned, guc_id invalid, or not registered.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 +++
1 file changed, 3 i
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completely successfully.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/selftests/i915_request.c | 100 ++
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple selftest
injects errors
Drop pin count check trick between a sched_disable and re-pin, now rely
on the lock and counter of the number of committed requests to determine
if scheduling should be disabled on the context.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +
.../gpu/drm/i91
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 42 +---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 19 ++
Move guc_blocked fence to struct guc_state as the lock which protects
the fence lives there.
s/ce->guc_blocked/ce->guc_state.blocked_fence/g
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c| 5 +++--
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++---
...
If the context is reset as a result of the request cancelation the
context reset G2H is received after schedule disable done G2H which is
likely the wrong order. The schedule disable done G2H release the
waiting request cancelation code which resubmits the context. This races
with the context reset
Lock the xarray and take ref to the context if needed.
v2:
(Checkpatch)
- Add new line after declaration
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 84 ---
1 file changed, 73 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i9
Move GuC management fields in context under guc_active struct as this is
where the lock that protects theses fields lives. Also only set guc_prio
field once during context init.
Fixes: ee242ca704d3 ("drm/i915/guc: Implement GuC priority management")
Signed-off-by: Matthew Brost
Cc:
---
drivers/
Rework and simplify the locking with GuC subission. Drop
sched_state_no_lock and move all fields under the guc_state.sched_state
and protect all these fields with guc_state.lock . This requires
changing the locking hierarchy from guc_state.lock -> sched_engine.lock
to sched_engine.lock -> guc_state
It isn't safe to scrub for missing G2H or continue with the reset until
all G2H processing is complete. Flush the G2H work queue during reset to
ensure it is done running.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
---
.../gpu/dr
Reset LRC descriptor if a context register returns -ENODEV as this means
we are mid-reset.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 --
1 file changed, 4 insertions(
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Sig
Error captures can now be done in a work queue processing G2H messages.
These messages need to be completely done being processed in the reset
path, to avoid races in the missing G2H cleanup, which create a
dependency on memory allocations and dma fences (i915_requests).
Requests depend on resets,
On Mon, Aug 16, 2021 at 12:31 PM Desmond Cheong Zhi Xi
wrote:
>
> On 16/8/21 5:04 pm, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 10:53 AM Desmond Cheong Zhi Xi
> > wrote:
> >> On 16/8/21 2:47 am, kernel test robot wrote:
> >>> Hi Desmond,
> >>>
> >>> Thank you for the patch! Yet something t
Makes sense
Reviewed-by: Jason Ekstrand
On Mon, Aug 16, 2021 at 2:40 AM Christian König
wrote:
>
> Am 10.08.21 um 21:59 schrieb Dan Moulding:
> > In 69de4421bb4c ("drm/ttm: Initialize debugfs from
> > ttm_global_init()"), ttm_global_init was changed so that if creation
> > of the debugfs global
On Sat, Aug 14, 2021 at 09:30:19AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 13, 2021 at 01:41:26PM +0200, Paul Cercueil wrote:
> > Hi,
> >
> > A few months ago we (ADI) tried to upstream the interface we use with our
> > high-speed ADCs and DACs. It is a system with custom ioctls on the iio
On 2021-08-16 2:06 p.m., Christian König wrote:
> Am 16.08.21 um 13:33 schrieb Lazar, Lijo:
>> On 8/16/2021 4:05 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> schedule_delayed_work does not push back the work if it was already
>>> scheduled before, so amdgpu_device_delay_enable_gfx_off
On Fri, Aug 13, 2021 at 08:18:02AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/2021 7:37 AM, Daniel Vetter wrote:
> > On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> > > This api allow user mode to create protected buffers and to mark
> > > contexts as making use
On Fri, Aug 13, 2021 at 08:24:44AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/2021 7:42 AM, Daniel Vetter wrote:
> > On Fri, Aug 13, 2021 at 04:37:53PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> > > > This api allow user mod
On Sat, Aug 07, 2021 at 11:37:57AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For an atomic commit updating a single CRTC (ie. a pageflip) calculate
> the next vblank time, and inform the fence(s) of that deadline.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 3
On Mon, Aug 16, 2021 at 12:14:35PM +0200, Christian König wrote:
> Am 07.08.21 um 20:37 schrieb Rob Clark:
> > From: Rob Clark
> >
> > As the finished fence is the one that is exposed to userspace, and
> > therefore the one that other operations, like atomic update, would
> > block on, we need to
On Fri, Aug 13, 2021 at 07:02:55PM +, Matthew Brost wrote:
> On Fri, Aug 13, 2021 at 05:11:59PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 12, 2021 at 10:38:18PM +, Matthew Brost wrote:
> > > On Thu, Aug 12, 2021 at 09:47:23PM +0200, Daniel Vetter wrote:
> > > > On Thu, Aug 12, 2021 at 03:
Hi Robert,
On Mon, Aug 16, 2021 at 01:14:51PM +0200, Robert Foss wrote:
> The return value of sp_tx_rst_aux() is stored, but never read.
> This happens in the context EDID communication already failing,
> which means that this additional failure doesn't necessarily
> convey any additional inforama
On 8/16/2021 8:15 AM, Daniel Vetter wrote:
On Fri, Aug 13, 2021 at 08:18:02AM -0700, Daniele Ceraolo Spurio wrote:
On 8/13/2021 7:37 AM, Daniel Vetter wrote:
On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
This api allow user mode to create protected buffers and to
On Wed, Aug 04, 2021 at 11:24:02PM +0800, Kai-Heng Feng wrote:
> Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
> fast+narrow link on eDP again and fall back to the old max strategy on
> failure"), the screen starts to have wobbly effect.
>
> Commit a5c936add6a2 ("drm/i915/dp
It's only used by the for_i915_gem_ww() macro and we can use
the (typically) on-stack _err variable in its place.
v2:
- Don't clear the _err variable when entering the loop
(Matthew Auld, Maarten Lankhorst).
- Use parentheses around the _err macro argument.
- Fix up comment.
Cc: Matthew Auld
S
On Thu, Aug 12, 2021 at 05:38:01AM +0530, Sankeerth Billakanti wrote:
> The eDP controller on SC7280 is similar to the eDP/DP controllers
> supported by the current driver implementation.
>
> SC7280 supports one EDP and one DP controller which can operate
> concurrently.
>
> The following are som
On Thu, Aug 12, 2021 at 05:38:02AM +0530, Sankeerth Billakanti wrote:
> The Qualcomm SC7280 platform supports an eDP controller, add
> compatible string for it to msm/binding.
>
> Signed-off-by: Sankeerth Billakanti
> ---
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 3 +++
Applied. Thanks!
Alex
On Mon, Aug 16, 2021 at 3:23 AM Christian König
wrote:
>
> Am 15.08.21 um 21:29 schrieb Nathan Chancellor:
> > Clang + -Wimplicit-fallthrough warns:
> >
> > drivers/gpu/drm/radeon/radeon_fb.c:170:2: warning: unannotated
> > fall-through between switch labels [-Wimplicit-fa
Am 2021-08-15 um 5:10 a.m. schrieb Christoph Hellwig:
>> @@ -880,17 +881,22 @@ int svm_migrate_init(struct amdgpu_device *adev)
>> * should remove reserved size
>> */
>> size = ALIGN(adev->gmc.real_vram_size, 2ULL << 20);
>> -res = devm_request_free_mem_region(adev->dev, &iomem
Am 2021-08-15 um 4:40 p.m. schrieb John Hubbard:
> On 8/15/21 8:37 AM, Christoph Hellwig wrote:
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index 8ae31622deef..d48a1f0889d1 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -1218,7 +1218,7 @@ __maybe_unused str
Am 2021-08-15 um 11:40 a.m. schrieb Christoph Hellwig:
> On Fri, Aug 13, 2021 at 01:31:45AM -0500, Alex Sierra wrote:
>> Add MEMORY_DEVICE_GENERIC case to free_zone_device_page callback.
>> Device generic type memory case is now able to free its pages properly.
> How is this going to work for the
Applied. Thanks!
Alex
On Mon, Aug 16, 2021 at 11:07 AM Michel Dänzer wrote:
>
> On 2021-08-16 2:06 p.m., Christian König wrote:
> > Am 16.08.21 um 13:33 schrieb Lazar, Lijo:
> >> On 8/16/2021 4:05 PM, Michel Dänzer wrote:
> >>> From: Michel Dänzer
> >>>
> >>> schedule_delayed_work does not pus
Hi everyone,
this series is built around the DisplayPort driver. The dpi/dpintf driver and
the added helper functions are required for the DisplayPort.
Note that this is an RFC. I would like to have your opinion on the driver and
what needs to change. The driver itself has its rough edges that I
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Signed-off-by: Markus Schneider-Pargmann
---
drivers/gpu/drm/drm_edid.c |
DP_INTF is similar to the actual dpi. They differ in some points
regarding registers and what needs to be set but the function blocks
itself are similar in design.
Signed-off-by: Markus Schneider-Pargmann
---
.../display/mediatek/mediatek,dpi.yaml| 48 ---
1 file changed,
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not available for dpintf
which are now excluded from code
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp().
hdmi_audio_infoframe_pack_only() is split into two parts. One of them
packs th
On 8/15/2021 10:38 AM, Christoph Hellwig wrote:
On Fri, Aug 13, 2021 at 01:31:42AM -0500, Alex Sierra wrote:
migrate.vma = vma;
migrate.start = start;
migrate.end = end;
- migrate.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
migrate.pgmap_owner = SVM_ADEV_PG
Hi Markus,
A few general things in the following. This is what I look for first in
a bridge driver - and I had no time today to review the driver in full.
Please address these, then cc: me on next revision where I hopefully
have more time.
Sam
> +static int mtk_dp_bridge_attach(struct dr
Regards,
Oak
On 2021-08-16, 3:53 PM, "amd-gfx on behalf of Sierra Guiza, Alejandro (Alex)"
wrote:
On 8/15/2021 10:38 AM, Christoph Hellwig wrote:
> On Fri, Aug 13, 2021 at 01:31:42AM -0500, Alex Sierra wrote:
>> migrate.vma = vma;
>> migrate.start = sta
1 - 100 of 147 matches
Mail list logo
