Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 16 Feb 2022 15:11:27 +0100
From:   Maxime Ripard <maxime@cerno.tech>
To:     Sui Jingfeng <15330273260@189.cn>
Cc:     Dan Carpenter <dan.carpenter@oracle.com>,
        Lucas Stach <l.stach@pengutronix.de>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Roland Scheidegger <sroland@vmware.com>,
        Zack Rusin <zackr@vmware.com>,
        Christian Gmeiner <christian.gmeiner@gmail.com>,
        David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        Rob Herring <robh+dt@kernel.org>,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Krzysztof Kozlowski <krzk@kernel.org>,
        Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>,
        Sam Ravnborg <sam@ravnborg.org>,
        suijingfeng <suijingfeng@loongson.cn>,
        linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org,
        Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display
 controller
Message-ID: <20220216141127.2b7frii62w7xp3tu@houat>
References: <20220203082546.3099-1-15330273260@189.cn>
 <20220203082546.3099-2-15330273260@189.cn>
 <20220203085851.yqstkfgt4dz7rcnw@houat>
 <11ac5696-29e3-fefa-31c0-b7b86c88bbdc@189.cn>
 <20220209084908.kub4bs64rzhvpvon@houat>
 <84bfb2fc-595c-3bae-e8a0-c19ccbcfcfd8@189.cn>
 <20220209161624.42ijbnhanaaari46@houat>
 <965ca520-229f-5729-bf06-ae64ed3af383@189.cn>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="if4dkzifithtnd47"
Content-Disposition: inline
In-Reply-To: <965ca520-229f-5729-bf06-ae64ed3af383@189.cn>
Precedence: bulk


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


On Wed, Feb 16, 2022 at 09:34:47PM +0800, Sui Jingfeng wrote:
> On 2022/2/10 00:16, Maxime Ripard wrote:
> > And, to reinstate, we already have a mechanism to set an EDID, and if it
> > wasn't an option, the DT is not the place to store an EDID blob.
>=20
> Hi,
>=20
>=20
> if DT is not the place to store EDID blob, why nvidia can do that ?
>=20
> output->edid =3D of_get_property(output->of_node, "nvidia,edid", &size);
> [1][2]

Because that binding is 10 years old and never got reviewed by a DT maintai=
ner.

Things change, some things we did in the past have been mistakes that we
don't want to repeat, can we move forward?

Maxime

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

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

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYg0GDwAKCRDj7w1vZxhR
xfrUAQDoc1GrrZYHXc7NMWEIsyPQ1lsWTu8qjcZQon9X0OfsPgEAwkVb2Uv/vcHy
dC/YeqCI6cZBcH7PZOIyLedrztqdEgA=
=ryuu
-----END PGP SIGNATURE-----

--if4dkzifithtnd47--