Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Along with it, drop the unnecessary assignment before the
snd_dma_alloc_pages() call and simplify by returning the error code
directly.
Link: https://lore.kernel.org/r/20191105151856.10785-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Along with it, the unneeded assignment before snd_dma_alloc_pages*()
call is dropped.
Link: https://lore.kernel.org/r/20191105151856.10785-22-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Also slightly refactor the code (drop the return value check from the
preallocation) as it never returns an error.
Link: https://lore.kernel.org/r/20191105151856.10785-21-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_pcm_sgbuf_ops_page is no longer needed to be set explicitly to PCM
page ops since the recent change in the PCM core (*). Leaving it NULL
should work as long as the preallocation has been done properly.
This patch drops the redundant lines.
(*) 7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-19-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-18-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Since the driver requires the DMA32 allocation, it passes the
specially encoded device to snd_pcm_lib_preallocate_pages().
Link: https://lore.kernel.org/r/20191105151856.10785-17-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Since the driver requires the DMA32 allocation, it passes the
specially encoded device to snd_pcm_lib_preallocate_pages().
Link: https://lore.kernel.org/r/20191105151856.10785-16-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-15-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-14-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-13-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-12-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page
mapping in the default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Also, since the SG-buffer-specific PCM ops becomes identical with the
normal PCM ops, unify them again to the single ops, too.
Link: https://lore.kernel.org/r/20191105151856.10785-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c559d: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c559d: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c559d: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c559d: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c559d: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c559d: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It makes little sense to create prealloc proc files for streams that
have the zero max size, which is a typical case for vmalloc buffers.
Skip the proc file creations to save resources in such a case.
Link: https://lore.kernel.org/r/20191105191007.18150-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Warn if snd_pcm_lib_preallocate_pages*() is applied to the stream that
has already the preallocated buffers and skip the allocation. It's a
clearly a driver bug.
Link: https://lore.kernel.org/r/20191105191007.18150-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a driver needs to deal with a special buffer like a SG or a
vmalloc buffer, it has to set up the PCM page ops explicitly for the
corresponding helper function. This is rather error-prone and many
people forgot or incorrectly used it.
For simplifying the call patterns and avoiding such a potential bug,
this patch enhances the PCM default mmap handler to check the
(pre-)allocated buffer type and handles the page gracefully depending
on the buffer type. If the PCM page ops is given, the ops is still
used in a higher priority. The new code path is only for the default
(NULL page ops) case.
Link: https://lore.kernel.org/r/20191105080138.1260-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the vmalloc buffer support to ALSA memalloc core. A
new type, SNDRV_DMA_TYPE_VMALLOC was added.
The vmalloc buffer has been already supported in the PCM via a few own
helper functions, but the user sometimes get confused and misuse
them. With this patch, the whole buffer management is integrated into
the memalloc core, so they can be used in a sole common way.
Link: https://lore.kernel.org/r/20191105080138.1260-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we pass the artificial device pointer to the allocation
helper in the case of SNDRV_DMA_TYPE_CONTINUOUS for passing the GFP
flags. But all common cases are the allocations with GFP_KERNEL, and
it's messy to put this in each place.
In this patch, the memalloc core helper is changed to accept the NULL
device pointer and it treats as the default mode, GFP_KERNEL, so that
all callers can omit the complex argument but just leave NULL.
Link: https://lore.kernel.org/r/20191105080138.1260-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_soc_dobj is used only when SND_SOC_TOPOLOGY was selected.
Let's enable it under SND_SOC_TOPOLOGY.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87o8xq251d.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc-core has some API which is used from topology, but it is doing
topology specific operation at soc-core.
soc-core should care about core things, and topology should care
about topology things, otherwise, it is very confusable.
For example topology type is not related to soc-core,
it is topology side issue.
This patch removes meaningless check from soc-core.
This patch keeps extra initialization/destruction at
snd_soc_add_dai_link() / snd_soc_remove_dai_link()
which were for topology.
From this patch, non-topology card can use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87pni6251h.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
This patch calls snd_soc_register_dai() from snd_soc_register_dais()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87r22m251l.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
snd_soc_register_dai() is now used from topology.
But to reduce duplicated code, it should be used from _dais(), too.
Because of topology side specific reason,
it is calling snd_soc_dapm_new_dai_widgets(),
but it is not needed _dais() side.
This patch factorizes snd_soc_register_dai() to
topology / _dais() common part, and topology specific part.
And do topology specific part at soc-topology.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87sgn2251p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
snd_soc_register_dai() is now used from topology.
But to reduce duplicated code, it should be used from _dais(), too.
To prepare it, this patch adds missing parameter legacy_dai_naming
to snd_soc_register_dai().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87tv7i251u.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is easy to read code if it is cleanly using paired function/naming,
like start <-> stop, register <-> unregister, etc, etc.
But, current ALSA SoC code is very random, unbalance, not paired, etc.
It is easy to create bug at the such code, and is difficult to debug.
This patch adds missing soc_del_dai() and snd_soc_unregister_dai().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87v9ry251z.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch moves snd_soc_unregister_dais() next to
snd_soc_register_dais().
This is prepare for snd_soc_register_dais() cleanup
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87woce2524.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch moves snd_soc_register_dai() next to
snd_soc_register_dais().
This is prepare for snd_soc_register_dais() cleanup.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87y2wu2528.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_unregister_component() is now finding component manually,
but we already have snd_soc_lookup_component() to find component;
Let's use existing function.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87zhha252c.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc-core has
snd_soc_add_component(), snd_soc_component_add(),
snd_soc_del_component(), snd_soc_component_del().
These are very confusing naming.
snd_soc_component_xxx() are called from snd_soc_xxx_component(),
and these are very small.
Let's merge these into snd_soc_xxx_component(), and
remove snd_soc_component_xxx().
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/871rum3jmy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is easy to read code if it is cleanly using paired function/naming,
like start <-> stop, register <-> unregister, etc, etc.
But, current ALSA SoC code is very random, unbalance, not paired, etc.
It is easy to create bug at the such code, and is difficult to debug.
Now ALSA SoC has snd_soc_add_component(), but there is no paired
snd_soc_del_component(). Thus, snd_soc_unregister_component() is
calling cleanup function randomly. it is difficult to read.
This patch adds missing snd_soc_del_component_unlocked() and
balance up code.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/8736f23jn4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_lookup_component() is using mix of continue and break
in the same loop. It is odd.
This patch cleanup it.
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/874kzi3jn8.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch moves snd_soc_lookup_component() to upper side.
This is prepare for snd_soc_unregister_component()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/875zjy3jnd.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is easy to read code if it is cleanly using paired function/naming,
like start <-> stop, register <-> unregister, etc, etc.
But, current ALSA SoC code is very random, unbalance, not paired, etc.
It is easy to create bug at the such code, and it will be difficult to
debug.
ALSA SoC has soc_bind_dai_link(), but its paired soc_unbind_dai_link()
is not implemented.
More confusable is that soc_remove_pcm_runtimes() which should be
soc_unbind_dai_link() is implemented without synchronised
to soc_bind_dai_link().
This patch cleanup this unbalance.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/877e4e3jni.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If we focus to soc_bind_dai_link() at snd_soc_instantiate_card(),
we will notice very complex operation.
static int snd_soc_instantiate_card(...)
{
...
/*
* (1) Bind dai_link via card pre-linked dai_link
*
* Bind dai_link via card pre-linked.
* 1 dai_link will be 1 rtd, and connected to card.
* for_each_card_prelinks() is for card pre-linked dai_link.
*
* Image
*
* card
* - rtd(A)
* - rtd(A)
*/
for_each_card_prelinks(card, i, dai_link) {
ret = soc_bind_dai_link(card, dai_link);
...
}
...
/*
* (2) Connect card pre-linked dai_link to card list
*
* Connect all card pre-linked dai_link to *card list*.
* Here, (A) means from card pre-linked.
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
*/
for_each_card_prelinks(card, i, dai_link) {
ret = snd_soc_add_dai_link(card, dai_link);
...
}
...
/*
* (3) Probe binded component
*
* Each rtd has many components.
* Here probes each rtd connected components.
* rtd(A) in Image is the probe target.
*
* During this component probe, topology may add new dai_link to
* *card list* by using snd_soc_add_dai_link() which is
* used at (2).
* Here, (B) means from topology
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
* - dai_link(B)
* - dai_link(B)
*/
ret = soc_probe_link_components(card);
...
/*
* (4) Bind dai_link again
*
* Bind dai_link again for topology.
* Note, (1) used for_each_card_prelinks(),
* here is using for_each_card_links()
*
* This means from card list.
* As Image indicating, it has dai_link(A) (from card pre-link)
* and dai_link(B) (from topology).
* main target here is dai_link(B).
* soc_bind_dai_link() ignores already used
* dai_link (= dai_link(A))
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
* - rtd(B) - dai_link(B)
* - rtd(B) - dai_link(B)
*/
for_each_card_links(card, dai_link) {
ret = soc_bind_dai_link(card, dai_link);
...
}
...
}
As you see above, it is doing very complex method.
The problem is binding dai_link via "card pre-linked" (= (1)) and
"topology added dai_link" (= (3)) are separated.
The code can be simple if we can bind dai_link when dai_link
is connected to *card list*.
This patch do it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/878sou3jnn.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_is_dai_link_bound() check will be called both
*before* soc_bind_dai_link() (A), and
*under* soc_bind_dai_link() (B).
These are very verbose code. Let's remove one of them.
* static int soc_bind_dai_link(...)
{
...
(B) if (soc_is_dai_link_bound(...)) {
...
return 0;
}
...
}
static int snd_soc_instantiate_card(...)
{
...
for_each_card_links(...) {
(A) if (soc_is_dai_link_bound(...))
continue;
* ret = soc_bind_dai_link(...);
if (ret)
goto probe_end;
}
...
}
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a79a3jns.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_init_dai_link() is needed to be called before soc_bind_dai_link().
int snd_soc_instantiate_card()
{
for_each_card_prelinks(...) {
(1) ret = soc_init_dai_link(...);
...
}
...
for_each_card_prelinks(...) {
(2) ret = soc_bind_dai_link(...);
...
}
...
for_each_card_links(...) {
...
(A) ret = soc_init_dai_link(...);
...
(B) ret = soc_bind_dai_link(...);
}
...
(1) is for (2), and (A) is for (B)
(1) and (2) are for card prelink dai_link.
(A) and (B) are for topology added dai_link.
soc_init_dai_link() is sanity check for dai_link, not initializing today.
Therefore, it is confusable naming. We can rename it as sanity_check.
And this check is for soc_bind_dai_link().
It can be more simple code if we can call it from soc_bind_dai_link().
This patch renames it to soc_dai_link_sanity_check(), and
call it from soc_bind_dai_link().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87d0e63joh.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch moves soc_init_dai_link() next to soc_bind_dai_link().
This is prepare for soc_bind_dai_link() cleanup.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87eeym3joq.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ADAU7118 has an example where the codec has an i2c address of 14, and
the unit address set to 14 as well.
However, while the address is expressed in decimal, the unit-address is
supposed to be in hexadecimal, which ends up with two different addresses
that trigger a DTC warning. Fix this by setting the address to 0x14.
Cc: Nuno Sá <nuno.sa@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Fixes: 969d49b2cd ("dt-bindings: asoc: Add ADAU7118 documentation")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20191105105615.21391-1-maxime@cerno.tech
Signed-off-by: Mark Brown <broonie@kernel.org>
Takashi Iwai