Re: [Intel-gfx] [PATCH] drm/i915/pxp: Hold RPM wakelock during PXP unbind
On Tue, 2021-12-21 at 07:09 -0800, Daniele Ceraolo Spurio wrote:
>
>
> On 12/20/2021 12:40 PM, Juston Li wrote:
> > Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock
> > during
> > PXP suspend") but to fix the same warning for unbind during
> > shutdown:
> >
> > [ cut here ]
> > RPM wakelock ref not held during HW access
> > WARNING: CPU: 0 PID: 4139 at
> > drivers/gpu/drm/i915/intel_runtime_pm.h:115
> > gen12_fwtable_write32+0x1b7/0
> > Modules linked in: 8021q ccm rfcomm cmac algif_hash algif_skcipher
> > af_alg uinput snd_hda_codec_hdmi vf industrialio iwl7000_mac80211
> > cros_ec_sensorhub lzo_rle lzo_compress zram iwlwifi cfg80211 joydev
> > CPU: 0 PID: 4139 Comm: halt Tainted: G U W
> > 5.10.84 #13 344e11e079c4a03940d949e537eab645f6
> > RIP: 0010:gen12_fwtable_write32+0x1b7/0x200
> > Code: 48 c7 c7 fc b3 b5 89 31 c0 e8 2c f3 ad ff 0f 0b e9 04 ff ff
> > ff c6
> > 05 71 e9 1d 01 01 48 c7 c7 d67
> > RSP: 0018:a09ec0bb3bb0 EFLAGS: 00010246
> > RAX: 12dde97bbd260300 RBX: 000320f0 RCX: 89e60ea0
> > RDX: RSI: dfff RDI: 89e60e70
> > RBP: a09ec0bb3bd8 R08: R09: a09ec0bb3950
> > R10: dfff R11: 89e91160 R12:
> > R13: 28121969 R14: 9515c32f0990 R15: 4000
> > FS: 790dcf225740() GS:95173780()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 58b25efae147 CR3: 000133ea6001 CR4: 00770ef0
> > DR0: DR1: DR2:
> > DR3: DR6: 07f0 DR7: 0400
> > PKRU: 5554
> > Call Trace:
> > intel_pxp_fini_hw+0x2f/0x39
> > i915_pxp_tee_component_unbind+0x1c/0x42
> > component_unbind+0x32/0x48
> > component_unbind_all+0x80/0x9d
> > take_down_master+0x24/0x36
> > component_master_del+0x56/0x70
> > mei_pxp_remove+0x2c/0x68
> > mei_cl_device_remove+0x35/0x68
> > device_release_driver_internal+0x100/0x1a1
> > mei_cl_bus_remove_device+0x21/0x79
> > mei_cl_bus_remove_devices+0x3b/0x51
> > mei_stop+0x3b/0xae
> > mei_me_shutdown+0x23/0x58
> > device_shutdown+0x144/0x1d3
> > kernel_power_off+0x13/0x4c
> > __se_sys_reboot+0x1d4/0x1e9
> > do_syscall_64+0x43/0x55
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x790dcf316273
> > Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
> > 44 00
> > 00 89 fa be 69 19 12 28 bf ad8
> > RSP: 002b:7ffca0df9198 EFLAGS: 0202 ORIG_RAX:
> > 00a9
> > RAX: ffda RBX: 4321fedc RCX: 790dcf316273
> > RDX: 4321fedc RSI: 28121969 RDI: fee1dead
> > RBP: 7ffca0df9200 R08: 0007 R09: 563ce8cd8970
> > R10: R11: 0202 R12: 7ffca0df9308
> > R13: 0001 R14: R15: 0003
> > ---[ end trace 2f501b01b348f114 ]---
> > ACPI: Preparing to enter system sleep state S5
> > reboot: Power down
> >
> > Fixes: 0cfab4cb3c4e ("drm/i915/pxp: Enable PXP power management")
> > Suggested-by: Lee Shawn C
> > Signed-off-by: Juston Li
>
> Reviewed-by: Daniele Ceraolo Spurio
>
> Can you send it to trybot
> (https://lists.freedesktop.org/mailman/listinfo/intel-gfx-trybot)
> with
> an added change to turn on the PXP config (see below), so we can get
> a
> CI run on it with PXP enabled?
Sent, thanks!
>
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -48,6 +48,8 @@ config DRM_I915_DEBUG
> select DRM_I915_DEBUG_RUNTIME_PM
> select DRM_I915_SW_FENCE_DEBUG_OBJECTS
> select DRM_I915_SELFTEST
> + select INTEL_MEI_PXP
> + select DRM_I915_PXP
> select BROKEN # for prototype uAPI
> default n
> help
>
> Thanks,
> Daniele
>
> > ---
> > drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > index 49508f31dcb7..d2980370d929 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > @@ -103,9 +103,12 @@ static int i915_pxp_tee_component_bind(struct
> > device *i915_kdev,
> > static void i915_pxp_tee_component_unbind(struct device
> > *i915_kdev,
> > struct device *tee_kdev,
> > void *data)
> > {
> > + struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
> > struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
> > + intel_wakeref_t wakeref;
> >
> > - intel_pxp_fini_hw(pxp);
> > + with_intel_runtime_pm_if_in_use(&i915->runtime_pm, wakeref)
> > + intel_pxp_fini_hw(pxp);
> >
> > mutex_lock(&pxp->tee_mutex);
> > pxp->pxp_component = NULL;
>
Re: [Intel-gfx] [PATCH 0/4] drm/i915: Clean up the pxp stuff
On Thu, 2021-10-07 at 02:57 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > I was just perusing skl_program_plane() when I stumbled on > this slightly iffy pxp stuff. Let's try to clean it up. > > Cc: Anshuman Gupta > Cc: Daniele Ceraolo Spurio > Cc: Juston Li > Cc: Rodrigo Vivi > Cc: Uma Shankar I've verifed this patchset on CrOS with TGL. Appreciate the clean up :) > Ville Syrjälä (4): > drm/i915: Move the pxp plane state computation > drm/i915: Fix up skl_program_plane() pxp stuff > drm/i915: Remove the drm_dbg() from the vblank evade critical > section > drm/i915: Rename intel_load_plane_csc_black() > > drivers/gpu/drm/i915/display/intel_display.c | 31 +-- > .../drm/i915/display/skl_universal_plane.c | 80 +++-- > -- > 2 files changed, 46 insertions(+), 65 deletions(-) >
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Rename intel_load_plane_csc_black()
On Thu, 2021-10-07 at 02:57 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_load_plane_csc_black() is specific to glk+ so deserves
> a name reflecting that fact. Also rename the variables to
> standard form so I won't get confused reading the code.
>
> Cc: Anshuman Gupta
> Cc: Daniele Ceraolo Spurio
> Cc: Juston Li
> Cc: Rodrigo Vivi
> Cc: Uma Shankar
> Signed-off-by: Ville Syrjälä
Reviewed-by: Juston Li
> ---
> .../drm/i915/display/skl_universal_plane.c | 35 +--
> 1 file changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 1e85ea98231f..709ab7166d88 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -1011,29 +1011,28 @@ static u32 skl_surf_address(const struct
> intel_plane_state *plane_state,
> }
> }
>
> -static void intel_load_plane_csc_black(struct intel_plane
> *intel_plane)
> +static void glk_plane_csc_load_black(struct intel_plane *plane)
> {
> - struct drm_i915_private *dev_priv = to_i915(intel_plane-
> >base.dev);
> - enum pipe pipe = intel_plane->pipe;
> - enum plane_id plane = intel_plane->id;
> - u16 postoff = 0;
> + struct drm_i915_private *i915 = to_i915(plane->base.dev);
> + enum plane_id plane_id = plane->id;
> + enum pipe pipe = plane->pipe;
>
> - intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0),
> 0);
> - intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1),
> 0);
> + intel_de_write_fw(i915, PLANE_CSC_COEFF(pipe, plane_id, 0), 0);
> + intel_de_write_fw(i915, PLANE_CSC_COEFF(pipe, plane_id, 1), 0);
>
> - intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2),
> 0);
> - intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3),
> 0);
> + intel_de_write_fw(i915, PLANE_CSC_COEFF(pipe, plane_id, 2), 0);
> + intel_de_write_fw(i915, PLANE_CSC_COEFF(pipe, plane_id, 3), 0);
>
> - intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4),
> 0);
> - intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5),
> 0);
> + intel_de_write_fw(i915, PLANE_CSC_COEFF(pipe, plane_id, 4), 0);
> + intel_de_write_fw(i915, PLANE_CSC_COEFF(pipe, plane_id, 5), 0);
>
> - intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0),
> 0);
> - intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1),
> 0);
> - intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2),
> 0);
> + intel_de_write_fw(i915, PLANE_CSC_PREOFF(pipe, plane_id, 0),
> 0);
> + intel_de_write_fw(i915, PLANE_CSC_PREOFF(pipe, plane_id, 1),
> 0);
> + intel_de_write_fw(i915, PLANE_CSC_PREOFF(pipe, plane_id, 2),
> 0);
>
> - intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 0),
> postoff);
> - intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 1),
> postoff);
> - intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 2),
> postoff);
> + intel_de_write_fw(i915, PLANE_CSC_POSTOFF(pipe, plane_id, 0),
> 0);
> + intel_de_write_fw(i915, PLANE_CSC_POSTOFF(pipe, plane_id, 1),
> 0);
> + intel_de_write_fw(i915, PLANE_CSC_POSTOFF(pipe, plane_id, 2),
> 0);
> }
>
> static void
> @@ -1102,7 +1101,7 @@ skl_program_plane(struct intel_plane *plane,
> * or after the commit, display content will be garbage.
> */
> if (plane_state->force_black)
> - intel_load_plane_csc_black(plane);
> + glk_plane_csc_load_black(plane);
>
> intel_de_write_fw(dev_priv, PLANE_STRIDE(pipe, plane_id),
> stride);
> intel_de_write_fw(dev_priv, PLANE_POS(pipe, plane_id),
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the drm_dbg() from the vblank evade critical section
On Thu, 2021-10-07 at 02:57 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We are inside the vblank evade critical section here, racing > against the raster beam. There is no time to print debug > messages. > > Cc: Anshuman Gupta > Cc: Daniele Ceraolo Spurio > Cc: Juston Li > Cc: Rodrigo Vivi > Cc: Uma Shankar > Signed-off-by: Ville Syrjälä Reviewed-by: Juston Li > --- > drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c > b/drivers/gpu/drm/i915/display/skl_universal_plane.c > index 55dae8c8fcad..1e85ea98231f 100644 > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c > @@ -1018,8 +1018,6 @@ static void intel_load_plane_csc_black(struct > intel_plane *intel_plane) > enum plane_id plane = intel_plane->id; > u16 postoff = 0; > > - drm_dbg_kms(&dev_priv->drm, "plane color CTM to black > %s:%d\n", > - intel_plane->base.name, plane); > intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0), > 0); > intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1), > 0); >
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move the pxp plane state computation
On Thu, 2021-10-07 at 02:57 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No real reason to have this pxp state computation in
> intel_atomic_check_planes(). Just stuff it into skl_plane_check().
>
> There was also some funny state copying being done from the
> old plane state to the new plane state when the plane is anyway
> disabled.
>
> The one thing we presumably must remember to do is copy
> over the decrypt state when assigning a Y plane for planar
> YCbCr scanout, so that the Y plane's PLANE_SURF will get the
> appropriate bit set. The force_black thing should not matter
> as I'm pretty sure all that stuff is ignored for the Y plane.
> I suppose this was the reason for the odd placement for the
> state computation, but I see no reason to deviate from the
> standard way of doing these things. This also guarantees
> that we don't calculate things differently between the
> linked UV and Y plane.
>
> Cc: Anshuman Gupta
> Cc: Daniele Ceraolo Spurio
> Cc: Juston Li
> Cc: Rodrigo Vivi
> Cc: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 31 +
> --
> .../drm/i915/display/skl_universal_plane.c | 15 +
> 2 files changed, 16 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4f0badb11bbb..bb45872cb619 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -71,8 +71,6 @@
> #include "gt/intel_rps.h"
> #include "gt/gen8_ppgtt.h"
>
> -#include "pxp/intel_pxp.h"
> -
> #include "g4x_dp.h"
> #include "g4x_hdmi.h"
> #include "i915_drv.h"
> @@ -6662,6 +6660,7 @@ static int icl_check_nv12_planes(struct
> intel_crtc_state *crtc_state)
> linked_state->ctl = plane_state->ctl |
> PLANE_CTL_YUV420_Y_PLANE;
> linked_state->color_ctl = plane_state->color_ctl;
> linked_state->view = plane_state->view;
> + linked_state->decrypt = plane_state->decrypt;
Ahh this was what we were missing before.
The computation was originally in skl_plane_check() but to get it
working I moved it to intel_atomic_check_planes() after
icl_check_nv12_planes() so that it would set that plane's decrypt flag
as well, not knowing I could just do this.
Reviewed-by: Juston Li
> intel_plane_copy_hw_state(linked_state, plane_state);
> linked_state->uapi.src = plane_state->uapi.src;
> @@ -9024,28 +9023,13 @@ static int
> intel_bigjoiner_add_affected_planes(struct intel_atomic_state *state)
> return 0;
> }
>
> -static bool bo_has_valid_encryption(struct drm_i915_gem_object *obj)
> -{
> - struct drm_i915_private *i915 = to_i915(obj->base.dev);
> -
> - return intel_pxp_key_check(&i915->gt.pxp, obj, false) == 0;
> -}
> -
> -static bool pxp_is_borked(struct drm_i915_gem_object *obj)
> -{
> - return i915_gem_object_is_protected(obj) &&
> !bo_has_valid_encryption(obj);
> -}
> -
> static int intel_atomic_check_planes(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> struct intel_plane_state *plane_state;
> struct intel_plane *plane;
> - struct intel_plane_state *new_plane_state;
> - struct intel_plane_state *old_plane_state;
> struct intel_crtc *crtc;
> - const struct drm_framebuffer *fb;
> int i, ret;
>
> ret = icl_add_linked_planes(state);
> @@ -9093,19 +9077,6 @@ static int intel_atomic_check_planes(struct
> intel_atomic_state *state)
> return ret;
> }
>
> - for_each_new_intel_plane_in_state(state, plane, plane_state, i)
> {
> - new_plane_state =
> intel_atomic_get_new_plane_state(state, plane);
> - old_plane_state =
> intel_atomic_get_old_plane_state(state, plane);
> - fb = new_plane_state->hw.fb;
> - if (fb) {
> - new_plane_state->decrypt =
> bo_has_valid_encryption(intel_fb_obj(fb));
> - new_plane_state->force_black =
> pxp_is_borked(intel_fb_obj(fb));
> - } else {
> - new_plane_state->decrypt = old_plane_state-
> >decrypt;
> - new_plane_state->force_black = old_plane_state-
> >force_black;
> - }
> - }
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index a0e53a3b267a..1fcb41942c7e 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -1737,6 +1737,18 @@ static bool skl_fb_scalable(const struct
> drm_framebuffer *fb)
> }
> }
>
> +static bool bo_has_valid_encryption(struct drm_i915
Re: [Intel-gfx] [PATCH v5 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
On Wed, 2021-08-18 at 11:51 +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Li, Juston
> > Sent: Friday, August 13, 2021 12:14 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: seanp...@chromium.org; Gupta, Anshuman <
> > anshuman.gu...@intel.com>;
> > C, Ramalingam ; Vivi, Rodrigo
> > ; Li, Juston
> > Subject: [Intel-gfx] [PATCH v5 3/3] drm/i915/hdcp: reuse rx_info
> > for mst stream
> > type1 capability check
> >
> > On some MST docking stations, rx_info can only be read after
> > RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
> > otherwise
> > the read will return -EIO.
> >
> > This behavior causes the mst stream type1 capability test to fail
> > to read rx_info
> > and determine if the topology supports type1 and fallback to type0.
> >
> > To fix this, check for type1 capability when we receive rx_info
> > within the AKE
> > flow when we read RepeaterAuth_Send_ReceiverID_List instead of an
> > explicit
> > read just for type1 capability checking.
> >
> > This does require moving where we set stream_types to after
> > hdcp2_authenticate_sink() when we get rx_info but this occurs
> > before we do
> > hdcp2_propagate_stream_management_info.
> >
> > Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check
> > for that as
> > well.
> >
> > Changes since v4:
> > - move topology_type1_capable to intel_digital_port and rename it
> > as
> > hdcp_mst_type1_capable (Anshuman)
> > - make a helper function intel_set_stream_types() to set stream
> > types
> > in hdcp2_authenticate_and_encrypt() (Anshuman)
> > - break on failure to set stream types and retry instead of
> > returning
> > - remove no longer used declaration for streams_type1_capable()
> >
> > Changes since v2:
> > - Remove no longer used variables in _intel_hdcp2_enable()
> >
> > Signed-off-by: Juston Li
> > Reviewed-by: Ramalingam C
> > ---
> > .../drm/i915/display/intel_display_types.h | 6 +-
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 64 +++
> >
> > 3 files changed, 38 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index dbdfe54d0340..1f85ff344ab7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -428,10 +428,6 @@ struct intel_hdcp_shim {
> > int (*hdcp_2_2_capable)(struct intel_digital_port *dig_port,
> > bool *capable);
> >
> > -/* Detects whether a HDCP 1.4 sink connected in MST topology */
> > -int (*streams_type1_capable)(struct intel_connector *connector,
> > - bool *capable);
> > -
> > /* Write HDCP2.2 messages */
> > int (*write_2_2_msg)(struct intel_digital_port *dig_port,
> > void *buf, size_t size);
> > @@ -1684,6 +1680,8 @@ struct intel_digital_port {
> > bool hdcp_auth_status;
> > /* HDCP port data need to pass to security f/w */
> > struct hdcp_port_data hdcp_port_data;
> > +/* Whether the MST topology supports HDCP Type 1 Content */
> > +bool hdcp_mst_type1_capable;
> >
> > void (*write_infoframe)(struct intel_encoder *encoder,
> > const struct intel_crtc_state *crtc_state, diff --
> > git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index fbfb3c4d16bb..540a669e01dd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -478,23 +478,6 @@ int intel_dp_hdcp2_write_msg(struct
> > intel_digital_port
> > *dig_port,
> > return size;
> > }
> >
> > -static int
> > -get_rxinfo_hdcp_1_dev_downstream(struct intel_digital_port
> > *dig_port, bool
> > *hdcp_1_x) -{
> > -u8 rx_info[HDCP_2_2_RXINFO_LEN];
> > -int ret;
> > -
> > -ret = drm_dp_dpcd_read(&dig_port->dp.aux,
> > - DP_HDCP_2_2_REG_RXINFO_OFFSET,
> > - (void *)rx_info, HDCP_2_2_RXINFO_LEN);
> > -
> > -if (ret != HDCP_2_2_RXINFO_LEN)
> > -return ret >= 0 ? -EIO : ret;
> > -
> > -*hdcp_1_x = HDCP_2_2_HDCP1_DEVICE_CONNECTED(rx_info[1]) ? true
> > : false;
> > -return 0;
> > -}
> > -
> > static
> > ssize_t get_receiver_id_list_rx_info(struct in
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
On Thu, 2021-08-12 at 12:40 +0530, Anshuman Gupta wrote:
> On 2021-08-11 at 14:23:14 -0700, Juston Li wrote:
> > On some MST docking stations, rx_info can only be read after
> > RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
> > otherwise the read will return -EIO.
> >
> > This behavior causes the mst stream type1 capability test to fail
> > to
> > read rx_info and determine if the topology supports type1 and
> > fallback
> > to type0.
> >
> > To fix this, check for type1 capability when we receive rx_info
> > within
> > the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead
> > of an explicit read just for type1 capability checking.
> >
> > This does require moving where we set stream_types to after
> > hdcp2_authenticate_sink() when we get rx_info but this occurs
> > before we
> > do hdcp2_propagate_stream_management_info.
> >
> > Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check
> > for
> > that as well.
> >
> > Changes since v2:
> > - Remove no longer used variables in _intel_hdcp2_enable()
> >
> > Signed-off-by: Juston Li
> > Reviewed-by: Ramalingam C
> > ---
> > .../drm/i915/display/intel_display_types.h | 2 +
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ---
> >
> > 3 files changed, 23 insertions(+), 67 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index dbdfe54d0340..c8b687ff0374 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -516,6 +516,8 @@ struct intel_hdcp {
> > enum transcoder cpu_transcoder;
> > /* Only used for DP MST stream encryption */
> > enum transcoder stream_transcoder;
> > +
> > + bool topology_type1_capable;
> Topology is not going to be change for each connector in mst
> topology.
> IMHO dig_port should contain this, prefix by mst as this is specific
> to mst usages.
Sure, will move to intel_digital_port and I settled on renaming it
hdcp_mst_type1_capable
> > };
> >
> > struct intel_connector {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index fbfb3c4d16bb..540a669e01dd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -478,23 +478,6 @@ int intel_dp_hdcp2_write_msg(struct
> > intel_digital_port *dig_port,
> > return size;
> > }
> >
> > -static int
> > -get_rxinfo_hdcp_1_dev_downstream(struct intel_digital_port
> > *dig_port, bool *hdcp_1_x)
> > -{
> > - u8 rx_info[HDCP_2_2_RXINFO_LEN];
> > - int ret;
> > -
> > - ret = drm_dp_dpcd_read(&dig_port->dp.aux,
> > - DP_HDCP_2_2_REG_RXINFO_OFFSET,
> > - (void *)rx_info,
> > HDCP_2_2_RXINFO_LEN);
> > -
> > - if (ret != HDCP_2_2_RXINFO_LEN)
> > - return ret >= 0 ? -EIO : ret;
> > -
> > - *hdcp_1_x = HDCP_2_2_HDCP1_DEVICE_CONNECTED(rx_info[1]) ?
> > true : false;
> > - return 0;
> > -}
> > -
> > static
> > ssize_t get_receiver_id_list_rx_info(struct intel_digital_port
> > *dig_port, u32 *dev_cnt, u8 *byte)
> > {
> > @@ -665,27 +648,6 @@ int intel_dp_hdcp2_capable(struct
> > intel_digital_port *dig_port,
> > return 0;
> > }
> >
> > -static
> > -int intel_dp_mst_streams_type1_capable(struct intel_connector
> > *connector,
> > - bool *capable)
> > -{
> > - struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > - struct drm_i915_private *i915 = to_i915(dig_port-
> > >base.base.dev);
> > - int ret;
> > - bool hdcp_1_x;
> > -
> > - ret = get_rxinfo_hdcp_1_dev_downstream(dig_port,
> > &hdcp_1_x);
> > - if (ret) {
> > - drm_dbg_kms(&i915->drm,
> > - "[%s:%d] failed to read RxInfo
> > ret=%d\n",
> > - connector->base.name, connector-
> > >base.base.id, ret);
> > - return ret;
> > - }
> > -
> > - *capable = !hdcp_1_x;
> > - return 0;
> > -}
> > -
> > static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
> > .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> > .read_bksv = intel_dp_hdcp_read_bksv,
> > @@ -834,7 +796,6 @@ static const struct intel_hdcp_shim
> > intel_dp_mst_hdcp_shim = {
> > .stream_2_2_encryption =
> > intel_dp_mst_hdcp2_stream_encryption,
> > .check_2_2_link = intel_dp_mst_hdcp2_check_link,
> > .hdcp_2_2_capable = intel_dp_hdcp2_capable,
> > - .streams_type1_capable =
> > intel_dp_mst_streams_type1_capable,
> > .protocol = HDCP_PROTOCOL_DP,
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
On Wed, 2021-08-11 at 15:34 -0400, Rodrigo Vivi wrote:
> On Tue, Aug 10, 2021 at 04:52:11PM -0700, Juston Li wrote:
> > When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by
> > itself
> > once to retrieve the DEVICE_COUNT to calculate the size of the
> > ReceiverID list then read a second time as a part of reading
> > ReceiverID
> > list.
> >
> > On some MST docking stations, RxInfo can only be read after the
> > RxStatus
> > READY bit is set otherwise the read will return -EIO. The spec
> > states that
> > the READY bit should be cleared as soon as RxInfo has been read.
> >
> > In this case, the first RxInfo read succeeds but after the READY
> > bit is
> > cleared, the second read fails.
> >
> > Fix it by reading RxInfo once and storing it before reading the
> > rest of
> > RepeaterAuth_Send_ReceiverID_List once we know the size.
> >
> > Modify get_receiver_id_list_size() to read and store RxInfo in the
> > message buffer and also parse DEVICE_COUNT so we know the size of
> > RepeaterAuth_Send_ReceiverID_List.
> >
> > Afterwards, retrieve the rest of the message at the offset for
> > seq_num_V.
> >
> > Changes in v4:
> > - rebase and edit commit message
> >
> > Changes in v3:
> > - remove comment
> >
> > Changes in v2:
> > - remove unnecessary moving of drm_i915_private from patch 1
> >
> > Signed-off-by: Juston Li
> > Acked-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 30 ++--
> >
> > include/drm/drm_dp_helper.h | 2 +-
> > 2 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index 1d0096654776..526fd58b9b51 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
> > intel_digital_port *dig_port, bool *hdcp
> > }
> >
> > static
> > -ssize_t get_receiver_id_list_size(struct intel_digital_port
> > *dig_port)
> > +ssize_t get_receiver_id_list_rx_info(struct intel_digital_port
> > *dig_port, u32 *dev_cnt, u8 *byte)
> > {
> > - u8 rx_info[HDCP_2_2_RXINFO_LEN];
> > - u32 dev_cnt;
> > ssize_t ret;
> > + u8 *rx_info = byte;
> >
> > ret = drm_dp_dpcd_read(&dig_port->dp.aux,
> > DP_HDCP_2_2_REG_RXINFO_OFFSET,
> > @@ -508,15 +507,11 @@ ssize_t get_receiver_id_list_size(struct
> > intel_digital_port *dig_port)
> > if (ret != HDCP_2_2_RXINFO_LEN)
> > return ret >= 0 ? -EIO : ret;
> >
> > - dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> > + *dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> > HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
> >
> > - if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
> > - dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
> > -
> > - ret = sizeof(struct hdcp2_rep_send_receiverid_list) -
> > - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
> > - (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> > + if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
> > + *dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
> >
> > return ret;
> > }
> > @@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct
> > intel_digital_port *dig_port,
> > const struct hdcp2_dp_msg_data *hdcp2_msg_data;
> > ktime_t msg_end = ktime_set(0, 0);
> > bool msg_expired;
> > + u32 dev_cnt;
> >
> > hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
> > if (!hdcp2_msg_data)
> > @@ -546,17 +542,21 @@ int intel_dp_hdcp2_read_msg(struct
> > intel_digital_port *dig_port,
> >
> > hdcp->cp_irq_count_cached = atomic_read(&hdcp-
> > >cp_irq_count);
> >
> > + /* DP adaptation msgs has no msg_id */
> > + byte++;
> > +
> > if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
> > - ret = get_receiver_id_list_size(dig_port);
> > + ret = get_receiver_id_list_rx_info(dig_port,
> > &dev_cnt, byte);
> > if (ret < 0)
> > return ret;
> >
> > - size = ret;
> > + byte += ret;
> > + size = sizeof(struct
> > hdcp2_rep_send_receiverid_list) -
> > + HDCP_2_2_RXINFO_LEN - HDCP_2_2_RECEIVER_IDS_MAX_LEN
> > +
> > + (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> > }
> > - bytes_to_recv = size - 1;
> >
> > - /* DP adaptation msgs has no msg_id */
> > - byte++;
> > + bytes_to_recv = size - 1;
> >
> > while (bytes_to_recv) {
> > len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
>
> I was about to merge to drm-intel-next but then I noticed this..
>
> So we need to cc Dave and Daniel here to get an ack from them.
>
> > index 3f2715eb965f..7476e7c6
Re: [Intel-gfx] [PATCH v9 14/19] drm/i915/hdcp: MST streams support in hdcp port_data
On Mon, 2021-01-11 at 13:41 +0530, Anshuman Gupta wrote:
> Add support for multiple mst stream in hdcp port data
> which will be used by RepeaterAuthStreamManage msg and
> HDCP 2.2 security f/w for m' validation.
>
> Security f/w doesn't have any provision to mark the stream_type
> for each stream separately, it just take single input of
> stream_type while authenticating the port and applies the
> same stream_type to all streams. So driver mark each stream_type
> with common highest supported content type for all streams
> in DP MST Topology.
>
> Security f/w supports RepeaterAuthStreamManage msg and m'
> validation only once during port authentication and encryption.
> Though it is not compulsory, security fw should support dynamic
> update of content_type and should support RepeaterAuthStreamManage
> msg and m' validation whenever required.
>
> v2:
> - Init the hdcp port data k for HDMI/DP SST stream.
> v3:
> - Cosmetic changes. [Uma]
> v4:
> - 's/port_auth/hdcp_port_auth'. [Ram]
> - Commit log improvement.
> v5:
> - Comment and commit log improvement. [Ram]
> v6:
> - Check first connector connected status before intel_encoder_is_mst
> to avoid any NULL pointer dereference.
>
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
> Reviewed-by: Ramalingam C
> Tested-by: Karthik B S
> Signed-off-by: Anshuman Gupta
> ---
> .../drm/i915/display/intel_display_types.h | 4 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 113 +++-
> --
> 2 files changed, 102 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b74c10c8b01c..b37a02a73de6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1502,10 +1502,12 @@ struct intel_digital_port {
> enum phy_fia tc_phy_fia;
> u8 tc_phy_fia_idx;
>
> - /* protects num_hdcp_streams reference count, hdcp_port_data
> */
> + /* protects num_hdcp_streams reference count, hdcp_port_data
> and hdcp_auth_status */
> struct mutex hdcp_mutex;
> /* the number of pipes using HDCP signalling out of this port
> */
> unsigned int num_hdcp_streams;
> + /* port HDCP auth status */
> + bool hdcp_auth_status;
> /* HDCP port data need to pass to security f/w */
> struct hdcp_port_data hdcp_port_data;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 2bec26123a05..bd87694def74 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -26,6 +26,74 @@
> #define KEY_LOAD_TRIES 5
> #define HDCP2_LC_RETRY_CNT 3
>
> +static int intel_conn_to_vcpi(struct intel_connector *connector)
> +{
> + /* For HDMI this is forced to be 0x0. For DP SST also this is
> 0x0. */
> + return connector->port ? connector->port->vcpi.vcpi : 0;
> +}
> +
> +/*
> + * intel_hdcp_required_content_stream selects the most highest
> common possible HDCP
> + * content_type for all streams in DP MST topology because security
> f/w doesn't
> + * have any provision to mark content_type for each stream
> separately, it marks
> + * all available streams with the content_type proivided at the time
> of port
> + * authentication. This may prohibit the userspace to use type1
> content on
> + * HDCP 2.2 capable sink because of other sink are not capable of
> HDCP 2.2 in
> + * DP MST topology. Though it is not compulsory, security fw should
> change its
> + * policy to mark different content_types for different streams.
> + */
> +static int
> +intel_hdcp_required_content_stream(struct intel_digital_port
> *dig_port)
> +{
> + struct drm_connector_list_iter conn_iter;
> + struct intel_digital_port *conn_dig_port;
> + struct intel_connector *connector;
> + struct drm_i915_private *i915 = to_i915(dig_port-
> >base.base.dev);
> + struct hdcp_port_data *data = &dig_port->hdcp_port_data;
> + bool enforce_type0 = false;
> + int k;
> +
> + if (dig_port->hdcp_auth_status)
> + return 0;
> +
> + drm_connector_list_iter_begin(&i915->drm, &conn_iter);
> + for_each_intel_connector_iter(connector, &conn_iter) {
> + if (connector->base.status ==
> connector_status_disconnected)
> + continue;
> +
> + if
> (!intel_encoder_is_mst(intel_attached_encoder(connector)))
> + continue;
> +
> + conn_dig_port = intel_attached_dig_port(connector);
> + if (conn_dig_port != dig_port)
> + continue;
> +
> + if (!enforce_type0 &&
> !intel_hdcp2_capable(connector))
> + enforce_type0 = true;
> +
> + data->streams[data->k].stream_id =
> intel_conn_to_vcpi(connector);
> + data->k++;
Re: [Intel-gfx] [PATCH v6 i-g-t 2/2] tests/kms_getfb: Add getfb2 tests
On Tue, 2020-02-11 at 13:22 -0800, Juston Li wrote:
> From: Daniel Stone
>
> Mirroring addfb2, add tests for the new ioctl which will return us
> information about framebuffers containing multiple buffers, as well
> as
> modifiers.
>
> Changes since v5:
> - Add documentation
>
> Changes since v4:
> - Remove unnecessary bo creation for getfb2-handle-closed subtest
>
> Changes since v3:
> - Add subtests to ensure handles aren't returned for non-root and
> non-master callers
>
> Changes since v1:
> - Add test that uses getfb2 output to call addfb2 as suggested by
> Ville
>
> Signed-off-by: Daniel Stone
> Signed-off-by: Juston Li
> Reviewed-by: Ville Syrjälä
Friendly nudge, can this be merged now?
Added documentation, passing BAT now.
Thanks
Juston
> ---
> tests/kms_getfb.c | 171
> ++
> 1 file changed, 171 insertions(+)
>
> diff --git a/tests/kms_getfb.c b/tests/kms_getfb.c
> index 292679ad3eb9..c3d3c93070cd 100644
> --- a/tests/kms_getfb.c
> +++ b/tests/kms_getfb.c
> @@ -40,6 +40,10 @@
> #include "drm.h"
> #include "drm_fourcc.h"
>
> +#include "igt_device.h"
> +
> +IGT_TEST_DESCRIPTION("Tests GETFB and GETFB2 ioctls.");
> +
> static bool has_getfb_iface(int fd)
> {
> struct drm_mode_fb_cmd arg = { };
> @@ -252,6 +256,167 @@ static void test_duplicate_handles(int fd)
> }
> }
>
> +static void test_getfb2(int fd)
> +{
> + struct drm_mode_fb_cmd2 add_basic = {};
> +
> + igt_fixture {
> + struct drm_mode_fb_cmd2 get = {};
> +
> + add_basic.width = 1024;
> + add_basic.height = 1024;
> + add_basic.pixel_format = DRM_FORMAT_XRGB;
> + add_basic.pitches[0] = 1024*4;
> + add_basic.handles[0] =
> igt_create_bo_with_dimensions(fd, 1024, 1024,
> + DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
> + igt_assert(add_basic.handles[0]);
> + do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, &add_basic);
> +
> + get.fb_id = add_basic.fb_id;
> + do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, &get);
> + igt_assert_neq_u32(get.handles[0], 0);
> + gem_close(fd, get.handles[0]);
> + }
> +
> + igt_describe("Tests error handling for a zero'd input.");
> + igt_subtest("getfb2-handle-zero") {
> + struct drm_mode_fb_cmd2 get = {};
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, &get, ENOENT);
> + }
> +
> + igt_describe("Tests error handling when passing a handle that "
> + "has been closed.");
> + igt_subtest("getfb2-handle-closed") {
> + struct drm_mode_fb_cmd2 add = add_basic;
> + struct drm_mode_fb_cmd2 get = { };
> +
> + do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, &add);
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB, &add.fb_id);
> +
> + get.fb_id = add.fb_id;
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, &get, ENOENT);
> + }
> +
> + igt_describe("Tests error handling when passing an invalid "
> + "handle.");
> + igt_subtest("getfb2-handle-not-fb") {
> + struct drm_mode_fb_cmd2 get = { .fb_id =
> get_any_prop_id(fd) };
> + igt_require(get.fb_id > 0);
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, &get, ENOENT);
> + }
> +
> + igt_describe("Tests outputs are correct when retrieving a "
> + "CCS framebuffer.");
> + igt_subtest("getfb2-accept-ccs") {
> + struct drm_mode_fb_cmd2 add_ccs = { };
> + struct drm_mode_fb_cmd2 get = { };
> + int i;
> +
> + get_ccs_fb(fd, &add_ccs);
> + igt_require(add_ccs.fb_id != 0);
> + get.fb_id = add_ccs.fb_id;
> + do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, &get);
> +
> + igt_assert_eq_u32(get.width, add_ccs.width);
> + igt_assert_eq_u32(get.height, add_ccs.height);
> + igt_assert(get.flags & DRM_MODE_FB_MODIFIERS);
> +
> + for (i = 0; i < ARRAY_SIZE(get.handles); i++) {
> + igt_assert_eq_u32(get.pitches[i],
> add_ccs.pitches[i]);
> + igt_assert_eq_u32(get.offsets[i],
> add_ccs.offsets[i]);
> + if (add_ccs.handles[i] != 0) {
> + igt_assert_neq_u32(get.handles[i], 0);
> + igt_assert_neq_u32(get.handles[i],
> +add_ccs.handles[i]);
> + igt_assert_eq_u64(get.modifier[i],
> + add_ccs.modifier[i]);
> + } else {
> + igt_assert_eq_u32(get.handles[i], 0);
> + igt_assert_eq_u64(get.modifier[i], 0);
> + }
> + }
> + igt_assert_eq_u32(get.handles[0], get.handles[1]);
> +
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB,
Re: [Intel-gfx] [PATCH v4 13.5/14] drm/i915: Print HDCP version info for all connectors
On Thu, 2020-02-27 at 13:56 -0500, Sean Paul wrote:
> From: Sean Paul
>
> De-duplicate the HDCP version code and print it for all connectors.
>
> Cc: Juston Li
> Signed-off-by: Sean Paul
>
> Changes in v4:
> - Added to the set
LGTM, thanks for adding this!
Reviewed-by: Juston Li
> ---
> .../drm/i915/display/intel_display_debugfs.c| 17 +
>
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 46954cc7b6c01..eb948a14cfd61 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -597,6 +597,11 @@ static void intel_hdcp_info(struct seq_file *m,
> {
> bool hdcp_cap, hdcp2_cap;
>
> + if (!intel_connector->hdcp.shim) {
> + seq_puts(m, "No Connector Support");
> + goto out;
> + }
> +
> hdcp_cap = intel_hdcp_capable(intel_connector);
> hdcp2_cap = intel_hdcp2_capable(intel_connector);
>
> @@ -608,6 +613,7 @@ static void intel_hdcp_info(struct seq_file *m,
> if (!hdcp_cap && !hdcp2_cap)
> seq_puts(m, "None");
>
> +out:
> seq_puts(m, "\n");
> }
>
> @@ -624,10 +630,6 @@ static void intel_dp_info(struct seq_file *m,
>
> drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp-
> >downstream_ports,
> &intel_dp->aux);
> - if (intel_connector->hdcp.shim) {
> - seq_puts(m, "\tHDCP version: ");
> - intel_hdcp_info(m, intel_connector);
> - }
> }
>
> static void intel_dp_mst_info(struct seq_file *m,
> @@ -651,10 +653,6 @@ static void intel_hdmi_info(struct seq_file *m,
> struct intel_hdmi *intel_hdmi =
> enc_to_intel_hdmi(intel_encoder);
>
> seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi-
> >has_audio));
> - if (intel_connector->hdcp.shim) {
> - seq_puts(m, "\tHDCP version: ");
> - intel_hdcp_info(m, intel_connector);
> - }
> }
>
> static void intel_lvds_info(struct seq_file *m,
> @@ -710,6 +708,9 @@ static void intel_connector_info(struct seq_file
> *m,
> break;
> }
>
> + seq_puts(m, "\tHDCP version: ");
> + intel_hdcp_info(m, intel_connector);
> +
> seq_printf(m, "\tmodes:\n");
> list_for_each_entry(mode, &connector->modes, head)
> intel_seq_print_mode(m, 2, mode);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 00/14] drm/i915: Add support for HDCP 1.4 over MST connectors
On Tue, 2020-02-18 at 17:02 -0500, Sean Paul wrote: > From: Sean Paul > > Hey all, > Back with a v4. Rebased on latest drm-tip. > > Biggest change was adding the QUERY_STREAM_ENCRYPTION_STATUS check > which > ensures not only the link to the first branch is encrypted, but also > that the channel iteself is also protected. > > Sean > nit, i915_display_info debugfs for intel_dp_mst_info() doesn't show "HDCP version: " Juston > Sean Paul (14): > drm/i915: Fix sha_text population code > drm/i915: Clear the repeater bit on HDCP disable > drm/i915: WARN if HDCP signalling is enabled upon disable > drm/i915: Intercept Aksv writes in the aux hooks > drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP > signalling > drm/i915: Factor out hdcp->value assignments > drm/i915: Protect workers against disappearing connectors > drm/i915: Don't fully disable HDCP on a port if multiple pipes are > using it > drm/i915: Support DP MST in enc_to_dig_port() function > drm/i915: Use ddi_update_pipe in intel_dp_mst > drm/i915: Factor out HDCP shim functions from dp for use by dp_mst > drm/i915: Add connector to hdcp_shim->check_link() > drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST > sideband > message > drm/i915: Add HDCP 1.4 support for MST connectors > > drivers/gpu/drm/drm_dp_mst_topology.c | 117 +++ > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/display/intel_ddi.c | 26 +- > drivers/gpu/drm/i915/display/intel_ddi.h | 2 + > .../drm/i915/display/intel_display_types.h| 30 +- > drivers/gpu/drm/i915/display/intel_dp.c | 620 +-- > drivers/gpu/drm/i915/display/intel_dp.h | 7 + > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 705 > ++ > drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 + > drivers/gpu/drm/i915/display/intel_hdcp.c | 199 +++-- > drivers/gpu/drm/i915/display/intel_hdmi.c | 23 +- > include/drm/drm_dp_helper.h | 3 + > include/drm/drm_dp_mst_helper.h | 44 ++ > include/drm/drm_hdcp.h| 3 + > 14 files changed, 1127 insertions(+), 668 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 i-g-t 2/2] tests/kms_getfb: Add getfb2 tests
On Wed, 2020-01-22 at 15:16 -0800, Juston Li wrote:
> From: Daniel Stone
>
> Mirroring addfb2, add tests for the new ioctl which will return us
> information about framebuffers containing multiple buffers, as well
> as
> modifiers.
>
> Changes since v4:
> - Remove unnecessary bo creation for getfb2-handle-closed subtest
>
> Changes since v3:
> - Add subtests to ensure handles aren't returned for non-root and
> non-master callers
>
> Changes since v1:
> - Add test that uses getfb2 output to call addfb2 as suggested by
> Ville
>
> Signed-off-by: Daniel Stone
> Signed-off-by: Juston Li
> Reviewed-by: Ville Syrjälä
> ---
> tests/kms_getfb.c | 156
> ++
> 1 file changed, 156 insertions(+)
>
> diff --git a/tests/kms_getfb.c b/tests/kms_getfb.c
> index 292679ad3eb9..e046a43a1555 100644
> --- a/tests/kms_getfb.c
> +++ b/tests/kms_getfb.c
> @@ -40,6 +40,8 @@
> #include "drm.h"
> #include "drm_fourcc.h"
>
> +#include "igt_device.h"
> +
> static bool has_getfb_iface(int fd)
> {
> struct drm_mode_fb_cmd arg = { };
> @@ -252,6 +254,154 @@ static void test_duplicate_handles(int fd)
> }
> }
>
> +static void test_getfb2(int fd)
> +{
> + struct drm_mode_fb_cmd2 add_basic = {};
> +
> + igt_fixture {
> + struct drm_mode_fb_cmd2 get = {};
> +
> + add_basic.width = 1024;
> + add_basic.height = 1024;
> + add_basic.pixel_format = DRM_FORMAT_XRGB;
> + add_basic.pitches[0] = 1024*4;
> + add_basic.handles[0] =
> igt_create_bo_with_dimensions(fd, 1024, 1024,
> + DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
> + igt_assert(add_basic.handles[0]);
> + do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, &add_basic);
> +
> + get.fb_id = add_basic.fb_id;
> + do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, &get);
> + igt_assert_neq_u32(get.handles[0], 0);
> + gem_close(fd, get.handles[0]);
> + }
> +
> + igt_subtest("getfb2-handle-zero") {
> + struct drm_mode_fb_cmd2 get = {};
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, &get, ENOENT);
> + }
> +
> + igt_subtest("getfb2-handle-closed") {
> + struct drm_mode_fb_cmd2 add = add_basic;
> + struct drm_mode_fb_cmd2 get = { };
> +
> + do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, &add);
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB, &add.fb_id);
> +
> + get.fb_id = add.fb_id;
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, &get, ENOENT);
> + }
> +
> + igt_subtest("getfb2-handle-not-fb") {
> + struct drm_mode_fb_cmd2 get = { .fb_id =
> get_any_prop_id(fd) };
> + igt_require(get.fb_id > 0);
> + do_ioctl_err(fd, DRM_IOCTL_MODE_GETFB2, &get, ENOENT);
> + }
> +
> + igt_subtest("getfb2-accept-ccs") {
> + struct drm_mode_fb_cmd2 add_ccs = { };
> + struct drm_mode_fb_cmd2 get = { };
> + int i;
> +
> + get_ccs_fb(fd, &add_ccs);
> + igt_require(add_ccs.fb_id != 0);
> + get.fb_id = add_ccs.fb_id;
> + do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, &get);
> +
> + igt_assert_eq_u32(get.width, add_ccs.width);
> + igt_assert_eq_u32(get.height, add_ccs.height);
> + igt_assert(get.flags & DRM_MODE_FB_MODIFIERS);
> +
> + for (i = 0; i < ARRAY_SIZE(get.handles); i++) {
> + igt_assert_eq_u32(get.pitches[i],
> add_ccs.pitches[i]);
> + igt_assert_eq_u32(get.offsets[i],
> add_ccs.offsets[i]);
> + if (add_ccs.handles[i] != 0) {
> + igt_assert_neq_u32(get.handles[i], 0);
> + igt_assert_neq_u32(get.handles[i],
> +add_ccs.handles[i]);
> + igt_assert_eq_u64(get.modifier[i],
> + add_ccs.modifier[i]);
> + } else {
> + igt_assert_eq_u32(get.handles[i], 0);
> + igt_assert_eq_u64(get.modifier[i], 0);
> + }
> + }
> + igt_assert_eq_u32(get.handles[0], get.handles[1]);
> +
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB, &get.fb_id);
> + gem_close(fd, add_ccs.handles[0]);
> + gem_close(fd, get.handles[0]);
> + }
> +
> + igt_subtest("getfb2-into-addfb2") {
> + struct drm_mode_fb_cmd2 cmd = { };
> +
> + cmd.fb_id = add_basic.fb_id;
> + do_ioctl(fd, DRM_IOCTL_MODE_GETFB2, &cmd);
> + do_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, &cmd);
> +
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB, &cmd.fb_id);
> + gem_close(fd, cmd.handles[0]);
> + }
> +
> + igt_fixture {
> + do_ioctl(fd, DRM_IOCTL_MODE_RMFB, &add_bas
Re: [Intel-gfx] [RESEND PATCH v2] drm: Add getfb2 ioctl
On Fri, 2019-12-13 at 23:36 +0200, Ville Syrjälä wrote:
> On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> > From: Daniel Stone
> >
> > getfb2 allows us to pass multiple planes and modifiers, just like
> > addfb2
> > over addfb.
> >
> > Changes since v1:
> > - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> > - update ioctl number
> >
> > Signed-off-by: Daniel Stone
> > Signed-off-by: Juston Li
> > ---
> > drivers/gpu/drm/drm_crtc_internal.h | 2 +
> > drivers/gpu/drm/drm_framebuffer.c | 110
> >
> > drivers/gpu/drm/drm_ioctl.c | 1 +
> > include/uapi/drm/drm.h | 2 +
> > 4 files changed, 115 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > b/drivers/gpu/drm/drm_crtc_internal.h
> > index c7d5e4c21423..16f2413403aa 100644
> > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > @@ -216,6 +216,8 @@ int drm_mode_rmfb_ioctl(struct drm_device *dev,
> > void *data, struct drm_file *file_priv);
> > int drm_mode_getfb(struct drm_device *dev,
> >void *data, struct drm_file *file_priv);
> > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > + void *data, struct drm_file *file_priv);
> > int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> >void *data, struct drm_file *file_priv);
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index 57564318ceea..6db54f177443 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -548,7 +549,116 @@ int drm_mode_getfb(struct drm_device *dev,
> >
> > out:
> > drm_framebuffer_put(fb);
> > + return ret;
> > +}
> > +
> > +/**
> > + * drm_mode_getfb2 - get extended FB info
> > + * @dev: drm device for the ioctl
> > + * @data: data pointer for the ioctl
> > + * @file_priv: drm file for the ioctl call
> > + *
> > + * Lookup the FB given its ID and return info about it.
> > + *
> > + * Called by the user via ioctl.
> > + *
> > + * Returns:
> > + * Zero on success, negative errno on failure.
> > + */
> > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > + void *data, struct drm_file *file_priv)
> > +{
> > + struct drm_mode_fb_cmd2 *r = data;
> > + struct drm_framebuffer *fb;
> > + unsigned int i;
> > + int ret;
> > +
> > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > + return -EINVAL;
> > +
> > + fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> > + if (!fb)
> > + return -ENOENT;
> > +
> > + /* For multi-plane framebuffers, we require the driver to place
> > the
> > +* GEM objects directly in the drm_framebuffer. For single-
> > plane
> > +* framebuffers, we can fall back to create_handle.
> > +*/
> > + if (!fb->obj[0] &&
> > + (fb->format->num_planes > 1 || !fb->funcs->create_handle))
> > {
> > + ret = -ENODEV;
> > + goto out;
> > + }
> > +
> > + r->height = fb->height;
> > + r->width = fb->width;
> > + r->pixel_format = fb->format->format;
> > +
> > + r->flags = 0;
> > + if (dev->mode_config.allow_fb_modifiers)
> > + r->flags |= DRM_MODE_FB_MODIFIERS;
> > +
> > + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> > + r->handles[i] = 0;
> > + r->pitches[i] = 0;
> > + r->offsets[i] = 0;
> > + r->modifier[i] = 0;
> > + }
> >
> > + for (i = 0; i < fb->format->num_planes; i++) {
> > + int j;
> > +
> > + r->pitches[i] = fb->pitches[i];
> > + r->offsets[i] = fb->offsets[i];
> > + if (dev->mode_config.allow_fb_modifiers)
> > + r->modifier[i] = fb->modifier;
> > +
> > + /* If we reuse the same object for multiple planes,
> > also
> > +* return the same handle.
> > +*/
> > + for (j = 0; j < i; j++) {
> > + if (fb->obj[i] == fb->obj[j]) {
> > + r->handles[i] = r->handles[j];
> > + break;
> > + }
> > + }
> > +
> > + if (r->handles[i])
> > + continue;
> > +
> > + if (fb->obj[i]) {
> > + ret = drm_gem_handle_create(file_priv, fb-
> > >obj[i],
> > + &r->handles[i]);
> > + } else {
> > + WARN_ON(i > 0);
> > + ret = fb->funcs->create_handle(fb, file_priv,
> > + &r->handles[i]);
> > + }
>
> getfb1 doesn't allow non-master/root to see the handles. Here we
> don't
> seem to have that same protection?
Hmm yeah sorry I missed the protections handling.
I think we can
Re: [Intel-gfx] [RESEND PATCH v2] drm: Add getfb2 ioctl
On Thu, 2019-11-21 at 10:28 +0100, Daniel Vetter wrote: > On Thu, Nov 21, 2019 at 9:26 AM Timo Aaltonen > wrote: > > On 9.10.2019 18.50, Daniel Vetter wrote: > > > On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote: > > > > From: Daniel Stone > > > > > > > > getfb2 allows us to pass multiple planes and modifiers, just > > > > like addfb2 > > > > over addfb. > > > > > > > > Changes since v1: > > > > - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID > > > > - update ioctl number > > > > > > > > Signed-off-by: Daniel Stone > > > > Signed-off-by: Juston Li > > > > > > Looks all good from a very quick glance (kernel, libdrm, igt), > > > but where's > > > the userspace? Link to weston/drm_hwc/whatever MR good enough. > > > -Daniel > > > > xserver too > > > > https://lists.x.org/archives/xorg-devel/2018-March/056363.html > > > > to fix > > > > https://gitlab.freedesktop.org/xorg/xserver/issues/33 > > > > which forces Ubuntu to disable CCS compression, and I'd like to get > > rid > > of that patch. > > > > Thanks Juston for pushing this! > > Acked-by: Daniel Vetter > > ... but someone needs to review all the patches and make sure kernel > patch + igt work and pass intel CI and then push it all, and given > the > pile of committers we have that's not me I think. Just in case people > expect me to push this forward, I only jumped in here to make sure > new > uapi is done by the book and checks all the boxes. > -Daniel Thanks for clarifying Daniel, I'll try to find someone to review. Juston ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH v2] drm: Add getfb2 ioctl
On Mon, 2019-10-14 at 19:51 +0200, Daniel Vetter wrote:
> On Mon, Oct 14, 2019 at 6:21 PM Li, Juston
> wrote:
> > On Wed, 2019-10-09 at 17:50 +0200, Daniel Vetter wrote:
> > > On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> > > > From: Daniel Stone
> > > >
> > > > getfb2 allows us to pass multiple planes and modifiers, just
> > > > like
> > > > addfb2
> > > > over addfb.
> > > >
> > > > Changes since v1:
> > > > - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> > > > - update ioctl number
> > > >
> > > > Signed-off-by: Daniel Stone
> > > > Signed-off-by: Juston Li
> > >
> > > Looks all good from a very quick glance (kernel, libdrm, igt),
> > > but
> > > where's
> > > the userspace? Link to weston/drm_hwc/whatever MR good enough.
> > > -Daniel
> >
> > My use case is a screenshot utility in chromiuomos that breaks with
> > y-
> > tiled ccs enabled.
> > Review linked is just WIP hack for now since it depends on this
> > merging:
> > https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1815146
>
> Adding Sean & Daniele to confirm this is real cros.
> -Daniel
+Mark, who I've been talking about enabling render buffer compression.
This patch allows me to fix a regression w/ screenshot utility when
enabling RBC:
https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1759155
Thanks
Juston
> > > > ---
> > > > drivers/gpu/drm/drm_crtc_internal.h | 2 +
> > > > drivers/gpu/drm/drm_framebuffer.c | 110
> > > >
> > > > drivers/gpu/drm/drm_ioctl.c | 1 +
> > > > include/uapi/drm/drm.h | 2 +
> > > > 4 files changed, 115 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > > > b/drivers/gpu/drm/drm_crtc_internal.h
> > > > index c7d5e4c21423..16f2413403aa 100644
> > > > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > > > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > > > @@ -216,6 +216,8 @@ int drm_mode_rmfb_ioctl(struct drm_device
> > > > *dev,
> > > > void *data, struct drm_file *file_priv);
> > > > int drm_mode_getfb(struct drm_device *dev,
> > > >void *data, struct drm_file *file_priv);
> > > > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > > > + void *data, struct drm_file *file_priv);
> > > > int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> > > >void *data, struct drm_file *file_priv);
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > > > b/drivers/gpu/drm/drm_framebuffer.c
> > > > index 57564318ceea..6db54f177443 100644
> > > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > > @@ -31,6 +31,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > >
> > > > @@ -548,7 +549,116 @@ int drm_mode_getfb(struct drm_device
> > > > *dev,
> > > >
> > > > out:
> > > > drm_framebuffer_put(fb);
> > > > + return ret;
> > > > +}
> > > > +
> > > > +/**
> > > > + * drm_mode_getfb2 - get extended FB info
> > > > + * @dev: drm device for the ioctl
> > > > + * @data: data pointer for the ioctl
> > > > + * @file_priv: drm file for the ioctl call
> > > > + *
> > > > + * Lookup the FB given its ID and return info about it.
> > > > + *
> > > > + * Called by the user via ioctl.
> > > > + *
> > > > + * Returns:
> > > > + * Zero on success, negative errno on failure.
> > > > + */
> > > > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > > > + void *data, struct drm_file *file_priv)
> > > > +{
> > > > + struct drm_mode_fb_cmd2 *r = data;
> > > > + struct drm_framebuffer *fb;
> > > > + unsigned int i;
> > > > + int ret;
> > > > +
> > > > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > > + return -EINVAL;
> >
Re: [Intel-gfx] [PATCH i-g-t v2 2/2] NOMERGE: Import drm.h up to 54ecb8f7028c
On Wed, 2019-10-09 at 17:49 +0200, Daniel Vetter wrote:
> On Thu, Oct 03, 2019 at 11:46:28AM -0700, Juston Li wrote:
> > Depends on ummerged kernel code for getfb2
> >
> > Rest of drm.h taken from:
> > commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
> > Author: Linus Torvalds
> > Date: Mon Sep 30 10:35:40 2019 -0700
> >
> > Linux 5.4-rc1
> >
> > Signed-off-by: Juston Li
>
> I guess this should be first, then the patch that uses it?
> -Daniel
Yes, apologies. I'll swap the order around.
Thanks
Juston
> > ---
> > include/drm-uapi/drm.h | 39
> > +++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
> > index 85c685a2075e..0b02f4c92d1e 100644
> > --- a/include/drm-uapi/drm.h
> > +++ b/include/drm-uapi/drm.h
> > @@ -643,6 +643,7 @@ struct drm_gem_open {
> > #define DRM_CAP_PAGE_FLIP_TARGET 0x11
> > #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
> > #define DRM_CAP_SYNCOBJ0x13
> > +#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
> >
> > /** DRM_IOCTL_GET_CAP ioctl argument type */
> > struct drm_get_cap {
> > @@ -729,8 +730,18 @@ struct drm_syncobj_handle {
> > __u32 pad;
> > };
> >
> > +struct drm_syncobj_transfer {
> > + __u32 src_handle;
> > + __u32 dst_handle;
> > + __u64 src_point;
> > + __u64 dst_point;
> > + __u32 flags;
> > + __u32 pad;
> > +};
> > +
> > #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
> > #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
> > +#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for
> > time point to become available */
> > struct drm_syncobj_wait {
> > __u64 handles;
> > /* absolute timeout */
> > @@ -741,12 +752,33 @@ struct drm_syncobj_wait {
> > __u32 pad;
> > };
> >
> > +struct drm_syncobj_timeline_wait {
> > + __u64 handles;
> > + /* wait on specific timeline point for every handles*/
> > + __u64 points;
> > + /* absolute timeout */
> > + __s64 timeout_nsec;
> > + __u32 count_handles;
> > + __u32 flags;
> > + __u32 first_signaled; /* only valid when not waiting all */
> > + __u32 pad;
> > +};
> > +
> > +
> > struct drm_syncobj_array {
> > __u64 handles;
> > __u32 count_handles;
> > __u32 pad;
> > };
> >
> > +struct drm_syncobj_timeline_array {
> > + __u64 handles;
> > + __u64 points;
> > + __u32 count_handles;
> > + __u32 pad;
> > +};
> > +
> > +
> > /* Query current scanout sequence number */
> > struct drm_crtc_get_sequence {
> > __u32 crtc_id; /* requested crtc_id */
> > @@ -903,6 +935,13 @@ extern "C" {
> > #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
> > drm_mode_get_lease)
> > #define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
> > drm_mode_revoke_lease)
> >
> > +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
> > drm_syncobj_timeline_wait)
> > +#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
> > drm_syncobj_timeline_array)
> > +#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
> > drm_syncobj_transfer)
> > +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
> > drm_syncobj_timeline_array)
> > +
> > +#define DRM_IOCTL_MODE_GETFB2 DRM_IOWR(0xCE, struct
> > drm_mode_fb_cmd2)
> > +
> > /**
> > * Device specific ioctls should only be in their respective
> > headers
> > * The device specific ioctl range is from 0x40 to 0x9f.
> > --
> > 2.21.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH v2] drm: Add getfb2 ioctl
On Wed, 2019-10-09 at 17:50 +0200, Daniel Vetter wrote:
> On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> > From: Daniel Stone
> >
> > getfb2 allows us to pass multiple planes and modifiers, just like
> > addfb2
> > over addfb.
> >
> > Changes since v1:
> > - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> > - update ioctl number
> >
> > Signed-off-by: Daniel Stone
> > Signed-off-by: Juston Li
>
> Looks all good from a very quick glance (kernel, libdrm, igt), but
> where's
> the userspace? Link to weston/drm_hwc/whatever MR good enough.
> -Daniel
My use case is a screenshot utility in chromiuomos that breaks with y-
tiled ccs enabled.
Review linked is just WIP hack for now since it depends on this
merging:
https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1815146
Thanks
Juston
> > ---
> > drivers/gpu/drm/drm_crtc_internal.h | 2 +
> > drivers/gpu/drm/drm_framebuffer.c | 110
> >
> > drivers/gpu/drm/drm_ioctl.c | 1 +
> > include/uapi/drm/drm.h | 2 +
> > 4 files changed, 115 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > b/drivers/gpu/drm/drm_crtc_internal.h
> > index c7d5e4c21423..16f2413403aa 100644
> > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > @@ -216,6 +216,8 @@ int drm_mode_rmfb_ioctl(struct drm_device *dev,
> > void *data, struct drm_file *file_priv);
> > int drm_mode_getfb(struct drm_device *dev,
> >void *data, struct drm_file *file_priv);
> > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > + void *data, struct drm_file *file_priv);
> > int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> >void *data, struct drm_file *file_priv);
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index 57564318ceea..6db54f177443 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -548,7 +549,116 @@ int drm_mode_getfb(struct drm_device *dev,
> >
> > out:
> > drm_framebuffer_put(fb);
> > + return ret;
> > +}
> > +
> > +/**
> > + * drm_mode_getfb2 - get extended FB info
> > + * @dev: drm device for the ioctl
> > + * @data: data pointer for the ioctl
> > + * @file_priv: drm file for the ioctl call
> > + *
> > + * Lookup the FB given its ID and return info about it.
> > + *
> > + * Called by the user via ioctl.
> > + *
> > + * Returns:
> > + * Zero on success, negative errno on failure.
> > + */
> > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > + void *data, struct drm_file *file_priv)
> > +{
> > + struct drm_mode_fb_cmd2 *r = data;
> > + struct drm_framebuffer *fb;
> > + unsigned int i;
> > + int ret;
> > +
> > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > + return -EINVAL;
> > +
> > + fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> > + if (!fb)
> > + return -ENOENT;
> > +
> > + /* For multi-plane framebuffers, we require the driver to place
> > the
> > +* GEM objects directly in the drm_framebuffer. For single-
> > plane
> > +* framebuffers, we can fall back to create_handle.
> > +*/
> > + if (!fb->obj[0] &&
> > + (fb->format->num_planes > 1 || !fb->funcs->create_handle))
> > {
> > + ret = -ENODEV;
> > + goto out;
> > + }
> > +
> > + r->height = fb->height;
> > + r->width = fb->width;
> > + r->pixel_format = fb->format->format;
> > +
> > + r->flags = 0;
> > + if (dev->mode_config.allow_fb_modifiers)
> > + r->flags |= DRM_MODE_FB_MODIFIERS;
> > +
> > + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> > + r->handles[i] = 0;
> > + r->pitches[i] = 0;
> > + r->offsets[i] = 0;
> > + r->modifier[i] = 0;
> > + }
> >
> > + for (i = 0; i < fb->format->num_planes; i++) {
> > + int j;
> > +
> > + r->pitches[i] = fb->pitches[i];
> > + r->offsets[i] = fb->offsets[i];
> > + if (dev->mode_config.allow_fb_modifiers)
> > + r->modifier[i] = fb->modifier;
> > +
> > + /* If we reuse the same object for multiple planes,
> > also
> > +* return the same handle.
> > +*/
> > + for (j = 0; j < i; j++) {
> > + if (fb->obj[i] == fb->obj[j]) {
> > + r->handles[i] = r->handles[j];
> > + break;
> > + }
> > + }
> > +
> > + if (r->handles[i])
> > + continue;
> > +
> > + if (fb->obj[i]) {
> > + ret = drm_gem_handle_create(file_priv, fb-
> > >obj[i],
> > + &r->handles[
Re: [Intel-gfx] [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume
Sorry for the late reply, email got caught in a bad filter =/ I haven't been looking into it lately but we are still interested in getting this fixed so I can start looking into this again. In your last email you mentioned a sysfs hotplug could be the way to go? Thanks Juston On Thu, 2018-11-08 at 19:43 -0500, Lyude Paul wrote: > Are you still looking into this at all? Even if it's not the right > approach > I'm still interested in seeing this get fixed as well/discussing what > I said > before > > On Wed, 2018-10-24 at 22:45 +, Li, Juston wrote: > > On Wed, 2018-10-24 at 18:09 -0400, Lyude Paul wrote: > > > Since there's going to be quite a number of changes I need to > > > make to > > > this I'm > > > just going to make the changes myself! I'll make sure to Cc you > > > with > > > the > > > respin > > > > Sounds good, thanks for picking it up! > > > > Juston > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume
On Wed, 2018-10-24 at 18:09 -0400, Lyude Paul wrote: > Since there's going to be quite a number of changes I need to make to > this I'm > just going to make the changes myself! I'll make sure to Cc you with > the > respin Sounds good, thanks for picking it up! Juston ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH v2 0/2] Check MST topology change on resume
On Wed, 2018-10-24 at 10:57 +0200, Daniel Vetter wrote: > On Tue, Oct 23, 2018 at 07:19:23PM -0700, Juston Li wrote: > > > > Signed-off-by: Juston Li > > For formality, does this also imply a reviewed-by tag? I'm quite new to drm so I'll withhold a reviewed-by tag and ask that someone else take a look at it too. Lyude, the original author, mentioned he should probably take a look again also since the patchset is a bit old. > For merging propably best we wait for the backmerge and the push > these in > through drm-misc-next-fixes. > > Well for drm-misc-next-fixes drm-misc maintainers need to roll the > tree > forward. Either way needs synchronization. Plus an ack from drm-intel > maintainers. > -Daniel > Will do Thanks Juston ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
