Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756167AbbDJVaF (ORCPT <rfc822;w@1wt.eu>);
	Fri, 10 Apr 2015 17:30:05 -0400
Received: from smtp.codeaurora.org ([198.145.29.96]:45241 "EHLO
	smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753814AbbDJVaD (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 10 Apr 2015 17:30:03 -0400
Date: Fri, 10 Apr 2015 16:30:00 -0500
From: Andy Gross <agross@codeaurora.org>
To: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Cc: Kumar Gala <galak@codeaurora.org>, David Brown <davidb@codeaurora.org>,
        Jeffrey Hugo <jhugo@codeaurora.org>, linux-kernel@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org
Subject: Re: [PATCH 2/2] soc: qcom: Add Shared Memory Manager driver
Message-ID: <20150410213000.GA11763@qualcomm.com>
References: <1428102200-5948-1-git-send-email-bjorn.andersson@sonymobile.com>
 <1428102200-5948-2-git-send-email-bjorn.andersson@sonymobile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1428102200-5948-2-git-send-email-bjorn.andersson@sonymobile.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2791
Lines: 105

On Fri, Apr 03, 2015 at 04:03:20PM -0700, Bjorn Andersson wrote:
<snip>

> +static int qcom_smem_alloc_private(struct qcom_smem *smem,
> +				   unsigned host,
> +				   unsigned item,
> +				   size_t size)
> +{

<snip>

> +	alloc_size = sizeof(*hdr) + ALIGN(size, 8);
> +	if (p + alloc_size >= (void *)phdr + phdr->offset_free_uncached) {
> +		dev_err(smem->dev, "Out of memory\n");
> +		return -ENOSPC;
> +	}

This check always fails due to the fact that we always get a ptr that points to
something beyond the free_uncached area.  We ought to use:
alloc_size > phdr->offset_free_cached - phdr->offset_free_uncached

> +
> +	hdr = p;
> +	hdr->canary = SMEM_PRIVATE_CANARY;
> +	hdr->item = item;
> +	hdr->size = ALIGN(size, 8);
> +	hdr->padding_data = hdr->size - size;
> +	hdr->padding_hdr = 0;
> +

<snip>

> +static int qcom_smem_probe(struct platform_device *pdev)
> +{

<snip>

> +	ret = of_address_to_resource(np, 0, &r);
> +	of_node_put(np);
> +	if (ret)
> +		return ret;
> +
> +	smem->regions[0].aux_base = (u32)r.start;
> +	smem->regions[0].size = resource_size(&r);
> +	smem->regions[0].virt_base = devm_ioremap(&pdev->dev,
> +						  r.start,
> +						  resource_size(&r));

Need to use devm_ioremap_nocache() instead.  We need uncached accesses.

> +	if (!smem->regions[0].virt_base)
> +		return -ENOMEM;
> +
> +	for (i = 1; i < num_regions; i++) {
> +		res = platform_get_resource(pdev, IORESOURCE_MEM, i - 1);
> +
> +		smem->regions[i].aux_base = (u32)res->start;
> +		smem->regions[i].size = resource_size(res);
> +		smem->regions[i].virt_base = devm_ioremap(&pdev->dev,
> +							  res->start,
> +							  resource_size(res));

Same thing here.

> +		if (!smem->regions[i].virt_base)
> +			return -ENOMEM;
> +	}
> +

<snip>

> diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
> new file mode 100644
> index 0000000..294070de
> --- /dev/null
> +++ b/include/linux/soc/qcom/smem.h
> @@ -0,0 +1,14 @@
> +#ifndef __QCOM_SMEM_H__
> +#define __QCOM_SMEM_H__
> +
> +struct device_node;
> +struct qcom_smem;
> +
> +#define QCOM_SMEM_HOST_ANY -1

Would it make sense to throw in the remote processor enumeration?  Same with the
fixed/dynamic item list?

> +
> +int qcom_smem_alloc(unsigned host, unsigned item, size_t size);
> +int qcom_smem_get(unsigned host, unsigned item, void **ptr, size_t *size);
> +
> +int qcom_smem_get_free_space(unsigned host);


-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/