On Fri, May 25, 2018 at 4:47 AM, Marco Felsch <m.felsch@xxxxxxxxxxxxxx> wrote: > Hi Rob, > > On 18-05-23 11:53, Rob Herring wrote: >> On Fri, May 18, 2018 at 12:46:49PM +0200, Philipp Zabel wrote: >> > Hi Rob, >> > >> > On Thu, 2018-05-17 at 11:14 -0500, Rob Herring wrote: >> > > On Thu, May 17, 2018 at 8:30 AM, Marco Felsch <m.felsch@xxxxxxxxxxxxxx> wrote: >> > > > From: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> >> > > > >> > > > According to the ssm2603 data sheet (control register sequencing), the >> > > > digital core should be activated only after all necessary bits in the >> > > > power register are enabled, and a delay determined by the decoupling >> > > > capacitor on the VMID pin has passed. If the digital core is activated >> > > > too early, or even before the ADC is powered up, audible artifacts >> > > > appear at the beginning of the recorded signal. >> > > > >> > > > The digital core is also needed for playback, so when recording starts >> > > > it may already be enabled. This means we cannot get the power sequence >> > > > correct when we want to be able to start recording after playback. >> > > > >> > > > As a workaround put the MIC mute switch into the DAPM routes. This >> > > > way we can keep the recording disabled until the MIC Bias has settled >> > > > and thus get rid of audible artifacts. >> > > > >> > > > The delay we have to wait depends on a board specific capacitor >> > > > connected to the VMID pins, so make the delay configurable in the device >> > > > tree. >> > > > >> > > > Signed-off-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> >> > > > Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> >> > > > Signed-off-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> >> > > > --- >> > > > .../devicetree/bindings/sound/adi,ssm2602.txt | 7 +++++ >> > > > sound/soc/codecs/ssm2602.c | 30 +++++++++++++++++-- >> > > > 2 files changed, 35 insertions(+), 2 deletions(-) >> > > > >> > > > diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2602.txt b/Documentation/devicetree/bindings/sound/adi,ssm2602.txt >> > > > index 3b3302fe399b..9334d48c0462 100644 >> > > > --- a/Documentation/devicetree/bindings/sound/adi,ssm2602.txt >> > > > +++ b/Documentation/devicetree/bindings/sound/adi,ssm2602.txt >> > > > @@ -11,9 +11,16 @@ Required properties: >> > > > - reg : the I2C address of the device for I2C, the chip select >> > > > number for SPI. >> > > > >> > > > +Optional properties: >> > > > + >> > > > + - startup-delay-us : delay between powering on and activating the digital >> > > > + core, determined by the decoupling capacitor C on the >> > > > + VMID pin: delay [µs] = C [µF] * 25000 / 3.5 >> > > > + >> > > >> > > We already have similarly defined property. Please reuse that. See mmc >> > > pwrseq binding. >> > >> > Do you mean 'post-power-on-delay-ms' from 'mmc-pwseq-simple'? >> > It is documented as: >> > >> > - post-power-on-delay-ms : Delay in ms after powering the card and >> > de-asserting the reset-gpios (if any) >> > >> > The startup delay here is not after powering the whole IC or deasserting >> > resets and before it can be used, but after powering up a specific part >> > of the codec (the ADC) and before unmuting the MIC input to the digital >> > core during start of decoding. With this in mind, do you still think the >> > property should be called the same as the mmc full-chip poweron delay? >> > If so, would it be acceptable to use post-power-on-delay-us to keep the >> > microsecond resolution? >> >> Okay, then I'd suggest something a bit more specific. Perhaps >> "pre-unmute-delay-us" and document in a common location. >> >> Rob > > The delay is not just for the line-in/mic path it is also for the out > path. More technical, it is needed to charge the decouple capacity which > provides the voltage bias for the analog input/output frontends. > > I found the: "ti,charge-period (sound/ti,tas5086.txt)" binding which > represents nearly the same but it is not common. One opportunity would be to > introduce a common "charge-period-us" binding and change the ti binding the > common binding later. > > Would that be okay? Sure, sounds fine to me. Rob -- 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
