Hi Mark, On Fri, 2018-05-25 at 18:24 +0100, Mark Brown wrote: > On Fri, May 25, 2018 at 05:18:09PM +0200, Philipp Zabel wrote: > > On Fri, 2018-05-25 at 15:52 +0100, Mark Brown wrote: > > > On Fri, May 25, 2018 at 01:42:53PM +0200, Marco Felsch wrote: > > > > Also the formula for the delay time (t = C × 25,000/3.5) depends only on > > > > the capacity size. > > > Why not just have the user specify the capacitance of the capacitor on > > > the rail which they can directly read from the schematic rather than > > > forcing them to do the calcualtion? That seems a bit clearer and more > > > user friendly (plus if someone decides the spec was wrong it's easier to > > > roll out fixes). > > The exact capacitance may not be known or vary above the nominal value > > because of cheap components, and the formula from the datasheet is just > > a guideline. > > That variability is going to apply just as much to the charge time > calculations/measurements as it is to the initial capacitance value - > the results are going to be very much garbage in, garbage out. True. > > I'd expect the usual method to set this delay to be semi-empirical: > > "start from the value calculated from datasheet and schematics and then > > increase until no more audio artifacts on a representative sample of > > boards". > > I think it is be better to specify a delay that works than a bogus > > capacitance value that happens to correspond to a delay that works. > > 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. 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. 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. regards Philipp -- 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
