All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: pierre-louis.bossart@linux.intel.com,
	alsa-devel@alsa-project.org, filip.kaczmarski@intel.com,
	harshapriya.n@intel.com, marcin.barlik@intel.com,
	zwisler@google.com, lgirdwood@gmail.com, tiwai@suse.com,
	filip.proborszcz@intel.com, broonie@kernel.org,
	amadeuszx.slawinski@linux.intel.com, michal.wasko@intel.com,
	cujomalainey@chromium.org, krzysztof.hejmowski@intel.com,
	ppapierkowski@habana.ai, vamshi.krishna.gopal@intel.com
Subject: Re: [PATCH v4 02/13] ASoC: Intel: catpt: Define DSP operations
Date: Thu, 13 Aug 2020 21:51:29 +0300	[thread overview]
Message-ID: <20200813185129.GB1891694@smile.fi.intel.com> (raw)
In-Reply-To: <20200812205753.29115-3-cezary.rojewski@intel.com>

On Wed, Aug 12, 2020 at 10:57:42PM +0200, Cezary Rojewski wrote:
> Implement dsp lifecycle functions such as core RESET and STALL,
> SRAM power control and LP clock selection. This also adds functions for
> handling transport over DW DMA controller.

...

> +static void catpt_dma_transfer_complete(void *arg)
> +{
> +	struct catpt_dev *cdev = arg;
> +

> +	dev_dbg(cdev->dev, "%s\n", __func__);

Noise. Somebody should provide either trace events, of get used to function tracer / perf.

> +}

...

> +static bool catpt_dma_filter(struct dma_chan *chan, void *param)
> +{

> +	return chan->device->dev == (struct device *)param;

Redundant casting, and please, consider to swap left and right side (in this
case easily to find these and perhaps provide a generic helper function).

> +}

...

> +#define CATPT_DMA_DEVID		1 /* dma engine used */

Not sure I understand what exactly this means.

...

> +#define CATPT_DMA_MAXBURST	0x3

We have DMA engine definitions for that, please avoid magic numbers.

...

> +#define CATPT_DMA_DSP_ADDR_MASK	0xFFF00000

GENMASK()

...

> +	dma_cap_set(DMA_SLAVE, mask);

How this helps with mem2mem channel?

...

> +	chan = dma_request_channel(mask, catpt_dma_filter, cdev->dev);
> +	if (!chan) {
> +		dev_err(cdev->dev, "request channel failed\n");

> +		dump_stack();

Huh?!

> +		return ERR_PTR(-EPROBE_DEFER);
> +	}

...

> +	status = dma_wait_for_async_tx(desc);

> +	catpt_updatel_shim(cdev, HMDC,
> +			   CATPT_HMDC_HDDA(CATPT_DMA_DEVID, chan->chan_id), 0);

Update even in erroneous case?

> +	return (status == DMA_COMPLETE) ? 0 : -EPROTO;

...

> +static void catpt_dsp_set_srampge(struct catpt_dev *cdev, struct resource *sram,
> +				  unsigned long mask, unsigned long new)
> +{
> +	unsigned long old;
> +	u32 off = sram->start;
> +	u32 b = __ffs(mask);
> +
> +	old = catpt_readl_pci(cdev, VDRTCTL0) & mask;

> +	dev_dbg(cdev->dev, "SRAMPGE [0x%08lx] 0x%08lx -> 0x%08lx",
> +		mask, old, new);

trace event / point?

> +	if (old == new)
> +		return;
> +
> +	catpt_updatel_pci(cdev, VDRTCTL0, mask, new);

> +	udelay(60);

Delays should be commented.

> +
> +	/*
> +	 * dummy read as the very first access after block enable
> +	 * to prevent byte loss in future operations
> +	 */
> +	for_each_clear_bit_from(b, &new, fls(mask)) {

fls_long()

> +		u8 buf[4];
> +
> +		/* newly enabled: new bit=0 while old bit=1 */
> +		if (test_bit(b, &old)) {
> +			dev_dbg(cdev->dev, "sanitize block %ld: off 0x%08x\n",

> +				(b - __ffs(mask)), off);

Unneeded parentheses.

> +			memcpy_fromio(buf, cdev->lpe_ba + off, sizeof(buf));
> +		}
> +		off += CATPT_MEMBLOCK_SIZE;
> +	}
> +}

...

> +	/* offset value given mask's start and invert it as ON=b0 */

> +	new <<= __ffs(mask);
> +	new = ~(new) & mask;

Unneeded parentheses.
And perhaps in one line it will be better to understand:

	new = ~(new << __ffs(mask)) & mask;

...

> +	if (waiti) {
> +		/* wait for DSP to signal WAIT state */
> +		ret = catpt_readl_poll_shim(cdev, ISD,
> +					    reg, (reg & CATPT_ISD_DCPWM),
> +					    500, 10000);
> +		if (ret < 0) {

> +			dev_warn(cdev->dev, "await WAITI timeout\n");

Shouldn't be an error level?

> +			mutex_unlock(&cdev->clk_mutex);
> +			return ret;
> +		}
> +	}

...

> +int catpt_dsp_update_lpclock(struct catpt_dev *cdev)
> +{
> +	struct catpt_stream_runtime *stream;

> +	bool lp;
> +
> +	if (list_empty(&cdev->stream_list))
> +		return catpt_dsp_select_lpclock(cdev, true, true);
> +
> +	lp = true;
> +	list_for_each_entry(stream, &cdev->stream_list, node) {
> +		if (stream->prepared) {
> +			lp = false;
> +			break;
> +		}
> +	}
> +
> +	return catpt_dsp_select_lpclock(cdev, lp, true);

Seems too much duplication.

	struct catpt_stream_runtime *stream;

	list_for_each_entry(stream, &cdev->stream_list, node) {
		if (stream->prepared)
			return catpt_dsp_select_lpclock(cdev, false, true);
	}

	return catpt_dsp_select_lpclock(cdev, true, true);


Better?

> +}

...

> +	/* set D3 */
> +	catpt_updatel_pci(cdev, PMCS, CATPT_PMCS_PS, CATPT_PMCS_PS_D3HOT);
> +	udelay(50);

Don't we have PCI core function for this?

...

> +	/* set D0 */
> +	catpt_updatel_pci(cdev, PMCS, CATPT_PMCS_PS, 0);
> +	udelay(100);

Ditto.

...

> +	/* set D3 */
> +	catpt_updatel_pci(cdev, PMCS, CATPT_PMCS_PS, CATPT_PMCS_PS_D3HOT);
> +	udelay(50);

Ditto.

...

> +	/* set D0 */
> +	catpt_updatel_pci(cdev, PMCS, CATPT_PMCS_PS, 0);

Ditto.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2020-08-13 18:52 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-12 20:57 [PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 01/13] ASoC: Intel: Add catpt device Cezary Rojewski
2020-08-13 18:29   ` Andy Shevchenko
2020-08-17 10:02     ` Cezary Rojewski
2020-08-18 10:07       ` Andy Shevchenko
2020-08-19 13:26         ` Cezary Rojewski
2020-08-19 13:43           ` Andy Shevchenko
2020-08-25  9:32             ` Cezary Rojewski
2020-08-25 13:18               ` Andy Shevchenko
2020-08-25 13:19                 ` Andy Shevchenko
2020-08-25 20:43       ` Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 02/13] ASoC: Intel: catpt: Define DSP operations Cezary Rojewski
2020-08-13 18:51   ` Andy Shevchenko [this message]
2020-08-17 11:12     ` Cezary Rojewski
2020-08-18 11:50       ` Andy Shevchenko
2020-08-19 13:46         ` Cezary Rojewski
2020-08-19 14:21           ` Andy Shevchenko
2020-08-19 14:54             ` Cezary Rojewski
2020-08-20  7:30       ` Cezary Rojewski
2020-08-20  9:00         ` Andy Shevchenko
2020-08-24 16:33           ` Cezary Rojewski
2020-08-25 13:16             ` Andy Shevchenko
2020-08-25 13:23               ` Andy Shevchenko
2020-08-27 10:06               ` Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 03/13] ASoC: Intel: catpt: Firmware loading and context restore Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 04/13] ASoC: Intel: catpt: Implement IPC protocol Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 05/13] ASoC: Intel: catpt: Add IPC messages Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 06/13] ASoC: Intel: catpt: PCM operations Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 07/13] ASoC: Intel: catpt: Event tracing Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 08/13] ASoC: Intel: catpt: Simple sysfs attributes Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 09/13] ASoC: Intel: Select catpt and deprecate haswell Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 10/13] ASoC: Intel: haswell: Remove haswell-solution specific code Cezary Rojewski
2020-08-13 18:57   ` Andy Shevchenko
2020-08-12 20:57 ` [PATCH v4 11/13] ASoC: Intel: broadwell: " Cezary Rojewski
2020-08-13 18:56   ` Andy Shevchenko
2020-08-12 20:57 ` [PATCH v4 12/13] ASoC: Intel: bdw-5650: " Cezary Rojewski
2020-08-13 18:56   ` Andy Shevchenko
2020-08-12 20:57 ` [PATCH v4 13/13] ASoC: Intel: bdw-5677: " Cezary Rojewski
2020-08-13 18:57   ` Andy Shevchenko
2020-08-13  8:30 ` [PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point Amadeusz Sławiński
2020-08-13 16:00 ` Liam Girdwood
2020-08-13 18:11   ` Cezary Rojewski
2020-08-13 19:03     ` Liam Girdwood

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=20200813185129.GB1891694@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=cujomalainey@chromium.org \
    --cc=filip.kaczmarski@intel.com \
    --cc=filip.proborszcz@intel.com \
    --cc=harshapriya.n@intel.com \
    --cc=krzysztof.hejmowski@intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=marcin.barlik@intel.com \
    --cc=michal.wasko@intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ppapierkowski@habana.ai \
    --cc=tiwai@suse.com \
    --cc=vamshi.krishna.gopal@intel.com \
    --cc=zwisler@google.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.