Hi Mark
Thank you for your feedback
the other edge) but there are other examples. This means we probably want drivers to be able to list at least two levels of preferences for formats separately then try to ideally use one they both like, but it gets a little tricky. We probably also want to have some priority list in the kernel where we try to rank how likely formats are to have bugs in the hardware to maximise the chances that things will work.
(snip)
I'm not 100% sure I get why we have the separate _POSSIBLE_ macros here? One thing we'll have to take account of is that there's some DAIs that have some restrictions on what options they can combine - for example only doing I2S with one format of clock but allowing clock inversion in DSP mode. It might be safer (if tedious for driver authors without some help...) to just have arrays of fully specified daifmt values.
(snip)
- /* use original dai_fmt if sound card specify */
- if (!(dai_link->dai_fmt & SND_SOC_DAIFMT_FORMAT_MASK))
mask |= SND_SOC_DAIFMT_FORMAT_MASK;- if (!(dai_link->dai_fmt & SND_SOC_DAIFMT_CLOCK_MASK))
mask |= SND_SOC_DAIFMT_CLOCK_MASK;- if (!(dai_link->dai_fmt & SND_SOC_DAIFMT_INV_MASK))
mask |= SND_SOC_DAIFMT_INV_MASK;- if (!(dai_link->dai_fmt & SND_SOC_DAIFMT_MASTER_MASK))
mask |= SND_SOC_DAIFMT_MASTER_MASK;- dai_link->dai_fmt = dai_link->dai_fmt | (dai_fmt & mask);
If the sound card specifies something why not just use it verbatim instead of trying to merge?
I'm thinking the way that for example select "format" automatically, but specify others from Card, etc (= not all settings). Because as you are concerning, some driver might has complex limitations for some parts. We want to manually and directly select it from Card in such case.
My idea was very simple, but indeed I could understand your concern. I have no good idea so far, but want to consider about it more.
Thank you for your help !!
Best regards --- Kuninori Morimoto