linux-kernel - Re: [PATCH v2 15/15] drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d64ff9f1525fe3563502e470b2a31303de08a7c6.camel@mediatek.com>
Date: Tue, 17 Dec 2024 06:40:11 +0000
From: CK Hu (胡俊光) <ck.hu@...iatek.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>
CC: "robh@...nel.org" <robh@...nel.org>, "jie.qiu@...iatek.com"
	<jie.qiu@...iatek.com>, "kernel@...labora.com" <kernel@...labora.com>,
	"simona@...ll.ch" <simona@...ll.ch>, "mripard@...nel.org"
	<mripard@...nel.org>, "tzimmermann@...e.de" <tzimmermann@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "p.zabel@...gutronix.de"
	<p.zabel@...gutronix.de>, Jitao Shi (石记涛)
	<jitao.shi@...iatek.com>, "airlied@...il.com" <airlied@...il.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, "junzhi.zhao@...iatek.com"
	<junzhi.zhao@...iatek.com>
Subject: Re: [PATCH v2 15/15] drm/mediatek: Introduce HDMI/DDC v2 for
 MT8195/MT8188

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@...labora.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);
> > > +}
> > > +
> > 
> > 
> 
> 
>