From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> To: Jon Hunter <jonathanh@nvidia.com> Cc: Mark Brown <broonie@kernel.org>, Liam Girdwood <lgirdwood@gmail.com>, linux-tegra@vger.kernel.org, Matthias Reichl <hias@horus.com>, alsa-devel@alsa-project.org, Marcel Ziswiler <marcel.ziswiler@toradex.com>, Takashi Iwai <tiwai@suse.com>, linux-kernel@vger.kernel.org, Marcel Ziswiler <marcel@ziswiler.com> Subject: Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement Date: 09 Jan 2019 10:51:48 +0900 [thread overview] Message-ID: <87k1je38w7.wl-kuninori.morimoto.gx@renesas.com> (raw) In-Reply-To: <865d2a3e-bf6b-1f30-1179-7e922c0d0641@nvidia.com> Hi Jon Thank you for your help > > Yes so this does workaround the problem. However, per my previous > > comments, I would like to explore whether it is necessary to allocate > > the platform link component or if it can be static. OK, thanks. It *will* be static, but not yet. Thank you for your patch. I guess you worry about allocated memory leak when failed case ? It is using devm_kzalloc(), so all allocated memory will be automatically freed when card was detached. But indeed if driver gots -EPROBE_DEFER many times, it will allocate many unused platform. Here is the background of snd_soc_init_platform. Legacy dai_link was xxx_name/xxx_of_node style, but multi codec support starts to use snd_soc_dai_link_component style. OTOH Lars-Petter is thinking that current ALSA SoC is not good match for modern sound device. I guess, we need "multi xxx" support as 1st step for modern sound device. "multi codec" is already supported, "multi cpu" patch was posted, but not yet accepted (or rejected ??). "multi platform" is no plan (?). These want to use snd_soc_dai_link_component style, because it is nice for multi xxx support style, I think. I think no one is planing for "multi platform" so far, thus, I posted snd_soc_dai_link_component style for it. # Maybe it should have num_platform, too. # all driver will have .num_platform = 1, thus I didn't added. # maybe it was my fault... The reason why platform/codec is allocating/copying by snd_soc_init_xxx so far is that it is glue for xxx_name/xxx_of_node (legacy style) <-> snd_soc_init_platform (modern style). I want to which to modern style immediately and remove legacy style. But as you know, we have too many ALSA SoC drivers now. So, if I posted "switch legacy style to modern style" patch for each (= for codec, for platform, for cpu), it will be patch-bomb, and Lars-Petter/Mark don't like it. Thus, I'm waiting "multi CPU" support patch. If CPU/Codec/Platform can be snd_soc_init_platform style, then, we can switch to modern style for all drivers. Then, all driver will have *static* platform. # So, I guess if your driver can switch to use # snd_soc_init_platform style directly, your problem can gone ? > Mark If there is no plan for "multi CPU" so far, I can post snd_soc_dai_link_component style for CPU. and post switch modern style for all drivers. Then, this issue can be solved ? Best regards --- Kuninori Morimoto
WARNING: multiple messages have this Message-ID (diff)
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> To: Jon Hunter <jonathanh@nvidia.com> Cc: Mark Brown <broonie@kernel.org>, Liam Girdwood <lgirdwood@gmail.com>, <linux-tegra@vger.kernel.org>, Matthias Reichl <hias@horus.com>, <alsa-devel@alsa-project.org>, Marcel Ziswiler <marcel.ziswiler@toradex.com>, Takashi Iwai <tiwai@suse.com>, <linux-kernel@vger.kernel.org>, Marcel Ziswiler <marcel@ziswiler.com> Subject: Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement Date: 09 Jan 2019 10:51:48 +0900 [thread overview] Message-ID: <87k1je38w7.wl-kuninori.morimoto.gx@renesas.com> (raw) In-Reply-To: <865d2a3e-bf6b-1f30-1179-7e922c0d0641@nvidia.com> Hi Jon Thank you for your help > > Yes so this does workaround the problem. However, per my previous > > comments, I would like to explore whether it is necessary to allocate > > the platform link component or if it can be static. OK, thanks. It *will* be static, but not yet. Thank you for your patch. I guess you worry about allocated memory leak when failed case ? It is using devm_kzalloc(), so all allocated memory will be automatically freed when card was detached. But indeed if driver gots -EPROBE_DEFER many times, it will allocate many unused platform. Here is the background of snd_soc_init_platform. Legacy dai_link was xxx_name/xxx_of_node style, but multi codec support starts to use snd_soc_dai_link_component style. OTOH Lars-Petter is thinking that current ALSA SoC is not good match for modern sound device. I guess, we need "multi xxx" support as 1st step for modern sound device. "multi codec" is already supported, "multi cpu" patch was posted, but not yet accepted (or rejected ??). "multi platform" is no plan (?). These want to use snd_soc_dai_link_component style, because it is nice for multi xxx support style, I think. I think no one is planing for "multi platform" so far, thus, I posted snd_soc_dai_link_component style for it. # Maybe it should have num_platform, too. # all driver will have .num_platform = 1, thus I didn't added. # maybe it was my fault... The reason why platform/codec is allocating/copying by snd_soc_init_xxx so far is that it is glue for xxx_name/xxx_of_node (legacy style) <-> snd_soc_init_platform (modern style). I want to which to modern style immediately and remove legacy style. But as you know, we have too many ALSA SoC drivers now. So, if I posted "switch legacy style to modern style" patch for each (= for codec, for platform, for cpu), it will be patch-bomb, and Lars-Petter/Mark don't like it. Thus, I'm waiting "multi CPU" support patch. If CPU/Codec/Platform can be snd_soc_init_platform style, then, we can switch to modern style for all drivers. Then, all driver will have *static* platform. # So, I guess if your driver can switch to use # snd_soc_init_platform style directly, your problem can gone ? > Mark If there is no plan for "multi CPU" so far, I can post snd_soc_dai_link_component style for CPU. and post switch modern style for all drivers. Then, this issue can be solved ? Best regards --- Kuninori Morimoto
next prev parent reply other threads:[~2019-01-09 1:51 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-18 11:18 [PATCH v1 0/3] ASoC: last minute fixes Marcel Ziswiler 2018-10-18 11:18 ` Marcel Ziswiler 2018-10-18 11:18 ` [PATCH v1 1/3] ASoC: tegra_sgtl5000: fix device_node refcounting Marcel Ziswiler 2018-10-18 11:18 ` Marcel Ziswiler 2018-10-18 11:18 ` [PATCH v1 2/3] ASoC: soc-core: fix trivial checkpatch issues Marcel Ziswiler 2018-10-18 11:18 ` Marcel Ziswiler 2018-10-19 12:26 ` Applied "ASoC: soc-core: fix trivial checkpatch issues" to the asoc tree Mark Brown 2018-10-19 12:26 ` Mark Brown 2018-10-19 12:26 ` Mark Brown 2018-10-19 12:34 ` Mark Brown 2018-10-19 12:34 ` Mark Brown 2018-10-19 12:34 ` Mark Brown 2018-10-18 11:18 ` [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement Marcel Ziswiler 2018-10-18 11:18 ` Marcel Ziswiler 2018-10-19 10:22 ` Jon Hunter 2018-10-19 10:22 ` Jon Hunter 2018-10-21 11:23 ` Mark Brown 2018-10-21 11:23 ` Mark Brown 2018-12-18 17:40 ` Matthias Reichl 2018-12-18 17:40 ` [alsa-devel] " Matthias Reichl 2019-01-03 16:42 ` Jon Hunter 2019-01-03 16:42 ` Jon Hunter 2019-01-08 2:25 ` Kuninori Morimoto 2019-01-08 2:25 ` Kuninori Morimoto 2019-01-08 10:50 ` Jon Hunter 2019-01-08 10:50 ` [alsa-devel] " Jon Hunter 2019-01-08 12:03 ` Jon Hunter 2019-01-08 12:03 ` Jon Hunter 2019-01-08 15:48 ` Jon Hunter 2019-01-08 15:48 ` Jon Hunter 2019-01-08 16:09 ` Mark Brown 2019-01-08 16:09 ` [alsa-devel] " Mark Brown 2019-01-09 1:51 ` Kuninori Morimoto [this message] 2019-01-09 1:51 ` Kuninori Morimoto 2019-01-09 11:03 ` Jon Hunter 2019-01-09 11:03 ` Jon Hunter 2019-01-09 12:53 ` Mark Brown 2019-01-09 12:53 ` [alsa-devel] " Mark Brown 2019-01-09 14:11 ` Jon Hunter 2019-01-09 14:11 ` Jon Hunter 2019-01-09 14:14 ` Mark Brown 2019-01-09 14:14 ` [alsa-devel] " Mark Brown 2019-01-10 1:16 ` Kuninori Morimoto 2019-01-10 3:46 ` Kuninori Morimoto 2019-01-10 10:56 ` Jon Hunter 2019-01-10 10:56 ` Jon Hunter 2019-01-11 0:52 ` Kuninori Morimoto 2019-01-11 0:52 ` [alsa-devel] " Kuninori Morimoto 2019-01-11 8:41 ` Jon Hunter 2019-01-11 8:41 ` Jon Hunter 2019-01-11 8:51 ` Kuninori Morimoto 2019-01-11 8:51 ` Kuninori Morimoto 2019-01-11 9:15 ` Jon Hunter 2019-01-11 9:15 ` Jon Hunter 2019-01-14 23:02 ` Mark Brown 2019-01-14 23:02 ` [alsa-devel] " Mark Brown 2019-01-15 15:26 ` Jon Hunter 2019-01-15 15:26 ` Jon Hunter 2019-01-15 18:07 ` Matthias Reichl 2019-01-08 15:33 ` Mark Brown 2019-01-08 15:33 ` [alsa-devel] " Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87k1je38w7.wl-kuninori.morimoto.gx@renesas.com \ --to=kuninori.morimoto.gx@renesas.com \ --cc=alsa-devel@alsa-project.org \ --cc=broonie@kernel.org \ --cc=hias@horus.com \ --cc=jonathanh@nvidia.com \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-tegra@vger.kernel.org \ --cc=marcel.ziswiler@toradex.com \ --cc=marcel@ziswiler.com \ --cc=tiwai@suse.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.