> On 24/02/2023 11:54, Chancel Liu wrote: > >> On 22/02/2023 12:39, Chancel Liu wrote: > >>> This property specifies power up to audio out time. It's necessary > >>> beacause this device has to wait some time before ready to output audio > >> > >> typo... run spellcheck, also on the subject > >> > >>> after MCLK, BCLK and MUTE=1 are enabled. For more details about the > >>> timing constraints, please refer to WTN0302 on > >>> > >>> > >>> Signed-off-by: Chancel Liu <chancel.liu@xxxxxxx> > >>> --- > >>> .../devicetree/bindings/sound/wlf,wm8524.yaml | 10 > >> ++++++++++ > >>> 1 file changed, 10 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml > >> b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml > >>> index 09c54cc7de95..54b4da5470e4 100644 > >>> --- a/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml > >>> +++ b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml > >>> @@ -21,6 +21,15 @@ properties: > >>> description: > >>> a GPIO spec for the MUTE pin. > >>> > >>> + wlf,power-up-delay-ms: > >>> + maximum: 1500 > >> > >> maximum is 1003. Where do you see 1500? > >> > >> minimum: 82 > >> > > > > Yes, you are absolutely right. From the power up to audio out timing table in > > WTN0302, the minimum number is 82 and the maximum is 1003. > > > > Consider the following possibilities: > > 1. These timings may depend on the system design > > 2. These timings may be simulated results > > 3. These timings may be the minimum values > > > > I set a larger value trying to extend the time. The larger value of course > > introduces unwanted time delay but it benefits on avoiding beginning audio > > lost. > > > > I also did some tests on a board. If I want to work on 48KHZ sample rate and > > 512FS, the recommended value is 143. But the test result showed 143ms is not > > enough. I increased the value to 500ms and could hear the beginning sound. > > Maybe you miss proper regulator ramp-up? > > > > > Maybe it's a better choice to let DT set the suitable value? Is there a similar > > situation before? > > That's not really good argument. DT should describe hardware and if this > property does not match hardware, it means you mix this with something > else. Something not for DT. > > > Best regards, > Krzysztof OK. The patches for adding such property are not really good. I need to find a better way to address the issue. I think PATCH 1 and PATCH 3 can be kept. So I will modify them according comments. Thank you for your review. That benefits me a lot. Regards, Chancel Liu
