Re: [Intel-gfx] [PATCH v4 6/7] drm/i915/mtl: Add function to send command to GSC CS

["Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>]

I've send offline email to clear up session cleanup behavior for hdcp (maybe its a PXP-only thing). But still wanna pursue a bit more on below portion:

On Fri, 2022-12-23 at 09:07 +0000, Kandpal, Suraj wrote:
> > 
> > 
> > > +	memset(cmd, 0, obj->base.size);
> > 
> > Alan: question: how often is this hdcp message being created, pinned,cleared
> > and used to send message?
> > Is this very infrequent - such as only during initial port connection establishment
> > or if in unlikely cases of dp/hdmi link-disruption..
> > Or is intel_hdcp_check_work something that has to exercise these gsc messages
> > frequently (such as every few seconds)?
> 
> It is more frequent so during the link estabilishment and then every few seconds
> To check if link in working right through check work but saving message in hdcp
> In intel hdcp does not seem right as message that need to be sent vary in size.
> ,creation pinning and clearance makes it simpler and cleaner.
> 
> 
> > I am just wondering if its the latter, whether its more efficient to initialize and
> > store the hdcp_message structure into intel_hdcp if hdcp on connector is
> > enabled and freed (intel_free_hdcp_gsc_message) only at port disabling time?
> > Also, in any case, would the entire object need to be memset? (I'm wondering if
> > we only need to memset the mtl-gsc-header and leave the rest since gsc hdcp
> > service is able to determine the range of valid bytes based on the hdcp command
> > and thus we don't need to memset the entire object)
> > 
> > Alan:[snip]
> > 
> 
> memsetting of the entire object would be required as the range of valid bytes can change depending on
> Various use cases one example would be if Km is already stored in fw or not this keeps it
> more cleaner and less prone to error
> > 
1. Is there a max size for the hdcp communications throughout the various types of message packets through out the various state-machine stages of the hdcp link life-cycle?
If there is a deterministic max size, we can allocate that up front and keep re-using the same object.

2. Is the "range of valid bytes" consistent for the same HDCP-command? Based on patch #5 it looks that way. For exmaple, if the heci packet contained HDCP command
HDCP_CMD_WIRED_AAA, then do we know for sure that command AAA will always have a specific fixed-size structure (size of struct aaa)? And for command HDCP_CMD_WIRED_BBB, it is
a different structure but also has a fixed-size (size of struct bbb). If this the case, then we dont need to memset the entire object, we only need to ensure the memory size
that corresponds to the structure of the specific HDCP command is initialized correctly - i.e. ensure we fill up every dword in that structure (and not need a memset for the
full 4K - or whatever buffer size was allocated?). I'm assuming the security-firmware hdcp-service would only read data up until the expected fixed-size struct depending on
the command.