On 05/12/2015 12:21 PM, Srinivas Kandagatla wrote:
+ adding Lars
On 12/05/15 05:06, Kenneth Westfield wrote:
Srinivas,
I was able to get audio working on the Storm board. There were several
issues. First, the I2S control port was saved in the DAI driver id field
(which was 4), but the DAI id field was used by the macro (which was 0).
The patch below fixed it:
Ah, I did not expect that to happen, dai->id and dai->driver->id should be
same. Surprisingly this is not true for IPQ806x platform only because dais
count == 1. Which results in dai->id not getting assigned to dai->driver->id
due to below code snippet in sound/soc/soc-core.c
--------------------><------------------------------------------
/*
* Back in the old days when we still had component-less DAIs,
* instead of having a static name, component-less DAIs would
* inherit the name of the parent device so it is possible to
* register multiple instances of the DAI. We still need to keep
* the same naming style even though those DAIs are not
* component-less anymore.
*/
if (count == 1 && legacy_dai_naming) {
dai->name = fmt_single_name(dev, &dai->id);
} else {
dai->name = fmt_multiple_name(dev, &dai_drv[i]);
if (dai_drv[i].id)
dai->id = dai_drv[i].id;
else
dai->id = i;
}
--------------------><------------------------------------------
Its not clear from code, why should we enter to legacy naming if the dais
count == 1 even-though the dai_drv has has valid name and id information.
Mark/Lars,
I can workaround this by using dai->driver->id in the driver, But do you
think that dai name and id should be assigned from dai drv if present?
I think it should be OK to extend that if condition to
if (count == 1 && dai_drv[0].id == 0 && legacy_dai_naming) ...
It doesn't look like any of the systems for which we currently take the
legacy path do set id to non 0. And the less new systems following legacy
naming scheme the better.
- Lars
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
