On Tue, Jun 05, 2018 at 11:58:51AM +0200, Philipp Zabel wrote: > On Fri, 2018-05-25 at 18:24 +0100, Mark Brown wrote: > > If this is varying so drastically per board/system that it's relevant > > then we're already into problematic territory. For most devices we just > > have a number for the part, not something that varies so wildly that > > each system needs to configure it. > I'm not arguing this should be configured per individual device, just > per board DT. Even per board is a very surprising amount of variability TBH. > It's just that my experience of one datapoint consists of a board where > I had to increase the delay to about three times the delay calculated > from the nominal capacitance according to the datasheet before audible > artifacts disappeared reliably on multiple devices. > Putting the extended delay into the device tree with a comment > explaining its empirical nature seemed more straightforward than putting > a bogus capacitance value, that differs from the schematics, and that I > have never measured. The thing that's surprising me here is that there's even a board to board variance that's so bad that it needs to be configured like this - usually these things are just hard coded into the driver so they work for everyone rather than needing per-board tuning. It seems entirely possible that the formula quoted in the datasheet is just nonsense in general and that the driver would be better off using your number for all systems for example. If we do have to hard code something in the DT it seems better to hard code something that is at least coming from a spec rather than a measured number that needs to come from an average over a batch of boards since at least we can revise how we handle the number without needing to do something that shows up in the ABI. > Also, by using the capacitance we are guaranteed to end up with a codec > specific property name (adi,vmid-decoupling-capacitance ?) as opposed to > the possibility of defining a common delay property that could be used > for different codecs. That's actually something I want to avoid since the delays tend to need to come in the middle of write sequences which makes a general property a lot more complicated, and obviously some devices have multiple delays too.
Attachment:
signature.asc
Description: PGP signature
