On Tue, Mar 03, 2015 at 12:09:14PM +0200, Jyri Sarha wrote:
On 03/02/2015 09:58 PM, Lars-Peter Clausen wrote:
Can you include a description why this is needed and how and when it is supposed to be used?
Would this addition do:
These constraints help to disable the sample-format and sample-rate combinations that do not properly work on a specific HW.
Not entirely...
The reason why we need these is coming from limitations in McASP clock generation. With a simple divider one can only produce certain bit-clocks. With those bit-clocks we can only play/capture some sample-rate and sample-width combinations accurately.
The McASP driver could try to set the constraints automatically. However, since the constraint code can not select sample-width and sample-rate combinations there is a compromise to be made between them. Making such compromises automatically does not usually work that well.
...this is more the point. Perhaps the constraints language needs improvement here?
In our case these properties could of course be added to McASP driver, but then again I would expect that there is a wider need for this kind of functionality. And it may not always be clear if either end of the link alone is responsible for less than perfect operation.
The trouble with this sort of interface is that it's a quick and dirty way for people to bodge around things rather than actually fixing them properly. Of course sometimes fixing things properly is really hard and that means we want a temporary bodge but having to put them in DT is really unfortunate.