Re: [Intel-gfx] [PATCH] drm/i915/pxp: Hold RPM wakelock during PXP unbind

2021-12-21 Thread Li, Juston
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 h

Re: [Intel-gfx] [PATCH 0/4] drm/i915: Clean up the pxp stuff

2021-10-06 Thread Li, Juston
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:

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Rename intel_load_plane_csc_black()

2021-10-06 Thread Li, Juston
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: Danie

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the drm_dbg() from the vblank evade critical section

2021-10-06 Thread Li, Juston
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: Rodri

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move the pxp plane state computation

2021-10-06 Thread Li, Juston
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

Re: [Intel-gfx] [PATCH v5 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check

2021-08-19 Thread Li, Juston
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 < > >

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check

2021-08-12 Thread Li, Juston
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. > > > > Thi

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 sec

Re: [Intel-gfx] [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

Re: [Intel-gfx] [PATCH v6 i-g-t 2/2] tests/kms_getfb: Add getfb2 tests

2020-03-06 Thread Li, Juston
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 v

Re: [Intel-gfx] [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 > --- > .

Re: [Intel-gfx] [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

Re: [Intel-gfx] [PATCH v5 i-g-t 2/2] tests/kms_getfb: Add getfb2 tests

2020-02-05 Thread Li, Juston
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 get

Re: [Intel-gfx] [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 t

Re: [Intel-gfx] [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 multi

Re: [Intel-gfx] [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

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

Re: [Intel-gfx] [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 t

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

2018-11-26 Thread Li, Juston
18-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 wr

Re: [Intel-gfx] [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

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