On Fri, 10 May 2019 19:56:51 +0200, Pierre-Louis Bossart wrote: > > > >>>> Yes, that would work. OTOH, I see no merit to build an extra module > >>>> for nocodec. nocodec.c can be built together with sof-core stuff. > >> > >> the module has its benefits. Today nocodec includes all possible DAIs, > >> I wanted to add module parameters to restrict things a bit for > >> tests/debug. It'll be e.g. very helpful for SoundWire to avoid > >> exposing the SSP DAIs. > >> > >> Also nocodec is incompatible with hdaudio/hdmi support at the moment, > >> we had all sorts of issues with suspend/resume. > > > > Well, in the case of SOF, the core code calls directly > > soc_nocodec_setup(), hence it's rather a direct link. So it makes > > little sense to make the nocodec code split from sof-core, unless the > > nocodec code is used / linked by components other than SOF. I doubt > > the possibility because the current DAI is clearly only for SOF... > > > > The module option can be still be there; it'll be applied just to > > sof-core instead of sof-nocodec. > > I see your point and this SOF core/nocodec dependency is a conceptual > miss on our side. Thanks for bringing our attention on this. > > The core is really supposed to be about the DSP side of things. It > shouldn't be burdened with machine driver stuff, but it unfortunately > is at two levels. > > Initially the nocodec code was handled at the soc-acpi-dev or > soc-pci-dev level, and it's still there that the FORCE_CODEC mode is > handled, along with the calls to check the codec ACPI IDs. Now when we > enabled the HDaudio case, we somehow ended-up moving parts of the > nocodec support in the SOF core to simplify our life but created a > dependency that wasn't intentional at all. we collectively missed it > while we were struggling with nocodec/hdaudio compatibility. > > The second issue is that we create a platform_device for the machine > driver in the SOF core. This is a shortcut that we took and that works > for Intel, but for DeviceTree-based platforms this will have to > change. > > So long story short, I'd rather have a simple Kconfig fix to avoid > compilation issues for now and revisit all the machine driver support, > e.g. when the i.MX patches show up, than strengthen a dependency that > we introduced by accident rather than by design. OK, thanks, that's convincing enough. My proposal was just some minor optimization, and as long as there is a planned change in future, it's fine to leave in the current or similar form. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
