On 23.05.2016, at 19:18, Mark Rutland mark.rutland@arm.com wrote:
On Fri, May 20, 2016 at 12:30:43PM +0000, kernel@martin.sperl.org wrote:
From: Martin Sperl kernel@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