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
--
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
