This series adds support for mt8192 h264 decoder. Firstly, need to refactor
power/clock/interrupt interfaces for mt8192 is lat and core architecture.
Secondly, add new functions to get frame buffer size and resolution according
to decoder capability from scp side. Then add callback function to get
MT8173 platform use vpu firmware, mt8183/mt8192 will use scp
firmware instead, using chip name is not reasonable to separate
different firmware architecture. Using firmware type is much better.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
---
drivers/media/platform/mtk-vcodec/mtk_vcodec
Lock, power and clock are highly coupled operations. Adds vdec
enable/disable hardware helpers and uses them.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 5 -
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 168 +++---
.
Different capture buffer format has different buffer size, need to get
real buffer size according to buffer type from scp.
Signed-off-by: Yunfei Dong
---
comments:
+static void handle_get_param_msg_ack(
+ const struct vdec_vpu_ipi_get_param_ack *msg)
+{
+ struct vdec_vpu_inst *vpu = (
lat thread: output queue \
-> lat hardware -> lat trans buffer
lat trans buffer /
core thread: capture queue \
->core hardware -> capture queue
lat trans buffer /
Lat and core work in different thre
For lat and core decode in parallel, need to get capture buffer
when core start to decode and put put capture buffer to display
list when core decode done.
Signed-off-by: Yunfei Dong
---
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 123 --
.../platform/mtk-vcodec/mtk_vcodec_dr
Supported output and capture format types for mt8192 are different
with mt8183. Needs to get format types according to decoder capability.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 8 +-
.../mtk-vcodec/mtk_vcodec_dec_stateful.c | 13 +-
.../mtk-vcodec
Supported max resolution for different platforms are not the same: 2K
or 4K, getting it according to dec_capability.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
---
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 31 +++
.../platform/mtk-vcodec/mtk_vcodec_drv.h |
Needs to use mediatek compressed mode for mt8192 decoder.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c | 7 ++-
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers
For vp8 not support 4K, need to disable it.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_d
Need to use default pic info when get pic info fail.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/m
Capture queue format type is difference for different platform,
need to calculate capture buffer size according to capture queue
format type in scp.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 2 ++
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 2 ++
Adds h264 lat and core driver for mt8192, and the decode mode is frame
based for stateless decoder.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../mtk-vcodec/vdec/vdec_h264_req_lat_if.c| 620 ++
.../media/platform/mtk-vcodec/vdec_drv
Mt8192 can use some of common code with mt8183. Moves them to
a new file in order to reuse.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../mtk-vcodec/vdec/vdec_h264_req_common.c| 303 ++
.../mtk-vcodec/vdec/vdec_h264_req_common.h| 24
Hi, Oak.
On 1/4/22 00:08, Zeng, Oak wrote:
Regards,
Oak
Looks like your emails always start with "Regards, Oak". a misconfiguration?
-Original Message-
From: Thomas Hellström
Sent: January 3, 2022 1:58 PM
To: Zeng, Oak ; intel-...@lists.freedesktop.org;
dri-devel@lists.freedeskto
On Tue, 2022-01-04 at 08:47 +0100, Christian König wrote:
> Am 03.01.22 um 19:57 schrieb John Stultz:
> > On Mon, Dec 27, 2021 at 1:52 AM wrote:
> > > From: Guangming
> > >
> >
> > Thanks for submitting this!
> >
> > > Add a size check for allcation since the allocation size is
> >
> > nit: "
V1:
1. The MCU FW controling ASPEED DP is loaded by BMC boot loader.
2. Driver starts after CR[3:1] == 111b that indicates Tx is ASTDP,
and CRD1[5] has been asserted by BMVC boot loader.
3. EDID is prioritized by DP monitor.
4. DP's EDID has high priority to decide resolution supporting.
V2:
Mo
Il 03/01/22 06:47, Miles Chen ha scritto:
In current implementation, mtk_cec_mask() writes val into target register
and ignores the mask. After talking to our hdmi experts, mtk_cec_mask()
should read a register, clean only mask bits, and update (val | mask) bits
to the register.
Fixes: 8f83f2689
Hi Christian,
I'm not sure what do you mean by "we need to change SRIOV not the driver".
Do you mean we should change the reset sequence in SRIOV? This will be a huge
change for our SRIOV solution.
>From my point of view, we can directly use
amdgpu_device_lock_adev and amdgpu_device_unlock_adev
Il 10/12/21 12:36, AngeloGioacchino Del Regno ha scritto:
DRM bridge drivers are now attaching their DSI device at probe time,
which requires us to register our DSI host in order to let the bridge
to probe: this recently started producing an endless -EPROBE_DEFER
loop on some machines that are us
Il 04/01/22 09:01, Yunfei Dong ha scritto:
MT8173 platform use vpu firmware, mt8183/mt8192 will use scp
firmware instead, using chip name is not reasonable to separate
different firmware architecture. Using firmware type is much better.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
He
-邮件原件-
发件人: bern...@vivo.com 代表 Jani Nikula
发送时间: 2021年12月31日 19:09
收件人: 赵军奎 ; Maarten Lankhorst
; Maxime Ripard ; Thomas
Zimmermann ; David Airlie ; Daniel
Vetter ; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
抄送: 赵军奎
主题: Re: [PATCH] gpu/drm: fix potential memleak in
Hi,
On 10.12.2021 12:36, AngeloGioacchino Del Regno wrote:
DRM bridge drivers are now attaching their DSI device at probe time,
which requires us to register our DSI host in order to let the bridge
to probe: this recently started producing an endless -EPROBE_DEFER
loop on some machines that are
DRM bridge drivers are now attaching their DSI device at probe time,
which requires us to register our DSI host in order to let the bridge
to probe: this recently started producing an endless -EPROBE_DEFER
loop on some machines that are using external bridges, like the
parade-ps8640, found on the A
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #19 from spassw...@web.de ---
Created attachment 300222
--> https://bugzilla.kernel.org/attachment.cgi?id=300222&action=edit
debugging patch
I added some more dev_info calls to figure out where things are called:
[ 34.946911] wlp4
Hi Jingwen,
well what I mean is that we need to adjust the implementation in amdgpu
to actually match the requirements.
Could be that the reset sequence is questionable in general, but I doubt
so at least for now.
See the FLR request from the hypervisor is just another source of
signaling
On 12/15/21 10:47 PM, Yannick Fertre wrote:
Replace the legacy register access by regmap API.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 138 ++---
drivers/gpu/drm/stm/ltdc.h | 1 +
2 files changed, 68 insertions(+), 71 deletions(-)
On 12/15/21 10:47 PM, Yannick Fertre wrote:
LTDC 40100 hw version supports the YCbCr 422 output,
reducing the output pins from 24 to 16. This feature
is useful for some external devices like HDMI bridges.
Both ITU-R BT.601 & ITU-R BT.709 are supported.
It is also possible to choose the chrom
On 12/15/21 10:48 PM, Yannick Fertre wrote:
Recent ltdc hardware versions offer the ability
to update a plane independently of others planes.
This is could be useful especially if a plane is
assigned to another OS.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 26 +
https://bugzilla.kernel.org/show_bug.cgi?id=215436
spassw...@web.de changed:
What|Removed |Added
Attachment #300222|0 |1
is obsolete|
On 12/15/21 10:48 PM, Yannick Fertre wrote:
This feature allows the generation of any RGB pixel format.
The list of supported formats is no longer linked to the
register LXPFCR_PF, that the reason why a list of drm formats is
defined for each display controller version.
Signed-off-by: Yannick
On 12/15/21 10:48 PM, Yannick Fertre wrote:
This patch adds the following YCbCr input pixel formats on the latest
LTDC hardware version:
1 plane (co-planar) : YUYV, YVYU, UYVY, VYUY
2 planes (semi-planar): NV12, NV21
3 planes (full-planar): YU12=I420=DRM YUV420, YV12=DRM YVU420
Signed-off-
From: Minghao Chi
Return value from aty_ld_8() directly instead
of taking this in another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
Signed-off-by: CGEL ZTE
---
drivers/video/fbdev/aty/mach64_ct.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --gi
On 12/18/21 10:50 PM, Antonio Borneo wrote:
There is no need to re-compute the dsi lane capability because it
only depends on dsi hw version.
Since dsi hw version is detected at probe(), move there also the
assignment of dsi lane capability.
Signed-off-by: Antonio Borneo
---
To: David Airlie
[AMD Official Use Only]
>> See the FLR request from the hypervisor is just another source of signaling
>> the need for a reset, similar to each job timeout on each queue. Otherwise
>> you have a race condition between the hypervisor and the scheduler.
No it's not, FLR from hypervisor is just to
On 12/18/21 10:50 PM, Antonio Borneo wrote:
To evaluate the validity of a video mode, some additional internal
value has to be passed to the platform implementation.
Extend the prototype of mode_valid().
Signed-off-by: Antonio Borneo
---
To: David Airlie
To: Daniel Vetter
To: Andrzej Hajd
On 12/18/21 10:50 PM, Antonio Borneo wrote:
The dsi has several constraints on the video modes it can support,
mainly due to the frequencies that can be generated by the PLL
integrated in the DSI device.
Verify that the required HS clock can be generated by the PLL.
The dsi clock from the ds
Hi Sascha:
Please add Series-version for all the patch series. add also Series-changes.
I saw you have Series-changes in cover-letter, but we usually include
them in patch.
Here is a link you can take for reference[0]
[0]https://source.denx.de/u-boot/u-boot/-/tree/master/tools/patman
On 12
https://bugzilla.kernel.org/show_bug.cgi?id=215436
spassw...@web.de changed:
What|Removed |Added
Attachment #300223|0 |1
is obsolete|
On Tue, 04 Jan 2022, 赵军奎 wrote:
> -邮件原件-
> 发件人: bern...@vivo.com 代表 Jani Nikula
> 发送时间: 2021年12月31日 19:09
> 收件人: 赵军奎 ; Maarten Lankhorst
> ; Maxime Ripard ;
> Thomas Zimmermann ; David Airlie ;
> Daniel Vetter ; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org
> 抄送: 赵军奎
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #22 from spassw...@web.de ---
I get similar message if I just lock the screen which then switches off:
[ 1732.526162] amdgpu :08:00.0: amdgpu: Calling dc_commit_state from
amdgpu_dm_atomic_commit_tail
[ 1732.640992] amdgpu :08:
Am 04.01.22 um 11:49 schrieb Liu, Monk:
[AMD Official Use Only]
See the FLR request from the hypervisor is just another source of signaling the
need for a reset, similar to each job timeout on each queue. Otherwise you have
a race condition between the hypervisor and the scheduler.
No it's n
Hi Chris
Thanks for the patch.
On Mon, 3 Jan 2022 at 17:41, Chris Morgan wrote:
>
> From: Chris Morgan
>
> Add support for the VC4 DPI driver to utilize DPI mode 3. This is
> defined here as xxxRxxGGxxxB:
>
> https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#para
On Tue, 4 Jan 2022 at 11:47, Philippe CORNU wrote:
>
>
>
> On 12/18/21 10:50 PM, Antonio Borneo wrote:
> > There is no need to re-compute the dsi lane capability because it
> > only depends on dsi hw version.
> > Since dsi hw version is detected at probe(), move there also the
> > assignment of ds
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number i
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thom
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the ins
A pin-count is already held by vma->pages so taking an additional pin
during async binds is not necessary.
When we introduce async unbinding we have other means of keeping the
object pages alive.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 5 +
1 file changed, 1 in
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to a
Add a selftest to exercise asynchronous migration and -unbining.
Extend the gem_migrate selftest to perform the migrations while
depending on a spinner and a bound vma set up on the migrated
buffer object.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 12 ++
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a s
On Mon, 27 Dec 2021 at 10:25, Miaoqian Lin wrote:
>
> rc_dev is allocated by rc_allocate_device(), and doesn't assigned to
> ctx->rc_dev before calling rc_free_device(ctx->rc_dev).
> So it should call rc_free_device(rc_dev);
>
> Fixes: e25f1f7 ("drm/bridge/sii8620: add remote control support")
>
Applied to drm-misc-next
On Sun, 19 Dec 2021 at 17:41, Jagan Teki wrote:
>
> On Fri, Nov 19, 2021 at 8:23 PM Jagan Teki wrote:
> >
> > Replace atomic version of the pre_enable/enable/post_disable
> > operations to continue the transition to the atomic API.
> >
> > Also added default drm atomic operations for duplicate, d
On Fri, 19 Nov 2021 at 15:53, Jagan Teki wrote:
>
> Get the display mode settings via mode_set bridge
> function instead of explicitly de-reference.
>
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/bridge/chipone-icn6211.c | 18 --
> 1 file changed, 12 insertions(+), 6 delet
Applied to drm-misc-next
On Fri, 19 Nov 2021 at 02:58, Xin Ji wrote:
>
> As GPIO probe function "devm_gpiod_get_optional()" may return error
> code, driver should identify GPIO desc as NULL to avoid crash.
>
> Acked-by: Tzung-Bi Shih
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 9
Applied to drm-misc-next
Jiri: Are you able to test this patch?
Vinay: Could you supply a R-b tag, if you feel that it is warranted?
On Tue, 14 Dec 2021 at 09:13, Vinay Simha B N wrote:
>
> Robert,
> I do not have the hardware to test this feature. Sorry for the late response.
>
> On Thu, Nov 18, 2021 at 8:20 PM Robert
On 12/14/21 11:15 AM, Philippe CORNU wrote:
On 12/6/21 3:23 PM, Thomas Zimmermann wrote:
Hi
Am 06.12.21 um 14:47 schrieb Yannick Fertre:
In case of using simplefb or another conflicting framebuffer,
call drm_aperture_remove_framebuffers() to remove memory allocated.
Signed-off-by: Yannic
On 12/14/21 11:19 AM, Philippe CORNU wrote:
On 12/3/21 9:56 AM, Yannick Fertre wrote:
Add support of new hardware version 0x40100.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 172 ++---
drivers/gpu/drm/stm/ltdc.h | 3 +-
2 files cha
On 26/12/2021 22:24, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation a
On 26/12/2021 22:24, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #23 from mario.limoncie...@amd.com ---
Did you try out my patch? It should have given an extra explicit call in the
suspend path.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watchin
Hey Zhou,
Thanks for submitting this patch.
On Tue, 30 Nov 2021 at 14:11, Zhou Qingyang wrote:
>
> In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate()
> is assigned to mhdp_state->current_mode and used in drm_mode_set_name().
> There is a dereference of it in drm_mode_set_name
On Wed, Dec 29, 2021 at 06:03:56PM +0100, Luca Weiss wrote:
> PM6150L contains WLED of version 5. Add support ofr it to the driver.
>
> Signed-off-by: Luca Weiss
Reviewed-by: Daniel Thompson
Daniel.
Hey AngeloGioacchino,
On Tue, 2 Nov 2021 at 14:08, AngeloGioacchino Del Regno
wrote:
>
> Entering suspend while the display attached to this bridge is still on
> makes the resume sequence to resume the bridge first, display last:
> when this happens, we get a timeout while resuming the bridge, as
Hey Miaoqian,
Thanks for submitting this fix.
On Wed, 22 Dec 2021 at 09:33, Miaoqian Lin wrote:
>
> Since i2c_new_client_device() function return error pointers.
> The i2c_new_dummy_device() function does not return NULL, It returns error
> pointers too. Using IS_ERR() to check the return value
Actually, this patch is based on testing with a real HW with dual-link LVDS
display (full HD) and it also matches with a datasheet. Without this fix it
does not work at all.
út 4. 1. 2022 v 14:51 odesílatel Robert Foss
napsal:
> Jiri: Are you able to test this patch?
>
> Vinay: Could you supply
Applied to drm-misc-next
Excellent.
Jiri, can you add your Tested-by tag to this patch?
On Tue, 4 Jan 2022 at 15:29, Jiří Vaněk wrote:
>
> Actually, this patch is based on testing with a real HW with dual-link LVDS
> display (full HD) and it also matches with a datasheet. Without this fix it
> does not work at all.
>
Il 04/01/22 15:22, Robert Foss ha scritto:
Hey AngeloGioacchino,
On Tue, 2 Nov 2021 at 14:08, AngeloGioacchino Del Regno
wrote:
Entering suspend while the display attached to this bridge is still on
makes the resume sequence to resume the bridge first, display last:
when this happens, we get
Hey Xin,
On Tue, 9 Nov 2021 at 03:42, Xin Ji wrote:
>
> This patch provides HDCP setting interface for userspace to dynamic
> enable/disable HDCP function.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 368 +-
> drivers/gpu/drm/bridge/analogix
On Tue, 9 Nov 2021 at 03:43, Xin Ji wrote:
>
> Provide .get_eld interface in hdmi_codec_ops for hdmi-codec driver.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analo
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #24 from spassw...@web.de ---
That's it! The extra call to clk_mgr_optimize_pwr_state now leads to
rn_update_clock being called with adev->in_s0ix = 1:
[ 31.142514] wlp4s0: deauthenticating from 54:67:51:3d:a2:e0 by local choice
(R
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #25 from mario.limoncie...@amd.com ---
Can you check the state of the other variables though with that extra call?
That was in my debugging patch but not inyours.
Is the HPD active?
--
You may reply to this email to add a comment.
Hi Jagan,
On Mon, 22 Nov 2021 at 08:06, Jagan Teki wrote:
>
> Get the display mode settings via mode_set bridge function
> instead of explicitly de-reference.
>
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 -
> 1 file changed, 12 insertions(+), 1
Am 22.12.21 um 22:43 schrieb Daniel Vetter:
On Tue, Dec 07, 2021 at 01:34:00PM +0100, Christian König wrote:
So far we had the approach of using a directed acyclic
graph with the dma_resv obj.
This turned out to have many downsides, especially it means
that every single driver and user of this
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #26 from spassw...@web.de ---
For the extra call hpd_state = 0:
[ 30.684201] wlp4s0: deauthenticating from 54:67:51:3d:a2:e0 by local choice
(Reason: 3=DEAUTH_LEAVING)
[ 30.794571] amdgpu :08:00.0: amdgpu: Calling optimize_band
https://bugzilla.kernel.org/show_bug.cgi?id=215436
--- Comment #27 from mario.limoncie...@amd.com ---
Great!
OK, let me send that out for review then and see what folks think.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of
Regards,
Oak
> -Original Message-
> From: Thomas Hellström
> Sent: January 4, 2022 3:29 AM
> To: Zeng, Oak ; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org
> Cc: Auld, Matthew
> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as
> argument f
> -Original Message-
> From: Souza, Jose
> Sent: Wednesday, November 24, 2021 1:07 AM
> To: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; intel-...@lists.freedesktop.org
> Cc: Mun, Gwan-gyeong ; Nikula, Jani
> ; Kahola, Mika ; Navare,
> Manasi D
> Subject: Re: [PATCH v3 1/5] drm/i
Hi,
> -Original Message-
> From: Souza, Jose
> Sent: Wednesday, November 24, 2021 1:19 AM
> To: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; intel-...@lists.freedesktop.org
> Cc: Mun, Gwan-gyeong ; Nikula, Jani
> ; Kahola, Mika ; Navare,
> Manasi D
> Subject: Re: [PATCH v3 3/5] dr
On Tue, 2022-01-04 at 21:21 +0530, Manna, Animesh wrote:
> Hi,
>
> > -Original Message-
> > From: Souza, Jose
> > Sent: Wednesday, November 24, 2021 1:19 AM
> > To: dri-devel@lists.freedesktop.org; Manna, Animesh
> > ; intel-...@lists.freedesktop.org
> > Cc: Mun, Gwan-gyeong ; Nikula, Jan
Hi, Oak,
On 1/4/22 16:35, Zeng, Oak wrote:
Regards,
Oak
-Original Message-
From: Thomas Hellström
Sent: January 4, 2022 3:29 AM
To: Zeng, Oak ; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Auld, Matthew
Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use t
> -Original Message-
> From: Souza, Jose
> Sent: Tuesday, January 4, 2022 9:25 PM
> To: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; intel-...@lists.freedesktop.org
> Cc: Mun, Gwan-gyeong ; Nikula, Jani
> ; Kahola, Mika ; Navare,
> Manasi D
> Subject: Re: [PATCH v3 3/5] drm/i915/
On 2022-01-04 6:36 a.m., Christian König wrote:
Am 04.01.22 um 11:49 schrieb Liu, Monk:
[AMD Official Use Only]
See the FLR request from the hypervisor is just another source of
signaling the need for a reset, similar to each job timeout on each
queue. Otherwise you have a race condition be
On Tue, Jan 4, 2022, 17:56 Vinay Simha B N wrote:
> Robert,
> What is R-b tag?
>
It looks like this Reviewed-by: Name Lastname
Maybe have a quick look at this document.
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
>
> On Tue, Jan 4, 2022 at 7:21 PM Robert Foss wrot
[AMD Official Use Only]
I mostly agree with the sequences Christian described . Just one thing might
need to discuss here. For FLR notified from host, in new sequenceas
described , driver need to reply the READY_TO_RESET in the workitem from a
reset work queue which means inside flr_
intel_context_timeline_lock can return can error if interrupted by a
user when trying to lock the timeline mutex. Check the return value of
intel_context_timeline_lock in eb_pin_timeline (execbuf IOCTL).
Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
Signed-off-by: Matthew Brost
---
drivers/
On Mon, Jan 03, 2022 at 01:17:10PM -0800, Matt Roper wrote:
On Tue, Dec 21, 2021 at 09:46:29PM +0200, Andi Shyti wrote:
Hi Matt,
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
> > index 170bba913c30..128315aec517 100644
> > --- a/drivers/gpu/drm/i915/i915_
[+Adrian]
Am 2021-12-23 um 2:05 a.m. schrieb Christian König:
> Am 22.12.21 um 21:53 schrieb Daniel Vetter:
>> On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
>>
>> [SNIP]
>> Still sounds funky. I think minimally we should have an ack from CRIU
>> developers that this is offic
DP_SINK_COUNT_ESI and DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 have the same
contents as DP_SINK_COUNT and DP_DEVICE_SERVICE_IRQ_VECTOR,
respectively.
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_dp
Take bit 7 into account when reading sink count from
DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_top
On Tue, 21 Dec 2021 08:51:45 -0400, Rob Herring wrote:
> With 'unevaluatedProperties' support enabled, the st,stm32-dsi binding
> has a new warning:
>
> Documentation/devicetree/bindings/display/st,stm32-dsi.example.dt.yaml:
> dsi@5a00: Unevaluated properties are not allowed ('panel-dsi@0' wa
On Wed, 22 Dec 2021 14:32:00 +0100, Marek Vasut wrote:
> Add Multi-Inno Technology MI0700S4T-6 7" 800x480 DPI panel
> compatible string.
>
> Signed-off-by: Marek Vasut
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
> .../device
On Fri, 24 Dec 2021 08:23:09 +0300, Nikita Yushchenko wrote:
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS encoder
> bindings.
>
> Signed-off-by: Nikita Yushchenko
> ---
> .../devicetree/bindings/display/bridge/renesas,lvds.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
A
On 2022-01-04 12:13 p.m., Liu, Shaoyun wrote:
[AMD Official Use Only]
I mostly agree with the sequences Christian described . Just one thing might
need to discuss here. For FLR notified from host, in new sequenceas
described , driver need to reply the READY_TO_RESET in the workitem
On Fri, Dec 24, 2021 at 05:24:57PM +0100, David Heidelberg wrote:
> Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
>
> Other changes:
> - fixed reg-names numbering to match 0..3 instead 0,1,3,4
>
> Signed-off-by: David Heidelberg
> ---
> .../devicetree/bindings/display/msm/h
On Fri, 24 Dec 2021 20:53:54 +0100, David Heidelberg wrote:
> Enable port inside panel bindings.
>
> Fixes warnings generated by `make qcom-apq8064-asus-nexus7-flo.dtb` as:
> arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dt.yaml: panel@0: 'port' does
> not match any of the regexes: 'pinctrl-[0-9
1 - 100 of 119 matches
Mail list logo
