On 2/7/2025 6:04 PM, Dmitry Baryshkov wrote:
On Fri, Feb 07, 2025 at 05:31:20PM -0800, Abhinav Kumar wrote:
On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
that requires manual repacking in the driver, while GENERIC0 doesn't
have such format requirements. The msm-4.4 kernel uses GENERIC0 to send
HDR InfoFrame which we do not at this point anyway.
True that GENERIC_0/1 packets can be used for any infoframe. But because we
have so many of them, thats why when there are dedicated registers for some
of them, we use them to save the GENERIC0 ones for others.
True
Lets take a case where we want to send HVSIF, SPD and HDR together for the
same frame, then we run out as there are no HDR specific infoframe registers
we can use. Is the expectation that we will migrate to VENSPEC_INFO regs for
HVSIF when we add HDR support?
Most likely, yes. That would be a part of the HDR support. At the same
time note, we can use GENERIC0 to send new HFVS InfoFrames defined in
HDMI 2.x (once Linux gets support for that). At the same time we can not
use VENSPEC_INFO to send those.
I can imagine that the driver will have to switch GENERIC1 between HDR
(if required) and SPD (in all other cases).
We dont have to use GENERIC0 for HFVS infoframes. We have dedicated
HFVS_INFO registers for those.
Also from a validation standpoint, I guess to really validate this change
you need an analyzer which decodes the HVSIF. So was this mostly sanity
tested at this pointed to make sure that the sink just comes up?
Vertex 2 dumps received HVS InfoFrame, so the InfoFrame contents has
been validated (validated SPD, AUD, HVS and AVI frames).
Yup, vertex2 validation is perfect for this!
Overall, I am fine with this,
Reviewed-by: Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx>
