December 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH AUTOSEL 5.4 214/350] ALSA: timer: Limit max amount of slave instances
by Sasha Levin 10 Dec '19

10 Dec '19

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit fdea53fe5de532969a332d6e5e727f2ad8bf084d ] The fuzzer tries to open the timer instances as much as possible, and this may cause a system hiccup easily. We've already introduced the cap for the max number of available instances for the h/w timers, and we should put such a limit also to the slave timers, too. This patch introduces the limit to the multiple opened slave timers. The upper limit is hard-coded to 1000 for now, which should suffice for any practical usages up to now. Link: https://lore.kernel.org/r/20191106154257.5853-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/core/timer.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index 59ae21b0bb936..013f0e69ff0f7 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -74,6 +74,9 @@ static LIST_HEAD(snd_timer_slave_list); /* lock for slave active lists */ static DEFINE_SPINLOCK(slave_active_lock); +#define MAX_SLAVE_INSTANCES 1000 +static int num_slaves; + static DEFINE_MUTEX(register_mutex); static int snd_timer_free(struct snd_timer *timer); @@ -252,6 +255,10 @@ int snd_timer_open(struct snd_timer_instance **ti, err = -EINVAL; goto unlock; } + if (num_slaves >= MAX_SLAVE_INSTANCES) { + err = -EBUSY; + goto unlock; + } timeri = snd_timer_instance_new(owner, NULL); if (!timeri) { err = -ENOMEM; @@ -261,6 +268,7 @@ int snd_timer_open(struct snd_timer_instance **ti, timeri->slave_id = tid->device; timeri->flags |= SNDRV_TIMER_IFLG_SLAVE; list_add_tail(&timeri->open_list, &snd_timer_slave_list); + num_slaves++; err = snd_timer_check_slave(timeri); if (err < 0) { snd_timer_close_locked(timeri, &card_dev_to_put); @@ -356,6 +364,8 @@ static int snd_timer_close_locked(struct snd_timer_instance *timeri, } list_del(&timeri->open_list); + if (timeri->flags & SNDRV_TIMER_IFLG_SLAVE) + num_slaves--; /* force to stop the timer */ snd_timer_stop(timeri); -- 2.20.1

1 0

[alsa-devel] [PATCH AUTOSEL 5.4 208/350] ASoC: SOF: topology: set trigger order for FE DAI link
by Sasha Levin 10 Dec '19

10 Dec '19

From: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> [ Upstream commit 5eee2b3f60065a2530d13f28e771be48b989eb4c ] Set trigger order for FE DAI links to SND_SOC_DPCM_TRIGGER_POST to trigger the BE DAI's before the FE DAI's. This prevents the xruns seen on playback pipelines using the link DMA. Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20191104224812.3393-3-ranjani.sridharan@linux.int… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/topology.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index 4452594c2e17a..fa299e0781561 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -2828,6 +2828,10 @@ static int sof_link_load(struct snd_soc_component *scomp, int index, if (!link->no_pcm) { link->nonatomic = true; + /* set trigger order */ + link->trigger[0] = SND_SOC_DPCM_TRIGGER_POST; + link->trigger[1] = SND_SOC_DPCM_TRIGGER_POST; + /* nothing more to do for FE dai links */ return 0; } -- 2.20.1

1 0

[alsa-devel] [PATCH AUTOSEL 5.4 195/350] ALSA: pcm: Fix missing check of the new non-cached buffer type
by Sasha Levin 10 Dec '19

10 Dec '19

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit 6111fd2370eecae9f11bfdc08ba097e0b51fcfd3 ] The check for the mmap support via hw_support_mmap() function misses the case where the device is with SNDRV_DMA_TYPE_DEV_UC, which should have been treated equally as SNDRV_DMA_TYPE_DEV. Let's fix it. Note that this bug doesn't hit any practical problem, because SNDRV_DMA_TYPE_DEV_UC is used only for x86-specific drivers (snd-hda-intel and snd-intel8x0) for the specific platforms that need the non-cached buffers. And, on such platforms, hw_support_mmap() already returns true in anyway. That's the reason I didn't put Cc-to-stable mark here. This is only for any theoretical future extension. Fixes: 425da159707b ("ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*") Fixes: 42e748a0b325 ("ALSA: memalloc: Add non-cached buffer type") Link: https://lore.kernel.org/r/20191104101115.27311-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/core/pcm_native.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 91c6ad58729fe..c3a139436ac26 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -222,7 +222,8 @@ static bool hw_support_mmap(struct snd_pcm_substream *substream) return false; if (substream->ops->mmap || - substream->dma_buffer.dev.type != SNDRV_DMA_TYPE_DEV) + (substream->dma_buffer.dev.type != SNDRV_DMA_TYPE_DEV && + substream->dma_buffer.dev.type != SNDRV_DMA_TYPE_DEV_UC)) return true; return dma_can_mmap(substream->dma_buffer.dev.dev); -- 2.20.1

1 0

[alsa-devel] [PATCH AUTOSEL 5.4 191/350] ALSA: bebob: expand sleep just after breaking connections for protocol version 1
by Sasha Levin 10 Dec '19

10 Dec '19

From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> [ Upstream commit d3eabe939aee3ffd5b133766a932629a9746298c ] As long as I investigated, some devices with BeBoB protocol version 1 can be freezed during several hundreds milliseconds after breaking connections. When accessing during the freezed time, any transaction is corrupted. In the worst case, the device is going to reboot. I can see this issue in: * Roland FA-66 * M-Audio FireWire Solo This commit expands sleep just after breaking connections to avoid the freezed time as much as possible. I note that the freeze/reboot behaviour is similar to below models: * Focusrite Saffire Pro 10 I/O * Focusrite Saffire Pro 26 I/O The above models certainly reboot after breaking connections. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Link: https://lore.kernel.org/r/20191101131323.17300-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/firewire/bebob/bebob_stream.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/sound/firewire/bebob/bebob_stream.c b/sound/firewire/bebob/bebob_stream.c index 6c1497d9f52ba..ce07ea0d4e71d 100644 --- a/sound/firewire/bebob/bebob_stream.c +++ b/sound/firewire/bebob/bebob_stream.c @@ -415,15 +415,16 @@ static int make_both_connections(struct snd_bebob *bebob) return 0; } -static void -break_both_connections(struct snd_bebob *bebob) +static void break_both_connections(struct snd_bebob *bebob) { cmp_connection_break(&bebob->in_conn); cmp_connection_break(&bebob->out_conn); - /* These models seems to be in transition state for a longer time. */ - if (bebob->maudio_special_quirk != NULL) - msleep(200); + // These models seem to be in transition state for a longer time. When + // accessing in the state, any transactions is corrupted. In the worst + // case, the device is going to reboot. + if (bebob->version < 2) + msleep(600); } static int -- 2.20.1

1 0

[alsa-devel] [PATCH AUTOSEL 5.4 179/350] ALSA: hda/hdmi - implement mst_no_extra_pcms flag
by Sasha Levin 10 Dec '19

10 Dec '19

From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> [ Upstream commit 2a2edfbbfee47947dd05f5860c66c0e80ee5e09d ] To support the DP-MST multiple streams via single connector feature, the HDMI driver was extended with the concept of backup PCMs. See commit 9152085defb6 ("ALSA: hda - add DP MST audio support"). This implementation works fine with snd_hda_intel.c as PCM topology is fully managed within the single driver. When the HDA codec driver is used from ASoC components, the concept of backup PCMs no longer fits. For ASoC topologies, the physical HDMI converters are presented as backend DAIs and these should match with hardware capabilities. The ASoC topology may define arbitrary PCMs (i.e. frontend DAIs) and have processing elements before eventual routing to the HDMI BE DAIs. With backup PCMs, the link between FE and BE DAIs would become dynamic and change when monitors are (un)plugged. This would lead to modifying the topology every time hotplug events happen, which is not currently possible in ASoC and there does not seem to be any obvious benefits from this design. To overcome above problems and enable the HDMI driver to be used from ASoC, this patch adds a new mode (mst_no_extra_pcms flags) to patch_hdmi.c. In this mode, the codec driver does not assume the backup PCMs to be created. Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Reviewed-by: Takashi Iwai <tiwai(a)suse.de> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20191029134017.18901-2-kai.vehmanen@linux.intel.c… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- include/sound/hda_codec.h | 1 + sound/pci/hda/patch_hdmi.c | 19 ++++++++++++++----- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/include/sound/hda_codec.h b/include/sound/hda_codec.h index 9a0393cf024c2..ac18f428eda6c 100644 --- a/include/sound/hda_codec.h +++ b/include/sound/hda_codec.h @@ -254,6 +254,7 @@ struct hda_codec { unsigned int force_pin_prefix:1; /* Add location prefix */ unsigned int link_down_at_suspend:1; /* link down at runtime suspend */ unsigned int relaxed_resume:1; /* don't resume forcibly for jack */ + unsigned int mst_no_extra_pcms:1; /* no backup PCMs for DP-MST */ #ifdef CONFIG_PM unsigned long power_on_acct; diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index d14f6684737d0..b8579cd218098 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2075,15 +2075,24 @@ static bool is_hdmi_pcm_attached(struct hdac_device *hdac, int pcm_idx) static int generic_hdmi_build_pcms(struct hda_codec *codec) { struct hdmi_spec *spec = codec->spec; - int idx; + int idx, pcm_num; /* * for non-mst mode, pcm number is the same as before - * for DP MST mode, pcm number is (nid number + dev_num - 1) - * dev_num is the device entry number in a pin - * + * for DP MST mode without extra PCM, pcm number is same + * for DP MST mode with extra PCMs, pcm number is + * (nid number + dev_num - 1) + * dev_num is the device entry number in a pin */ - for (idx = 0; idx < spec->num_nids + spec->dev_num - 1; idx++) { + + if (codec->mst_no_extra_pcms) + pcm_num = spec->num_nids; + else + pcm_num = spec->num_nids + spec->dev_num - 1; + + codec_dbg(codec, "hdmi: pcm_num set to %d\n", pcm_num); + + for (idx = 0; idx < pcm_num; idx++) { struct hda_pcm *info; struct hda_pcm_stream *pstr; -- 2.20.1

1 0

[alsa-devel] [PATCH AUTOSEL 5.4 170/350] ALSA: hda - Fix pending unsol events at shutdown
by Sasha Levin 10 Dec '19

10 Dec '19

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit ca58f55108fee41d87c9123f85ad4863e5de7f45 ] This is an alternative fix attemp for the issue reported in the commit caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling") that was reverted later due to regressions. Instead of tweaking the hardware disablement order and the enforced irq flushing, do calling cancel_work_sync() of the unsol work early enough, and explicitly ignore the unsol events during the shutdown by checking the bus->shutdown flag. Fixes: caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Link: https://lore.kernel.org/r/s5h1ruxt9cz.wl-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/hda_bind.c | 4 ++++ sound/pci/hda/hda_intel.c | 3 +++ 2 files changed, 7 insertions(+) diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c index 8272b50b83493..6a85645663759 100644 --- a/sound/pci/hda/hda_bind.c +++ b/sound/pci/hda/hda_bind.c @@ -43,6 +43,10 @@ static void hda_codec_unsol_event(struct hdac_device *dev, unsigned int ev) { struct hda_codec *codec = container_of(dev, struct hda_codec, core); + /* ignore unsol events during shutdown */ + if (codec->bus->shutdown) + return; + if (codec->patch_ops.unsol_event) codec->patch_ops.unsol_event(codec, ev); } diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index c52419376c748..86a416cdeb296 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1382,8 +1382,11 @@ static int azx_free(struct azx *chip) static int azx_dev_disconnect(struct snd_device *device) { struct azx *chip = device->device_data; + struct hdac_bus *bus = azx_bus(chip); chip->bus.shutdown = 1; + cancel_work_sync(&bus->unsol_work); + return 0; } -- 2.20.1

1 0

[alsa-devel] [PATCH AUTOSEL 5.4 138/350] ASoC: soc-pcm: fixup dpcm_prune_paths() loop continue
by Sasha Levin 10 Dec '19

10 Dec '19

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> [ Upstream commit bed646dc3f7bcec91178c278deaf969cce0700a8 ] dpcm_prune_paths() is checking widget at 2 parts. (A) is for CPU, (B) is for Codec. If we focus to (A) part, continue at (a) is for (1) loop. But, if we focus to (B) part, continue at (b) is for (2) loop, not for (1). This is bug. This patch fixup this issue. static int dpcm_prune_paths(...) { ... (1) for_each_dpcm_be(fe, stream, dpcm) { ... ^ widget = dai_get_widget(...); | (A) if (widget && widget_in_list(...)) | (a) continue; v ^ (2) for_each_rtd_codec_dai(...) { | widget = dai_get_widget(...); (B) | if (widget && widget_in_list(...)) v (b) continue; } ... Fixes: 2e5894d73789 ("ASoC: pcm: Add support for DAI multicodec") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Link: https://lore.kernel.org/r/87blui64mf.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/soc-pcm.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index b600d3eaaf5cd..cdce96a3051bf 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1385,6 +1385,7 @@ static int dpcm_prune_paths(struct snd_soc_pcm_runtime *fe, int stream, struct snd_soc_dapm_widget *widget; struct snd_soc_dai *dai; int prune = 0; + int do_prune; /* Destroy any old FE <--> BE connections */ for_each_dpcm_be(fe, stream, dpcm) { @@ -1398,13 +1399,16 @@ static int dpcm_prune_paths(struct snd_soc_pcm_runtime *fe, int stream, continue; /* is there a valid CODEC DAI widget for this BE */ + do_prune = 1; for_each_rtd_codec_dai(dpcm->be, i, dai) { widget = dai_get_widget(dai, stream); /* prune the BE if it's no longer in our active list */ if (widget && widget_in_list(list, widget)) - continue; + do_prune = 0; } + if (!do_prune) + continue; dev_dbg(fe->dev, "ASoC: pruning %s BE %s for %s\n", stream ? "capture" : "playback", -- 2.20.1

1 0

[alsa-devel] [PATCH AUTOSEL 5.4 088/350] ASoC: SOF: enable sync_write in hdac_bus
by Sasha Levin 10 Dec '19

10 Dec '19

From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> [ Upstream commit f3416e7144f5d4ba0fc5dcef6ebfff891266c46a ] Align SOF HDA implementation with snd-hda-intel driver and enable sync_write flag for all supported Intel platforms in SOF. When set, a sync is issued after each verb write. Sync after write has helped to overcome intermittent delays in system resume flow on Intel Coffee Lake systems, and most recently probe errors related to the HDMI codec on Ice Lake systems. Matches the snd-hda-intel driver change done in commit 2756d9143aa5 ("ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"). Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-2-pierre-louis.bossart@linux.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 06e84679087bc..5a5163eef2ef4 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -268,6 +268,7 @@ static int hda_init(struct snd_sof_dev *sdev) bus->use_posbuf = 1; bus->bdl_pos_adj = 0; + bus->sync_write = 1; mutex_init(&hbus->prepare_mutex); hbus->pci = pci; -- 2.20.1

1 0

Re: [alsa-devel] [PATCH v3 03/15] soc: tegra: Add Tegra PMC clock registrations into PMC driver
by Dmitry Osipenko 10 Dec '19

10 Dec '19

10.12.2019 22:18, Sowjanya Komatineni пишет: > > On 12/10/19 10:30 AM, Dmitry Osipenko wrote: >> 10.12.2019 20:48, Sowjanya Komatineni пишет: >>> On 12/10/19 9:41 AM, Dmitry Osipenko wrote: >>>> 09.12.2019 23:46, Sowjanya Komatineni пишет: >>>>> On 12/9/19 12:12 PM, Dmitry Osipenko wrote: >>>>>> 08.12.2019 00:36, Sowjanya Komatineni пишет: >>>>>>> On 12/7/19 11:59 AM, Sowjanya Komatineni wrote: >>>>>>>> On 12/7/19 8:00 AM, Dmitry Osipenko wrote: >>>>>>>>> 07.12.2019 18:53, Dmitry Osipenko пишет: >>>>>>>>>> 07.12.2019 18:47, Dmitry Osipenko пишет: >>>>>>>>>>> 07.12.2019 17:28, Dmitry Osipenko пишет: >>>>>>>>>>>> 06.12.2019 05:48, Sowjanya Komatineni пишет: >>>>>>>>>>>>> Tegra210 and prior Tegra PMC has clk_out_1, clk_out_2, >>>>>>>>>>>>> clk_out_3 >>>>>>>>>>>>> with >>>>>>>>>>>>> mux and gate for each of these clocks. >>>>>>>>>>>>> >>>>>>>>>>>>> Currently these PMC clocks are registered by Tegra clock >>>>>>>>>>>>> driver >>>>>>>>>>>>> using >>>>>>>>>>>>> clk_register_mux and clk_register_gate by passing PMC base >>>>>>>>>>>>> address >>>>>>>>>>>>> and register offsets and PMC programming for these clocks >>>>>>>>>>>>> happens >>>>>>>>>>>>> through direct PMC access by the clock driver. >>>>>>>>>>>>> >>>>>>>>>>>>> With this, when PMC is in secure mode any direct PMC access >>>>>>>>>>>>> from the >>>>>>>>>>>>> non-secure world does not go through and these clocks will >>>>>>>>>>>>> not be >>>>>>>>>>>>> functional. >>>>>>>>>>>>> >>>>>>>>>>>>> This patch adds these clocks registration with PMC as a clock >>>>>>>>>>>>> provider >>>>>>>>>>>>> for these clocks. clk_ops callback implementations for these >>>>>>>>>>>>> clocks >>>>>>>>>>>>> uses tegra_pmc_readl and tegra_pmc_writel which supports PMC >>>>>>>>>>>>> programming >>>>>>>>>>>>> in secure mode and non-secure mode. >>>>>>>>>>>>> >>>>>>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni(a)nvidia.com> >>>>>>>>>>>>> --- >>>>>>>>>>> [snip] >>>>>>>>>>> >>>>>>>>>>>>> + >>>>>>>>>>>>> +static const struct clk_ops pmc_clk_gate_ops = { >>>>>>>>>>>>> + .is_enabled = pmc_clk_is_enabled, >>>>>>>>>>>>> + .enable = pmc_clk_enable, >>>>>>>>>>>>> + .disable = pmc_clk_disable, >>>>>>>>>>>>> +}; >>>>>>>>>>>> What's the benefit of separating GATE from the MUX? >>>>>>>>>>>> >>>>>>>>>>>> I think it could be a single clock. >>>>>>>>>>> According to TRM: >>>>>>>>>>> >>>>>>>>>>> 1. GATE and MUX are separate entities. >>>>>>>>>>> >>>>>>>>>>> 2. GATE is the parent of MUX (see PMC's CLK_OUT paths diagram in >>>>>>>>>>> TRM). >>>>>>>>>>> >>>>>>>>>>> 3. PMC doesn't gate EXTPERIPH clock but could "force-enable" it, >>>>>>>>>>> correct? >>>>>>> Was following existing clk-tegra-pmc as I am not sure of reason for >>>>>>> having these clocks registered as separate mux and gate clocks. >>>>>>> >>>>>>> Yes, PMC clocks can be registered as single clock and can use >>>>>>> clk_ops >>>>>>> for set/get parent and enable/disable. >>>>>>> >>>>>>> enable/disable of PMC clocks is for force-enable to force the >>>>>>> clock to >>>>>>> run regardless of ACCEPT_REQ or INVERT_REQ. >>>>>>> >>>>>>>>>> 4. clk_m_div2/4 are internal PMC OSC dividers and thus these >>>>>>>>>> clocks >>>>>>>>>> should belong to PMC. >>>>>>>>> Also, it should be "osc" and not "clk_m". >>>>>>>> I followed the same parents as it were in existing clk-tegra-pmc >>>>>>>> driver. >>>>>>>> >>>>>>>> Yeah they are wrong and they should be from osc and not clk_m. >>>>>>>> >>>>>>>> Will fix in next version. >>>>>>>> >>>>>> Could you please describe the full EXTPERIPH clock topology and >>>>>> how the >>>>>> pinmux configuration is related to it all? >>>>>> >>>>>> What is internal to the Tegra chip and what are the external outputs? >>>>>> >>>>>> Is it possible to bypass PMC on T30+ for the EXTPERIPH clocks? >>>>> PMC CLK1/2/3 possible sources are OSC_DIV1, OSC_DIV2, OSC_DIV4, >>>>> EXTPERIPH from CAR. >>>>> >>>>> OSC_DIV1/2/4 are with internal dividers at the OSC Pads >>>>> >>>>> EXTPERIPH is from CAR and it has reset and enable controls along with >>>>> clock source selections to choose one of the PLLA_OUT0, CLK_S, >>>>> PLLP_OUT0, CLK_M, PLLE_OUT0 >>>> Are you sure that EXTPERIPH has a reset? What will it reset? Why it's >>>> not documented in TRM? >>> Yes, Extperiph1/2/3 has RST part of CAR RST_DEVICES_V bits 24/25/26 >> Are these bits not documented in a public TRMs? I checked >> T30/114/124/210 TRMs and CLK_RST_CONTROLLER_RST_DEVICES_V_0 doesn't have >> those bits in the docs. >> > Yeah these bits are missing in all Tegra TRM docs. Will request for > having EXTPERIPH reset bits to be updated in TRM... Thanks

1 0

Re: [alsa-devel] [PATCH v3 03/15] soc: tegra: Add Tegra PMC clock registrations into PMC driver
by Dmitry Osipenko 10 Dec '19

10 Dec '19

10.12.2019 20:48, Sowjanya Komatineni пишет: > > On 12/10/19 9:41 AM, Dmitry Osipenko wrote: >> 09.12.2019 23:46, Sowjanya Komatineni пишет: >>> On 12/9/19 12:12 PM, Dmitry Osipenko wrote: >>>> 08.12.2019 00:36, Sowjanya Komatineni пишет: >>>>> On 12/7/19 11:59 AM, Sowjanya Komatineni wrote: >>>>>> On 12/7/19 8:00 AM, Dmitry Osipenko wrote: >>>>>>> 07.12.2019 18:53, Dmitry Osipenko пишет: >>>>>>>> 07.12.2019 18:47, Dmitry Osipenko пишет: >>>>>>>>> 07.12.2019 17:28, Dmitry Osipenko пишет: >>>>>>>>>> 06.12.2019 05:48, Sowjanya Komatineni пишет: >>>>>>>>>>> Tegra210 and prior Tegra PMC has clk_out_1, clk_out_2, clk_out_3 >>>>>>>>>>> with >>>>>>>>>>> mux and gate for each of these clocks. >>>>>>>>>>> >>>>>>>>>>> Currently these PMC clocks are registered by Tegra clock driver >>>>>>>>>>> using >>>>>>>>>>> clk_register_mux and clk_register_gate by passing PMC base address >>>>>>>>>>> and register offsets and PMC programming for these clocks happens >>>>>>>>>>> through direct PMC access by the clock driver. >>>>>>>>>>> >>>>>>>>>>> With this, when PMC is in secure mode any direct PMC access >>>>>>>>>>> from the >>>>>>>>>>> non-secure world does not go through and these clocks will not be >>>>>>>>>>> functional. >>>>>>>>>>> >>>>>>>>>>> This patch adds these clocks registration with PMC as a clock >>>>>>>>>>> provider >>>>>>>>>>> for these clocks. clk_ops callback implementations for these >>>>>>>>>>> clocks >>>>>>>>>>> uses tegra_pmc_readl and tegra_pmc_writel which supports PMC >>>>>>>>>>> programming >>>>>>>>>>> in secure mode and non-secure mode. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni(a)nvidia.com> >>>>>>>>>>> --- >>>>>>>>> [snip] >>>>>>>>> >>>>>>>>>>> + >>>>>>>>>>> +static const struct clk_ops pmc_clk_gate_ops = { >>>>>>>>>>> + .is_enabled = pmc_clk_is_enabled, >>>>>>>>>>> + .enable = pmc_clk_enable, >>>>>>>>>>> + .disable = pmc_clk_disable, >>>>>>>>>>> +}; >>>>>>>>>> What's the benefit of separating GATE from the MUX? >>>>>>>>>> >>>>>>>>>> I think it could be a single clock. >>>>>>>>> According to TRM: >>>>>>>>> >>>>>>>>> 1. GATE and MUX are separate entities. >>>>>>>>> >>>>>>>>> 2. GATE is the parent of MUX (see PMC's CLK_OUT paths diagram in >>>>>>>>> TRM). >>>>>>>>> >>>>>>>>> 3. PMC doesn't gate EXTPERIPH clock but could "force-enable" it, >>>>>>>>> correct? >>>>> Was following existing clk-tegra-pmc as I am not sure of reason for >>>>> having these clocks registered as separate mux and gate clocks. >>>>> >>>>> Yes, PMC clocks can be registered as single clock and can use clk_ops >>>>> for set/get parent and enable/disable. >>>>> >>>>> enable/disable of PMC clocks is for force-enable to force the clock to >>>>> run regardless of ACCEPT_REQ or INVERT_REQ. >>>>> >>>>>>>> 4. clk_m_div2/4 are internal PMC OSC dividers and thus these clocks >>>>>>>> should belong to PMC. >>>>>>> Also, it should be "osc" and not "clk_m". >>>>>> I followed the same parents as it were in existing clk-tegra-pmc >>>>>> driver. >>>>>> >>>>>> Yeah they are wrong and they should be from osc and not clk_m. >>>>>> >>>>>> Will fix in next version. >>>>>> >>>> Could you please describe the full EXTPERIPH clock topology and how the >>>> pinmux configuration is related to it all? >>>> >>>> What is internal to the Tegra chip and what are the external outputs? >>>> >>>> Is it possible to bypass PMC on T30+ for the EXTPERIPH clocks? >>> PMC CLK1/2/3 possible sources are OSC_DIV1, OSC_DIV2, OSC_DIV4, >>> EXTPERIPH from CAR. >>> >>> OSC_DIV1/2/4 are with internal dividers at the OSC Pads >>> >>> EXTPERIPH is from CAR and it has reset and enable controls along with >>> clock source selections to choose one of the PLLA_OUT0, CLK_S, >>> PLLP_OUT0, CLK_M, PLLE_OUT0 >> Are you sure that EXTPERIPH has a reset? What will it reset? Why it's >> not documented in TRM? > Yes, Extperiph1/2/3 has RST part of CAR RST_DEVICES_V bits 24/25/26 Are these bits not documented in a public TRMs? I checked T30/114/124/210 TRMs and CLK_RST_CONTROLLER_RST_DEVICES_V_0 doesn't have those bits in the docs. >>> So, PMC CLK1/2/4 possible parents are OSC_DIV1, OSC_DIV2, OSC_DIV4, EXTERN. >>> >>> >>> CLK1/2/3 also has Pinmux to route EXTPERIPH output on to these pins. >> Could you please clarify what are "these" pins? Perhaps you meant the >> EXTERN pin of PMC? > By CLK1/2/3 pins, I am referring to CLK_OUT_1/2/3 pins from Tegra I see now what you meant, thanks. [snip}

1 0