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