From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kuninori Morimoto Subject: Re: [PATCH 000/127] ASoC: codec cleanup - codec probe/remove Date: Fri, 12 Aug 2016 01:27:06 +0000 Message-ID: <87wpjmrdgw.wl%kuninori.morimoto.gx@renesas.com> References: <87popieek9.wl%kuninori.morimoto.gx@renesas.com> <54ffe6bb-9a97-db02-e96b-588630b08468@metafoo.de> <20160809112639.GJ10383@sirena.org.uk> <87a8glii9q.wl%kuninori.morimoto.gx@renesas.com> <20160810111748.GI9347@sirena.org.uk> <871t1wuntb.wl%kuninori.morimoto.gx@renesas.com> <5a3d865f-087f-eab2-82d8-0477c2ca1400@metafoo.de> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from relmlie2.idc.renesas.com (relmlor3.renesas.com [210.160.252.173]) by alsa0.perex.cz (Postfix) with ESMTP id 50597265A98 for ; Fri, 12 Aug 2016 03:27:13 +0200 (CEST) In-Reply-To: <5a3d865f-087f-eab2-82d8-0477c2ca1400@metafoo.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Lars-Peter Clausen Cc: Linux-ALSA , Mark Brown , Liam Girdwood , Simon List-Id: alsa-devel@alsa-project.org Hi Mark, Lars > Over time the hardware landscape changed and the distinction feature wise > did become smaller between the different types of components. The CPU side > components started to take care of tasks that were previously only found in > CODECS and wise versa. > > This lead to a lot of code duplication in ASoC since the same functionality > was now implemented multiple times. Is this where the original > componentization effort started. The goal of this effort was to introduce > the snd_soc_component struct as a common base for all types of components in > ASoC. This allowed us to remove a lot of duplicated code and also reduce > struct sizes by implementing a more strict hierarchy. Ahh... I see... OK, I could understand. > > According to your (and Lars ?) idea, if component includes all features, > > then, current "codec" will be "component", and "platform" will be "component" too (?). > > If so, I think necessary patch in final stage is like this ? > > > > - static struct snd_soc_codec_driver xxxx = { > > + static struct snd_soc_component_driver xxxx = { > > In the long run probably yes, with the distinction of particular features > happening at a different level. E.g. like I pointed out in one of the > earlier e-mails, one such layer could be the domain and bridge layer were a > component is subdivided into domains and bridges. If my understanding was correct, current CPU/Codec/Platform will merged and goes to your "component" position. current snd_soc_dai will be cleanuped and goes to your "bridge" position. Are these correct ? But I wonder current which portion is the "domain" position ? ("domain" + "bridge" = current snd_soc_dai ?) Or we don't have such position at this point ? BTW, I would like to replace below as next challenge. These are easy, and necessary. snd_soc_write() -> snd_soc_component_write() snd_soc_update_bits() -> snd_soc_component_update_bits() This is a little bit difficult, but I can do is step-by-step. snd_soc_read() -> snd_soc_component_read() If above were OK, some codec driver can use component side .probe/.remove I think Lars's opinion is that this should be final stage, but I think we can do this as parallel, and I like step-by-step approach. Of course I can skip it if you have strong objection. So please let me know. I will have summer vacation from tomorrow, so I can start it after that.