Hi Mark > First up sorry it's taken me a while to respond to this - I > wanted to get it clear in my head what I thought the best > approach is here. I think your code here is good with a couple > of documentation tweaks: Thank you for your feedback / review, and no worry about taken times. This is very challeng patch, and I know you are always busy :) > > For example, some driver want to select format "automatically", > > but want to select other fields "manually", because of complex limitation. > > Or other example, in case of both CPU and Codec are possible to be > > clock provider, but the quality was different. > > In these case, user need/want to *manually* select each fields > > from Sound Card driver. > > > > It uses Sound Card specified fields preferentially, and try to select > > non-specific fields from CPU and Codec driver settings if driver had > > callbacks. > > In other words, we can select all dai_fmt via Sound Card driver > > same as before. > > I mentioned last time around the idea of having first and second > preferences for the DAIs, for things like "this will work but > only if you get the configuration exactly right". These patches > don't support that, they just treat everything the DAI reports as > being equally valid. I've actually come round to thinking that > might be OK for now but... (snip) > so that instead of worrying about formats that aren't quite > supported properly we just tell drivers not to list them for now > so if the system is relying on the framework to pick the DAI > format then we know it's one that's robust, we're not going to > choose one that the hardware in one of the devices isn't very > good at. Does that make sense to you? > > If we did do first and second choices we'd get an algorithm like: > > 1. Try to match both DAI's 1st choice, if match use that. > 2. Pick one DAI A, try it's 2nd choice with the other DAI B's 1st > choice. > 3. Swap and try 1st choice of A and 2nd choice of B. > 4. Try 2nd choices of both DAIs. > > but I think that might get too complicated and we'd end up stuck > if we ever wanted to change the algorithm since DTs that don't > specify a format may break if a different format is picked. If > we go with ranking every format individually it gets even more > complicated for both driver authors and the core. > > I think with the documentation tweak above your idea is a better > one for now, we can always go back later with more experience. Yes, we want to have robust code, and indeed it might be issue in the future if something happen around algorithm. To avoid such case, indeed having "priority" is nice idea, and indicating such things is indeed nesessary. OK, thank you for your feedback, I will update code, and repost it. Thank you for your help !! Best regards --- Kuninori Morimoto
