All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Subhransu S. Prusty" <subhransu.s.prusty@intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: vinod.koul@intel.com, alsa-devel@alsa-project.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	lgirdwood@gmail.com
Subject: Re: [alsa-devel] [v3 02/11] ASoC: Intel: mrfld - Add DSP load and management
Date: Mon, 1 Sep 2014 17:15:14 +0530	[thread overview]
Message-ID: <20140901114514.GB12898@vinod.koul@linux.intel.com> (raw)
In-Reply-To: <20140827201719.GV17528@sirena.org.uk>

On Wed, Aug 27, 2014 at 09:17:19PM +0100, Mark Brown wrote:
> On Thu, Aug 21, 2014 at 06:20:41PM +0530, Subhransu S. Prusty wrote:
> 
> > +#ifndef CONFIG_X86_64
> > +#define MEMCPY_TOIO memcpy_toio
> > +#else
> > +#define MEMCPY_TOIO memcpy32_toio
> > +#endif
> 
> This is a counterintuitve way to write this (with a reversed test) and
> surely if this is needed it would be better done by the architecture
> headers defining memcpy32_toio on 32 bit platforms too?  I'm also not
> immediately seeing memcpy32_toio() defined when I grep except as a local
> definition in the Atmel NAND driver.  Oh, except...
> 
> > +/**
> > + * memcpy32_toio: Copy using writel commands
> > + *
> > + * This is needed because the hardware does not support
> > + * 64-bit moveq insructions while writing to PCI MMIO
> > + */
> > +void memcpy32_toio(void *dst, const void *src, int count)
> > +{
> > +	int i;
> > +	const u32 *src_32 = src;
> > +	u32 *dst_32 = dst;
> > +
> > +	for (i = 0; i < count/sizeof(u32); i++)
> > +		writel(*src_32++, dst_32++);
> > +}
> 
> ...which is very similar but missing static, __iomem and const
> annotations.  I'd suggest lifting the existing version into generic
> code.

Will send a patch for generic code.
> 
> > +#define SST_CALC_DMA_DSTN(lpe_viewpt_rqd, ia_viewpt_addr, elf_paddr, \
> > +			lpe_viewpt_addr) ((lpe_viewpt_rqd) ? \
> > +		elf_paddr : (ia_viewpt_addr + elf_paddr - lpe_viewpt_addr))
> 
> Can we make this a function please?
Yes. 
> 
> > +static int sst_fill_dstn(struct intel_sst_drv *sst, struct sst_info info,
> > +		Elf32_Phdr *pr, void **dstn, unsigned int *dstn_phys,
> > +		int *mem_type)
> > +{
> > +	/* work arnd-since only 4 byte align copying is only allowed for ICCM */
> 
> around.
> 
> 
> > + * Adds the node to the list after required fields
> > + * are populated in the node
> > + */
> > +
> > +static int sst_fill_memcpy_list(struct list_head *memcpy_list,
> > +			void *destn, const void *src, u32 size, bool is_io)
> 
> Extra blank line.
Will remove.
> 
> > +	for (count = 0; count < module->blocks; count++) {
> 
> > +		block = (void *)block + sizeof(*block) + block->size;
> 
> We're not doing any validation that the data we're reading from the
> firmware file isn't corrupt here - we're just trusting both the number
> of blocks and the sizes of the blocks.  We should be a bit less trusting
> about userspace data.

Will add sanity checks.
> 
> > +static void sst_memcpy_free_lib_resources(struct intel_sst_drv *sst_drv_ctx)
> > +{
> > +	struct sst_memcpy_list *listnode, *tmplistnode;
> > +
> > +	pr_debug("entry:%s\n", __func__);
> > +
> > +	/*Free the list*/
> > +	if (!list_empty(&sst_drv_ctx->libmemcpy_list)) {
> 
> Why the list_empty() check here?
Not required here. Will remove.
> 
> > +		list_for_each_entry_safe(listnode, tmplistnode,
> > +				&sst_drv_ctx->libmemcpy_list, memcpylist) {
> > +			list_del(&listnode->memcpylist);
> > +			kfree(listnode);
> > +		}
> > +	}
> > +}
> > +
> > +void sst_memcpy_free_resources(struct intel_sst_drv *sst_drv_ctx)
> > +{
> > +	struct sst_memcpy_list *listnode, *tmplistnode;
> > +
> > +	pr_debug("entry:%s\n", __func__);
> > +
> > +	/*Free the list*/
> > +	if (!list_empty(&sst_drv_ctx->memcpy_list)) {
> 
> So we have a memcpy() list and a libmemcpy() list?  That seems confusing
> and redundant...
We need libmemcpy to load libraries. Will remove from this from this patch
series and add later.
> 
> > +	if (ctx->sst_state != SST_RESET ||
> > +			ctx->fw_in_mem != NULL)
> > +		goto out;
> 
> Is this perhaps an error conditon we should complain about?
No, this is not an error condition. The firmware can be requested from the
userspace through async request in probe or in the load_firmware through a
request from the userspace. This check is to synchroize between these two.
> 
> > +	if (ctx->info.use_elf == true)
> > +		ret = sst_validate_elf(fw, false);
> 
> I can't find anything that ever sets use_elf...
Not required. Will remove.
> 
> > +static int sst_request_fw(struct intel_sst_drv *sst)
> > +{
> > +	int retval = 0;
> > +	char name[20];
> > +	const struct firmware *fw;
> > +
> > +	snprintf(name, sizeof(name), "%s%04x%s", "fw_sst_",
> > +				sst->pci_id, ".bin");
> > +	pr_debug("Requesting FW %s now...\n", name);
> > +
> > +	retval = request_firmware(&fw, name, sst->dev);
> 
> There was a name in the driver struct for async requests and this does
> appear to duplicate a lot of code from the async callback...
Yes, will factor out the common code..
> 
> > +static inline void print_lib_info(struct snd_sst_lib_download_info *resp)
> > +{
> > +	pr_debug("codec Type %d Ver %d Built %s: %s\n",
> > +		resp->dload_lib.lib_info.lib_type,
> > +		resp->dload_lib.lib_info.lib_version,
> > +		resp->dload_lib.lib_info.b_date,
> > +		resp->dload_lib.lib_info.b_time);
> > +}
> 
> sysfs or debugfs?  There don't seem to be any users of this anyway...
Ok



-- 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  parent reply	other threads:[~2014-09-01 12:07 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     ` Subhransu S. Prusty [this message]
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
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=20140901114514.GB12898@vinod.koul@linux.intel.com \
    --to=subhransu.s.prusty@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.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.