All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.