On Fri, Apr 30, 2010 at 7:18 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Apr 29, 2010 at 04:22:17PM -0500, Timur Tabi wrote:
int snd_soc_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) { if (dai->driver && dai->driver->ops->set_fmt) return dai->driver->ops->set_fmt(dai, fmt); else return 0; }
Due to the above issue I don't think this is a good idea - we really ought to let the machine driver know if the request it made was ignored in case it is trying to set up something that can't be supported. Another short term option would be to change the error code to be something a bit more distinctive than -EINVAL. If we want to support very generic machine drivers that genuinely don't know what hardware is able to do I think we'd be be better off doing something like adding capability masks to the drivers so these functions can validate what they're being asked to do, at which point we know the actual format so returning 0 isn't an issue.
The current expectation is that the machine driver knows what the hardware is capable of and won't try to set anything silly, in the case of fixed format devices that don't implement set_fmt() that consists of just not calling set_fmt() for the DAI at all.
Though I am ok with the status quo -- snd_soc_dai_ops members being truly optional and machine driver writers knowing both the DAIs and calling only appropriate functions, but if we are to move to more generic machine drivers how about hiding such members of snd_soc_dai_ops from machine drivers and let the machine drivers specify the exact requirement to ASoC via some generic enough data structure. Part of that configuration can be done by ASoC while the platform specific stuff passed onto DAI drivers.