Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List

2021-08-11 Thread Li, Juston
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(_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(
> > >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,
> > _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..7476e7c6d0be 100644
> 

Re: [PATCH v9 14/19] drm/i915/hdcp: MST streams support in hdcp port_data

2021-01-11 Thread Li, Juston
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 = _port->hdcp_port_data;
> +   bool enforce_type0 = false;
> +   int k;
> +
> +   if (dig_port->hdcp_auth_status)
> +   return 0;
> +
> +   drm_connector_list_iter_begin(>drm, _iter);
> +   for_each_intel_connector_iter(connector, _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: [PATCH v4 13.5/14] drm/i915: Print HDCP version info for all connectors

2020-02-27 Thread Li, Juston
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,
>   _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, >modes, head)
>   intel_seq_print_mode(m, 2, mode);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 00/14] drm/i915: Add support for HDCP 1.4 over MST connectors

2020-02-21 Thread Li, Juston
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
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 libdrm 2/2] Add drmModeGetFB2

2020-02-06 Thread Li, Juston
On Wed, 2020-02-05 at 23:27 +, Eric Engestrom wrote:
> On Wednesday, 2020-02-05 23:10:21 +0000, Li, Juston wrote:
> > On Wed, 2020-02-05 at 22:25 +, Eric Engestrom wrote:
> > > On Friday, 2020-01-31 13:41:09 -0800, Juston Li wrote:
> > > > From: Daniel Stone 
> > > > 
> > > > Add a wrapper around the getfb2 ioctl, which returns extended
> > > > framebuffer information mirroring addfb2, including multiple
> > > > planes
> > > > and
> > > > modifiers.
> > > > 
> > > > Changes since v3:
> > > >  - remove unnecessary null check in drmModeFreeFB2 (Daniel
> > > > Stone)
> > > > 
> > > > Changes since v2:
> > > >  - getfb2 ioctl has been merged upstream
> > > >  - sync include/drm/drm.h in a seperate patch
> > > > 
> > > > Changes since v1:
> > > >  - functions should be drm_public
> > > >  - modifier should be 64 bits
> > > >  - update ioctl number
> > > > 
> > > > Signed-off-by: Juston Li 
> > > > Signed-off-by: Daniel Stone 
> > > > ---
> > > >  xf86drmMode.c | 36 
> > > >  xf86drmMode.h | 15 +++
> > > >  2 files changed, 51 insertions(+)
> > > > 
> > > > diff --git a/xf86drmMode.c b/xf86drmMode.c
> > > > index 0cf7992c6e9a..94dc8ce38a5e 100644
> > > > --- a/xf86drmMode.c
> > > > +++ b/xf86drmMode.c
> > > > @@ -1594,3 +1594,39 @@ drmModeRevokeLease(int fd, uint32_t
> > > > lessee_id)
> > > >  return 0;
> > > >  return -errno;
> > > >  }
> > > > +
> > > > +drm_public drmModeFB2Ptr
> > > > +drmModeGetFB2(int fd, uint32_t fb_id)
> > > > +{
> > > > +struct drm_mode_fb_cmd2 get;
> > > > +drmModeFB2Ptr ret;
> > > > +int err;
> > > > +
> > > > +memclear(get);
> > > > +get.fb_id = fb_id;
> > > 
> > > As mentioned on IRC, could you write it like this instead?
> > > 
> > > struct drm_mode_fb_cmd2 get = {
> > > .fb_id = fb_id,
> > > };
> > > 
> > > With that, consider this patch
> > > Reviewed-by: Eric Engestrom 
> > 
> > Opps I sent v5 before seeing this but my code style differs and is
> > probably incorrect :) I'll send v6 with the style corrected.
> > 
> > Thanks for reviewing!
> 
> Ah, sorry about that, our emails crossed paths.
> 
> As for the other patch (I mean 1/2), did you follow the instructions
> in
> include/drm/README, specifically the section titled "When and how to
> update these files" ?
> Your commit message makes it look like you just applied that one
> change
> instead of syncing with `make headers_install`.
> 
> Cheers,
>   Eric

Yes, drm.h was copied from 'make headers_install' from drm-misc-next.
It had been updated fairly recently so GETFB2 is the only delta.

Sorry, I didn't see the README so the commit message isn't exactly as
requested.


Also, only drm.h was synced, is that preferred or would it be better to
sync the entire header directory?

Thanks
Juston
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 libdrm 2/2] Add drmModeGetFB2

2020-02-05 Thread Li, Juston
On Wed, 2020-02-05 at 22:25 +, Eric Engestrom wrote:
> On Friday, 2020-01-31 13:41:09 -0800, Juston Li wrote:
> > From: Daniel Stone 
> > 
> > Add a wrapper around the getfb2 ioctl, which returns extended
> > framebuffer information mirroring addfb2, including multiple planes
> > and
> > modifiers.
> > 
> > Changes since v3:
> >  - remove unnecessary null check in drmModeFreeFB2 (Daniel Stone)
> > 
> > Changes since v2:
> >  - getfb2 ioctl has been merged upstream
> >  - sync include/drm/drm.h in a seperate patch
> > 
> > Changes since v1:
> >  - functions should be drm_public
> >  - modifier should be 64 bits
> >  - update ioctl number
> > 
> > Signed-off-by: Juston Li 
> > Signed-off-by: Daniel Stone 
> > ---
> >  xf86drmMode.c | 36 
> >  xf86drmMode.h | 15 +++
> >  2 files changed, 51 insertions(+)
> > 
> > diff --git a/xf86drmMode.c b/xf86drmMode.c
> > index 0cf7992c6e9a..94dc8ce38a5e 100644
> > --- a/xf86drmMode.c
> > +++ b/xf86drmMode.c
> > @@ -1594,3 +1594,39 @@ drmModeRevokeLease(int fd, uint32_t
> > lessee_id)
> > return 0;
> > return -errno;
> >  }
> > +
> > +drm_public drmModeFB2Ptr
> > +drmModeGetFB2(int fd, uint32_t fb_id)
> > +{
> > +   struct drm_mode_fb_cmd2 get;
> > +   drmModeFB2Ptr ret;
> > +   int err;
> > +
> > +   memclear(get);
> > +   get.fb_id = fb_id;
> 
> As mentioned on IRC, could you write it like this instead?
> 
>   struct drm_mode_fb_cmd2 get = {
>   .fb_id = fb_id,
>   };
> 
> With that, consider this patch
> Reviewed-by: Eric Engestrom 

Opps I sent v5 before seeing this but my code style differs and is
probably incorrect :) I'll send v6 with the style corrected.

Thanks for reviewing!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RESEND PATCH v2] drm: Add getfb2 ioctl

2019-12-13 Thread Li, Juston
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],
> > +   >handles[i]);
> > +   } else {
> > +   WARN_ON(i > 0);
> > +   ret = fb->funcs->create_handle(fb, file_priv,
> > +  >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 just 

Re: [RESEND PATCH v2] drm: Add getfb2 ioctl

2019-11-21 Thread Li, Juston
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH v2] drm: Add getfb2 ioctl

2019-10-14 Thread Li, Juston
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

2019-10-14 Thread Li, Juston
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-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH v2] drm: Add getfb2 ioctl

2019-10-14 Thread Li, Juston
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],
> > +   

Re: [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

2018-11-26 Thread Li, Juston
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
> > 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

2018-10-24 Thread Li, Juston
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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Intel-gfx] [RESEND PATCH v2 0/2] Check MST topology change on resume

2018-10-24 Thread Li, Juston
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel