All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Subhransu S. Prusty" <subhransu.s.prusty@intel.com>
Cc: vinod.koul@intel.com, alsa-devel@alsa-project.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	lgirdwood@gmail.com
Subject: Re: [v3 04/11] ASoC: Intel: sst: Add IPC handling
Date: Wed, 27 Aug 2014 21:37:37 +0100	[thread overview]
Message-ID: <20140827203737.GY17528@sirena.org.uk> (raw)
In-Reply-To: <1408625450-32315-5-git-send-email-subhransu.s.prusty@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 2544 bytes --]

On Thu, Aug 21, 2014 at 06:20:43PM +0530, Subhransu S. Prusty wrote:

> +	spin_unlock_bh(&ctx->block_lock);
> +	pr_debug("Block not found or a response is received for a short message for ipc %d, drv_id %d\n",
> +			ipc, drv_id);

Is this not an error?

> +int sst_free_block(struct intel_sst_drv *ctx, struct sst_block *freed)
> +{
> +	struct sst_block *block = NULL, *__block;
> +
> +	pr_debug("in %s\n", __func__);
> +	spin_lock_bh(&ctx->block_lock);
> +	list_for_each_entry_safe(block, __block, &ctx->block_list, node) {
> +		if (block == freed) {
> +			list_del(&freed->node);
> +			kfree(freed->data);
> +			freed->data = NULL;
> +			kfree(freed);

Can you safely kfree() inside a spinlock?

> +			spin_unlock_bh(&ctx->block_lock);
> +			return 0;
> +		}
> +	}
> +	spin_unlock_bh(&ctx->block_lock);
> +	return -EINVAL;

I'd expect much louder complaints if we try to free something that's not
allocated - what happens if we end up reallocating something quickly and
then double freeing?  Better to complain if we hit such a code path.

> +	/* check busy bit */
> +	header.full = sst_shim_read64(sst_drv_ctx->shim, SST_IPCX);
> +	if (header.p.header_high.part.busy) {
> +		spin_unlock_irqrestore(&sst_drv_ctx->ipc_spin_lock, irq_flags);
> +		pr_debug("Busy not free... post later\n");
> +		return;
> +	}
> +	/* copy msg from list */

Blank line here.

> +	/* check busy bit */
> +	header.full = sst_shim_read64(sst_drv_ctx->shim, SST_IPCX);
> +	while (header.p.header_high.part.busy) {
> +		if (loop_count > 10) {
> +			pr_err("sst: Busy wait failed, cant send this msg\n");
> +			retval = -EBUSY;
> +			goto out;
> +		}
> +		cpu_relax();
> +		loop_count++;
> +		header.full = sst_shim_read64(sst_drv_ctx->shim, SST_IPCX);
> +	}

10 spins seems short but OK.

> +	pr_debug("sst: Post message: header = %x\n",
> +					msg->mrfld_header.p.header_high.full);
> +	pr_debug("sst: size = 0x%x\n", msg->mrfld_header.p.header_low_payload);
> +	if (msg->mrfld_header.p.header_high.part.large)
> +		memcpy_toio(sst_drv_ctx->mailbox + SST_MAILBOX_SEND,
> +			msg->mailbox_data,
> +			msg->mrfld_header.p.header_low_payload);
> +
> +	sst_shim_write64(sst_drv_ctx->shim, SST_IPCX, msg->mrfld_header.full);

Can we factor out the I/O bit with the non-blocking case here here?
It's just a small bit at the top of the function that's really
duplicated.

> +	case IPC_IA_FW_ASYNC_ERR_MRFLD:
> +		pr_err("FW sent async error msg:\n");
> +		for (i = 0; i < (data_size/4); i++)
> +			pr_err("0x%x\n", (*((unsigned int *)data_offset + i)));

print_hex_dump()?

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2014-08-27 20:37 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21 12:50 [v3 00/11] ASoC: Intel: sst - add the merrifield IPC driver Subhransu S. Prusty
2014-08-21 12:50 ` [v3 01/11] ASoC: Intel: mrfld - add the dsp sst driver Subhransu S. Prusty
2014-08-27 19:40   ` Mark Brown
2014-09-01 10:37     ` [alsa-devel] " Subhransu S. Prusty
2014-09-01 11:15       ` Mark Brown
2014-09-01 10:37     ` Subhransu S. Prusty
2014-08-21 12:50 ` [v3 02/11] ASoC: Intel: mrfld - Add DSP load and management Subhransu S. Prusty
2014-08-27 20:17   ` Mark Brown
2014-09-01 11:45     ` Subhransu S. Prusty
2014-09-01 11:45     ` [alsa-devel] " Subhransu S. Prusty
2014-08-21 12:50 ` [v3 03/11] ASoC: Intel: sst - add pcm ops handling Subhransu S. Prusty
2014-08-27 20:29   ` Mark Brown
2014-08-21 12:50 ` [v3 04/11] ASoC: Intel: sst: Add IPC handling Subhransu S. Prusty
2014-08-27 20:37   ` Mark Brown [this message]
2014-09-01 12:17     ` Subhransu S. Prusty
2014-09-01 12:17     ` [alsa-devel] " Subhransu S. Prusty
2014-09-01 12:51       ` Mark Brown
2014-09-01 13:57         ` Subhransu S. Prusty
2014-09-01 13:57         ` [alsa-devel] " Subhransu S. Prusty
2014-09-01 14:41           ` Mark Brown
2014-09-02  5:22             ` Vinod Koul
2014-09-03 18:39               ` Mark Brown
2014-08-21 12:50 ` [v3 05/11] ASoC: Intel: sst: add stream operations Subhransu S. Prusty
2014-08-27 20:41   ` Mark Brown
2014-09-01 12:18     ` [alsa-devel] " Subhransu S. Prusty
2014-09-01 12:18     ` Subhransu S. Prusty
2014-08-21 12:50 ` [v3 06/11] ASoC: Intel: sst: Add some helper functions Subhransu S. Prusty
2014-08-21 12:50 ` [v3 07/11] ASoC: Intel: sst: Add makefile and kconfig changes Subhransu S. Prusty
2014-08-21 12:50 ` [v3 08/11] ASoC: Intel: sst: add power management handling Subhransu S. Prusty
2014-08-27 20:46   ` Mark Brown
2014-09-01 12:19     ` [alsa-devel] " Subhransu S. Prusty
2014-09-01 12:19     ` Subhransu S. Prusty
2014-08-21 12:50 ` [v3 09/11] ASoC: Intel: sst: load firmware using async callback Subhransu S. Prusty
2014-08-21 12:50 ` [v3 10/11] ASoC: mfld-compress: Use dedicated function instead of ioctl Subhransu S. Prusty
2014-08-27 20:51   ` Mark Brown
2014-08-21 12:50 ` [v3 11/11] ASoC: Intel: sst - add compressed ops handling Subhransu S. Prusty
2014-08-27 20:52   ` Mark Brown

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=20140827203737.GY17528@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=subhransu.s.prusty@intel.com \
    --cc=vinod.koul@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.