Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 2 Jun 2020 17:54:21 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     Eric Anholt <eric@anholt.net>
Cc:     Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
        DRI Development <dri-devel@lists.freedesktop.org>,
        linux-rpi-kernel@lists.infradead.org,
        bcm-kernel-feedback-list@broadcom.com,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        Dave Stevenson <dave.stevenson@raspberrypi.com>,
        Tim Gover <tim.gover@raspberrypi.com>,
        Phil Elwell <phil@raspberrypi.com>
Subject: Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders
Message-ID: <20200602155421.niyvpwqc42xh5c7v@gilmour>
References: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
 <020de18840a1075b2671736c6cc2e451030fad74.1590594512.git-series.maxime@cerno.tech>
 <CADaigPXJ0BnMUp=XN6G92Tx=H9j55pmsBAujO2mcpiiTs-RHnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="qxxigstfuc465wjv"
Content-Disposition: inline
In-Reply-To: <CADaigPXJ0BnMUp=XN6G92Tx=H9j55pmsBAujO2mcpiiTs-RHnQ@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--qxxigstfuc465wjv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote:
> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > the vc4_hdmi driver has some custom structures to hold the data it need=
s to
> > associate with the drm_encoder and drm_connector structures.
> >
> > However, it allocates them separately from the vc4_hdmi structure which
> > makes it more complicated than it needs to be.
> >
> > Move those structures to be contained by vc4_hdmi and update the code
> > accordingly.
>=20
>=20
> > @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, stru=
ct device *master, void *data)
> >         struct drm_device *drm =3D dev_get_drvdata(master);
> >         struct vc4_dev *vc4 =3D drm->dev_private;
> >         struct vc4_hdmi *hdmi;
> > -       struct vc4_hdmi_encoder *vc4_hdmi_encoder;
> > +       struct drm_encoder *encoder;
> >         struct device_node *ddc_node;
> >         u32 value;
> >         int ret;
> > @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, st=
ruct device *master, void *data)
> >         if (!hdmi)
> >                 return -ENOMEM;
> >
> > -       vc4_hdmi_encoder =3D devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder=
),
> > -                                       GFP_KERNEL);
> > -       if (!vc4_hdmi_encoder)
> > -               return -ENOMEM;
> > -       vc4_hdmi_encoder->base.type =3D VC4_ENCODER_TYPE_HDMI0;
> > -       hdmi->encoder =3D &vc4_hdmi_encoder->base.base;
> > -
> >         hdmi->pdev =3D pdev;
> > +       encoder =3D &hdmi->encoder.base.base;
> > +       encoder->base.type =3D VC4_ENCODER_TYPE_HDMI0;
>=20
> Wait, does this patch build?

All those patches were build tested, so yep

> setting struct drm_encoder->base.type =3D VC4_* seems very wrong, when
> previously we were setting struct vc4_hdmi_encoder->base.type (struct
> vc4_encoder->type).

So the structure layout now is that vc4_hdmi embeds vc4_hdmi_encoder as
encoder. So &hdmi->encoder is a pointer to vc4_hdmi_encoder.
vc4_hdmi_encoder's base is since that patch a struct vc4_encoder. and
vc4_encoder's base is a drm_encoder.

so encoder being a drm_encoder is correct there.

However, drm_encoder's base is drm_mode_object that does have a type
field, which is an uint32_t, which will accept a VC4_ENCODER_TYPE_* just
fine...

Now, drm_encoder_init will then kick in and call drm_mode_object_add
which will override it to a proper value and since the clock select bit
in the PV is the same for both HDMI0 and HDMI1, everything works just
fine...

Good catch, I'll fix it. And I guess it's a good indication we don't
need a separate HDMI0 and HDMI1 encoder type.

> Other than this, patch 68-78 r-b.

Thanks for your review!
Maxime

--qxxigstfuc465wjv
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXtZ2LQAKCRDj7w1vZxhR
xfluAP43aoGu2OPb0dq0BcgQ5MBEsuDCQDD5MHgSVl0cRgWGjwD/aa+PuVsSgsR0
5+38Ljq0cbWaxeUJTzW8daGiUZDn8wM=
=KM7l
-----END PGP SIGNATURE-----

--qxxigstfuc465wjv--