[alsa-devel] [SAMPLE-PATCH 0/x] ASoC: replace snd_soc_read/write
Lars-Peter Clausen
lars at metafoo.de
Wed Oct 19 09:57:20 CEST 2016
On 10/19/2016 09:43 AM, Kuninori Morimoto wrote:
>
> Hi Takashi-san
>
> Thank you for your feedback
>
>>> These are part of "replace snd_soc_read/write to snd_soc_component_read/write"
>>> patch-set. Full-patch-set will be over 100 patches.
>>>
>>> [0/x] - [x-1/x] : ASoC: use snd_soc_component_read/write on xxxx
>>> [x/x] : ASoC: remove snd_soc_component_read/write
>>>
>>> [0/x] - [x-1/x] are almost same patches.
>>> so, I pickuped few of them for reviewing to avoid patch flood on ML.
>>>
>>> If these review were OK, I will post full-patch-set,
>>> or send git-pull-request.
>>>
>>> Main purpose of these patches are replace current snd_soc_read/write
>>> to snd_soc_component_read/write to remove codec related function.
>>
>> I really don't see any big merits by these changes.
>> What's wrong with keeping as is? The driver is accessing the codec
>> register, after all.
>>
>> For keeping consistency, replacing a few exceptions would be OK. But
>> replacing hundreds of callers needs a proper justification to do it
>> so.
>
> Now, ALSA SoC is planning to remove "struct snd_soc_codec" and
> "struct snd_soc_platform", and merge these into "struct snd_soc_component".
> New ALSA SoC will be based on "component", and additional new feature (= bridge ?).
>
> As 1st phase, I would like to cleanup these.
> my 1st step is removing codec related read/write (= use component read/write),
> and 2nd step is remove codec probe/remove (= use component probe/remove).
> and 3rd, 4th... I don't know how many steps are exist.
I agree with Takashi, in my opinion this is not the right change at this
point in time. snd_soc_{write,read}() are not problematic they are simple
wrapper functions around snd_soc_component_{write,read}() that make it more
convenient to use them in a CODEC driver. Same for the CODEC specific
probe()/remove() callbacks.
And while we are phasing out the concept of differentiating between
different types of components, since the hardware landscape has changed so
that there is no longer a really meaningful differentiating factor,
snd_soc_codec and snd_soc_codec drivers will still be around for a while.
The problematic bits are in the ASoC core where we have code that needs to
know whether a component is a CODEC or not. These are the issue we need to
resolve before we can think about converting more driver snd_soc_codec to
snd_soc_component.
Doing these partial conversions only leaves us with a lot of drivers that
are more convoluted than they need to be. In my opinion a driver should be
converted in one go, making it a complete component driver. But not leave it
partially component and partially CODEC. We've done this for the drivers
where it is possible, e.g. see [1].
But now it is time to fix the hard problems in the core first before we
start converting other drivers.
- Lars
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/sound/soc/codecs/max9768.c?id=04b5cbd80af899c6a4d51835b069b96ae8864e5a
More information about the Alsa-devel
mailing list