Re: [PATCH 11/17] drm/msm/dp: add VSC SDP support for YUV420 over DP

2024-01-31 Thread Dmitry Baryshkov
On Thu, 1 Feb 2024 at 03:56, Abhinav Kumar wrote: > > > > On 1/27/2024 9:39 PM, Dmitry Baryshkov wrote: > > On Sun, 28 Jan 2024 at 07:34, Paloma Arellano > > wrote: > >> > >> > >> On 1/25/2024 1:48 PM, Dmitry Baryshkov wrote: > >>> On 25/01/2024 21:38, Paloma Arellano wrote: > Add support

Re: [PATCH 14/17] drm/msm/dpu: modify encoder programming for CDM over DP

2024-01-31 Thread Dmitry Baryshkov
On Thu, 1 Feb 2024 at 03:30, Abhinav Kumar wrote: > > > > On 1/29/2024 3:44 PM, Dmitry Baryshkov wrote: > > On Mon, 29 Jan 2024 at 09:08, Abhinav Kumar > > wrote: > >> > >> On 1/28/2024 10:12 PM, Dmitry Baryshkov wrote: > >>> On Mon, 29 Jan 2024 at 07:03, Abhinav Kumar > >>> wrote: > >

Re: [PATCH 11/17] drm/msm/dp: add VSC SDP support for YUV420 over DP

2024-01-31 Thread Abhinav Kumar
On 1/27/2024 9:39 PM, Dmitry Baryshkov wrote: On Sun, 28 Jan 2024 at 07:34, Paloma Arellano wrote: On 1/25/2024 1:48 PM, Dmitry Baryshkov wrote: On 25/01/2024 21:38, Paloma Arellano wrote: Add support to pack and send the VSC SDP packet for DP. This therefore allows the transmision of

Re: [PATCH 14/17] drm/msm/dpu: modify encoder programming for CDM over DP

2024-01-31 Thread Abhinav Kumar
On 1/29/2024 3:44 PM, Dmitry Baryshkov wrote: On Mon, 29 Jan 2024 at 09:08, Abhinav Kumar wrote: On 1/28/2024 10:12 PM, Dmitry Baryshkov wrote: On Mon, 29 Jan 2024 at 07:03, Abhinav Kumar wrote: On 1/28/2024 7:42 PM, Dmitry Baryshkov wrote: On Mon, 29 Jan 2024 at 04:58, Abhinav

Re: [PATCH] drm/msm/dpu: fix the programming of INTF_CFG2_DATA_HCTL_EN

2024-01-31 Thread Abhinav Kumar
On 1/31/2024 5:05 PM, Dmitry Baryshkov wrote: On Thu, 1 Feb 2024 at 02:48, Abhinav Kumar wrote: Currently INTF_CFG2_DATA_HCTL_EN is coupled with the enablement of widebus but this is incorrect because we should be enabling this bit independent of widebus except for cases where compression

Re: [PATCH] drm/msm/dpu: fix the programming of INTF_CFG2_DATA_HCTL_EN

2024-01-31 Thread Dmitry Baryshkov
On Thu, 1 Feb 2024 at 02:48, Abhinav Kumar wrote: > > Currently INTF_CFG2_DATA_HCTL_EN is coupled with the enablement > of widebus but this is incorrect because we should be enabling > this bit independent of widebus except for cases where compression > is enabled in one pixel per clock mode. > >

[PATCH] drm/msm/dpu: fix the programming of INTF_CFG2_DATA_HCTL_EN

2024-01-31 Thread Abhinav Kumar
Currently INTF_CFG2_DATA_HCTL_EN is coupled with the enablement of widebus but this is incorrect because we should be enabling this bit independent of widebus except for cases where compression is enabled in one pixel per clock mode. Fix this by making the condition checks more explicit and

Re: [PATCH 4/5] drm/msm/dp: Try looking for link-frequencies into the port@0's endpoint first

2024-01-31 Thread Dmitry Baryshkov
On Wed, 31 Jan 2024 at 19:04, Abel Vesa wrote: > > On 24-01-29 17:08:29, Dmitry Baryshkov wrote: > > On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote: > > > > > > From: Abhinav Kumar > > > > > > On platforms where the endpoint used is on port@0, looking for port@1 > > > instead results in just

Re: [PATCH 4/5] drm/msm/dp: Try looking for link-frequencies into the port@0's endpoint first

2024-01-31 Thread Abel Vesa
On 24-01-29 17:08:29, Dmitry Baryshkov wrote: > On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote: > > > > From: Abhinav Kumar > > > > On platforms where the endpoint used is on port@0, looking for port@1 > > instead results in just ignoring the max link-frequencies altogether. > > Look at port@0

[PATCH v3] drm/msm/gem: Fix double resv lock aquire

2024-01-31 Thread Rob Clark
From: Rob Clark Since commit 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations"), the resv lock is already held in the prime vmap path, so don't try to grab it again. v2: This applies to vunmap path as well v3: Fix fixes commit Fixes: 79e2cf2e7a19 ("drm/gem: Take

Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks

2024-01-31 Thread Daniel Vetter
On Wed, Jan 31, 2024 at 12:26:45PM +0200, Dmitry Baryshkov wrote: > On Wed, 31 Jan 2024 at 11:11, Daniel Vetter wrote: > > > > On Wed, Jan 31, 2024 at 05:17:08AM +, Jason-JH Lin (林睿祥) wrote: > > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > > > External email : Please

Re: Re: Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks

2024-01-31 Thread mrip...@kernel.org
Hi, On Wed, Jan 31, 2024 at 05:27:14AM +, Jason-JH Lin (林睿祥) wrote: > > On Sun, 2024-01-28 at 10:24 +0100, Maxime Ripard wrote: > > On Thu, Jan 25, 2024 at 07:17:21PM +0100, Daniel Vetter wrote: > > > On Tue, Jan 23, 2024 at 06:09:05AM +, Jason-JH Lin (林睿祥) wrote: > > > > Hi Maxime,

Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks

2024-01-31 Thread Dmitry Baryshkov
On Wed, 31 Jan 2024 at 11:11, Daniel Vetter wrote: > > On Wed, Jan 31, 2024 at 05:17:08AM +, Jason-JH Lin (林睿祥) wrote: > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > External email : Please do not click links or open attachments until > > > you have verified the

Re: [PATCH] drm/msm/gem: Fix double resv lock aquire

2024-01-31 Thread Christian König
Am 30.01.24 um 23:35 schrieb Rob Clark: From: Rob Clark Since commit 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping functions"), the resv lock is already held in the prime vmap path, so don't try to grab it again. Fixes: 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping

Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks

2024-01-31 Thread Daniel Vetter
On Wed, Jan 31, 2024 at 05:17:08AM +, Jason-JH Lin (林睿祥) wrote: > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > On Tue, Jan 23, 2024 at 06:09:05AM

Re: [PATCH v2] drm/msm/gem: Fix double resv lock aquire

2024-01-31 Thread Dmitry Osipenko
On 1/31/24 04:15, Rob Clark wrote: > From: Rob Clark > > Since commit 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping > functions"), the resv lock is already held in the prime vmap path, so > don't try to grab it again. > > v2: This applies to vunmap path as well > > Fixes: