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. > >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. > 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.
Attachment:
signature.asc
Description: Digital signature
