Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Mukunda,Vijendar" <vijendar.mukunda@amd.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	broonie@kernel.org
Cc: alsa-devel@alsa-project.org, Basavaraj.Hiregoudar@amd.com,
	Sunil-kumar.Dommati@amd.com, Mastan.Katragadda@amd.com,
	Arungopal.kondaveeti@amd.com, mario.limonciello@amd.com,
	Liam Girdwood <lgirdwood@gmail.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Syed Saba Kareem <Syed.SabaKareem@amd.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 5/9] ASoC: amd: ps: add support for SoundWire DMA interrupts
Date: Tue, 23 May 2023 13:06:59 +0530	[thread overview]
Message-ID: <2dfeee7c-32bd-c054-22ff-3a2266e62c90@amd.com> (raw)
In-Reply-To: <fea3c862-1470-7911-ff77-5d945b1d77cf@linux.intel.com>

On 22/05/23 23:42, Pierre-Louis Bossart wrote:
>
> On 5/22/23 08:31, Vijendar Mukunda wrote:
>> Initialize workqueue for SoundWire DMA interrupts handling.
>> Whenever audio data equal to the SoundWire FIFO watermark level
>> are produced/consumed, interrupt is generated.
>> Acknowledge the interrupt and schedule the workqueue.
> It would help to explain why a work queue is needed is the first place,
> as opposed to handling periods in the interrupt thread.
For SoundWire DAI link, we are setting nonatomic flag to true.
If we return period elapsed from hard irq handler instead of workqueue,
soft lock up is observed during stream closure.

We can use interrupt thread as well. To have a symmetry with
SoundWire manager work queues, we have used workqueue for
DMA interrupts.

>> +static void acp63_sdw_dma_workthread(struct work_struct *work)
>> +{
>> +	struct acp63_dev_data *adata = container_of(work, struct acp63_dev_data,
>> +						    acp_sdw_dma_work);
>> +	struct sdw_dma_dev_data *sdw_dma_data;
>> +	u32 stream_index;
>> +	u16 pdev_index;
>> +
>> +	pdev_index = adata->sdw_dma_dev_index;
>> +	sdw_dma_data = dev_get_drvdata(&adata->pdev[pdev_index]->dev);
>> +
>> +	for (stream_index = 0; stream_index < ACP63_SDW0_DMA_MAX_STREAMS; stream_index++) {
>> +		if (adata->sdw0_dma_intr_stat[stream_index]) {
>> +			if (sdw_dma_data->sdw0_dma_stream[stream_index])
>> +				snd_pcm_period_elapsed(sdw_dma_data->sdw0_dma_stream[stream_index]);
>> +			adata->sdw0_dma_intr_stat[stream_index] = 0;
>> +		}
>> +	}
>> +	for (stream_index = 0; stream_index < ACP63_SDW1_DMA_MAX_STREAMS; stream_index++) {
>> +		if (adata->sdw1_dma_intr_stat[stream_index]) {
>> +			if (sdw_dma_data->sdw1_dma_stream[stream_index])
>> +				snd_pcm_period_elapsed(sdw_dma_data->sdw1_dma_stream[stream_index]);
>> +			adata->sdw1_dma_intr_stat[stream_index] = 0;
>> +		}
>> +	}
> I am not clear on the benefits of the workqueue which only tests a flag
> that's set ...
In top half, we are checking all stream irq mask and setting
corresponding stream id index in interrupt status array when dma
irq is raised.

Our intention is to handle snd_pcm_period_elapsed in process context.
if the flag is set, call the period elapsed for the substream based on stream
id in work queue.
>
>> +}
>> +
>>  static irqreturn_t acp63_irq_handler(int irq, void *dev_id)
>>  {
>>  	struct acp63_dev_data *adata;
>>  	struct pdm_dev_data *ps_pdm_data;
>>  	struct amd_sdw_manager *amd_manager;
>>  	u32 ext_intr_stat, ext_intr_stat1;
>> +	u32 stream_id = 0;
>>  	u16 irq_flag = 0;
>> +	u16 sdw_dma_irq_flag = 0;
>>  	u16 pdev_index;
>> +	u16 index;
>>  
>>  	adata = dev_id;
>>  	if (!adata)
>> @@ -148,7 +178,57 @@ static irqreturn_t acp63_irq_handler(int irq, void *dev_id)
>>  			snd_pcm_period_elapsed(ps_pdm_data->capture_stream);
>>  		irq_flag = 1;
>>  	}
>> -	if (irq_flag)
>> +	if (ext_intr_stat & ACP_SDW_DMA_IRQ_MASK) {
>> +		for (index = ACP_AUDIO2_RX_THRESHOLD; index <= ACP_AUDIO0_TX_THRESHOLD; index++) {
>> +			if (ext_intr_stat & BIT(index)) {
>> +				writel(BIT(index), adata->acp63_base + ACP_EXTERNAL_INTR_STAT);
>> +				switch (index) {
>> +				case ACP_AUDIO0_TX_THRESHOLD:
>> +					stream_id = ACP_SDW0_AUDIO0_TX;
>> +					break;
>> +				case ACP_AUDIO1_TX_THRESHOLD:
>> +					stream_id = ACP_SDW0_AUDIO1_TX;
>> +					break;
>> +				case ACP_AUDIO2_TX_THRESHOLD:
>> +					stream_id = ACP_SDW0_AUDIO2_TX;
>> +					break;
>> +				case ACP_AUDIO0_RX_THRESHOLD:
>> +					stream_id = ACP_SDW0_AUDIO0_RX;
>> +					break;
>> +				case ACP_AUDIO1_RX_THRESHOLD:
>> +					stream_id = ACP_SDW0_AUDIO1_RX;
>> +					break;
>> +				case ACP_AUDIO2_RX_THRESHOLD:
>> +					stream_id = ACP_SDW0_AUDIO2_RX;
>> +					break;
>> +				}
>> +
>> +				adata->sdw0_dma_intr_stat[stream_id] = 1;
> .. here ...
Please refer above comment.
>> +				sdw_dma_irq_flag = 1;
>> +			}
>> +		}
>> +	}
>> +
>> +	/* SDW1 BT RX */
>> +	if (ext_intr_stat1 & ACP_P1_AUDIO1_RX_THRESHOLD) {
>> +		writel(ACP_P1_AUDIO1_RX_THRESHOLD,
>> +		       adata->acp63_base + ACP_EXTERNAL_INTR_STAT1);
>> +		adata->sdw1_dma_intr_stat[ACP_SDW1_AUDIO1_RX] = 1;
> ... and here ...
>
>> +		sdw_dma_irq_flag = 1;
>> +	}
>> +
>> +	/* SDW1 BT TX*/
>> +	if (ext_intr_stat1 & ACP_P1_AUDIO1_TX_THRESHOLD) {
>> +		writel(ACP_P1_AUDIO1_TX_THRESHOLD,
>> +		       adata->acp63_base + ACP_EXTERNAL_INTR_STAT1);
>> +		adata->sdw1_dma_intr_stat[ACP_SDW1_AUDIO1_TX] = 1;
> ... or here ...
>
>> +		sdw_dma_irq_flag = 1;
>> +	}
>> +
>> +	if (sdw_dma_irq_flag)
>> +		schedule_work(&adata->acp_sdw_dma_work);
>> +
>> +	if (irq_flag || sdw_dma_irq_flag)
>>  		return IRQ_HANDLED;
>>  	else
>>  		return IRQ_NONE;


  reply	other threads:[~2023-05-23  7:33 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22 13:31 [PATCH V2 0/9] ASoC: amd: ps: add SoundWire support Vijendar Mukunda
2023-05-22 13:31 ` [PATCH V2 1/9] ASoC: amd: ps: create platform devices based on acp config Vijendar Mukunda
2023-05-22 16:16   ` Pierre-Louis Bossart
2023-05-23  6:25     ` Mukunda,Vijendar
2023-05-23 14:29       ` Pierre-Louis Bossart
2023-05-24  7:02         ` Mukunda,Vijendar
2023-05-22 13:31 ` [PATCH V2 2/9] ASoC: amd: ps: handle SoundWire interrupts in acp pci driver Vijendar Mukunda
2023-05-22 16:26   ` Pierre-Louis Bossart
2023-05-23  6:49     ` Mukunda,Vijendar
2023-05-23 14:34       ` Pierre-Louis Bossart
2023-05-24  7:01         ` Mukunda,Vijendar
2023-05-22 13:31 ` [PATCH V2 3/9] ASoC: amd: ps: add SoundWire dma driver Vijendar Mukunda
2023-05-22 16:34   ` Pierre-Louis Bossart
2023-05-23  7:11     ` Mukunda,Vijendar
2023-05-23 14:48       ` Pierre-Louis Bossart
2023-05-24 11:37         ` Mukunda,Vijendar
2023-05-25 11:43           ` Mukunda,Vijendar
2023-05-22 13:31 ` [PATCH V2 4/9] ASoC: amd: ps: add SoundWire dma driver dma ops Vijendar Mukunda
2023-05-22 16:39   ` Pierre-Louis Bossart
2023-05-23  5:41     ` Mukunda,Vijendar
2023-05-22 13:31 ` [PATCH V2 5/9] ASoC: amd: ps: add support for SoundWire DMA interrupts Vijendar Mukunda
2023-05-22 18:12   ` Pierre-Louis Bossart
2023-05-23  7:36     ` Mukunda,Vijendar [this message]
2023-05-23 15:00       ` Pierre-Louis Bossart
2023-05-24  7:45         ` Mukunda,Vijendar
2023-05-31  7:28           ` Mukunda,Vijendar
     [not found]             ` <5048a207-4ec4-e954-0fe8-88ed25320c1b@linux.intel.com>
2023-06-05 11:24               ` Mukunda,Vijendar
2023-05-22 13:31 ` [PATCH V2 6/9] ASoC: amd: ps: add pm ops support for SoundWire dma driver Vijendar Mukunda
2023-05-22 18:20   ` Pierre-Louis Bossart
2023-05-23 10:53     ` Mukunda,Vijendar
2023-05-23 15:03       ` Pierre-Louis Bossart
2023-05-22 13:31 ` [PATCH V2 7/9] ASoC: amd: ps: enable SoundWire dma driver build Vijendar Mukunda
2023-05-22 13:31 ` [PATCH V2 8/9] ASoC: amd: update comments in Kconfig file Vijendar Mukunda
2023-05-22 13:31 ` [PATCH V2 9/9] ASoC: amd: ps: Add SoundWire specific checks in pci driver in pm ops Vijendar Mukunda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2dfeee7c-32bd-c054-22ff-3a2266e62c90@amd.com \
    --to=vijendar.mukunda@amd.com \
    --cc=Arungopal.kondaveeti@amd.com \
    --cc=Basavaraj.Hiregoudar@amd.com \
    --cc=Mastan.Katragadda@amd.com \
    --cc=Sunil-kumar.Dommati@amd.com \
    --cc=Syed.SabaKareem@amd.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox