[PATCH v2 15/15] drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188

[CK Hu (胡俊光)]

On Mon, 2024-12-16 at 12:04 +0100, AngeloGioacchino Del Regno wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> Il 16/12/24 09:57, CK Hu (胡俊光) ha scritto:
> > Hi, Angelo:
> > 
> > On Thu, 2024-12-05 at 12:45 +0100, AngeloGioacchino Del Regno wrote:
> > > External email : Please do not click links or open attachments until you have verified the sender or the content.
> > > 
> > > 
> > > Add support for the newer HDMI-TX (Encoder) v2 and DDC v2 IPs
> > > found in MediaTek's MT8195, MT8188 SoC and their variants, and
> > > including support for display modes up to 4k60 and for HDMI
> > > Audio, as per the HDMI 2.0 spec.
> > > 
> > > HDCP and CEC functionalities are also supported by this hardware,
> > > but are not included in this commit and that also poses a slight
> > > difference between the V2 and V1 controllers in how they handle
> > > Hotplug Detection (HPD).
> > > 
> > > While the v1 controller was using the CEC controller to check
> > > HDMI cable connection and disconnection, in this driver the v2
> > > one does not.
> > > 
> > > This is due to the fact that on parts with v2 designs, like the
> > > MT8195 SoC, there is one CEC controller shared between the HDMI
> > > Transmitter (HDMI-TX) and Receiver (HDMI-RX): before eventually
> > > adding support to use the CEC HW to wake up the HDMI controllers
> > > it is necessary to have support for one TX, one RX *and* for both
> > > at the same time.
> > > 
> > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> > > ---
> > 
> > [snip]
> > 
> > > +static int mtk_hdmi_v2_bridge_atomic_check(struct drm_bridge *bridge,
> > > +                                          struct drm_bridge_state *bridge_state,
> > > +                                          struct drm_crtc_state *crtc_state,
> > > +                                          struct drm_connector_state *conn_state)
> > > +{
> > 
> > I would like v1 and v2 has the same behavior.
> > Why v2 has atomic check but v1 has no?
> > If this is better to have, add atomic check to v1, and this function would be common function.
> > 
> 
> That's because v2 uses the new helpers, while v1 does not.
> The v1 must be converted to the new helpers in order to use atomic_check() like v2.

I just find the description here, and I don't know why new helper need atomic_check().
Would you provide more information how new helper need atomic_check()?
For example, the call stack to atomic_check(). (You could use dump_stack() to show it)

        /**
        * @atomic_check:
        *
        * This method is responsible for checking bridge state correctness.
        * It can also check the state of the surrounding components in chain
        * to make sure the whole pipeline can work properly.
        *
        * &drm_bridge_funcs.atomic_check() hooks are called in reverse
        * order (from the last to the first bridge).
        *
        * This method is optional. &drm_bridge_funcs.mode_fixup() is not
        * called when &drm_bridge_funcs.atomic_check() is implemented, so only
        * one of them should be provided.
        *
        * If drivers need to tweak &drm_bridge_state.input_bus_cfg.flags or
        * &drm_bridge_state.output_bus_cfg.flags it should happen in
        * this function. By default the &drm_bridge_state.output_bus_cfg.flags
        * field is set to the next bridge
        * &drm_bridge_state.input_bus_cfg.flags value or
        * &drm_connector.display_info.bus_flags if the bridge is the last
        * element in the chain.
        *
        * RETURNS:
        * zero if the check passed, a negative error code otherwise.
        */

Regards,
CK

> 
> Cheers,
> Angelo
> 
> > Regards,
> > CK
> > 
> > > +       return drm_atomic_helper_connector_hdmi_check(conn_state->connector,
> > > +                                                     conn_state->state);
> > > +}
> > > +
> > 
> > 
> 
> 
>