[alsa-devel] [PATCH 2/2] ASoC: simple-card: Add support for samplerate and samplewidth constraints

[Jyri Sarha]

On 03/03/2015 05:34 PM, Mark Brown wrote:
> On Tue, Mar 03, 2015 at 02:00:31PM +0200, Jyri Sarha wrote:
>> On 03/03/2015 01:30 PM, Mark Brown wrote:
>
>>> ...this is more the point.  Perhaps the constraints language needs
>>> improvement here?
>
>> Improving constraint functionality would certainly help, however the way
>> that code works is beyond my understanding and I do not believe such an
>> improvement would be coming from anybody else any time soon either.
>
> It's probably worth putting together a description of the constraint and
> asking people like Takashi who understand the code - ideally it'd be
> easy to implement but I suspect you're right about timescales.
>

Now that Lars-Peter pointed me to the right direction, it seems there is 
a proper way to deal with issue after all.

>>> 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.
>
>> I agree with that. However, the simple-card binding goes already now quite a
>> bit beyond just describing the hardware. The binding for instance decides
>> the configuration that is going to be used over the dai-link. These
>> constraints could be seen as an extension to that configuration.
>
>> I am wondering if there would be some better way to select the dai-link
>> configuration than writing it to DT or creating a custom machine driver for
>> each setup.
>

Continuing this tought. I wonder if it would be better to introduce a 
new compatible match for each new card, with some clever way to manage 
the accumulating matches in the code, and hard code DAI-link 
configurations for each match. This way the old configurations would not 
be carved to stone in the old dtbs.

>> But about this patch. Should I just give it up, or would you be willing to
>> apply it if I improve the description more and add a warning against using
>> these properties to work around driver bugs to the binding document?
>
> I'm not totally against the idea so it's worth continuing.  Just not
> happy either but computer.
>
> It just occurred to me that we may be able to sidestep the issue by
> calling them "suggested rates/widths" so the implementation can ignore
> them later.  That's a *tiny* bit gross but does sidestep the ABI issues.
>

As there is a proper way to deal with this, I'll look into that first. 
However, if there still is a need for these properties I am happy to 
finish the patch.

Best regards,
Jyri