On 06/19/2014 03:10 AM, Qiao Zhou wrote:
On 06/18/2014 08:13 PM, Lars-Peter Clausen wrote:
On 06/18/2014 01:01 PM, Qiao Zhou wrote:
Hi Mark, Liam
This patch is to add another check besides cpu_dai/codec_dai name during dai_link bind. currently if the cpu_dai/codec_dai name match corresponding dai_link cpu/codec name, then a match is found. in this patch, it also checks whether cpu/codec dai id match dailink cpu_dai_id/codec_dai_id. Still check name first.
- if it doesn't match, it will keep checking whether cpu_id/codec_id match
corresponding dai_link cpu_dai_id/codec_dai_id. if the ids are equal, then a match is found. 2. if it does match, then a match is already found. no need to further check.
[...]
Could you help share your opinions? Thanks in advance.
Hi,
There is already snd_soc_of_get_dai_name() which will translate a phandle + specifier to a DAI name. By default it will use the DAI id for the specifier. Alternatively the driver can implement a of_xlate_dai_name callback that does the translation from specifier to name. The advantage of this approach is that the board driver does not need to know about the specific format of the DAI specifier.
- Lars
Hi Lars,
This API is powerful and meets my requirement. Thanks a lot.
I still have a small question. why don't we consider to also use DAI id to match DAIs & dai_link? It seems to be a more direct alternative. Please correct/instruct me if anything is wrong.
Matching by id would also work, I guess. But it doesn't really matter if name or id is used since both should be unique per CODEC. But what you shouldn't do is manually parse the id from the devicetree property in the machine driver since the specifier layout is CODEC specific and hence has to be parsed by the CODEC.
I think ideally the machine driver would pass the devicetree node and the name of the property that specifies the DAI to the core and the core would take care of everything else. As it is right now we first lookup the DAI by the of node and return the name of the DAI, then later on we use that name to lookup the DAI again. The second lookup is kind of superfluous since we already had a pointer to the DAI during the first lookup, so this is something that could be optimized if somebody was interested in optimizing this.
- Lars