Date:   Mon, 23 Jan 2023 18:26:13 +0100
From:   Thierry Reding <treding@nvidia.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Catalin Marinas <catalin.marinas@arm.com>,
        Mohan Kumar D <mkumard@nvidia.com>, will@kernel.org,
        dmitry.baryshkov@linaro.org, shawnguo@kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        jonathanh@nvidia.com
Subject: Re: [PATCH v2] arm64: defconfig: Enable HDA INTEL config for ARM64
Message-ID: <Y87DNf1tnB8aaKJS@orome>
References: <20230117181658.17010-1-mkumard@nvidia.com>
 <e871dae2-58ac-7ad9-c198-c4e90d26c69b@linaro.org>
 <1afa38ad-716f-49f8-efd1-ed37bd8dbf6e@nvidia.com>
 <ec440deb-2970-69b8-e54d-6519c95875a8@linaro.org>
 <35eb1396-b91b-8a7f-6585-30d2f2adcf85@nvidia.com>
 <cfb9b0f2-a8fa-9bee-a04d-d195d69e4918@linaro.org>
 <Y8rHzJpEg7bMzYM6@arm.com>
 <fbeff3da-e03b-aa82-1a53-d92f95b63770@linaro.org>
 <Y86uw7QF/hMrIvbs@orome>
 <2c6deeff-bf5f-24e5-4cf2-2640ea1e7402@linaro.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="O//JUppp0jKn8+fa"
Content-Disposition: inline
In-Reply-To: <2c6deeff-bf5f-24e5-4cf2-2640ea1e7402@linaro.org>
User-Agent: Mutt/2.2.9 (2022-11-12)
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bkjUdoJryVc/r4mm0y+SVGqhKtYCJM9VCGnvJQLZbdYnol6aEH7svJYuZ0it?=
 =?us-ascii?Q?aAOZscu4Wk2+zKwJtFxFsSqdAq+X5uTR9VyuSoOLnpeDDeV6HS6eC3u//uQF?=
 =?us-ascii?Q?1R0VJo4ed/nrYvWKuVjVacpdlOAwef0GV1d9eyasBuLQhOMF2/lqFjtj2H44?=
 =?us-ascii?Q?kbVHEw3WdFqUmCjmIBIKiYfFWHrC0FAIW9DJUMPe8A0rk7oLimFnJpM0XDEN?=
 =?us-ascii?Q?VbUfqDKBAZdlaLh/mycJqwxLg83nzXsDoJYNToSCJMmAfQioK0TBR+RvfSHo?=
 =?us-ascii?Q?RnD+z6cnHWSAgdjn+5XW82QCQUSeGRe0fZZfUCSg9mYaYPbhsH6QELra8IjA?=
 =?us-ascii?Q?+edyAqCm++5WO4YDqKElNR3640JiP8RIuAfidInWPjVrUD//90yBp/3Zsu1C?=
 =?us-ascii?Q?uBh8MARYos7VnkTE/JMDjAvf4FhANRm+Icrwzwq8uuENRiCR/E7rPIkmsX7L?=
 =?us-ascii?Q?Y8HQ309GTvjFOG028G6upoD9H3iap63xIS9fzcuf4pcSrIX6GQGrVs/BqOEm?=
 =?us-ascii?Q?U3kAz9h8hsVsDcGkqJ1RdR9CpWs32Zb7ydEX6pTVipxxs8DpsjW4CIjemVxG?=
 =?us-ascii?Q?XCJMXk32zJ8GtOwDUHZY3EenwEAma3M1aKBrBJqKSK7dN/6TJJpYS2Cpf+5k?=
 =?us-ascii?Q?4SxMIypyMyTDxHFqSfVi7RZ1/XVkxX3tm7q4Jge8NAgBG8Gy1xTkmekMGhEb?=
 =?us-ascii?Q?68gB6RwIXgmmkrY3g64tMvQ79kwt1iHP5wv9CEimswrnYhepb+uoh0uW4ekw?=
 =?us-ascii?Q?NVIWiMBXEDapO1sjHamLiyn6emaNtZwQrQt5eslk4000EdXe6ZKJsUnZHdrB?=
 =?us-ascii?Q?LZk9SzH6E2F++Y2cl3jzW7zk/u77DZK8X5np80fU0mbSAR4I8lxkjPiFSBQ0?=
 =?us-ascii?Q?8QNwbjdIrvmtjpj/Xh9mvT79N1nj4doecBJTHjGHGnJAfY6qkmQpKYZnElPV?=
 =?us-ascii?Q?8HyCGY6MsgUrdRDVbbdTOopGajWrUzqM1zVhbPrc0qRKXYZZa+9by7fe/oIo?=
 =?us-ascii?Q?eFV4tmJNpDx0z3bh3JRXIKagK9er7u214AUvLEESnXj2mf9z2HSM8ocw/NX9?=
 =?us-ascii?Q?4umK2lRwuH+31f2Hd6NLXmPUXrlg6EmXhR0mRuabxCL/sFPrQGnb7IVmP5xB?=
 =?us-ascii?Q?Drt8JpQkKYg8KaWJOekam2VhqNAduZ0G8e9QrgsQaXG3/QeE+4pL+HaD86DT?=
 =?us-ascii?Q?ddDtqamj6LbPBEYIZwB8uGhrTMU41wPYAm3bzpBAd56KulrxvRb41m4POUNU?=
 =?us-ascii?Q?lIZifQIMPBpIcKN+/dM0fAmqoZLp1Z4hOQ/eYG/MGAXFsDz6+0apGkz2Ihjd?=
 =?us-ascii?Q?bIOuekwp4EbOyVgB513pwr0+Im4qExRlcxeUZOCPaISERj5XAhz1kT3XF9mI?=
 =?us-ascii?Q?sk8fMxKflSqj+8D3C528PYBh2LKZCpmUW9bcXeqMkmSCYYNIRkVQ2AnAqf+k?=
 =?us-ascii?Q?FX4GcdAbF39fUrlD9+M0s/tjCaN3cV1MC5aOQnd3AEDmSMzsJPfrWHXVW1wj?=
 =?us-ascii?Q?xwhRk8PwhaDwcNFuBF9xX7GkzRoGvku51GwlpqQZaDYdJdZToKXL3eEIhre3?=
 =?us-ascii?Q?ef+8LlBK4W1d3hTwVdRI+qTXA4tiEozqRGyYGTh9USyJmTTO8ATUzc0ZUHur?=
 =?us-ascii?Q?83m++CKAmG/7ctY82k5RCEnvv8CAo0DEUrAMrYqA1uXP?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ea24a584-766c-4098-6b83-08dafd66f25b
X-MS-Exchange-CrossTenant-AuthSource: DM8PR12MB5413.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2023 17:26:22.3571
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: BP8E1kozszrAA3qA6WRvKVHuvQoYaGRYjgwy+2OMjeP3GwGVAFkf6KqAZi+9G05lqsPZv2bPx90XZ8iva4RQsg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4504
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--O//JUppp0jKn8+fa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 23, 2023 at 05:05:08PM +0100, Krzysztof Kozlowski wrote:
> On 23/01/2023 16:58, Thierry Reding wrote:
> > On Fri, Jan 20, 2023 at 06:00:25PM +0100, Krzysztof Kozlowski wrote:
> >> On 20/01/2023 17:56, Catalin Marinas wrote:
> >>> On Fri, Jan 20, 2023 at 07:20:01AM +0100, Krzysztof Kozlowski wrote:
> >>>> On 20/01/2023 06:48, Mohan Kumar D wrote:
> >>>>> On 18-01-2023 18:06, Krzysztof Kozlowski wrote:
> >>>>>> External email: Use caution opening links or attachments
> >>>>>> On 18/01/2023 12:46, Mohan Kumar D wrote:
> >>>>>>> On 18-01-2023 13:04, Krzysztof Kozlowski wrote:
> >>>>>>>> External email: Use caution opening links or attachments
> >>>>>>>> On 17/01/2023 19:16, Mohan Kumar wrote:
> >>>>>>>>> Enable CONFIG_SND_HDA_INTEL for NVIDIA PCI based graphics sound=
 card for
> >>>>>>>>> ARM64 based platforms as Intel PCI driver was used for register=
ing the
> >>>>>>>>> sound card.
> >>>>>>>> It's not a part of SoC, not a common device used during debuggin=
g or
> >>>>>>>> development, so I don't think it is reasonable to enable it. We =
do not
> >>>>>>>> enable driver just because someone uses them. Otherwise please c=
larify
> >>>>>>>> which board has this device embedded (not pluggable by user, but=
 embedded).
> >>>>>>> This change is required for enabling HDA sound registration for N=
vidia
> >>>>>>> discrete GPU cards based on PCI and pluggable to Nvidia Jetson Pl=
atforms.
> >>>>>> You can plug anything to PCI slot and we do not enable every such =
PCI
> >>>>>> adapter.
> >>>>> Without this config enabled, the Intel hda audio driver won't be bu=
ilt=20
> >>>>> and dGPU won't be able to register sound card. Do you have any=20
> >>>>> suggestion here?
> >>>>
> >>>> Without hundreds of other drivers they also won't be built and won't=
 be
> >>>> usable. Anyway, this is just defconfig, so it does not matter. You c=
an
> >>>> always enable it in your setup, why is this a problem?
> >>>>
> >>>> Again, we do not enable drivers for every PCI card.
> >>>
> >>> I don't think we have any set rules for what goes in a defconfig. If =
one
> >>> has a real use-case, we tend to enable stuff in defconfig, especially=
 if
> >>> it's a module.
> >>
> >> There will be always an use case for every PCI and USB card. It's not
> >> related to storage or networking which could justify device bringup
> >> (rootfs). It's really not needed for any board operation. defconfig is
> >> not for marketing products but for our development and reference platf=
orms.
> >=20
> > If defconfig were only for boot-critical drivers, it's terribly bloated
>=20
> We enable drivers for devices present in our platforms. Everything which
> is on such platforms. For pluggable USB/PCI/whatever third-party
> devices, then comes the argument as boot-related.
>=20
> > as it is. We enable things like multimedia, infrared and audio. None of
> > those are critical to booting a system. Heck, we also enable most of
> > DRM/KMS, which are useful for boot on consumer devices, but are rarely
> > critical on development and reference platforms.
> >=20
> > Besides, a PCI board can be considered a development platform depending
> > on who you are.
> >=20
> > I've always looked at defconfig as more of a guideline as to what's a
> > useful baseline configuration for an architecture.
>=20
> Yep and this one here is nowhere near that architecture. It's pluggable
> card, not related to hardware nor arm64 (If I understood correctly). Why
> you do not enable it on x86? Or multi_v7? or hundreds of other defconfigs?

My understanding is that the code behind SND_HDA_INTEL, despite the
name, is in fact generic PCI HDA code and is compatible with a number of
non-Intel devices. It's also nothing x86-specific because this code
works on any PCI-enabled platform (it's for driving generic PCI HDA
controllers).

It's quite common for people to hook up PCI cards on NVIDIA Jetson
platforms (which are arm64). Often these will be NVIDIA GPUs, but they
can be any brand of GPU, really (SND_HDA_INTEL supports hardware from a
large number of vendors).

> >> The only argument behind this change is "I have a PCI card and I want =
it
> >> in defconfig", but why it has to be in defconfig in the first place?
> >> There is no reason. This is not distro...
> >=20
> > That's highly subjective and honestly that argument can go in both
> > directions. People can, after all, start from an allnoconfig and then
> > work their way up to something that's usable on their particular device.
> > Or they could start from an allmodconfig and work their way down.
>=20
> I am sorry, but adding new stuff does not require arguments against.
> Adding new stuff requires argument for it. You reverse the argumentation
> that I need to find proves that we do not need it in mainline platforms,
> if I got your response correctly.

Adding new stuff also doesn't require arguments in favour. At least
that's not been my experience in kernel development. If somebody spends
the time to write a driver, we don't tend to ask proof of why it's
useful, we trust that they wouldn't have spent the effort if they didn't
think it worth it.

Besides, this is to enable support for these various HDA controllers
that can be plugged into Jetson platforms, which very well are mainline
platforms.

> > The point of defconfig is to give you something that's somewhere between
> > the two extremes. Obviously if we start enabling everything, it defeats
> > that purpose. If we prohibit the enablement of new options, we equally
> > limit its usefulness.
>=20
> I don't think we discuss the same thing. There are no extremes here at
> all. The patch is about enabling arm64-unrelated PCI pluggable device,
> just because it came from @nvidia.com author. If you think some PCI

I think you're making this into something it's not. What would be the
benefit for NVIDIA to enable something that is unused? If there's
consensus that only boot-critical pieces should go into defconfig, then
that's fine with me. Currently that's not the case, so painting this as
some sort of marketing stunt is hardly fair.

> pluggable 3rd party device is suitable for defconfig, I will bring
> hundreds of other drivers I am also plugging over PCI to my boards, just
> because I want some audio.
>=20
> It's not reasonable path...

Well, then what is a reasonable path? We've had per-platform defconfigs
on 32-bit ARM and people weren't happy about those. But if the single
defconfig on 64-bit ARM doesn't generate a configuration that is useful
for many people, then we don't need it. People could then just keep
their own, local default configurations.

Surely I'm not the only one that gets annoyed if I have to tweak config
and rebuild multiple times until I have the right configuration.

Thierry

--O//JUppp0jKn8+fa
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmPOwzMACgkQ3SOs138+
s6HVRBAAnqpWg5tTvmv0jzdT0+wr3ICHoVNHkx80os6Y5EdOvAeWJhz/tTJup6fH
rNHKYtnyRV1Eewot7s9QAS0cEz/gXL7GiHHP7QF5bGdKcio39BMNV8tgj5l1bKz2
XwcDFY+nJ9X9HwTum5qxmFlYNqAbNtCnlAXdFUjFoRvl26N9b8kK/1XNVXWZzmkR
dhvLtAY9Hp+qsnn6noMphC/XYYTxTCU8RiFnSaju6BnKcckwM0+bqUykpYwSCvwW
AupQbgjftDKquGX5nM4r3bMIF5WfGkPRdnTLug07hujFKl88K7MjjHijcyEzu1My
v/GSKlD8Z5KEqEAVm4GbYC9cZQRPHQyW57Bom5j/aeiH5GSvZCgtApKxJv3wAj+5
HfI0WL9cnTbJxp6CedWi37v8+M7mB/Xn0sVqXgmYLc43q9E3Hi0LI4pYJp8OWQq8
Y7TUqoiihoB9Kqc5IUIpdPqSxV1loEgXuWu8AEDe0xpnzPCNCkD8yxrGlGM4L9bd
DwE3N3GhA7YEs3X93Gu7kX2f5rVSVFLjIQxj820qy20Mzi7HET3Nd8EMdJGnrxeM
jsT7fUkDkWogQaQCejZ+SdVBr7YzjLL9ym2dP44nYNwrkZS+SRVjsjzJA7ecU6GE
tt2oAkSfJJD9rJFDiOeMOVVhABsOzwk7xyveyAaeoxRSPnOaQVk=
=+gIA
-----END PGP SIGNATURE-----

--O//JUppp0jKn8+fa--