Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 23 Aug 2019 13:04:07 +0530 | From | Vinod Koul <> | Subject | Re: [alsa-devel] [RFC PATCH 31/40] soundwire: intel: move shutdown() callback and don't export symbol |
| |
On 14-08-19, 14:31, Pierre-Louis Bossart wrote: > > > > > > > +void intel_shutdown(struct snd_pcm_substream *substream, > > > > > + struct snd_soc_dai *dai) > > > > > +{ > > > > > + struct sdw_cdns_dma_data *dma; > > > > > + > > > > > + dma = snd_soc_dai_get_dma_data(dai, substream); > > > > > + if (!dma) > > > > > + return; > > > > > + > > > > > + snd_soc_dai_set_dma_data(dai, substream, NULL); > > > > > + kfree(dma); > > > > > +} > > > > > > > > Correct me if I'm wrong, but do we really need to _get_dma_ here? > > > > _set_dma_ seems bulletproof, same for kfree. > > > > > > I must admit I have no idea why we have a reference to DMAs here, this looks > > > like an abuse to store a dai-specific context, and the initial test looks > > > like copy-paste to detect invalid configs, as done in other callbacks. Vinod > > > and Sanyog might have more history than me here. > > > > I dont see snd_soc_dai_set_dma_data() call for > > sdw_cdns_dma_data so somthing is missing (at least in upstream code) > > > > IIRC we should have a snd_soc_dai_set_dma_data() in alloc or some > > initialization routine and we free it here.. Sanyog? > > Vinod, I double-checked that we do not indeed have a call to > snd_soc_dai_dma_data(), but there is code in cdns_set_stream() that sets the > relevant dai->playback/capture_dma_data, see below > > I am not a big fan of this code, touching the ASoC core internal fields > isn't a good idea in general.
IIRC as long as you stick to single link I do not see this required. The question comes into picture when we have multi links as you would need to allocate a soundwire stream and set that for all the sdw DAIs
So, what is the current model of soundwire stream, which entity allocates that and do you still care about multi-link? is there any machine driver with soundwire upstream yet?
> Also not sure why for a DAI we need both _drvdata and _dma_data (especially
_drvdata is global for driver whereas _dma_data is typically used per DAI
> for this case where the information stored has absolutely nothing to do with > DMAs). > > If the idea was to keep a context that is direction-dependent, that's likely > unnecessary. For the Intel/Cadence case the interfaces can be configured as > playback OR capture, not both concurrently, so the "dma" information could > have been stored in the generic DAI _drvdata. > > I have other things to look into for now but this code will likely need to > be cleaned-up at some point to remove unnecessary parts.
Sure please go ahead and do the cleanup. > > int cdns_set_sdw_stream(struct snd_soc_dai *dai, > void *stream, bool pcm, int direction) > { > struct sdw_cdns *cdns = snd_soc_dai_get_drvdata(dai); > struct sdw_cdns_dma_data *dma; > > dma = kzalloc(sizeof(*dma), GFP_KERNEL); > if (!dma) > return -ENOMEM; > > if (pcm) > dma->stream_type = SDW_STREAM_PCM; > else > dma->stream_type = SDW_STREAM_PDM; > > dma->bus = &cdns->bus; > dma->link_id = cdns->instance; > > dma->stream = stream; > > >>> this is equivalent to snd_soc_dai_dma_data() > > if (direction == SNDRV_PCM_STREAM_PLAYBACK) > dai->playback_dma_data = dma; > else > dai->capture_dma_data = dma; > <<<< > return 0; > } > EXPORT_SYMBOL(cdns_set_sdw_stream);
-- ~Vinod
| ![\](/images/icornerr.gif) |