From: Mark Yacoub
On reporting back the frame number of the CRCs through
drm_crtc_add_crc_entry(), send back the vblank count at the time the frame
CRC starts calculating rather than when the CRCs are ready to be
reported.
Tested by running IGT module: kms_plane::capture_crc()
Cc: Harry
From: Mark Yacoub
[Why]
Userspace should get back a copy of the request that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
back. When the type is RELATIVE, it modifies it to ABSOLUT
From: Mark Yacoub
[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it back. When the type is RELATIVE, it modifies it to ABS
On Thu, Aug 12, 2021 at 5:26 AM Michel Dänzer wrote:
>
> On 2021-08-11 7:55 p.m., Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > Userspace should get back a copy of the request that's been modified
> > even when drm_wait_vblank_i
Thanks for your review Michel!
@MAINTAINER, could you please strip the Change-Id when applying.
Thanks!
On Fri, Aug 13, 2021 at 3:33 AM Michel Dänzer wrote:
>
> On 2021-08-12 9:49 p.m., Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > Users
"friendly ping"
On Wed, Mar 10, 2021 at 11:14 AM Mark Yacoub
wrote:
> From: Mark Yacoub
>
> On initializing the framebuffer, call drm_any_plane_has_format to do a
> check if the modifier is supported. drm_any_plane_has_format calls
> dm_plane_format_mod_supported whic
On Tue, Mar 23, 2021 at 11:02 AM Alex Deucher wrote:
>
> On Wed, Mar 10, 2021 at 11:15 AM Mark Yacoub wrote:
> >
> > From: Mark Yacoub
> >
> > On initializing the framebuffer, call drm_any_plane_has_format to do a
> > check if the modifier is suppo
On Wed, Mar 24, 2021 at 8:10 AM Daniel Stone wrote:
>
> On Wed, 24 Mar 2021 at 10:53, Bas Nieuwenhuizen
> wrote:
>>
>> On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer wrote:
>>>
>>> No modifier support does not imply linear. It's generally signalled via
>>> DRM_FORMAT_MOD_INVALID, which roughly
On Wed, Mar 24, 2021 at 11:25 AM Daniel Stone wrote:
>
> Hi Mark,
>
> On Wed, 24 Mar 2021 at 14:58, Mark Yacoub wrote:
>>
>> So you mean it would make more sense to be more explicit in handling
>> DRM_FORMAT_MOD_INVALID as an incoming modifier (which will, just
From: Mark Yacoub
On initializing the framebuffer, call drm_any_plane_has_format to do a
check if the modifier is supported. drm_any_plane_has_format calls
dm_plane_format_mod_supported which is extended to validate that the
modifier is on the list of the plane's supported modifiers.
Th
bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
Suggested-by: Sean Paul
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Mark Yacoub
Change-Id: I9de3e21657510781b97f06afdc5db06d79f6f0f4
bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
Suggested-by: Sean Paul
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Mark Yacoub base.obj[0] = obj;
- drm_helper_mode_fill_fb_struct(dev
bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
Suggested-by: Sean Paul
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8
From: Mark Yacoub
To initialize the framebuffer, use drm_gem_fb_init_with_funcs which
verifies that the BO size can fit the FB size by calculating the minimum
expected size of each plane.
The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
From: Mark Yacoub
To initialize the framebuffer, call drm_gem_fb_init_with_funcs which
verifies that the BO size can fit the FB size by calculating the minimum
expected size of each plane.
The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
From: Mark Yacoub
On initializing the framebuffer, call drm_any_plane_has_format to do a
check if the modifier is supported. drm_any_plane_has_format calls
dm_plane_format_mod_supported which is extended to validate that the
modifier is on the list of the plane's supported modifiers.
Th
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. C
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
v1:
Remove
On Fri, Oct 1, 2021 at 4:34 PM Sean Paul wrote:
>
> On Wed, Sep 29, 2021 at 03:39:25PM -0400, Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> > or Degamma props in
From: Mark Yacoub
[Why]
The Rotation prob is a bitmask value. It must always have a valid value.
A default NO rotation is equal to 1 not 0.
[How]
1. At the reset hook, call __drm_atomic_helper_plane_reset which is
called at the initialization of the plane and sets the default value of
all
From: Mark Yacoub
[Why]
Creating the prop uses UNKNOWN as the initial value, which is not a
supported value if the props is to be supported.
[How]
Set the panel orientation default value to NORMAL right after creating
the prop.
Tested on Jacuzzi(MTK)
Fixes IGT@kms_properties@get_properties
From: Mark Yacoub
[Why]
This function and enum do not do generic checking on the luts but they
test color channels in the LUTs.
Keeping the name explicit as more generic LUT checks will follow.
Tested on Eldrid ChromeOS (TGL).
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/drm_color_mgmt.c
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. C
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
v1:
Remove
On Tue, Oct 26, 2021 at 8:02 AM Paul Menzel wrote:
>
> Dear Mark,
>
>
> Thank you for your patch.
>
> On 13.10.21 20:12, Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > 1. drm_atomic_helper_check doesn't check for the LUT sizes of
On Mon, Oct 25, 2021 at 9:26 PM Sean Paul wrote:
>
> On Wed, Oct 13, 2021 at 02:12:20PM -0400, Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> > or Degamma props in
new patch: https://patchwork.freedesktop.org/series/96314/
On Tue, Oct 26, 2021 at 3:24 PM Mark Yacoub wrote:
>
> On Tue, Oct 26, 2021 at 8:02 AM Paul Menzel wrote:
> >
> > Dear Mark,
> >
> >
> > Thank you for your patch.
> >
> > On 13.10.21 2
From: Mark Yacoub
At the reset hook, call __drm_atomic_helper_plane_reset which is
called at the initialization of the plane and sets the default value of
rotation on all planes to DRM_MODE_ROTATE_0 which is equal to 1.
Tested on Jacuzzi (MTK).
Resolves IGT@kms_properties@plane-properties
From: Mark Yacoub
[Why]
The rotation property must have a valid bitmask value. 0 isn't a valid
value.
The state should not be overwritten when performing an overlay value
check.
[How]
Do not overwrite state during the check.
Resolves: IGT@kms_properties@get_properties-sanity-{atomic,non-a
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. C
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
Signed-off-by: Mark
On Thu, Oct 28, 2021 at 8:42 PM Sean Paul wrote:
>
> On Tue, Oct 26, 2021 at 03:21:00PM -0400, Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > This function and enum do not do generic checking on the luts but they
> > test color channels in the LUT
From: Mark Yacoub
[Why]
The tests of LUT_EQUAL_CHANNELS and LUT_NON_DECREASING are currently
unique to i915 driver.
Freeing up the function name for the more generic LUT checks to folllow
Tested on Eldrid ChromeOS (TGL).
v1:
Stuff the test function from DRM to intel driver.
Signed-off-by
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. C
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
v1:
Remove
From: Mark Yacoub
[Why]
The tests of LUT_EQUAL_CHANNELS and LUT_NON_DECREASING are currently
unique to i915 driver.
Freeing up the function name for the more generic LUT checks to folllow
Tested on Eldrid ChromeOS (TGL).
v2:
1. Convert the enum to #define.
2. Add INTEL_COLOR_ prefix.
v1
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. C
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
v1:
Remove
From: Mark Yacoub
[Why]
vblank timestamp needs GPU high precision timestamp query to avoid using
the current monotonic/gettimeofday timestamp as best estimate.
[How]
Implement driver get_vblank_timestamp call which calls
get_scanout_position which loops over the CRTC comps to find a
component
From: Mark Yacoub
[Why]
drm_handle_vblank_events loops over vblank_event_list to send any event
that is current or has passed.
More than 1 event could be pending with past sequence time that need to
be send. This can be a side effect of drivers without hardware vblank
counter and they depend on
On Fri, Dec 3, 2021 at 1:03 PM Michel Dänzer wrote:
>
> On 2021-12-03 16:58, Matthias Brugger wrote:
> > Hi Mark,
> >
> > On 02/12/2021 16:11, Mark Yacoub wrote:
> >> From: Mark Yacoub
> >>
> >
> > please make sure to add the linux-me
From: Mark Yacoub
[Why]
The user space can allocate a LUT of any size. We must validate that it
is the expected MTK_LUT_SIZE.
[How]
Bring the .atomic_check function internal to mediatek driver and check
that the new CRTC state LUT size is equal to MTK_LUT_SIZE.
Fixes igt@kms_color@pipe-A
On Wed, Dec 8, 2021 at 7:16 PM Chun-Kuang Hu wrote:
>
> Hi Mark:
>
> Mark Yacoub 於 2021年10月28日 週四 上午12:28寫道：
> >
> > From: Mark Yacoub
> >
> > At the reset hook, call __drm_atomic_helper_plane_reset which is
> > called at the initialization
-off-by: Mark Yacoub
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index e6dcb34d30522..accd26481b9fb 100644
--- a/drivers/gpu/drm/mediatek
Hey CK, can we have this merged?
Thank you!
On Mon, Oct 25, 2021 at 9:13 PM Sean Paul wrote:
>
> On Fri, Oct 22, 2021 at 01:24:03PM -0400, Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > Creating the prop uses UNKNOWN as the initial value, which is no
Thank you so much!
On Mon, Dec 13, 2021 at 6:27 PM Chun-Kuang Hu wrote:
>
> Hi, Mark:
>
> Mark Yacoub 於 2021年12月14日 週二 上午12:08寫道：
> >
> > At the reset hook, call __drm_atomic_helper_plane_reset which is
> > called at the initialization of the plane and sets the de
On Wed, Dec 15, 2021 at 11:14 AM Chun-Kuang Hu wrote:
>
> Hi, Mark:
>
> Mark Yacoub 於 2021年12月14日 週二 下午11:13寫道：
> >
> > Hey CK, can we have this merged?
> > Thank you!
> >
> > On Mon, Oct 25, 2021 at 9:13 PM Sean Paul wrote:
> > >
> >
This makes sense. Thanks for pointing that out I wasn't aware of it.
I'll take a closer look and try to come up with something better.
Thanks Chun-Kuang!
On Thu, Dec 16, 2021 at 11:53 AM Chun-Kuang Hu wrote:
>
> Hi, Mark:
>
> Mark Yacoub 於 2021年12月16日 週四 上午1:25寫道：
> &
x27;t be
overriden once initialized to a value.
v1:
Set panel orientation only if DSI panel does not exist.
Tested on Jacuzzi(MTK)
Fixes IGT@kms_properties@get_properties-sanity-{atomic,non-atomic}
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
1 file chang
x27;t be
overriden once initialized to a value.
v1:
Set panel orientation only if DSI panel does not exist.
Tested on Jacuzzi(MTK)
Fixes IGT@kms_properties@get_properties-sanity-{atomic,non-atomic}
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
1 file chang
hey - uploaded v2 that takes care of the panel:
https://patchwork.kernel.org/project/linux-mediatek/patch/20211229184420.793234-1-markyac...@chromium.org/
Thanks!
On Tue, Dec 14, 2021 at 10:26 AM Mark Yacoub wrote:
>
> Thank you so much!
>
> On Mon, Dec 13, 2021 at 6:27 PM Chun-Kua
x27;t be
overriden once initialized to a value.
v2:
Move to the latest code where struct mtk_dsi{} has no member 'panel'.
v1:
Set panel orientation only if DSI panel does not exist.
Tested on Jacuzzi(MTK)
Fixes IGT@kms_properties@get_properties-sanity-{atomic,non-atomic}
Signed-off-
igned-off-by: Mark Yacoub
---
drivers/gpu/drm/drm_atomic_uapi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index acb1ee93d206..36b0f664dd80 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gp
DRM_MODE_CREATE_BLOB_WRITE_ONLY flag used by user space to
create a blob and mark the blob as write only.
On reading back the blob, data will be not be copied if it's a write
only blob
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/drm_property.c | 3 ++-
include/drm/drm_property.h | 2 ++
include/uap
friendly ping :)
On Tue, May 10, 2022 at 2:28 PM Mark Yacoub wrote:
>
> [Why]
> If a connector property is attached but
> drm_atomic_connector_get_property doesn't handle a case for it,
> modeteset will crash with a segfault without.
>
> [How]
> Add a debug messag
friendly ping :)
On Tue, May 10, 2022 at 3:08 PM Mark Yacoub wrote:
>
> [Why]
> User space might need to inject data into the kernel without allowing it
> to be read again by any user space.
> An example of where this is particularly useful is secret keys fetched
> by user
flag
argument.
Signed-off-by: Mark Yacoub
---
include/drm/drm_mode.h | 6 ++
xf86drmMode.c | 7 +++
xf86drmMode.h | 3 +++
3 files changed, 16 insertions(+)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 9b6722d4..b0df381f 100644
--- a/include/drm
friendly ping :))
On Tue, May 10, 2022 at 3:08 PM Mark Yacoub wrote:
>
> [Why]
> User space might need to inject data into the kernel without allowing it
> to be read again by any user space.
> An example of where this is particularly useful is secret keys fetched
> by user
friendly ping :))
On Tue, May 10, 2022 at 2:28 PM Mark Yacoub wrote:
>
> [Why]
> If a connector property is attached but
> drm_atomic_connector_get_property doesn't handle a case for it,
> modeteset will crash with a segfault without.
>
> [How]
> Add a debug messag
/ozone/platform/drm/gpu/drm_display.cc#203
I also wrote an IGT test to verify the intended behavior:
https://patchwork.freedesktop.org/patch/487331/?series=104373&rev=1
Let me know if I would need to update the commit message with any of
the aforementioned context.
Thanks!
-Mark Yacoub
On Tue,
Hi Jani, let me know if you need more info or more changes are needed. Thanks!
On Wed, May 25, 2022 at 3:31 PM Mark Yacoub wrote:
>
> Hi Jani, thanks for your review. I got all the user space
> implementation ready to see it in context.
>
> libdrm patch to wrap this functio
instead to inject the key into the kernel,
So, so far what we have implemented in the user space creating the
blob and injecting it into the kernel, and the part where the key is
needed,
Thanks!
On Thu, Jun 30, 2022 at 4:58 AM Jani Nikula wrote:
>
> On Wed, 29 Jun 2022, Mark Yacoub wrote:
>
Tested it on my end and confirmed that it works as intended.
On Fri, Nov 1, 2019 at 9:26 AM Sean Paul wrote:
>
> From: Sean Paul
>
> Expose the rotation property and handle REFLECT_Y rotations.
>
> Cc: Fritz Koenig
> Cc: Daniele Castagna
> Cc: Miguel Casas
> Cc: M
@lists.freedesktop.org
Cc: Daniele Castagna
Cc: Philipp Zabel
Cc: David Airlie
Cc: Daniel Vetter
Cc: Matthias Brugger
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ---
1 file changed, 4
Thanks for the update!
On Tue, Dec 24, 2019, 9:25 PM CK Hu wrote:
> Hi, Mark:
>
> On Wed, 2019-12-11 at 10:49 -0500, Mark Yacoub wrote:
> > drm/mediatek: return if plane pending state is disabled.
> >
> > If the plane pending state is disabled, call mtk_ovl_layer_of
From: Mark Yacoub
For each CRTC state, check the size of Gamma and Degamma LUTs so
unexpected and larger sizes wouldn't slip through.
TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
Signed-off-by: Mark Yacoub
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++
.../gpu/dr
From: Mark Yacoub
For each CRTC state, check the size of Gamma and Degamma LUTs so
unexpected and larger sizes wouldn't slip through.
TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
Signed-off-by: Mark Yacoub
Change-Id: I9d513a38e8ac2af1b4bf802e1feb1a4d726fba4c
---
.../gpu/drm/amd/di
Ignore this patch, in favor of (
https://patchwork.freedesktop.org/series/91023/), which appends the commit
title with drm/amd/display.
On Fri, Jun 4, 2021 at 12:59 PM Mark Yacoub wrote:
> From: Mark Yacoub
>
> For each CRTC state, check the size of Gamma and Degamma LUTs so
> un
On Fri, Jun 4, 2021 at 4:17 PM Harry Wentland wrote:
>
>
>
> On 2021-06-04 1:01 p.m., Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > For each CRTC state, check the size of Gamma and Degamma LUTs so
> > unexpected and larger sizes wouldn't slip t
ff-by don't match
> and you had some assignments in if clauses. I've fixed those up.
>
> Alex
>
>
> On Fri, Jun 11, 2021 at 1:35 PM Alex Deucher wrote:
> >
> > Applied. Thanks!
> >
> > On Thu, Jun 10, 2021 at 5:14 PM Harry Wentland
> > wrote
From: Mark Yacoub
Hello,
I rebased this series which is authored by Sean Paul.
A major rebase conflict was that drm/drm_hdcp was split to drm/display/drm_hdcp
& drm/display/drm_hdcp_helper.
Another major one was in msm dp where drm_connector was no longer tracked, but
it's re
-by: Sean Paul
Signed-off-by: Mark Yacoub
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-2-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, simply return
true if the content protection value is changing and let the driver
decide whether a modeset is required or not.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/2021091317574
y: Abhinav Kumar
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-5-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-5-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop
ani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Abhinav Kumar
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-4-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-4-s...@
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
Link:
https
pable HDCP 2.x callbacks and leave the
interesting stuff for the driver. Once we have another HDCP 2.x
implementation, we should do a similar migration.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747
From: Sean Paul
This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
helpers.
Cc: Stephen Boyd
Cc: Abhinav Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s
From: Sean Paul
This patch adds the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller. Now that these are supported, change the
compatible string to "dp-hdcp".
Signed-off-by: Sean Paul
Signed-of
ields are optional.
Cc: Rob Herring
Cc: Stephen Boyd
Reviewed-by: Rob Herring
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-13-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20210915203834
in the original intel flow
as it splits the unique driver protocol from the generic implementation.
Patches 5-7 split the HDCP flow on the i915 driver to make use of the common
DRM helpers.
Patches 8-10 implement HDCP on MSM driver.
Thanks,
-Mark Yacoub
Sean Paul (10):
drm/hdcp: Add
: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: move helper from drm_hdcp.c to drm_hdcp_helper.c
Changes in v7:
-Removed links to patch from commit msg (Dmitry Baryshkov)
drivers/gpu/drm/display/drm_hdcp_helper.c | 64
Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Changes in v7:
-Renamed the function from drm_hdcp_atomic_check to drm_hdcp_has_changed
(Dmitry
leave that
decision to the helper and by calling drm_hdcp_helper_atomic_commit()
from the driver. All told, this will centralize the protocol and state
handling in the helper, ensuring we collect all of our bugs^Wlogic
in one place.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Signed-off-by: M
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-Fixed indentation issue identified by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Cha
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Non
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Suraj Kandpal
Signed-off-by: Sean Paul
Signed-off-by: Mark
From: Sean Paul
Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.
Reviewed-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v3:
-Split off into a new
: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Drop register range names (Stephen)
-Fix yaml errors (Rob)
Changes in v3:
-Add new compatible string for dp-hdcp
-Add descriptions to reg
-Add minItems/maxItems to reg
-Make reg depend on the new hdcp
pable HDCP 2.x callbacks and leave the
interesting stuff for the driver. Once we have another HDCP 2.x
implementation, we should do a similar migration.
Acked-by: Jani Nikula
Acked-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Fix mst helper functi
From: Sean Paul
Add HDCP 1.x support to msm DP bridges using the new HDCP
helpers.
Cc: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Squash [1] into this patch with the following changes (Stephen)
-Update the sc7180 dtsi
From: Mark Yacoub
Hi all,
Following up to my HDCP patches[1], this series introduces a new connector prop
that is required to push the key from user space to a driver that requires a
key from user space to enable HDCP on a connector.
Patch 1 is the DRM code that creates this prop.
Patch 2 is
From: Mark Yacoub
[Why]
To support protected content, the driver requires a key.
Currently, it's being injected from debugfs, which is not super useful
to run a user space in the wild.
[How]
When the key is needed, fetch the "Content Protection Property" on the
connector and g
From: Mark Yacoub
[Why]
To enable Protected Content, some drivers require a key to be injected
from user space to enable HDCP on the connector.
[How]
Create new "Content Protection Property" of type "Blob"
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/d
From: Mark Yacoub
Hi all,
Following up to my HDCP patches[1], this series introduces a new connector prop
that is required to push the key from user space to a driver that requires a
key from user space to enable HDCP on a connector.
Patch 1 is the WO blob patch to protect the key
Patch 2 is
From: Mark Yacoub
[Why]
User space might need to inject data into the kernel without allowing it
to be read again by any user space.
An example of where this is particularly useful is secret keys fetched
by user space and injected into the kernel to enable content protection.
[How]
Create a
From: Mark Yacoub
[Why]
To enable Protected Content, some drivers require a key to be injected
from user space to enable HDCP on the connector.
[How]
Create new "Content Protection Property" of type "Blob"
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/d
From: Mark Yacoub
[Why]
To support protected content, the driver requires a key.
Currently, it's being injected from debugfs, which is not super useful
to run a user space in the wild.
[How]
When the key is needed, fetch the "Content Protection Property" on the
connector and g
protocol from the generic implementation.
Patches 5-7 split the HDCP flow on the i915 driver to make use of the common
DRM helpers.
Patches 8-10 implement HDCP on MSM driver.
Thanks,
-Mark Yacoub
Sean Paul (10):
drm/hdcp: Add drm_hdcp_atomic_check()
drm/hdcp: Avoid changing crtc state in hdcp
1 - 100 of 145 matches
Mail list logo
