> On 13.05.2016, at 15:21, Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> On Fri, May 13, 2016 at 02:20:57PM +0200, Martin Sperl wrote:
>>> On 13.05.2016, at 12:54, Mark Brown <broonie@xxxxxxxxxx> wrote:
>
>>> You could almost use simple-card here but the BCLK ratio requirement is
>>> probably a bit much, I'm not immediately seeing a nice way to specify
>>> the ratio there since it depends on the sample width.
>
>> Actually it is just: <sample-width> * <number of channels>
>> where number of channels is fixed to 2 for bcm2835-i2s.
>
>> So maybe that already happens automatically in the framework?
>
> No, it's not handled. Lots of devices don't care or have different
> requirements (eg, 256fs). The tricky bit with specifying it is that the
> ratio depends on the sample width here but it might depend on something
> else with another device, or the number of channels might vary. That
> should be doable with DT but it feels like more trouble than it's
> reasonable to ask you to take here.
>
>> Something like this could get added to the core?
>> Is there interest in getting something like this?
>
>> Could look like this:
>> bclk-ratios =
>> /* for 96kHz at 16bit/channel use bclk-ratio 40 */
>> <96000 16 40>,
>> /* for 48kHz at 32bit/channel use bclk-ratio 80 */
>> <48000 16 80>,
>> /* for any (other) sample frequency at 16 bit use bclk-ratio 32 */
>> <0 16 32>,
>> /* for any (other) sample frequency at 32 bit use bclk-ratio 64 */
>> <0 32 64>;
>
>> but there could also be other approaches as well,
>> how this could get described in the device tree.
>
> You may well end up with something like that, yeah.
would something like this be a possibility:
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "HifiBerry DAC";
...
/* for 32bit@48k set bclk size to 40bit/channel = 80bits effectively */
hw-params-filter@0 {
match-rate = <48000>;
match-sample-bits = <32>;
match-channels = <2>;
action = "set-fixed-bclk-ratio";
action-value = <40>;
};
/* for 16bit@96k set bclk size to 20bit/channel = 40bits effectively */
hw-params-filter@1 {
match-rate = <96000>;
match-sample-bits = <16>;
match-channels = <2>;
action = "set-fixed-bclk-ratio";
action-value = <40>;
};
/* for all others take sample_bits * channel */
hw-params-filter@999 {
action = "set-bclk-ratio-multiple-sample-bits-channels";
};
};
The title of nodes and properties can easily get changed.
Additional "match-*” properties can also get added easily.
The biggest question is about "action" or maybe “actions”
(in the sense of an array, so that there can be multiple actions)?
Then if this should remain a string or should it be an id
(that we would need to define in an include)…
More actions could get added easily - there could even be a
framework that would allow drivers to specify more actions
inside different drivers that are assigned here.
I would think that the “first” one matches - order would be
enforced based on node name.
This would just get added to asoc_simple_card_hw_params.
This does not seem too complicated to create.
Thanks,
Martin--
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
