Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Wed, 9 Feb 2022 09:52:15 +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: <20220209085215.65qbdsgwtnvujdng@houat>
References: <20220203082546.3099-1-15330273260@189.cn>
 <20220203082546.3099-2-15330273260@189.cn>
 <20220203085851.yqstkfgt4dz7rcnw@houat>
 <57805e19-285a-76d3-16e3-09a3eb7a9540@189.cn>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="ya7qckwy2foywkx2"
Content-Disposition: inline
In-Reply-To: <57805e19-285a-76d3-16e3-09a3eb7a9540@189.cn>
Precedence: bulk


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

On Thu, Feb 03, 2022 at 11:47:16PM +0800, Sui Jingfeng wrote:
> On 2022/2/3 16:58, Maxime Ripard wrote:
> > > diff --git a/drivers/gpu/drm/lsdc/Kconfig b/drivers/gpu/drm/lsdc/Kcon=
fig
> > > new file mode 100644
> > > index 000000000000..7ed1b0fdbe1b
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/lsdc/Kconfig
> > > @@ -0,0 +1,38 @@
> > > +config DRM_LSDC
> > > +	tristate "DRM Support for loongson's display controller"
> > > +	depends on DRM && PCI
> > > +	depends on MACH_LOONGSON64 || LOONGARCH || MIPS || COMPILE_TEST
> > > +	select OF
> > > +	select CMA if HAVE_DMA_CONTIGUOUS
> > > +	select DMA_CMA if HAVE_DMA_CONTIGUOUS
> > > +	select DRM_KMS_HELPER
> > > +	select DRM_KMS_FB_HELPER
> > > +	select DRM_GEM_CMA_HELPER
> > > +	select VIDEOMODE_HELPERS
> > > +	select BACKLIGHT_PWM if CPU_LOONGSON2K
> > > +	select I2C_GPIO if CPU_LOONGSON2K
> > > +	select I2C_LS2X if CPU_LOONGSON2K
> > > +	default m
> > > +	help
> > > +	  This is a KMS driver for the display controller in the LS7A1000
> > > +	  bridge chip and LS2K1000 SoC. The display controller has two
> > > +	  display pipes and it is a PCI device.
> > > +	  When using this driver on LS2K1000/LS2K0500 SoC, its framebuffer
> > > +	  is located at system memory.
> > > +	  If "M" is selected, the module will be called lsdc.
> > > +
> > > +	  If in doubt, say "Y".
> > > +
> > > +config DRM_LSDC_VRAM_DRIVER
> > > +	bool "vram helper based device driver support"
> > > +	depends on DRM_LSDC
> > > +	select DRM_VRAM_HELPER
> > > +	default y
> > > +	help
> > > +	  When using this driver on LS7A1000 + LS3A3000/LS3A4000/LS3A5000
> > > +	  platform, the LS7A1000 bridge chip has dedicated video RAM. Using
> > > +	  "lsdc.use_vram_helper=3D1" in the kernel command line will enable
> > > +	  this driver mode and then the framebuffer will be located at the
> > > +	  VRAM at the price of losing PRIME support.
> > > +
> > > +	  If in doubt, say "Y".
> > This doesn't sound right. The driver should make the proper decision
> > depending on the platform, not the user or the distribution.
>=20
> The LS7A1000 north bridge chip has dedicated video RAM, but the DC in LS7=
A1000
> can also scanout from the system memory directly like a display controlle=
r in a
> SoC does. In fact, this display controller is envolved from early product=
 of
> Loongson 2H SoC. This driver still works even if the downstream PC board
> manufacturer doesn't solder a video RAM on the mother board.
>=20
> The lsdc_should_vram_helper_based() function in lsdc_drv.c will examine
> if the DC device node contain a use_vram_helper property at driver loadin=
g time.
> If there is no use_vram_helper property, CMA helper based DRM driver will=
 be used.
> Doing this way allow the user using "lsdc.use_vram_helper=3D0" override t=
he default
> behavior even through there is a "use_vram_helper;" property in the DTS.
>=20
> In short, It is intend to let the command line passed from kernel has hig=
her
> priority than the device tree. Otherwise the end user can not switch diff=
erent
> driver mode through the kernel command line once the DC device node conta=
in
> "use_vram_helper;" property.
>=20
> This driver's author already made the decision by the time when the patch=
 is
> sent out, even through this**may not proper.
>=20
> The CMA helper based driver will be used by default, if the DC device nod=
e contain
> "use_vram_helper;" then VRAM based driver will be used. This is my initia=
l intention.

DT isn't really a solution either. Let's take the distribution
perspective there. Suppose you're a Fedora or Debian developer, and want
to make a single kernel image, and ship a DT to the user for their board
without any modification. How is either the Kconfig solution or DT flags
solution any good there? It doesn't help them at all.

Maxime

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

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

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYgOAvwAKCRDj7w1vZxhR
xfmlAP9jrc/0alF0HbOEKem/PYILuIQZksQjvUqUpnADGQgZ2AD/YY/Mdq2iiu3Z
W6nZNr9i/aZ4agM5MHGTU59+JVzfAwA=
=9aeP
-----END PGP SIGNATURE-----

--ya7qckwy2foywkx2--