Re: [Freedreno] [PATCH RFC v6 00/10] Support for Solid Fill Planes
On 2023-08-28 20:05, Jessica Zhang wrote: > Some drivers support hardware that have optimizations for solid fill > planes. This series aims to expose these capabilities to userspace as > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android > hardware composer HAL) that can be set by apps like the Android Gears > app. > > In order to expose this capability to userspace, this series will: > > - Introduce solid_fill and pixel_source properties to allow userspace to > toggle between FB and solid fill sources > - Loosen NULL FB checks within the DRM atomic commit callstack to allow > for NULL FB when solid fill is enabled. > - Add NULL FB checks in methods where FB was previously assumed to be > non-NULL > - Have MSM DPU driver use drm_plane_state.solid_fill instead of > dpu_plane_state.color_fill > > Note: The solid fill planes feature depends on both the solid_fill *and* > pixel_source properties. > > To use this feature, userspace can set the solid_fill property to a blob > containing the appropriate version number and solid fill color (in > RGB323232 format) and and setting the pixel_source property to > DRM_PLANE_PIXEL_SOURCE_COLOR. This will disable memory fetch and the > resulting plane will display the color specified by the solid_fill blob. > > Currently, there's only one version of the solid_fill blob property. > However if other drivers want to support a similar feature, but require > more than just the solid fill color, they can extend this feature by > creating additional versions of the drm_solid_fill struct. > > This 2 property approach was chosen because passing in a special 1x1 FB > with the necessary color information would have unecessary overhead that > does not reflect the behavior of the solid fill feature. In addition, > assigning the solid fill blob to FB_ID would require loosening some core > drm_property checks that might cause unwanted side effects elsewhere. > I didn't have a detailed review of this patchset but at a high-level this change makes sense to me. Feel free to add my Acked-by: Harry Wentland to patches 1-5. Harry > --- > Changes in v6: > - Have _dpu_plane_color_fill() take in a single ABGR color instead > of having separate alpha and BGR color parameters (Dmitry) > - Drop plane->state->pixel_source != DRM_PLANE_PIXEL_SOURCE_FB check > in SetPlane ioctl (Dmitry) > - Add DRM_PLANE_PIXEL_SOURCE_NONE as a default pixel source (Sebastian) > - Dropped versioning from solid fill property blob (Dmitry) > - Use DRM_ENUM_NAME_FN (Dmitry) > - Use drm_atomic_replace_property_blob_from_id() (Dmitry) > - drm_atomic_check_fb -> drm_atomic_plane_check_fb (Dmitry) > - Group redundant NULL FB checks (Dmitry) > - Squashed drm_plane_needs_disable() implementation with > DRM_PLANE_PIXEL_SOURCE_NONE declaration (Sebastian) > - Add comment to support RGBA solid fill color in the future (Dmitry) > - Link to v5: > https://lore.kernel.org/r/20230728-solid-fill-v5-0-053dbefa9...@quicinc.com > > Changes in v5: > - Added support for PIXEL_SOURCE_NONE (Sebastian) > - Added WARN_ON() in drm_plane_has_visible_data() if pixel_source isn't > set (Dmitry) > - Added debugfs support for both properties (Dmitry) > - Corrected u32 to u8 conversion (Pekka) > - Moved drm_solid_fill_info struct and related documentation to > include/uapi (Pekka) > - Changed drm_solid_fill_info.version to __u32 for data alignment (Pekka) > - Added more detailed UAPI and kernel documentation (Pekka) > - Reordered patch series so that the pixel_source property is introduced > before solid_fill (Dmitry) > - Fixed inconsistent ABGR/RGBA format declaration (Pekka) > - Reset pixel_source to FB in drm_mode_setplane() (Dmitry) > - Rename supported_sources to extra_sources (Dmitry) > - Only destroy old solid_fill blob state if new state is valid (Pekka) > - Link to v4: > https://lore.kernel.org/r/20230404-solid-fill-v4-0-f4ec0caa7...@quicinc.com > > Changes in v4: > - Rebased onto latest kernel > - Reworded cover letter for clarity (Dmitry) > - Reworded commit messages for clarity > - Split existing changes into smaller commits > - Added pixel_source enum property (Dmitry, Pekka, Ville) > - Updated drm-kms comment docs with pixel_source and solid_fill > properties (Dmitry) > - Inlined drm_atomic_convert_solid_fill_info() (Dmitry) > - Passed in plane state alpha value to _dpu_plane_color_fill_pipe() > - Link to v3: > https://lore.kernel.org/r/20230104234036.636-1-quic_jessz...@quicinc.com > > Changes in v3: > - Fixed some logic errors in atomic checks (Dmitry) > - Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper > methods (Dmitry) > - Fixed typo in drm_solid_fi
Re: [Freedreno] [RFC PATCH v3 1/3] drm: Introduce solid fill property for drm plane
On 1/19/23 11:24, Jessica Zhang wrote:
>
>
> On 1/19/2023 7:57 AM, Harry Wentland wrote:
>>
>>
>> On 1/18/23 17:53, Jessica Zhang wrote:
>>>
>>>
>>> On 1/18/2023 10:57 AM, Harry Wentland wrote:
>>>> On 1/4/23 18:40, Jessica Zhang wrote:
>>>>> Add support for solid_fill property to drm_plane. In addition, add
>>>>> support for setting and getting the values for solid_fill.
>>>>>
>>>>> solid_fill holds data for supporting solid fill planes. The property
>>>>> accepts an RGB323232 value and the driver data is formatted as such:
>>>>>
>>>>> struct drm_solid_fill {
>>>>> u32 r;
>>>>> u32 g;
>>>>> u32 b;
>>>>> };
>>>>
>>>> Rather than special-casing this would it make sense to define this
>>>> as a single pixel of a FOURCC property?
>>>>
>>>> I.e., something like this:
>>>>
>>>> struct drm_solid_fill_info {
>>>> u32 format; /* FOURCC value */
>>>> u64 value; /* FOURCC pixel value */
>>>> }
>>>>
>>>> That removes some ambiguity how the value should be interpreted, i.e.,
>>>> it can be interpreted like a single pixel of the specified FOURCC format.
>>>>
>>>> It might also make sense to let drivers advertise the supported
>>>> FOURCC formats for solid_fill planes.
>>>
>>> Hi Harry,
>>>
>>> The initial v1 of this RFC had support for taking in a format and such, but
>>> it was decided that just supporting RGB323232 would work too.
>>>
>>> Here's the original thread discussing it [1], but to summarize, the work
>>> needed to convert the solid fill color to RGB is trivial (as it's just a
>>> single pixel of data). In addition, supporting various formats for
>>> solid_fill would add complexity as we'd have to communicate which formats
>>> are supported.
>>>
>>> [1]
>>> https://lists.freedesktop.org/archives/dri-devel/2022-November/379148.html
>>>
>>
>> Make sense, and thanks for summarizing.
>>
>> The only comment I would have left then, is that maybe it'd be good to add
>> an alpha value. I think it was suggested by someone else as well.
>
> Yep it was mentioned in the v1 discussion, but we came to the conclusion that
> user can set the alpha through the separate alpha plane property.
>
Got it.
Harry
> Thanks,
>
> Jessica Zhang
>
>>
>>>>
>>>> Is there an implementation for this in a corresponding canonical
>>>> upstream userspace project, to satisfy [1]? If not, what is the plan
>>>> for this? If so, please point to the corresponding patches.
>>>
>>> The use case we're trying to support here is the Android HWC SOLID_FILL
>>> hint [1], though it can also be used to address the Wayland single pixel FB
>>> protocol [2]. I'm also planning to add an IGT test to show an example of
>>> end to end usage.
>>>
>>> [1]
>>> https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/master/graphics/composer/aidl/android/hardware/graphics/composer3/Composition.aidl#52
>>>
>>> [2]
>>> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/104
>>>
>>
>> Makes sense.
>>
>> Harry
>>
>>> Thanks,
>>>
>>> Jessica Zhang
>>>
>>>>
>>>> [1]
>>>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>>>>
>>>> Harry
>>>>
>>>>>
>>>>> To enable solid fill planes, userspace must assigned solid_fill to a
>>>>> property blob containing the following information:
>>>>>
>>>>> struct drm_solid_fill_info {
>>>>> u8 version;
>>>>> u32 r, g, b;
>>>>> };
>>>>>
>>>>> Changes in V2:
>>>>> - Changed solid_fill property to a property blob (Simon, Dmitry)
>>>>> - Added drm_solid_fill struct (Simon)
>>>>> - Added drm_solid_fill_info struct (Simon)
>>>>>
>>>>> Changes in V3:
>>>>> - Corrected typo in drm_solid_fill struct documentation
>>>>>
>>>>> Signed-off-by: Jessica Zhang
>>>>> ---
>>>>> drivers/gpu/drm/drm_atomic_s
Re: [Freedreno] [RFC PATCH v3 1/3] drm: Introduce solid fill property for drm plane
On 1/18/23 17:53, Jessica Zhang wrote:
>
>
> On 1/18/2023 10:57 AM, Harry Wentland wrote:
>> On 1/4/23 18:40, Jessica Zhang wrote:
>>> Add support for solid_fill property to drm_plane. In addition, add
>>> support for setting and getting the values for solid_fill.
>>>
>>> solid_fill holds data for supporting solid fill planes. The property
>>> accepts an RGB323232 value and the driver data is formatted as such:
>>>
>>> struct drm_solid_fill {
>>> u32 r;
>>> u32 g;
>>> u32 b;
>>> };
>>
>> Rather than special-casing this would it make sense to define this
>> as a single pixel of a FOURCC property?
>>
>> I.e., something like this:
>>
>> struct drm_solid_fill_info {
>> u32 format; /* FOURCC value */
>> u64 value; /* FOURCC pixel value */
>> }
>>
>> That removes some ambiguity how the value should be interpreted, i.e.,
>> it can be interpreted like a single pixel of the specified FOURCC format.
>>
>> It might also make sense to let drivers advertise the supported
>> FOURCC formats for solid_fill planes.
>
> Hi Harry,
>
> The initial v1 of this RFC had support for taking in a format and such, but
> it was decided that just supporting RGB323232 would work too.
>
> Here's the original thread discussing it [1], but to summarize, the work
> needed to convert the solid fill color to RGB is trivial (as it's just a
> single pixel of data). In addition, supporting various formats for solid_fill
> would add complexity as we'd have to communicate which formats are supported.
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2022-November/379148.html
>
Make sense, and thanks for summarizing.
The only comment I would have left then, is that maybe it'd be good to add
an alpha value. I think it was suggested by someone else as well.
>>
>> Is there an implementation for this in a corresponding canonical
>> upstream userspace project, to satisfy [1]? If not, what is the plan
>> for this? If so, please point to the corresponding patches.
>
> The use case we're trying to support here is the Android HWC SOLID_FILL hint
> [1], though it can also be used to address the Wayland single pixel FB
> protocol [2]. I'm also planning to add an IGT test to show an example of end
> to end usage.
>
> [1]
> https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/master/graphics/composer/aidl/android/hardware/graphics/composer3/Composition.aidl#52
>
> [2]
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/104
>
Makes sense.
Harry
> Thanks,
>
> Jessica Zhang
>
>>
>> [1]
>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>>
>> Harry
>>
>>>
>>> To enable solid fill planes, userspace must assigned solid_fill to a
>>> property blob containing the following information:
>>>
>>> struct drm_solid_fill_info {
>>> u8 version;
>>> u32 r, g, b;
>>> };
>>>
>>> Changes in V2:
>>> - Changed solid_fill property to a property blob (Simon, Dmitry)
>>> - Added drm_solid_fill struct (Simon)
>>> - Added drm_solid_fill_info struct (Simon)
>>>
>>> Changes in V3:
>>> - Corrected typo in drm_solid_fill struct documentation
>>>
>>> Signed-off-by: Jessica Zhang
>>> ---
>>> drivers/gpu/drm/drm_atomic_state_helper.c | 9
>>> drivers/gpu/drm/drm_atomic_uapi.c | 59 +++
>>> drivers/gpu/drm/drm_blend.c | 17 +++
>>> include/drm/drm_blend.h | 1 +
>>> include/drm/drm_plane.h | 43 +
>>> 5 files changed, 129 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
>>> b/drivers/gpu/drm/drm_atomic_state_helper.c
>>> index dfb57217253b..c96fd1f2ad99 100644
>>> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
>>> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
>>> @@ -253,6 +253,11 @@ void __drm_atomic_helper_plane_state_reset(struct
>>> drm_plane_state *plane_state,
>>> plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
>>> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>>> + if (plane_state->solid_fill_blob) {
>>> + drm_property_blob_put(plane_state->solid_fill_blob);
>>> + plane_state->solid_fill_blob = NULL;
>>> + }
>>> +
>>>
Re: [Freedreno] [RFC PATCH v3 1/3] drm: Introduce solid fill property for drm plane
On 1/4/23 18:40, Jessica Zhang wrote:
> Add support for solid_fill property to drm_plane. In addition, add
> support for setting and getting the values for solid_fill.
>
> solid_fill holds data for supporting solid fill planes. The property
> accepts an RGB323232 value and the driver data is formatted as such:
>
> struct drm_solid_fill {
> u32 r;
> u32 g;
> u32 b;
> };
Rather than special-casing this would it make sense to define this
as a single pixel of a FOURCC property?
I.e., something like this:
struct drm_solid_fill_info {
u32 format; /* FOURCC value */
u64 value; /* FOURCC pixel value */
}
That removes some ambiguity how the value should be interpreted, i.e.,
it can be interpreted like a single pixel of the specified FOURCC format.
It might also make sense to let drivers advertise the supported
FOURCC formats for solid_fill planes.
Is there an implementation for this in a corresponding canonical
upstream userspace project, to satisfy [1]? If not, what is the plan
for this? If so, please point to the corresponding patches.
[1]
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
Harry
>
> To enable solid fill planes, userspace must assigned solid_fill to a
> property blob containing the following information:
>
> struct drm_solid_fill_info {
> u8 version;
> u32 r, g, b;
> };
>
> Changes in V2:
> - Changed solid_fill property to a property blob (Simon, Dmitry)
> - Added drm_solid_fill struct (Simon)
> - Added drm_solid_fill_info struct (Simon)
>
> Changes in V3:
> - Corrected typo in drm_solid_fill struct documentation
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 9
> drivers/gpu/drm/drm_atomic_uapi.c | 59 +++
> drivers/gpu/drm/drm_blend.c | 17 +++
> include/drm/drm_blend.h | 1 +
> include/drm/drm_plane.h | 43 +
> 5 files changed, 129 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index dfb57217253b..c96fd1f2ad99 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -253,6 +253,11 @@ void __drm_atomic_helper_plane_state_reset(struct
> drm_plane_state *plane_state,
> plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>
> + if (plane_state->solid_fill_blob) {
> + drm_property_blob_put(plane_state->solid_fill_blob);
> + plane_state->solid_fill_blob = NULL;
> + }
> +
> if (plane->color_encoding_property) {
> if (!drm_object_property_get_default_value(>base,
>
> plane->color_encoding_property,
> @@ -335,6 +340,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
> if (state->fb)
> drm_framebuffer_get(state->fb);
>
> + if (state->solid_fill_blob)
> + drm_property_blob_get(state->solid_fill_blob);
> +
> state->fence = NULL;
> state->commit = NULL;
> state->fb_damage_clips = NULL;
> @@ -384,6 +392,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
> drm_crtc_commit_put(state->commit);
>
> drm_property_blob_put(state->fb_damage_clips);
> + drm_property_blob_put(state->solid_fill_blob);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index c06d0639d552..8a1d2fb7a757 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -316,6 +316,55 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> }
> EXPORT_SYMBOL(drm_atomic_set_crtc_for_connector);
>
> +static void drm_atomic_convert_solid_fill_info(struct drm_solid_fill *out,
> + struct drm_solid_fill_info *in)
> +{
> + out->r = in->r;
> + out->g = in->g;
> + out->b = in->b;
> +}
> +
> +static int drm_atomic_set_solid_fill_prop(struct drm_plane_state *state,
> + struct drm_property_blob *blob)
> +{
> + int ret = 0;
> + int blob_version;
> +
> + if (blob == state->solid_fill_blob)
> + return 0;
> +
> + drm_property_blob_put(state->solid_fill_blob);
> + state->solid_fill_blob = NULL;
> +
> + memset(>solid_fill, 0, sizeof(state->solid_fill));
> +
> + if (blob) {
> + if (blob->length != sizeof(struct drm_solid_fill_info)) {
> + drm_dbg_atomic(state->plane->dev,
> + "[PLANE:%d:%s] bad solid fill blob
> length: %zu\n",
> + state->plane->base.id,
> state->plane->name,
> + blob->length);
>
Re: [Freedreno] [PATCH 02/15] drm/amdgpu: use drm_* functions instead of duplicated code in amdgpu driver
On 2021-10-15 07:37, Claudio Suarez wrote:
> a) Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. The amdgpu driver still calls
> drm_detect_hdmi_monitor() to retrieve the same information, which
> is less efficient. Change to drm_display_info.is_hdmi
>
> This is a TODO task in Documentation/gpu/todo.rst
>
> b) drm_display_info is updated by drm_get_edid() or
> drm_connector_update_edid_property(). In the amdgpu driver it is almost
> always updated when the edid is read in amdgpu_connector_get_edid(),
> but not always. Change amdgpu_connector_get_edid() and
> amdgpu_connector_free_edid() to keep drm_display_info updated. This allows a)
> to work properly.
>
> c) Use drm_edid_get_monitor_name() instead of duplicating the code that
> parses the EDID in dm_helpers_parse_edid_caps()
>
> Also, remove the unused "struct dc_context *ctx" parameter in
> dm_helpers_parse_edid_caps()
>
Thanks for this work.
The fact that you listed three separate changes in this commit
is a clear indication that this patch should be three separate
patches instead. Separating the functional bits from the straight
refactor will help with bisection if this leads to a regression.
All changes look reasonable to me, though. With this patch split
into three patches in the sequence (b), (c), then (a) this is
Reviewed-by: Harry Wentland
Harry
> Signed-off-by: Claudio Suarez
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +++
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.h| 2 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 4 +-
> .../gpu/drm/amd/amdgpu/atombios_encoders.c| 6 +--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 39 ++-
> drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
> drivers/gpu/drm/amd/display/dc/dm_helpers.h | 2 +-
> 9 files changed, 39 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index b9c11c2b2885..7b41a1120b70 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -25,6 +25,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -108,7 +109,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
> case DRM_MODE_CONNECTOR_DVII:
> case DRM_MODE_CONNECTOR_HDMIB:
> if (amdgpu_connector->use_digital) {
> - if
> (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
> if (connector->display_info.bpc)
> bpc = connector->display_info.bpc;
> }
> @@ -116,7 +117,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
> break;
> case DRM_MODE_CONNECTOR_DVID:
> case DRM_MODE_CONNECTOR_HDMIA:
> - if (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
> if (connector->display_info.bpc)
> bpc = connector->display_info.bpc;
> }
> @@ -125,7 +126,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
> dig_connector = amdgpu_connector->con_priv;
> if ((dig_connector->dp_sink_type ==
> CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
> (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP) ||
> - drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + (amdgpu_connector_is_hdmi_monitor(connector))) {
> if (connector->display_info.bpc)
> bpc = connector->display_info.bpc;
> }
> @@ -149,7 +150,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
> break;
> }
>
> - if (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
> /*
>* Pre DCE-8 hw can't handle > 12 bpc, and more than 12 bpc
> doesn't make
>* much sense without support for > 12 bpc framebuffers. RGB
> 4:4:4 at
> @@ -315,8 +316,10 @@ static void amdgpu_connector_get_edid(struct
> drm_connector *connector)
> if (!amdgpu
Re: [Freedreno] [PATCH 00/14] drm/hdcp: Pull HDCP auth/exchange/check into
On 2021-09-13 3:26 p.m., Sean Paul wrote: > On Mon, Sep 13, 2021 at 2:05 PM Alex Deucher wrote: >> >> On Mon, Sep 13, 2021 at 1:57 PM Sean Paul wrote: >>> >>> From: Sean Paul >>> >>> Hello, >>> This patchset pulls the HDCP protocol auth/exchange/check logic out from >>> i915 into a HDCP helper library which drivers can use to implement the >>> proper protocol and UAPI interactions for achieving HDCP. >>> >>> Originally this was all stuffed into i915 since it was the only driver >>> supporting HDCP. Over the last while I've been working on HDCP support >>> in the msm driver and have identified the parts which can/should be >>> shared between drivers and the parts which are hw-specific. >>> >>> We can generalize all of the sink interactions in the helper as well as >>> state handling and link checks. This tends to be the trickiest part of >>> adding HDCP support, since the property state and locking is a bit of a >>> nightmare. The driver need only implement the more mechanical display >>> controller register accesses. >>> >>> The first third of the pachset is establishing the helpers, the next >>> third is converting the i915 driver to use the helpers, and the last >>> third is the msm driver implementation. >>> >>> I've left out HDCP 2.x support, since we still only have i915 as the >>> reference implementation and I'm not super comfortable speculating on >>> which parts are platform independent. >> >> FWIW, amdgpu has support for both HDCP 1.x and 2.x >> > > Thanks Alex, I knew this and neglected to mention it, apologies for > the omission. > > IIRC amdgpu is much less hands-on than i915/msm, with PSP doing most > of the heavy lifting. There's probably some value in using the helpers > since it'll handle the state transitions in a consistent manner, do > you think this is something you can use? > We might be able to use drm_hdcp_atomic_check but the HDCP protocol stuff is sitting in our hdcp module and shared with other OSes so sharing it would be difficult. Harry > Sean > > >> Alex >> >>> >>> Please take a look, >>> >>> Sean >>> >>> Sean Paul (14): >>> drm/hdcp: Add drm_hdcp_atomic_check() >>> drm/hdcp: Avoid changing crtc state in hdcp atomic check >>> drm/hdcp: Update property value on content type and user changes >>> drm/hdcp: Expand HDCP helper library for enable/disable/check >>> drm/i915/hdcp: Consolidate HDCP setup/state cache >>> drm/i915/hdcp: Retain hdcp_capable return codes >>> drm/i915/hdcp: Use HDCP helpers for i915 >>> drm/msm/dpu_kms: Re-order dpu includes >>> drm/msm/dpu: Remove useless checks in dpu_encoder >>> drm/msm/dpu: Remove encoder->enable() hack >>> drm/msm/dp: Re-order dp_audio_put in deinit_sub_modules >>> dt-bindings: msm/dp: Add bindings for HDCP registers >>> drm/msm: Add hdcp register ranges to sc7180 device tree >>> drm/msm: Implement HDCP 1.x using the new drm HDCP helpers >>> >>> .../bindings/display/msm/dp-controller.yaml | 11 +- >>> drivers/gpu/drm/drm_hdcp.c| 1198 - >>> drivers/gpu/drm/i915/display/intel_atomic.c |7 +- >>> drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- >>> .../drm/i915/display/intel_display_debugfs.c | 11 +- >>> .../drm/i915/display/intel_display_types.h| 58 +- >>> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 341 ++--- >>> drivers/gpu/drm/i915/display/intel_dp_mst.c | 17 +- >>> drivers/gpu/drm/i915/display/intel_hdcp.c | 1011 +++--- >>> drivers/gpu/drm/i915/display/intel_hdcp.h | 35 +- >>> drivers/gpu/drm/i915/display/intel_hdmi.c | 256 ++-- >>> drivers/gpu/drm/msm/Makefile |1 + >>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 17 +- >>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 30 +- >>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |2 - >>> drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |4 - >>> drivers/gpu/drm/msm/dp/dp_debug.c | 49 +- >>> drivers/gpu/drm/msm/dp/dp_debug.h |6 +- >>> drivers/gpu/drm/msm/dp/dp_display.c | 47 +- >>> drivers/gpu/drm/msm/dp/dp_display.h |5 + >>> drivers/gpu/drm/msm/dp/dp_drm.c | 68 +- >>> drivers/gpu/drm/msm/dp/dp_drm.h |5 + >>> drivers/gpu/drm/msm/dp/dp_hdcp.c | 433 ++ >>> drivers/gpu/drm/msm/dp/dp_hdcp.h | 27 + >>> drivers/gpu/drm/msm/dp/dp_parser.c| 30 +- >>> drivers/gpu/drm/msm/dp/dp_parser.h|4 + >>> drivers/gpu/drm/msm/dp/dp_reg.h | 44 +- >>> drivers/gpu/drm/msm/msm_atomic.c | 15 + >>> include/drm/drm_hdcp.h| 194 +++ >>> 29 files changed, 2570 insertions(+), 1385 deletions(-) >>> create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c >>> create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h >>> >>> -- >>> Sean Paul, Software Engineer, Google / Chromium OS >>>
Re: [Freedreno] 2021 X.Org Foundation Election Candidates
Correction, we have 7 candidates for 4 positions. I seem to have overlooked Walter Harms's nomination email. My sincerest apologies. His personal affiliation, statement of contribution, and personal statement are below. The full slate of candidates can be found at https://wiki.freedesktop.org/xorg/BoardOfDirectors/Elections/2021/ ## Walter Harms __Current Affiliation:__ Scientist @ Bundesamt für Strahlenschutz __Statement of Contribution:__ I am involved into the open source since studying physics several years ago. I am also certified trainer for programmers. I contributed in the last years to projects like linux kernel, man pages, etc. Since a few years i have commit rights for X11 and did some work on libX11 and libXt. __Personal Statement:__ Since i started to become a trainer i have a predilection for documentation. Xorg has a lot good documentation but today is it less. NTL what is important is the application. I would like to see more training material and more X11 applications especially for remote access. But i was never involved in the xorg organisation. So i see myself more as an apprentice. We will see if i can help. Thanks, Harry Wentland, on behalf of the X.Org elections committee On 2021-03-15 2:47 p.m., Harry Wentland wrote: To all X.Org Foundation Members: The election for the X.Org Foundation Board of Directors will begin on 22 March 2021. We have 6 candidates who are running for 4 seats. They are (in alphabetical order): Samuel Iglesias Gonsálvez Manasi Navare Lyude Paul Rodrigo Siqueira Lucas Stach Daniel Vetter Attached below are the Personal Statements each candidate submitted for your consideration along with their Statements of Contribution that they submitted with the membership application. Please review each of the candidates' statements to help you decide whom to vote for during the upcoming election. If you have questions of the candidates, you should feel free to ask them here on the mailing list. The election committee will provide detailed instructions on how the voting system will work when the voting period begins. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Publication of Candidates & start of Candidate QA: Mon 15th March Deadline of X.Org membership application or renewal: Thu 18th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ** Nominees ** ## Samuel Iglesias Gonsálvez __Current Affiliation:__ Igalia __Personal Statement:__ I have been contributing to Mesa and piglit for 7 years improving open-source drivers for both OpenGL and Vulkan. During my time on the board, I have become the XDC organization coordinator and the XDC CFP committee chair, due to my experience organizing the XDC 2018 in A Coruña, Spain. Thanks to these experiences, I have been deeply involved in the XDC organization process, where I have helped make a great and welcoming conference every year. If I am elected, I plan to continue leading both the XDC organization process and the XDC CFP committee. ## Manasi Navare __Current Affiliation:__ Intel __Statement of contribution:__ I am a lead contributor to Intel’s Open source graphics kernel driver i915 as well as to the Linux Kernel DRM subsystem. One of my most widely used contributions is the Display Port Compliance code in i915, DRM as well as in Xserver and IGT to make the entire graphics stack Display Port compliant and reward the end users with black screen free displays. I have also enabled features like Display stream compression across DRM and i915 as per VESA’s DSC specification for Display Port. Most recently I have been working with both the DRM and i915 community as well as the AMD developers to implement and enable adaptive sync feature for variable refresh rate on display drivers for enhanced gaming experience. I also have commit rights to several upstream projects like drm-intel, drm-misc and Intel GPU Tools. I have served on X.org board of directors for last 2 years organizing XDC conferences, being on Code of Conduct committee for X.org and Freedesktop and taking over the treasurer responsibility since September 2020. __Personal Statement:__ I have been a Linux Open Source contributor for last 7 years since I joined Intel's Open source technology center. My major contributions are in enabling display interfaces and develop display features in upcoming display specifications in i915 and Linux DRM subsystem. I have presented several talks at Linux Graphics conferences like Embedded Linux Conference, XDC and FOSDEM on several graphics display features like Display Port compliance and Display Stream Compression, Tiled display support, Adaptive
[Freedreno] 2021 X.Org Foundation Election Candidates
To all X.Org Foundation Members: The election for the X.Org Foundation Board of Directors will begin on 22 March 2021. We have 6 candidates who are running for 4 seats. They are (in alphabetical order): Samuel Iglesias Gonsálvez Manasi Navare Lyude Paul Rodrigo Siqueira Lucas Stach Daniel Vetter Attached below are the Personal Statements each candidate submitted for your consideration along with their Statements of Contribution that they submitted with the membership application. Please review each of the candidates' statements to help you decide whom to vote for during the upcoming election. If you have questions of the candidates, you should feel free to ask them here on the mailing list. The election committee will provide detailed instructions on how the voting system will work when the voting period begins. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Publication of Candidates & start of Candidate QA: Mon 15th March Deadline of X.Org membership application or renewal: Thu 18th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ** Nominees ** ## Samuel Iglesias Gonsálvez __Current Affiliation:__ Igalia __Personal Statement:__ I have been contributing to Mesa and piglit for 7 years improving open-source drivers for both OpenGL and Vulkan. During my time on the board, I have become the XDC organization coordinator and the XDC CFP committee chair, due to my experience organizing the XDC 2018 in A Coruña, Spain. Thanks to these experiences, I have been deeply involved in the XDC organization process, where I have helped make a great and welcoming conference every year. If I am elected, I plan to continue leading both the XDC organization process and the XDC CFP committee. ## Manasi Navare __Current Affiliation:__ Intel __Statement of contribution:__ I am a lead contributor to Intel’s Open source graphics kernel driver i915 as well as to the Linux Kernel DRM subsystem. One of my most widely used contributions is the Display Port Compliance code in i915, DRM as well as in Xserver and IGT to make the entire graphics stack Display Port compliant and reward the end users with black screen free displays. I have also enabled features like Display stream compression across DRM and i915 as per VESA’s DSC specification for Display Port. Most recently I have been working with both the DRM and i915 community as well as the AMD developers to implement and enable adaptive sync feature for variable refresh rate on display drivers for enhanced gaming experience. I also have commit rights to several upstream projects like drm-intel, drm-misc and Intel GPU Tools. I have served on X.org board of directors for last 2 years organizing XDC conferences, being on Code of Conduct committee for X.org and Freedesktop and taking over the treasurer responsibility since September 2020. __Personal Statement:__ I have been a Linux Open Source contributor for last 7 years since I joined Intel's Open source technology center. My major contributions are in enabling display interfaces and develop display features in upcoming display specifications in i915 and Linux DRM subsystem. I have presented several talks at Linux Graphics conferences like Embedded Linux Conference, XDC and FOSDEM on several graphics display features like Display Port compliance and Display Stream Compression, Tiled display support, Adaptive Sync or Variable Refresh rate kernel support for gaming and I have been already actively involved in IRC discussions with DRM and i915 maintainers to constantly provide any solution on display port questions and work on improving the kernel documentation and code quality. I have served on the X.org board of directors since 2019 helping in XDC 2019 and XDC 2020 organization and for ensuring the Code of Conduct on the X.org community and during XDC events. I have previously mentored for the KMS project in Outreachy 2018 winter program as well as administered the Google summer of code 2019 program and will continue to do so whenever I get an opportunity. I joined the Code of Conduct Freedesktop committee as well to ensure it is followed on all the Freedesktop projects and open source channels. I have recently stepped up to take over the treasurer responsibility as part of the X.org board and working with all our sponsors to get the invoicing for the X.org events. If I get elected I would like to continue being a treasurer managing the XDC sponsorship and invoicing responsibilities as well as continue serving on the Code of conduct committee for X.org and Freedesktop. In addition to this I would like to help out on XDC event website organiza
[Freedreno] 2021 X.Org Foundation Membership renewal period extended to Mar 18
Due to some hickups with some of the early election emails and the large spike in membership registrations the elections committee decided to extend the membership deadline by one week to Mar 18, 2021. If you have not renewed your membership please do so by Thursday, Mar 18 at https://members.x.org. The nominated candidates will be announced on Sunday, allowing for a week of Candidate QA before the start of election on Mon Mar 22. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Publication of Candidates & start of Candidate QA: Mon 15th March Deadline of X.Org membership application or renewal: Thu 18th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
[Freedreno] 2021 X.Org Foundation Membership renewal ENDS on THURSDAY Mar 11
The nomination period for the 2021 X.Org Foundation Board of Directors Election closed yesterday and the election is rapidly approaching. We currently only see membership renewals for 59 people. If you have not renewed your membership please do so by Thursday, Mar 11 at https://members.x.org. The nominated candidates will be announced a week from yesterday. There were some hickups with our earlier emails and we realize some of you may have not received them. To ensure you receive this email we're BCCing any member that has been registered as a member in the last 2 years. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
[Freedreno] 2021 X.Org Board of Directions Nomination period ends next Sunday
Unfortunately my previous email seems to not have been received by many people. I will send this email separately to each mailing list to hopefully get better coverage. The nomination period is currently ongoing. So far we have received 3 nominations and will need at least 4 to fill the vacant spots on the board. We hope you will consider putting your nomination forward. To nominate yourself or someone else please send the nomination, along with a personal statement to elections at x dot org. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Cheers, Harry Wentland, on behalf of the X.Org elections committee ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
[Freedreno] 2021 X.Org Board of Directors Elections Nomination period is NOW
We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2021 election are now open and will remain open until Sunday, the 7th of March. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2020 were Eric Anholt, Mark Filion, Keith Packard, and Harry Wentland. They will continue to serve until their term ends in 2022. Current directors whose term expires in 2021 are Samuel Iglesias Gonsálvez, Manasi D Navare, Lyude Paul, and Daniel Vetter. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations must be received before the end of day on Sunday, the 7th of March. Membership applications or renewals and completed personal statements must be received no later than the end of day on Thursday, the 11tth of March. The slate of candidates will be published on Monday, the 15th of March and candidate Q will begin then. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Cheers, Harry Wentland, on behalf of the X.Org elections committee ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
[Freedreno] 2021 X.Org Foundation Membership renewal and election schedule
The 2021 X.Org Foundation elections are rapidly approaching. In preparation of the elections we would like to remind you that members will need to renew their membership each year in order to vote. Please take the time to renew your membership by logging into https://members.x.org and clicking on the "Apply" button to apply for the 2021-2022 membership. We would also like to encourage you to start considering yourself or someone else for nomination to the board. We will send another email to start the official nomination period when it opens. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RESEND 03/14] drm/amdgpu: Provide ddc symlink in dm connector's sysfs directory
On 2019-08-26 3:25 p.m., Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index cb7cfa9b34f2..e872a415b409 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5144,11 +5144,12 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
> connector_type = to_drm_connector_type(link->connector_signal);
>
> - res = drm_connector_init(
> + res = drm_connector_init_with_ddc(
> dm->ddev,
> >base,
> _dm_connector_funcs,
> - connector_type);
> + connector_type,
> + >base);
>
> if (res) {
> DRM_ERROR("connector_init failed\n");
>
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
