Messages in this thread | | | Date | Mon, 23 Jan 2023 17:05:08 +0100 | Subject | Re: [PATCH v2] arm64: defconfig: Enable HDA INTEL config for ARM64 | From | Krzysztof Kozlowski <> |
| |
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 registering the >>>>>>>>> sound card. >>>>>>>> It's not a part of SoC, not a common device used during debugging 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 clarify >>>>>>>> which board has this device embedded (not pluggable by user, but embedded). >>>>>>> This change is required for enabling HDA sound registration for Nvidia >>>>>>> discrete GPU cards based on PCI and pluggable to Nvidia Jetson Platforms. >>>>>> 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 built >>>>> and dGPU won't be able to register sound card. Do you have any >>>>> 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 can >>>> 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 platforms. > > If defconfig were only for boot-critical drivers, it's terribly bloated
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.
> 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. > > Besides, a PCI board can be considered a development platform depending > on who you are. > > I've always looked at defconfig as more of a guideline as to what's a > useful baseline configuration for an architecture.
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?
> >> 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... > > 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.
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.
> > 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.
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 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.
It's not reasonable path...
Best regards, Krzysztof
| |