linux-kernel - Re: [PATCH v2 6/6] drm/vs: Add hdmi driver

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: <CAA8EJppxQ7J8DEDFsWzPL8bDpNW-KY0nhUA++zDBRpMCpP-bkA@mail.gmail.com>
Date:   Thu, 26 Oct 2023 11:57:22 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Maxime Ripard <mripard@...nel.org>
Cc:     Keith Zhao <keith.zhao@...rfivetech.com>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Emil Renner Berthing <kernel@...il.dk>,
        Shengyang Chen <shengyang.chen@...rfivetech.com>,
        Conor Dooley <conor+dt@...nel.org>,
        Albert Ou <aou@...s.berkeley.edu>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Jagan Teki <jagan@...eble.ai>,
        Rob Herring <robh+dt@...nel.org>,
        Chris Morgan <macromorgan@...mail.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Changhuang Liang <changhuang.liang@...rfivetech.com>,
        Jack Zhu <jack.zhu@...rfivetech.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Shawn Guo <shawnguo@...nel.org>, christian.koenig@....com
Subject: Re: [PATCH v2 6/6] drm/vs: Add hdmi driver

On Thu, 26 Oct 2023 at 11:07, Maxime Ripard <mripard@...nel.org> wrote:
>
> On Thu, Oct 26, 2023 at 01:23:53AM +0300, Dmitry Baryshkov wrote:
> > > +static int starfive_hdmi_register(struct drm_device *drm, struct starfive_hdmi *hdmi)
> > > +{
> > > +   struct drm_encoder *encoder = &hdmi->encoder;
> > > +   struct device *dev = hdmi->dev;
> > > +
> > > +   encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
> > > +
> > > +   /*
> > > +    * If we failed to find the CRTC(s) which this encoder is
> > > +    * supposed to be connected to, it's because the CRTC has
> > > +    * not been registered yet.  Defer probing, and hope that
> > > +    * the required CRTC is added later.
> > > +    */
> > > +   if (encoder->possible_crtcs == 0)
> > > +           return -EPROBE_DEFER;
> > > +
> > > +   drm_encoder_helper_add(encoder, &starfive_hdmi_encoder_helper_funcs);
> > > +
> > > +   hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
> > > +
> > > +   drm_connector_helper_add(&hdmi->connector,
> > > +                            &starfive_hdmi_connector_helper_funcs);
> > > +   drmm_connector_init(drm, &hdmi->connector,
> > > +                       &starfive_hdmi_connector_funcs,
> > > +                       DRM_MODE_CONNECTOR_HDMIA,
> >
> > On an embedded device one can not be so sure. There can be MHL or HDMI
> > Alternative Mode. Usually we use drm_bridge here and drm_bridge_connector.
>
> On an HDMI driver, it's far from being a requirement, especially given
> the limitations bridges have.

It's a blessing that things like MHL / HDMI-in-USB-C / HDMI-to-MyDP
are not widely used in the wild and are mostly non-existing except
several phones that preate wide DP usage.
Using drm_connector directly prevents one from handling possible
modifications on the board level. For example, with the DRM connector
in place, handling a separate HPD GPIO will result in code duplication
from the hdmi-connector driver. Handling any other variations in the
board design (which are pretty common in the embedded world) will also
require changing the driver itself. drm_bridge / drm_bridge_connector
save us from those issues.

BTW: what are the limitations of the drm_bridge wrt. HDMI output? I'm
asking because we heavily depend on the bridge infrastructure for HDMI
output. Maybe we are missing something there, which went unnoticed to
me and my colleagues.

-- 
With best wishes
Dmitry