ASoC: SOF: hda-sdw-bpt: mark bpt_stream->link_locked

[bardliao]

Currently, the BPT stream will not run with other streams. So there is no issue we don't mark bpt_stream->link_locked. But we will support the BRA and audio streams run simultaneously. Therefore, marking link_locked is required to prevent the link being used by different streams.

[plbossart]

@bardliao the design assumptions was that all the frame was allocated to BPT or audio, I don't think it's possible to mix the two, nor why we would need this capability.

[bardliao]

@plbossart The request is from Cirrus. One scenario is that one codec and one amp are on the same SDW link. We may want to write the AMP firmware while the codec is playing. @charleskeepax @stuhenderson Do you have any comment?

[kv2019i]

Hmm, even if we end up not supporting concurrent use, this would seem a safe thing to align bpt assignement with the flow in hda_link_stream_assign() and mark the link as locked as done here.

[ranj063]

@bardliao IMO this may not be enough to meet the requirement for concurrent BPT and regular streams. I think we;d be oversimplifying it by assuming that the link DMA is always available when picking the host DMA channel isnt it? What if the link is already taken?

[bardliao]

I don't think the BPT stream will use a stream that bpt_stream->link_locked = 1. Both BTP and regular stream use hda_dsp_stream_get/put with the opened flag to manage the hdac_stream. So that BTP stream should not get a hdac_stream that is opened. But hda_link_stream_assign checked hext_stream->link_locked and that is why we need to set link_locked as regular streams.

[ranj063]

@bardliao I think you should squash the 2 patches and do the link_locked set/clear in the stream_get/put functions

[bardliao]

@bardliao I think you should squash the 2 patches and do the link_locked set/clear in the stream_get/put functions

Updated.

[kv2019i]

I'm afraid V2 raised some new questions, please see inline.

[kv2019i]

And do we really need to remember to pass "use_link_dma" to put? Shouldn't this be recorded in get and we allocated a linked link dma, we release it in put?

[kv2019i]

IOW, @ujfalusi is adding automatic re-coupling in #5525

Not sure how we book-keep the case where we'd have multiple link DMAs per one host DMA, but shouldn't we have some state to track which case this is so the put() can do the right thing?

[bardliao]

And do we really need to remember to pass "use_link_dma" to put? Shouldn't this be recorded in get and we allocated a linked link dma, we release it in put?

I thought about that, but I can't find a place to record the link_locked is set by hda_dsp_stream_get(). That's why originally, I set link_locked and call snd_hdac_ext_stream_release in hda_sdw_bpt_dma_prepare and hda_sdw_bpt_dma_deprepare where the stream is used/released.

[kv2019i]

Ack @bardliao . If you took look at the options, then I'm ok. @ujfalusi can you also take a look that this does not conflict with your thinking in #5525 ?

[kv2019i]

I'm not a fan of these true/false parameters. Can we add a enum or define for this?

hext_stream = hda_dsp_stream_get(sdev, direction, 0, HDA_STREAM_USE_LINK_DMA);

is much more readable. I know we have many true/false interfaces in existing code, so if you @bardliao @ranj063 @ujfalusi are ok, I'm not going to block, but I do find these hard to read (in the calling code).

[bardliao]

I'm not a fan of these true/false parameters. Can we add a enum or define for this?

hext_stream = hda_dsp_stream_get(sdev, direction, 0, HDA_STREAM_USE_LINK_DMA);

is much more readable. I know we have many true/false interfaces in existing code, so if you @bardliao @ranj063 @ujfalusi are ok, I'm not going to block, but I do find these hard to read (in the calling code).

Updated