[alsa-devel] [RFC-PATCH 0/2] ASoC: simple_card: support for hw-params rules

[kernel at martin.sperl.org]

> On 23.05.2016, at 19:18, Mark Rutland <mark.rutland at arm.com> wrote:
> 
> On Fri, May 20, 2016 at 12:30:43PM +0000, kernel at martin.sperl.org wrote:
>> From: Martin Sperl <kernel at martin.sperl.org>
>> 
>> Simple_card does require under some circumstances the ability
>> to configure certain hw_parameters based on clocks, bits, channels.
>> 
>> This patchset adds a generic way to configure these kind of things
>> via the device tree easily. This patchset implements this
>> for simple_card, but other drivers can just as easily make use of
>> this.
> 
> I'm not familiar with the class of hardware here.
> 
> What exactly needs to be configured, under which situations?

Well one example - here specifically is to set up bclk rates that
the I2S hw itself is transferring for specific combinations.

Some of these rules depend on:
* the i2s driver hw itself - the i2s bcm2835 can only handle 32 bit
  transfers - so the block size needs to be set as a multiple of 2.
  in this case: sample-bits * channels.
* HW limits - e.g 24 bit/sample need to get transferred as 32 bit
  for the rpi-pcm5102a combination
* Clock selection dependent - the choice of the block size
  may be also 40 or 80 bit so that a integer divider clock
  can get selected as a preference.
  E.g 32 bit/sample * 2 channels * 48kHz gives a divider of 25/4
  using the main oscillator at 19.2MHz, which introduces some
  (possibly) audible  noise due to jitter.
  while 40bit/sample * 2 channels * 48kHz gives an integer divider
  of 20.

So controlling those helps using the hw setup properly.

> 
> How varied is this in practice?
I heard about some other devices besides the HifiBerry DAC that
also would like to control the blockrate the same way.

I remember having seen some other possible things we want to
control on the driver side during hw-params invocation, but
I can not remember what these were on top of my head (GPIO,
external clock selection if I remember correctly)

> 
> Why does this make more sense than having individual drivers?
Because then the driver would have to know a lot more
about the combination of board and codec.

Also the idea proposed by Mark was to use simple-card
instead of a dedicated driver which does not allow for
these kind of controls.

The idea was also to make it generic enough that it could
get even become part of the framework.

> 
>> For now we have the following matchers and actions:
>> * matchers:
>>  * match_sample_bits
>>  * match_rate
>>  * match_channels
>> * actions:
>>  * set_fixed_bclk_size
>> 
>> As a note: the available matching rules and action rules right now
>> are hard-coded, but this could in principle get extended to be more
>> dynamic via kallsyms_lookup_name that would lookup the requested
>> symbol and assume it is a struct asoc_generic_hw_params_method,
>> on which it could apply several sanity-checks before using
>> the pointers for real.
> 
> I'm hoping that's a joke. ;)
Just food for thought, because otherwise there would be dependencies
on compiled codecs (or a long #ifdef list)

As an alternative we could also add a method tables to the codec
structure, so that codecs could expose additional methods, that could
then get used.

Martin