January 2021 - Alsa-devel - mailman.alsa-project.org

[PATCH] ALSA: hda: Add AlderLake-P PCI ID and HDMI codec vid
by Kai Vehmanen 13 Jan '21

13 Jan '21

Add HD Audio PCI ID and HDMI codec vendor ID for Intel AlderLake-P. Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> --- sound/pci/hda/hda_intel.c | 3 +++ sound/pci/hda/patch_hdmi.c | 1 + 2 files changed, 4 insertions(+) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f36ddf1149a6..279739fa3a7d 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2507,6 +2507,9 @@ static const struct pci_device_id azx_ids[] = { /* Alderlake-S */ { PCI_DEVICE(0x8086, 0x7ad0), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + /* Alderlake-P */ + { PCI_DEVICE(0x8086, 0x51c8), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, /* Elkhart Lake */ { PCI_DEVICE(0x8086, 0x4b55), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 74d246a0dc6d..97adff0cbcab 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -4346,6 +4346,7 @@ HDA_CODEC_ENTRY(0x8086280f, "Icelake HDMI", patch_i915_icl_hdmi), HDA_CODEC_ENTRY(0x80862812, "Tigerlake HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862814, "DG1 HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862815, "Alderlake HDMI", patch_i915_tgl_hdmi), +HDA_CODEC_ENTRY(0x8086281c, "Alderlake-P HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862816, "Rocketlake HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x8086281a, "Jasperlake HDMI", patch_i915_icl_hdmi), HDA_CODEC_ENTRY(0x8086281b, "Elkhartlake HDMI", patch_i915_icl_hdmi), -- 2.29.2

2 1

USB Wireless device support
by Bastien Nocera 13 Jan '21

13 Jan '21

Hey, I've recently bought a SteelSeries Arctis 1 wireless headset: https://steelseries.com/gaming-headsets/arctis-1-wireless-xbox and wanted to write a kernel driver to export a few features of the device, and needed some help getting started. The receiver shows up as a audio class USB device, with extra features on a separate USB interface.[1] The extra features that can be accessed are: - Presence detection. I wanted to use that so PulseAudio or Pipewire could make routing decisions based on whether the headset is available, or probably better, implementing a "jack detection" emulation for the main audio interface? - A slider to change the sidetone volume - Export the battery level The latter is the only one I know how to do, so I'd be happy with any pointers or examples about the first two items. Cheers [1]: User-space code that accesses those features: https://github.com/Sapd/HeadsetControl/blob/master/src/devices/steelseries_…

2 8

[PATCH v4 1/3] ASoC: SOF: Intel: hda: Resume codec to do jack detection
by Kai-Heng Feng 13 Jan '21

13 Jan '21

Instead of queueing jackpoll_work, runtime resume the codec to let it use different jack detection methods based on jackpoll_interval. This partially matches SOF driver's behavior with commit a6e7d0a4bdb0 ("ALSA: hda: fix jack detection with Realtek codecs when in D3"), the difference is SOF unconditionally resumes the codec. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- v4: No change. v3: Remove wrong assumption that only Realtek codec is used by SOF. v2: No change. sound/soc/sof/intel/hda-codec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index 6875fa570c2c..df59c79cfdfc 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -93,8 +93,7 @@ void hda_codec_jack_check(struct snd_sof_dev *sdev) * has been recorded in STATESTS */ if (codec->jacktbl.used) - schedule_delayed_work(&codec->jackpoll_work, - codec->jackpoll_interval); + pm_request_resume(&codec->core.dev); } #else void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev) {} -- 2.29.2

3 4

[PATCH 1/3] ASoC: atmel-pdc: Use managed DMA buffer allocation
by Lars-Peter Clausen 13 Jan '21

13 Jan '21

Instead of manually managing its DMA buffers using dma_{alloc,free}_coherent() lets the sound core take care of this using managed buffers. On one hand this reduces the amount of boiler plate code, but the main motivation for the change is to use the shared code where possible. This makes it easier to argue about correctness and that the code does not contain subtle bugs like data leakage or similar. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/atmel/atmel-pcm-pdc.c | 78 ++------------------------------- 1 file changed, 4 insertions(+), 74 deletions(-) diff --git a/sound/soc/atmel/atmel-pcm-pdc.c b/sound/soc/atmel/atmel-pcm-pdc.c index 704f700013d3..3e7ea2021b46 100644 --- a/sound/soc/atmel/atmel-pcm-pdc.c +++ b/sound/soc/atmel/atmel-pcm-pdc.c @@ -34,86 +34,21 @@ #include "atmel-pcm.h" -static int atmel_pcm_preallocate_dma_buffer(struct snd_pcm *pcm, - int stream) -{ - struct snd_pcm_substream *substream = pcm->streams[stream].substream; - struct snd_dma_buffer *buf = &substream->dma_buffer; - size_t size = ATMEL_SSC_DMABUF_SIZE; - - buf->dev.type = SNDRV_DMA_TYPE_DEV; - buf->dev.dev = pcm->card->dev; - buf->private_data = NULL; - buf->area = dma_alloc_coherent(pcm->card->dev, size, - &buf->addr, GFP_KERNEL); - pr_debug("atmel-pcm: alloc dma buffer: area=%p, addr=%p, size=%zu\n", - (void *)buf->area, (void *)(long)buf->addr, size); - - if (!buf->area) - return -ENOMEM; - - buf->bytes = size; - return 0; -} - -static int atmel_pcm_mmap(struct snd_soc_component *component, - struct snd_pcm_substream *substream, - struct vm_area_struct *vma) -{ - return remap_pfn_range(vma, vma->vm_start, - substream->dma_buffer.addr >> PAGE_SHIFT, - vma->vm_end - vma->vm_start, vma->vm_page_prot); -} - static int atmel_pcm_new(struct snd_soc_component *component, struct snd_soc_pcm_runtime *rtd) { struct snd_card *card = rtd->card->snd_card; - struct snd_pcm *pcm = rtd->pcm; int ret; ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32)); if (ret) return ret; - if (pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream) { - pr_debug("atmel-pcm: allocating PCM playback DMA buffer\n"); - ret = atmel_pcm_preallocate_dma_buffer(pcm, - SNDRV_PCM_STREAM_PLAYBACK); - if (ret) - goto out; - } + snd_pcm_set_managed_buffer_all(rtd->pcm, SNDRV_DMA_TYPE_DEV, + card->dev, ATMEL_SSC_DMABUF_SIZE, + ATMEL_SSC_DMABUF_SIZE); - if (pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream) { - pr_debug("atmel-pcm: allocating PCM capture DMA buffer\n"); - ret = atmel_pcm_preallocate_dma_buffer(pcm, - SNDRV_PCM_STREAM_CAPTURE); - if (ret) - goto out; - } - out: - return ret; -} - -static void atmel_pcm_free(struct snd_soc_component *component, - struct snd_pcm *pcm) -{ - struct snd_pcm_substream *substream; - struct snd_dma_buffer *buf; - int stream; - - for (stream = 0; stream < 2; stream++) { - substream = pcm->streams[stream].substream; - if (!substream) - continue; - - buf = &substream->dma_buffer; - if (!buf->area) - continue; - dma_free_coherent(pcm->card->dev, buf->bytes, - buf->area, buf->addr); - buf->area = NULL; - } + return 0; } /*--------------------------------------------------------------------------*\ @@ -210,9 +145,6 @@ static int atmel_pcm_hw_params(struct snd_soc_component *component, /* this may get called several times by oss emulation * with different params */ - snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer); - runtime->dma_bytes = params_buffer_bytes(params); - prtd->params = snd_soc_dai_get_dma_data(asoc_rtd_to_cpu(rtd, 0), substream); prtd->params->dma_intr_handler = atmel_pcm_dma_irq; @@ -384,9 +316,7 @@ static const struct snd_soc_component_driver atmel_soc_platform = { .prepare = atmel_pcm_prepare, .trigger = atmel_pcm_trigger, .pointer = atmel_pcm_pointer, - .mmap = atmel_pcm_mmap, .pcm_construct = atmel_pcm_new, - .pcm_destruct = atmel_pcm_free, }; int atmel_pcm_pdc_platform_register(struct device *dev) -- 2.20.1

3 4

[PATCH 0/2] Enable DMA mode on Intel Keem Bay platform
by Michael Sit Wei Hong 13 Jan '21

13 Jan '21

v1: Initial patch version, to enable DMA mode on Intel Keembay platform. Michael Sit Wei Hong (2): dt-bindings: sound: intel, keembay-i2s: Add info for device to use DMA ASoC: Intel: KMB: Enable DMA transfer mode .../bindings/sound/intel,keembay-i2s.yaml | 14 ++ sound/soc/intel/Kconfig | 2 + sound/soc/intel/keembay/kmb_platform.c | 157 ++++++++++++++++-- sound/soc/intel/keembay/kmb_platform.h | 9 + 4 files changed, 167 insertions(+), 15 deletions(-) -- 2.17.1

4 6

[PATCH] ASoC: qcom: qdsp6: Move frontend AIFs to q6asm-dai
by Stephan Gerhold 13 Jan '21

13 Jan '21

At the moment it is necessary to set up the DAPM routes between front-end AIF<->DAI explicitly in the device tree, e.g. using audio-routing = "MM_DL1", "MultiMedia1 Playback", "MM_DL3", "MultiMedia3 Playback", "MM_DL4", "MultiMedia4 Playback", "MultiMedia2 Capture", "MM_UL2"; This is prone to mistakes and (sadly) there is no clear error if one of these routes is missing. :( Actually, this should not be necessary because the ASoC core normally automatically links AIF<->DAI within snd_soc_dapm_link_dai_widgets(). This is done using the "stname" parameter of SND_SOC_DAPM_AIF_IN/OUT. For SND_SOC_DAPM_AIF_IN("MM_DL1", "MultiMedia1 Playback", 0, 0, 0, 0), it should create the route from above: MM_DL1 <-> MultiMedia1 Playback. This does not work at the moment because the AIF widget (MM_DL1) and the DAI widget (MultiMedia1 Playback) belong to different DAPM contexts (q6routing / q6asm-dai). Fix this by declaring the AIF widgets in the same driver as the DAIs (q6asm-dai). Now the routes above are created automatically and no longer need to be specified in the device tree. This is also more consistent with the back-end AIFs which are already declared in q6afe-dais instead of q6routing. q6routing should only link the components together using mixers. Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Fixes: 2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver") Signed-off-by: Stephan Gerhold <stephan(a)gerhold.net> --- sound/soc/qcom/qdsp6/q6asm-dai.c | 21 +++++++++++++++++++++ sound/soc/qcom/qdsp6/q6routing.c | 18 ------------------ 2 files changed, 21 insertions(+), 18 deletions(-) diff --git a/sound/soc/qcom/qdsp6/q6asm-dai.c b/sound/soc/qcom/qdsp6/q6asm-dai.c index c9ac9c1d26c4..9766725c2916 100644 --- a/sound/soc/qcom/qdsp6/q6asm-dai.c +++ b/sound/soc/qcom/qdsp6/q6asm-dai.c @@ -1233,6 +1233,25 @@ static void q6asm_dai_pcm_free(struct snd_soc_component *component, } } +static const struct snd_soc_dapm_widget q6asm_dapm_widgets[] = { + SND_SOC_DAPM_AIF_IN("MM_DL1", "MultiMedia1 Playback", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_IN("MM_DL2", "MultiMedia2 Playback", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_IN("MM_DL3", "MultiMedia3 Playback", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_IN("MM_DL4", "MultiMedia4 Playback", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_IN("MM_DL5", "MultiMedia5 Playback", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_IN("MM_DL6", "MultiMedia6 Playback", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_IN("MM_DL7", "MultiMedia7 Playback", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_IN("MM_DL8", "MultiMedia8 Playback", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("MM_UL1", "MultiMedia1 Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("MM_UL2", "MultiMedia2 Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("MM_UL3", "MultiMedia3 Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("MM_UL4", "MultiMedia4 Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("MM_UL5", "MultiMedia5 Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("MM_UL6", "MultiMedia6 Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("MM_UL7", "MultiMedia7 Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("MM_UL8", "MultiMedia8 Capture", 0, SND_SOC_NOPM, 0, 0), +}; + static const struct snd_soc_component_driver q6asm_fe_dai_component = { .name = DRV_NAME, .open = q6asm_dai_open, @@ -1245,6 +1264,8 @@ static const struct snd_soc_component_driver q6asm_fe_dai_component = { .pcm_construct = q6asm_dai_pcm_new, .pcm_destruct = q6asm_dai_pcm_free, .compress_ops = &q6asm_dai_compress_ops, + .dapm_widgets = q6asm_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(q6asm_dapm_widgets), }; static struct snd_soc_dai_driver q6asm_fe_dais_template[] = { diff --git a/sound/soc/qcom/qdsp6/q6routing.c b/sound/soc/qcom/qdsp6/q6routing.c index 53185e26fea1..0a6b9433f6ac 100644 --- a/sound/soc/qcom/qdsp6/q6routing.c +++ b/sound/soc/qcom/qdsp6/q6routing.c @@ -713,24 +713,6 @@ static const struct snd_kcontrol_new mmul8_mixer_controls[] = { Q6ROUTING_TX_MIXERS(MSM_FRONTEND_DAI_MULTIMEDIA8) }; static const struct snd_soc_dapm_widget msm_qdsp6_widgets[] = { - /* Frontend AIF */ - SND_SOC_DAPM_AIF_IN("MM_DL1", "MultiMedia1 Playback", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_IN("MM_DL2", "MultiMedia2 Playback", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_IN("MM_DL3", "MultiMedia3 Playback", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_IN("MM_DL4", "MultiMedia4 Playback", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_IN("MM_DL5", "MultiMedia5 Playback", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_IN("MM_DL6", "MultiMedia6 Playback", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_IN("MM_DL7", "MultiMedia7 Playback", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_IN("MM_DL8", "MultiMedia8 Playback", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_OUT("MM_UL1", "MultiMedia1 Capture", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_OUT("MM_UL2", "MultiMedia2 Capture", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_OUT("MM_UL3", "MultiMedia3 Capture", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_OUT("MM_UL4", "MultiMedia4 Capture", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_OUT("MM_UL5", "MultiMedia5 Capture", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_OUT("MM_UL6", "MultiMedia6 Capture", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_OUT("MM_UL7", "MultiMedia7 Capture", 0, 0, 0, 0), - SND_SOC_DAPM_AIF_OUT("MM_UL8", "MultiMedia8 Capture", 0, 0, 0, 0), - /* Mixer definitions */ SND_SOC_DAPM_MIXER("HDMI Mixer", SND_SOC_NOPM, 0, 0, hdmi_mixer_controls, -- 2.29.2

2 1

[PATCH] ASoC: cs42l56: fix up error handling in probe
by Dan Carpenter 13 Jan '21

13 Jan '21

There are two issues with this code. The first error path forgot to set the error code and instead returns success. The second error path doesn't clean up. Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- sound/soc/codecs/cs42l56.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/cs42l56.c b/sound/soc/codecs/cs42l56.c index bb9599cc832b..c44a5cdb796e 100644 --- a/sound/soc/codecs/cs42l56.c +++ b/sound/soc/codecs/cs42l56.c @@ -1250,6 +1250,7 @@ static int cs42l56_i2c_probe(struct i2c_client *i2c_client, dev_err(&i2c_client->dev, "CS42L56 Device ID (%X). Expected %X\n", devid, CS42L56_DEVID); + ret = -EINVAL; goto err_enable; } alpha_rev = reg & CS42L56_AREV_MASK; @@ -1307,7 +1308,7 @@ static int cs42l56_i2c_probe(struct i2c_client *i2c_client, ret = devm_snd_soc_register_component(&i2c_client->dev, &soc_component_dev_cs42l56, &cs42l56_dai, 1); if (ret < 0) - return ret; + goto err_enable; return 0; -- 2.29.2

2 1

[PATCH 0/6] ASoC: soc-pcm: cleanup code
by Kuninori Morimoto 13 Jan '21

13 Jan '21

Hi Mark These are not so important, but for soc-pcm cleanup patches. Kuninori Morimoto (6): ASoC: soc-pcm: move dpcm_set_fe_update_state() ASoC: soc-pcm: add dpcm_set_be_update_state() ASoC: soc-pcm: add soc_pcm_set_dai_params() ASoC: soc-pcm: cleanup soc_pcm_apply_symmetry() ASoC: soc-pcm: cleanup soc_pcm_params_symmetry() ASoC: soc-pcm: setup pcm at one place in soc_new_pcm() sound/soc/soc-pcm.c | 231 +++++++++++++++++--------------------------- 1 file changed, 90 insertions(+), 141 deletions(-) -- 2.25.1 Thank you for your help !! Best regards --- Kuninori Morimoto

2 8

[RFC PATCH v2 0/2] Enable using multiple kcontrol types in a widget
by Jaska Uimonen 13 Jan '21

13 Jan '21

Hi, I'm requesting comments to this small series to enable multiple different kcontrol types for a single widget. Currently asoc allows to define and parse multiple same type kcontrols for single widget. So you can have for example two volume controls in a widget but not for example one byte and one enum control. I personally had this kind of use case where I wanted to set filter coefficients with bytes and something else with an enum in one processing widget. I don't have that good perspective on the asoc history on this part so I don't know is there some reason for the existing logic or is it just ok to change it like in this series. I've been told some drivers use virtual widget for this kind of situation, so they define two widget's (one virtual) with separate controls, but in reality bind the controls into the same component in lower level. Or can we just actually use separate types in one widget? First patch is changing the kcontrol_type uint in dapm widget to a pointer to hold an array of kcontrol types and then creating these different types in a loop in dapm widget load. Second patch is me utilizing this in sof driver. Changes since v1: - don't add kcontrol type to core i.e. to kcontrol and kcontrol_news - extend existing dapm widget kcontrol_type into holding an array of types Jaska Uimonen (2): ASoC: soc-dapm: enable use of multiple control types ASoC: SOF: topology: use individual kcontrol types include/sound/soc-topology.h | 2 +- sound/soc/soc-topology.c | 466 +++++++++++++++++------------------ sound/soc/sof/topology.c | 13 +- 3 files changed, 232 insertions(+), 249 deletions(-) -- 2.24.1

1 2

[RFC PATCH 0/3] Enable using multiple kcontrol types in a widget
by Jaska Uimonen 13 Jan '21

13 Jan '21

Hi, I'm requesting comments to this small series to enable multiple different kcontrol types for a single widget. Currently asoc allows to define and parse multiple same type kcontrols for single widget. So you can have for example two volume controls in a widget but not for example one byte and one enum control. I personally had this kind of use case where I wanted to set filter coefficients with bytes and something else with an enum in one processing widget. I don't have that good perspective on the asoc history on this part so I don't know is there some reason for the existing logic or is it just ok to change it like in this series. I've been told some drivers use virtual widget for this kind of situation, so they define two widget's (one virtual) with separate controls, but in reality bind the controls into the same component in lower level. Or can we just actually use separate types in one widget? First patch is just adding the type field to kcontrol struct. Second patch is a refactoring to take into account the different control types in parsing the topology. So it looks a little bit messy, but is just actually looping through the types in the kcontrol creation. Third patch is me using this in sof driver, so not so directly needed here. I've tested this thing personally up from topology down till the dsp and for me it seems to work, but as said I can't be sure if I'm breaking something else here. Jaska Uimonen (3): ALSA: control: add kcontrol_type to control ASoC: soc-topology: enable use of multiple control types ASoC: SOF: topology: use individual kcontrol types include/sound/control.h | 2 + sound/core/control.c | 2 + sound/soc/soc-topology.c | 462 ++++++++++++++++++--------------------- sound/soc/sof/topology.c | 13 +- 4 files changed, 230 insertions(+), 249 deletions(-) -- 2.24.1

3 6