On Thu 13 Feb 2020 at 18:18, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Thu, Feb 13, 2020 at 04:51:51PM +0100, Jerome Brunet wrote: > >> At the moment, querying the dai_name will stop of the first component >> matching the dt node. This does not allow a device (single dt node) to >> provide several ASoC components which could then be used through DT. > >> This change let the search go on if the xlate function of the component >> returns an error, giving the possibility to another component to match >> and return the dai_name. > > My first question here would be why you'd want to do that rather than > combine everything into a single component since the hardware seems to > be doing that anyway. Hopefully the rest of the series will answer this > but it'd be good in the changelog here. Hi Mark, Sorry if I was not clear enough. This HW is messy. It is indeed one monolithic device which provides several functions/sub-devices/components I tried several approaches: * Just 1 component: This was ugly because the part that is present only on 1 SoC variant, I needed to reconstruct the dai, widget, route and control table which involved a fair amount of useless copies. * A lot of devices (and components) with syscon: This ended up being even uglier, difficult to work with since it did not really reflected the actual HW. The solution proposed here is just one device with 3 possible components (groups): * The CPU producers a associated path * The HDMI control * The Internal DAC control The impact on ASoC is rather small, the driver reflect quite well what the HW is and, with a sound-dai-cell=2, it fairly simple in DT as well. Do you think there is something wrong with a linux device providing several ASoC components ?
