[alsa-devel] [PATCH 4/7] Asoc: sti: add CPU DAI driver for capture

[Mark Brown]

On Mon, Apr 27, 2015 at 04:53:24PM +0200, Arnaud Pouliquen wrote:
> On 04/24/2015 08:20 PM, Mark Brown wrote:
> >On Tue, Apr 14, 2015 at 03:35:28PM +0200, Arnaud Pouliquen wrote:

> >>+const struct snd_pcm_hardware uni_reader_pcm_hw = {
> >>+	.info = (SNDRV_PCM_INFO_INTERLEAVED |
> >>+		 SNDRV_PCM_INFO_BLOCK_TRANSFER |
> >>+		 SNDRV_PCM_INFO_PAUSE),

> >The commit message says this is a CPU DAI but a snd_pcm_hardware is a
> >DMA controller.

> Do you means that i should just define a structure related to DAI
> constraints
> and fill snd_pcm_hardware in sti_platform.c?

I mean that if I'm reviewing a DAI driver I don't expect to see
definitions for a DMA controller without warning.

> >>+static inline int get_property_hdl(struct device *dev, struct device_node *np,
> >>+				   const char *prop, int idx)

> >This appears to be duplicated from the previous patch, as does a *lot*
> >of the code here.  Can we not share more of the code between playback
> >and capture paths?

> I spitted reader and player code,because it is 2 different IPs with some
> specific features and behavior
> ( clock, master/slave mode, IEC, standby ...).
> From my point of view is is more clear like this, but It is feasible to
> merge both code
> adding conditions on direction in most functions. Please tell me what you
> prefer.
> I case of merge i suppose that the best is to not define uniperif_ops struct
> but externalize functions...

That's reasonable, we just shouldn't be seeing large chunks of obvious
code duplication.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150427/4983c259/attachment.sig>