<html><body><p>
<pre>
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@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);
> > > +}
> > > +
> >
> >
>
>
>
</pre>
</p></body></html><!--type:text--><!--{--><pre>************* MEDIATEK Confidentiality Notice
********************
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may
be unlawful. If you are not an intended recipient of this e-mail, or believe
that you have received this e-mail in error, please notify the sender
immediately (by replying to this e-mail), delete any and all copies of
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
</pre><!--}-->