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: <3twc4zoohon7uujypgjtlnryfmebx4osvpykagnwr5nemmqz2w@w4vw55uswebh>
Date:   Thu, 26 Oct 2023 10:07:40 +0200
From:   Maxime Ripard <mripard@...nel.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.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, 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.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ