[PATCH 1/4] ASoC: dt-bindings: wlf,wm8524: Convert to json-schema
Convert the Wolfson WM8524 24-bit 192KHz Stereo DAC device tree binding documentation to json-schema.
Signed-off-by: Chancel Liu chancel.liu@nxp.com --- .../devicetree/bindings/sound/wlf,wm8524.yaml | 37 +++++++++++++++++++ .../devicetree/bindings/sound/wm8524.txt | 16 -------- 2 files changed, 37 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8524.yaml delete mode 100644 Documentation/devicetree/bindings/sound/wm8524.txt
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml new file mode 100644 index 000000000000..09c54cc7de95 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8524.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM8524 24-bit 192KHz Stereo DAC + +maintainers: + - patches@opensource.cirrus.com + +properties: + compatible: + const: wlf,wm8524 + + "#sound-dai-cells": + const: 0 + + wlf,mute-gpios: + maxItems: 1 + description: + a GPIO spec for the MUTE pin. + +required: + - compatible + - wlf,mute-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + wm8524: codec { + compatible = "wlf,wm8524"; + wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/sound/wm8524.txt b/Documentation/devicetree/bindings/sound/wm8524.txt deleted file mode 100644 index f6c0c263b135..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8524.txt +++ /dev/null @@ -1,16 +0,0 @@ -WM8524 audio CODEC - -This device does not use I2C or SPI but a simple Hardware Control Interface. - -Required properties: - - - compatible : "wlf,wm8524" - - - wlf,mute-gpios: a GPIO spec for the MUTE pin. - -Example: - -wm8524: codec { - compatible = "wlf,wm8524"; - wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; -};
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 after MCLK, BCLK and MUTE=1 are enabled. For more details about the timing constraints, please refer to WTN0302 on https://www.cirrus.com/products/wm8524/
Signed-off-by: Chancel Liu chancel.liu@nxp.com --- .../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 + default: 100 + description: + Power up sequency delay time in millisecond. It specifies power up to + audio out time. For more details about the timing constraints of this + device, please refer to WTN0302 on + https://www.cirrus.com/products/wm8524/. + required: - compatible - wlf,mute-gpios @@ -34,4 +43,5 @@ examples: wm8524: codec { compatible = "wlf,wm8524"; wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; + wlf,power-up-delay-ms = <300>; };
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 https://www.cirrus.com/products/wm8524/
Signed-off-by: Chancel Liu chancel.liu@nxp.com
.../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
- default: 100
- description:
Power up sequency delay time in millisecond. It specifies power up to
typo: sequence?
audio out time. For more details about the timing constraints of thisdevice, please refer to WTN0302 onhttps://www.cirrus.com/products/wm8524/.
According to WTN0302 this might or might not include regulator ramp-up-delay. You should clearly indicate which part of it this delay is to not mix up with ramp up. IOW, mention exactly from where the value comes (e.g. Δt POWER UP TO AUDIO OUT TIMING table, depending on sampling clock rate). Otherwise you introduce quite loose property which will be including regulator ramp up in some cases...
Best regards, Krzysztof
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@nxp.com
.../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 it's a better choice to let DT set the suitable value? Is there a similar situation before?
- default: 100
- description:
Power up sequency delay time in millisecond. It specifies power up totypo: sequence?
Sorry. I must avoid these spelling mistakes.
audio out time. For more details about the timing constraints of thisdevice, please refer to WTN0302 onAccording to WTN0302 this might or might not include regulator ramp-up-delay. You should clearly indicate which part of it this delay is to not mix up with ramp up. IOW, mention exactly from where the value comes (e.g. Δt POWER UP TO AUDIO OUT TIMING table, depending on sampling clock rate). Otherwise you introduce quite loose property which will be including regulator ramp up in some cases...
Best regards, Krzysztof
Yes. This property is designed for power up to audio out timing. I need to clearly point this out.
Thank you very much for your suggestions!
Regards, Chancel Liu
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@nxp.com
.../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:
- These timings may depend on the system design
- These timings may be simulated results
- 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
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@nxp.com
.../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:
- These timings may depend on the system design
- These timings may be simulated results
- 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
On Wed, Feb 22, 2023 at 07:39:43PM +0800, 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 after MCLK, BCLK and MUTE=1 are enabled. For more details about the timing constraints, please refer to WTN0302 on https://www.cirrus.com/products/wm8524/
According to that the delay is a property of MCLK and the sample rate rather than a per board constant, it shouldn't be in DT but rather the driver should figure out the required delay on each startup.
On Wed, Feb 22, 2023 at 07:39:43PM +0800, 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 after MCLK, BCLK and MUTE=1 are enabled. For more details about the timing constraints, please refer to WTN0302 on https://www.cirrus.com/products/wm8524/
According to that the delay is a property of MCLK and the sample rate rather than a per board constant, it shouldn't be in DT but rather the driver should figure out the required delay on each startup.
I can't agree with you more. From the power up to audio out timing table in WTN0302, the delay depends on sample rate and MCLK. Driver should calculate it rather than read it from DT. However as I mentioned in my last email, values in the table seem not accurate for all systems. It's a kind of compromise to get the value from DT. Do other codecs have a similar situation?
Thank you very much for your suggestions!
Regards, Chancel Liu
On 24/02/2023 11:56, Chancel Liu wrote:
On Wed, Feb 22, 2023 at 07:39:43PM +0800, 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 after MCLK, BCLK and MUTE=1 are enabled. For more details about the timing constraints, please refer to WTN0302 on https://www.cirrus.com/products/wm8524/
According to that the delay is a property of MCLK and the sample rate rather than a per board constant, it shouldn't be in DT but rather the driver should figure out the required delay on each startup.
I can't agree with you more. From the power up to audio out timing table in WTN0302, the delay depends on sample rate and MCLK. Driver should calculate it rather than read it from DT. However as I mentioned in my last email, values in the table seem not accurate for all systems. It's a kind of compromise to get the value from DT. Do other codecs have a similar situation?
DT is for hardware properties, not for software compromises.
Best regards, Krzysztof
wm8524 should be set to unmute while power up and set to mute while power off.
Signed-off-by: Chancel Liu chancel.liu@nxp.com --- sound/soc/codecs/wm8524.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/wm8524.c b/sound/soc/codecs/wm8524.c index b56dcac60244..8f2130e05b32 100644 --- a/sound/soc/codecs/wm8524.c +++ b/sound/soc/codecs/wm8524.c @@ -75,7 +75,7 @@ static int wm8524_startup(struct snd_pcm_substream *substream, SNDRV_PCM_HW_PARAM_RATE, &wm8524->rate_constraint);
- gpiod_set_value_cansleep(wm8524->mute, 1); + gpiod_set_value_cansleep(wm8524->mute, 0);
return 0; } @@ -86,7 +86,7 @@ static void wm8524_shutdown(struct snd_pcm_substream *substream, struct snd_soc_component *component = dai->component; struct wm8524_priv *wm8524 = snd_soc_component_get_drvdata(component);
- gpiod_set_value_cansleep(wm8524->mute, 0); + gpiod_set_value_cansleep(wm8524->mute, 1); }
static int wm8524_set_dai_sysclk(struct snd_soc_dai *codec_dai,
The recommended power sequence needs to be followed to ensure the best performance. After MCLK, BCLK and MUTE=1 are ready, this device has to wait some time before ready to output audio. Otherwise the beginning data may be lost. For more details about the timing constraints, please refer to WTN0302 on https://www.cirrus.com/products/wm8524/
Signed-off-by: Chancel Liu chancel.liu@nxp.com --- sound/soc/codecs/wm8524.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
diff --git a/sound/soc/codecs/wm8524.c b/sound/soc/codecs/wm8524.c index 8f2130e05b32..f61967b66c3b 100644 --- a/sound/soc/codecs/wm8524.c +++ b/sound/soc/codecs/wm8524.c @@ -21,6 +21,7 @@ #include <sound/soc.h> #include <sound/initval.h>
+#define WM8524_POWER_UP_DELAY_MS 100 #define WM8524_NUM_RATES 7
/* codec private data */ @@ -29,6 +30,7 @@ struct wm8524_priv { unsigned int sysclk; unsigned int rate_constraint_list[WM8524_NUM_RATES]; struct snd_pcm_hw_constraint_list rate_constraint; + unsigned int power_up_delay; };
@@ -157,6 +159,28 @@ static int wm8524_mute_stream(struct snd_soc_dai *dai, int mute, int stream) return 0; }
+static int wm8524_trigger(struct snd_pcm_substream *substream, int cmd, + struct snd_soc_dai *dai) +{ + struct wm8524_priv *wm8524 = snd_soc_dai_get_drvdata(dai); + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_RESUME: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + mdelay(wm8524->power_up_delay); + break; + case SNDRV_PCM_TRIGGER_STOP: + case SNDRV_PCM_TRIGGER_SUSPEND: + case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + break; + default: + return -EINVAL; + } + + return 0; +}; + #define WM8524_RATES SNDRV_PCM_RATE_8000_192000
#define WM8524_FORMATS (SNDRV_PCM_FMTBIT_S16_LE |\ @@ -169,6 +193,7 @@ static const struct snd_soc_dai_ops wm8524_dai_ops = { .set_sysclk = wm8524_set_dai_sysclk, .set_fmt = wm8524_set_fmt, .mute_stream = wm8524_mute_stream, + .trigger = wm8524_trigger, };
static struct snd_soc_dai_driver wm8524_dai = { @@ -213,6 +238,7 @@ MODULE_DEVICE_TABLE(of, wm8524_of_match);
static int wm8524_codec_probe(struct platform_device *pdev) { + struct device_node *np = pdev->dev.of_node; struct wm8524_priv *wm8524; int ret;
@@ -230,6 +256,9 @@ static int wm8524_codec_probe(struct platform_device *pdev) return ret; }
+ wm8524->power_up_delay = WM8524_POWER_UP_DELAY_MS; + of_property_read_u32(np, "wlf,power-up-delay-ms", &wm8524->power_up_delay); + ret = devm_snd_soc_register_component(&pdev->dev, &soc_component_dev_wm8524, &wm8524_dai, 1); if (ret < 0)
On Wed, Feb 22, 2023 at 07:39:45PM +0800, Chancel Liu wrote:
- switch (cmd) {
- case SNDRV_PCM_TRIGGER_START:
- case SNDRV_PCM_TRIGGER_RESUME:
- case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
mdelay(wm8524->power_up_delay);break;
Doing a 100ms busy wait in atomic context does not seem like a great idea, never mind a 1.5s one. This shouldn't be done in trigger, it needs to be done later - digital_mute() might be a better time to hook in, though longer delays like this are really quite bad.
On Wed, Feb 22, 2023 at 07:39:45PM +0800, Chancel Liu wrote:
- switch (cmd) {
- case SNDRV_PCM_TRIGGER_START:
- case SNDRV_PCM_TRIGGER_RESUME:
- case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
mdelay(wm8524->power_up_delay);break;Doing a 100ms busy wait in atomic context does not seem like a great idea, never mind a 1.5s one. This shouldn't be done in trigger, it needs to be done later - digital_mute() might be a better time to hook in, though longer delays like this are really quite bad.
Yes, such long time delay in driver is very bad. But this device requires waiting some time before able to output audio. We have to wait otherwise the beginning data may be lost.
The power up to audio out timing occurs after MCLK, BCLK and MUTE=1 are ready. I added the delay in trigger() because some CPU DAI drivers enable BCLK in trigger(). You suggested moving the delay to digital_mute(). It seems digital_mute() is called before cpu_dai->trigger. Please correct me if I'm wrong.
Regards, Chancel Liu
On Fri, Feb 24, 2023 at 10:54:59AM +0000, Chancel Liu wrote:
On Wed, Feb 22, 2023 at 07:39:45PM +0800, Chancel Liu wrote:
Doing a 100ms busy wait in atomic context does not seem like a great idea, never mind a 1.5s one. This shouldn't be done in trigger, it needs to be done later - digital_mute() might be a better time to hook in, though longer delays like this are really quite bad.
Yes, such long time delay in driver is very bad. But this device requires waiting some time before able to output audio. We have to wait otherwise the beginning data may be lost.
It's not just that it's doing this in the driver, it's doing it in the trigger() function which runs in atomic context. That's unreasonable.
The power up to audio out timing occurs after MCLK, BCLK and MUTE=1 are ready. I added the delay in trigger() because some CPU DAI drivers enable BCLK in trigger(). You suggested moving the delay to digital_mute(). It seems digital_mute() is called before cpu_dai->trigger. Please correct me if I'm wrong.
Hrm, right - in any case, it needs to be somewhere that isn't atomic context.
On Wed, Feb 22, 2023 at 07:39:45PM +0800, Chancel Liu wrote: Doing a 100ms busy wait in atomic context does not seem like a great idea, never mind a 1.5s one. This shouldn't be done in trigger, it needs to be done later - digital_mute() might be a better time to hook in, though longer delays like this are really quite bad.
Yes, such long time delay in driver is very bad. But this device requires waiting some time before able to output audio. We have to wait otherwise the beginning data may be lost.
It's not just that it's doing this in the driver, it's doing it in the trigger() function which runs in atomic context. That's unreasonable.
The power up to audio out timing occurs after MCLK, BCLK and MUTE=1 are ready. I added the delay in trigger() because some CPU DAI drivers enable BCLK in trigger(). You suggested moving the delay to digital_mute(). It seems digital_mute() is called before cpu_dai->trigger. Please correct me if I'm wrong.
Hrm, right - in any case, it needs to be somewhere that isn't atomic context.
OK. I will keep PATCH 1 and PATCH 3.
For PATCH 2 and PATCH 4, I have to find a better way in which long time delay can be avoided in atomic context.
Thank you very much for your comments.
Regards, Chancel Liu
On 22/02/2023 12:39, Chancel Liu wrote:
Convert the Wolfson WM8524 24-bit 192KHz Stereo DAC device tree binding documentation to json-schema.
Signed-off-by: Chancel Liu chancel.liu@nxp.com
.../devicetree/bindings/sound/wlf,wm8524.yaml | 37 +++++++++++++++++++ .../devicetree/bindings/sound/wm8524.txt | 16 -------- 2 files changed, 37 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8524.yaml delete mode 100644 Documentation/devicetree/bindings/sound/wm8524.txt
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml new file mode 100644 index 000000000000..09c54cc7de95 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8524.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: Wolfson WM8524 24-bit 192KHz Stereo DAC
+maintainers:
- patches@opensource.cirrus.com
$ref to dai-common.yaml
+properties:
- compatible:
- const: wlf,wm8524
- "#sound-dai-cells":
- const: 0
- wlf,mute-gpios:
- maxItems: 1
- description:
a GPIO spec for the MUTE pin.+required:
- compatible
- wlf,mute-gpios
+additionalProperties: false
and then this should be unevaluatedProperties: false
+examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- wm8524: codec {
compatible = "wlf,wm8524";
Use 4 spaces for example indentation.
Best regards, Krzysztof
participants (3)
-
Chancel Liu -
Krzysztof Kozlowski -
Mark Brown