Re: [PATCH v4 1/5] drm/msm/adreno: Implement SMEM-based speed bin
On Fri, Jun 28, 2024 at 10:24:52AM -0700, Elliot Berman wrote:
> On Tue, Jun 25, 2024 at 08:28:06PM +0200, Konrad Dybcio wrote:
> > On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
> > abstracted through SMEM, instead of being directly available in a fuse.
> >
> > Add support for SMEM-based speed binning, which includes getting
> > "feature code" and "product code" from said source and parsing them
> > to form something that lets us match OPPs against.
> >
> > Due to the product code being ignored in the context of Adreno on
> > production parts (as of SM8650), hardcode it to SOCINFO_PC_UNKNOWN.
> >
> > Signed-off-by: Konrad Dybcio
> > ---
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++---
> > drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c| 41
> > +++---
> > drivers/gpu/drm/msm/adreno/adreno_gpu.h| 7 -
> > 4 files changed, 50 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > index c98cdb1e9326..8ace096bb68c 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > @@ -2124,13 +2124,15 @@ static u32 fuse_to_supp_hw(const struct adreno_info
> > *info, u32 fuse)
> > return UINT_MAX;
> > }
> >
> > -static int a6xx_set_supported_hw(struct device *dev, const struct
> > adreno_info *info)
> > +static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
> > +struct device *dev,
> > +const struct adreno_info *info)
> > {
> > u32 supp_hw;
> > u32 speedbin;
> > int ret;
> >
> > - ret = adreno_read_speedbin(dev, );
> > + ret = adreno_read_speedbin(adreno_gpu, dev, );
> > /*
> > * -ENOENT means that the platform doesn't support speedbin which is
> > * fine
> > @@ -2290,7 +2292,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> >
> > a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
> >
> > - ret = a6xx_set_supported_hw(>dev, config->info);
> > + ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
> > if (ret) {
> > a6xx_llc_slices_destroy(a6xx_gpu);
> > kfree(a6xx_gpu);
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > index 1e789ff6945e..e514346088f9 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > @@ -6,6 +6,8 @@
> > * Copyright (c) 2014,2017 The Linux Foundation. All rights reserved.
> > */
> >
> > +#include
> > +
> > #include "adreno_gpu.h"
> >
> > bool hang_debug = false;
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 1c6626747b98..6ffd02f38499 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -21,6 +21,9 @@
> > #include "msm_gem.h"
> > #include "msm_mmu.h"
> >
> > +#include
> > +#include
> > +
> > static u64 address_space_size = 0;
> > MODULE_PARM_DESC(address_space_size, "Override for size of processes
> > private GPU address space");
> > module_param(address_space_size, ullong, 0600);
> > @@ -1061,9 +1064,39 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
> > *adreno_ocmem)
> >adreno_ocmem->hdl);
> > }
> >
> > -int adreno_read_speedbin(struct device *dev, u32 *speedbin)
> > +int adreno_read_speedbin(struct adreno_gpu *adreno_gpu,
> > +struct device *dev, u32 *fuse)
> > {
> > - return nvmem_cell_read_variable_le_u32(dev, "speed_bin", speedbin);
> > + u32 fcode;
> > + int ret;
> > +
> > + /*
> > +* Try reading the speedbin via a nvmem cell first
> > +* -ENOENT means "no nvmem-cells" and essentially means "old DT" or
> > +* "nvmem fuse is irrelevant", simply assume it's fine.
> > +*/
> > + ret = nvmem_cell_read_variable_le_u32(dev, "speed_bin", fuse);
> > + if (!ret)
> > + return 0;
> > + else if (ret != -ENOENT)
> > + return dev_err_probe(dev, ret, "Couldn't re
Re: [PATCH v4 1/5] drm/msm/adreno: Implement SMEM-based speed bin
On Tue, Jun 25, 2024 at 08:28:06PM +0200, Konrad Dybcio wrote:
> On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
> abstracted through SMEM, instead of being directly available in a fuse.
>
> Add support for SMEM-based speed binning, which includes getting
> "feature code" and "product code" from said source and parsing them
> to form something that lets us match OPPs against.
>
> Due to the product code being ignored in the context of Adreno on
> production parts (as of SM8650), hardcode it to SOCINFO_PC_UNKNOWN.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
> drivers/gpu/drm/msm/adreno/adreno_gpu.c| 41
> +++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 7 -
> 4 files changed, 50 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index c98cdb1e9326..8ace096bb68c 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -2124,13 +2124,15 @@ static u32 fuse_to_supp_hw(const struct adreno_info
> *info, u32 fuse)
> return UINT_MAX;
> }
>
> -static int a6xx_set_supported_hw(struct device *dev, const struct
> adreno_info *info)
> +static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
> + struct device *dev,
> + const struct adreno_info *info)
> {
> u32 supp_hw;
> u32 speedbin;
> int ret;
>
> - ret = adreno_read_speedbin(dev, );
> + ret = adreno_read_speedbin(adreno_gpu, dev, );
> /*
>* -ENOENT means that the platform doesn't support speedbin which is
>* fine
> @@ -2290,7 +2292,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
>
> a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
>
> - ret = a6xx_set_supported_hw(>dev, config->info);
> + ret = a6xx_set_supported_hw(adreno_gpu, >dev, config->info);
> if (ret) {
> a6xx_llc_slices_destroy(a6xx_gpu);
> kfree(a6xx_gpu);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 1e789ff6945e..e514346088f9 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -6,6 +6,8 @@
> * Copyright (c) 2014,2017 The Linux Foundation. All rights reserved.
> */
>
> +#include
> +
> #include "adreno_gpu.h"
>
> bool hang_debug = false;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 1c6626747b98..6ffd02f38499 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -21,6 +21,9 @@
> #include "msm_gem.h"
> #include "msm_mmu.h"
>
> +#include
> +#include
> +
> static u64 address_space_size = 0;
> MODULE_PARM_DESC(address_space_size, "Override for size of processes private
> GPU address space");
> module_param(address_space_size, ullong, 0600);
> @@ -1061,9 +1064,39 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem
> *adreno_ocmem)
> adreno_ocmem->hdl);
> }
>
> -int adreno_read_speedbin(struct device *dev, u32 *speedbin)
> +int adreno_read_speedbin(struct adreno_gpu *adreno_gpu,
> + struct device *dev, u32 *fuse)
> {
> - return nvmem_cell_read_variable_le_u32(dev, "speed_bin", speedbin);
> + u32 fcode;
> + int ret;
> +
> + /*
> + * Try reading the speedbin via a nvmem cell first
> + * -ENOENT means "no nvmem-cells" and essentially means "old DT" or
> + * "nvmem fuse is irrelevant", simply assume it's fine.
> + */
> + ret = nvmem_cell_read_variable_le_u32(dev, "speed_bin", fuse);
> + if (!ret)
> + return 0;
> + else if (ret != -ENOENT)
> + return dev_err_probe(dev, ret, "Couldn't read the speed bin
> fuse value\n");
> +
> +#ifdef CONFIG_QCOM_SMEM
> + /*
> + * Only check the feature code - the product code only matters for
> + * proto SoCs unavailable outside Qualcomm labs, as far as GPU bin
> + * matching is concerned.
> + *
> + * Ignore EOPNOTSUPP, as not all SoCs expose this info through SMEM.
> + */
> + ret = qcom_smem_get_feature_code();
> + if (!ret)
> + *fuse = ADRENO_SKU_ID(fcode);
> + else if (ret != -EOPNOTSUPP)
> + return dev_err_probe(dev, ret, "Couldn't get feature code from
> SMEM\n");
Probably want to update a6xx_set_supported_hw() error handling to ignore
-EOPNOTSUPP or do:
else /* ret == -EOPNOTSUPP */
return -ENOENT;
> +#endif
> +
> + return 0;
I noticed that if SMEM isn't enabled and nvmem returns -ENOENT, we still
return 0. That could lead to uninitialized access of speedbin in both
users of adreno_read_speedbin(). Maybe:
Re: [PATCH 1/6] soc: qcom: Move some socinfo defines to the header, expand them
On Fri, Apr 12, 2024 at 02:10:30AM +0200, Konrad Dybcio wrote: > > > On 4/12/24 01:49, Elliot Berman wrote: > > On Thu, Apr 11, 2024 at 10:24:08PM +0200, Konrad Dybcio wrote: > > > > > > > > > On 4/11/24 22:09, Elliot Berman wrote: > > > > On Thu, Apr 11, 2024 at 10:05:30PM +0200, Konrad Dybcio wrote: > > > > > > > > > > > > > > > On 4/11/24 20:55, Elliot Berman wrote: > > > > > > On Fri, Apr 05, 2024 at 10:41:29AM +0200, Konrad Dybcio wrote: > > > > > > > In preparation for parsing the chip "feature code" (FC) and > > > > > > > "product > > > > > > > code" (PC) (essentially the parameters that let us conclusively > > > > > > > characterize the sillicon we're running on, including various > > > > > > > speed > > > > > > > bins), move the socinfo version defines to the public header and > > > > > > > include some more FC/PC defines. > > > > > > > > > > > > > > Signed-off-by: Konrad Dybcio > > > > > > > --- > > > > > > [...] > > > > > > > > > > > 0xf is the last one. > > > > > > One more question, are the "internal/external feature codes" referring to > > > internality/externality of the chips (i.e. "are they QC-lab-only > > > engineering > > > samples), or what else does that represent? > > > > Yes, QC-lab-only engineering samples is the right interpretation of > > these feature codes. > > Do you think it would be beneficial to keep the logic for these ESes in > the upstream GPU driver? Otherwise, I can yank out half of the added lines. > Should be fine to yank, IMO.
Re: [PATCH 1/6] soc: qcom: Move some socinfo defines to the header, expand them
On Thu, Apr 11, 2024 at 10:24:08PM +0200, Konrad Dybcio wrote: > > > On 4/11/24 22:09, Elliot Berman wrote: > > On Thu, Apr 11, 2024 at 10:05:30PM +0200, Konrad Dybcio wrote: > > > > > > > > > On 4/11/24 20:55, Elliot Berman wrote: > > > > On Fri, Apr 05, 2024 at 10:41:29AM +0200, Konrad Dybcio wrote: > > > > > In preparation for parsing the chip "feature code" (FC) and "product > > > > > code" (PC) (essentially the parameters that let us conclusively > > > > > characterize the sillicon we're running on, including various speed > > > > > bins), move the socinfo version defines to the public header and > > > > > include some more FC/PC defines. > > > > > > > > > > Signed-off-by: Konrad Dybcio > > > > > --- > > [...] > > > > > 0xf is the last one. > > One more question, are the "internal/external feature codes" referring to > internality/externality of the chips (i.e. "are they QC-lab-only engineering > samples), or what else does that represent? Yes, QC-lab-only engineering samples is the right interpretation of these feature codes. Thanks, Elliot
Re: [PATCH 1/6] soc: qcom: Move some socinfo defines to the header, expand them
On Thu, Apr 11, 2024 at 10:05:30PM +0200, Konrad Dybcio wrote: > > > On 4/11/24 20:55, Elliot Berman wrote: > > On Fri, Apr 05, 2024 at 10:41:29AM +0200, Konrad Dybcio wrote: > > > In preparation for parsing the chip "feature code" (FC) and "product > > > code" (PC) (essentially the parameters that let us conclusively > > > characterize the sillicon we're running on, including various speed > > > bins), move the socinfo version defines to the public header and > > > include some more FC/PC defines. > > > > > > Signed-off-by: Konrad Dybcio > > > --- > > [...] > > > > + SOCINFO_FC_EXT_RESERVE, > > > +}; > > > > SOCINFO_FC_EXT_RESERVE was a convenient limit since we mapped > > SOCINFO_FC_AA -> string "AA" via an array, and we've only needed the 8 > > feature codes so far. > > > > We should remove the EXT_RESERVE and test for the Y0-YF (internal > > feature code) values instead. > > OK > > > > > > + > > > +/* Internal feature codes */ > > > +/* Valid values: 0 <= n <= 0xf */ > > > +#define SOCINFO_FC_Yn(n) (0xf1 + n) > > > +#define SOCINFO_FC_INT_RESERVE SOCINFO_FC_Yn(0x10) > > > > We probably should've named this SOCINFO_FC_INT_MAX. Reserve implies > > it's reserved for some future use, but it's really the max value it > > could be. > > So, should SOCINFO_FC_Yn(0x10) also be considered valid, or is (0xf) > the last one? > 0xf is the last one. Thanks, Elliot > > > > > + > > > +/* Product codes */ > > > +#define SOCINFO_PC_UNKNOWN 0 > > > +/* Valid values: 0 <= n <= 8, the rest is reserved */ > > > +#define SOCINFO_PCn(n) (n + 1) > > > +#define SOCINFO_PC_RESERVE (BIT(31) - 1) > > > > Similar comments here as the SOCINFO_FC_EXT_*. It's more like known > > values are [0,8], but more values could come in future chipsets. > > Ok, sounds good, I'll remove the comment then > > Konrad
Re: [PATCH 2/6] soc: qcom: smem: Add pcode/fcode getters
On Fri, Apr 05, 2024 at 10:41:30AM +0200, Konrad Dybcio wrote:
> Introduce getters for SoC product and feature codes and export them.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/smem.c | 66
> +++
> include/linux/soc/qcom/smem.h | 2 ++
> 2 files changed, 68 insertions(+)
>
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 7191fa0c087f..e89b4d26877a 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -795,6 +795,72 @@ int qcom_smem_get_soc_id(u32 *id)
> }
> EXPORT_SYMBOL_GPL(qcom_smem_get_soc_id);
>
> +/**
> + * qcom_smem_get_feature_code() - return the feature code
> + * @id: On success, we return the feature code here.
^^ code
> + *
> + * Look up the feature code identifier from SMEM and return it.
> + *
> + * Return: 0 on success, negative errno on failure.
> + */
> +int qcom_smem_get_feature_code(u32 *code)
> +{
> + struct socinfo *info;
> + u32 raw_code;
> +
> + info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, NULL);
> + if (IS_ERR(info))
> + return PTR_ERR(info);
> +
> + /* This only makes sense for socinfo >= 16 */
> + if (__le32_to_cpu(info->fmt) < SOCINFO_VERSION(0, 16))
> + return -EINVAL;
> +
> + raw_code = __le32_to_cpu(info->feature_code);
> +
> + /* Ensure the value makes sense */
> + if (raw_code >= SOCINFO_FC_INT_RESERVE)
> + raw_code = SOCINFO_FC_UNKNOWN;
> +
> + *code = raw_code;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(qcom_smem_get_feature_code);
> +
> +/**
> + * qcom_smem_get_product_code() - return the product code
> + * @id: On success, we return the product code here.
^^ code
> + *
> + * Look up feature code identifier from SMEM and return it.
> + *
> + * Return: 0 on success, negative errno on failure.
> + */
> +int qcom_smem_get_product_code(u32 *code)
> +{
> + struct socinfo *info;
> + u32 raw_code;
> +
> + info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, NULL);
> + if (IS_ERR(info))
> + return PTR_ERR(info);
> +
> + /* This only makes sense for socinfo >= 16 */
> + if (__le32_to_cpu(info->fmt) < SOCINFO_VERSION(0, 16))
> + return -EINVAL;
> +
> + raw_code = __le32_to_cpu(info->pcode);
> +
> + /* Ensure the value makes sense */
> + if (raw_code >= SOCINFO_FC_INT_RESERVE)
> + raw_code = SOCINFO_FC_UNKNOWN;
> +
> + *code = raw_code;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(qcom_smem_get_product_code);
> +
> static int qcom_smem_get_sbl_version(struct qcom_smem *smem)
> {
> struct smem_header *header;
> diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
> index a36a3b9d4929..aef8c9fc6c08 100644
> --- a/include/linux/soc/qcom/smem.h
> +++ b/include/linux/soc/qcom/smem.h
> @@ -13,5 +13,7 @@ int qcom_smem_get_free_space(unsigned host);
> phys_addr_t qcom_smem_virt_to_phys(void *p);
>
> int qcom_smem_get_soc_id(u32 *id);
> +int qcom_smem_get_feature_code(u32 *code);
> +int qcom_smem_get_product_code(u32 *code);
>
> #endif
>
> --
> 2.40.1
>
>
Re: [PATCH 1/6] soc: qcom: Move some socinfo defines to the header, expand them
On Fri, Apr 05, 2024 at 10:41:29AM +0200, Konrad Dybcio wrote:
> In preparation for parsing the chip "feature code" (FC) and "product
> code" (PC) (essentially the parameters that let us conclusively
> characterize the sillicon we're running on, including various speed
> bins), move the socinfo version defines to the public header and
> include some more FC/PC defines.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/socinfo.c | 8
> include/linux/soc/qcom/socinfo.h | 36
> 2 files changed, 36 insertions(+), 8 deletions(-)
>
...
> diff --git a/include/linux/soc/qcom/socinfo.h
> b/include/linux/soc/qcom/socinfo.h
...
> @@ -74,4 +84,30 @@ struct socinfo {
> __le32 boot_core;
> };
>
> +/* Internal feature codes */
> +enum feature_code {
> + /* External feature codes */
> + SOCINFO_FC_UNKNOWN = 0x0,
> + SOCINFO_FC_AA,
> + SOCINFO_FC_AB,
> + SOCINFO_FC_AC,
> + SOCINFO_FC_AD,
> + SOCINFO_FC_AE,
> + SOCINFO_FC_AF,
> + SOCINFO_FC_AG,
> + SOCINFO_FC_AH,
> + SOCINFO_FC_EXT_RESERVE,
> +};
SOCINFO_FC_EXT_RESERVE was a convenient limit since we mapped
SOCINFO_FC_AA -> string "AA" via an array, and we've only needed the 8
feature codes so far.
We should remove the EXT_RESERVE and test for the Y0-YF (internal
feature code) values instead.
> +
> +/* Internal feature codes */
> +/* Valid values: 0 <= n <= 0xf */
> +#define SOCINFO_FC_Yn(n) (0xf1 + n)
> +#define SOCINFO_FC_INT_RESERVE SOCINFO_FC_Yn(0x10)
We probably should've named this SOCINFO_FC_INT_MAX. Reserve implies
it's reserved for some future use, but it's really the max value it
could be.
> +
> +/* Product codes */
> +#define SOCINFO_PC_UNKNOWN 0
> +/* Valid values: 0 <= n <= 8, the rest is reserved */
> +#define SOCINFO_PCn(n) (n + 1)
> +#define SOCINFO_PC_RESERVE (BIT(31) - 1)
Similar comments here as the SOCINFO_FC_EXT_*. It's more like known
values are [0,8], but more values could come in future chipsets.
> +
> #endif
>
Re: [PATCH 2/2] dma-buf: heaps: secure_heap: Add qcom secure system heap
On 11/22/2023 5:47 AM, Pratyush Brahma wrote:
> From: Vijayanand Jitta
>
> Add secure system for Pixel and Non pixel video usecases, this
> allocates from system heap and secures using qcom_scm_aasign_mem.
^^
typo
>
> Change-Id: If0702f85bff651843c6a5c83694043364229e66b
> Signed-off-by: Vijayanand Jitta
Please get these patches reviewed internally before sending to mailing
list for basic checks. You can review go/upstream when within Qualcomm corp
network.
Pavan mentioned S-o-B is incorrect. Commit text should also not have Change-Id.
Please be sure to send to linux-arm-msm mailing list as well since this affects
Qualcomm chipsets
> ---
> drivers/dma-buf/heaps/secure_heap.c | 163 +++-
> 1 file changed, 160 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> index 04e2ee000e19..cdcf4b3f5333 100644
> --- a/drivers/dma-buf/heaps/secure_heap.c
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -58,6 +58,11 @@ enum secure_memory_type {
>* protect it, then the detail memory management also is inside the TEE.
>*/
> SECURE_MEMORY_TYPE_MTK_CM_CMA = 2,
> + /*
> + * QCOM secure system heap, use system heap to alloc/free.
> + * and use qcom_scm_assign_mem to secure the memory.
> + */
> + SECURE_MEMORY_TYPE_QCOM_SYSTEM = 3,
> };
>
> struct secure_buffer {
> @@ -69,6 +74,7 @@ struct secure_buffer {
>*/
> u32 sec_handle;
> struct page *cma_page;
> + struct sg_table sg_table;
> };
>
> #define TEE_MEM_COMMAND_ID_BASE_MTK 0x1
> @@ -329,11 +335,26 @@ static int secure_heap_qcom_secure_memory(struct
> secure_heap *sec_heap,
> next[0].vmid = data->vmid;
> next[0].perm = data->perm;
>
> -
> - ret = qcom_scm_assign_mem(page_to_phys(sec_buf->cma_page),
> + if (sec_heap->mem_type == SECURE_MEMORY_TYPE_CMA) {
> + ret = qcom_scm_assign_mem(page_to_phys(sec_buf->cma_page),
> sec_buf->size, _perms,
> next, 1);
> + } else if (sec_heap->mem_type == SECURE_MEMORY_TYPE_QCOM_SYSTEM) {
> + struct sg_table *table;
> + struct scatterlist *sg;
> + int i = 0;
> +
> + table = _buf->sg_table;
> + for_each_sgtable_sg(table, sg, i) {
> + struct page *page = sg_page(sg);
>
> + ret = qcom_scm_assign_mem(page_to_phys(page),
> + page_size(page), _perms,
> + next, 1);
> + if (ret)
> + break;
> + }
> + }
> return ret;
> }
>
> @@ -347,9 +368,24 @@ static void secure_heap_qcom_unsecure_memory(struct
> secure_heap *sec_heap,
> next[0].vmid = QCOM_SCM_VMID_HLOS;
> next[0].perm = QCOM_SCM_PERM_RWX;
>
> - qcom_scm_assign_mem(page_to_phys(sec_buf->cma_page),
> + if (sec_heap->mem_type == SECURE_MEMORY_TYPE_CMA) {
> + qcom_scm_assign_mem(page_to_phys(sec_buf->cma_page),
> sec_buf->size, _perms,
> next, 1);
> + } else if (sec_heap->mem_type == SECURE_MEMORY_TYPE_QCOM_SYSTEM) {
> + struct sg_table *table;
> + struct scatterlist *sg;
> + int i = 0;
> +
> + table = _buf->sg_table;
> + for_each_sgtable_sg(table, sg, i) {
> + struct page *page = sg_page(sg);
> +
> + qcom_scm_assign_mem(page_to_phys(page),
> + page_size(page), _perms,
> + next, 1);
> + }
> + }
> }
>
> const struct secure_heap_prv_data qcom_cma_sec_mem_data = {
> @@ -361,6 +397,117 @@ const struct secure_heap_prv_data qcom_cma_sec_mem_data
> = {
> .unsecure_the_memory= secure_heap_qcom_unsecure_memory,
> };
>
> +/* Using system heap allocator */
> +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO)
> +#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
> + | __GFP_NORETRY) & ~__GFP_RECLAIM) \
> + | __GFP_COMP)
> +static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP};
> +static const unsigned int orders[] = {8, 4, 0};
> +#define NUM_ORDERS ARRAY_SIZE(orders)
> +
> +static struct page *alloc_largest_available(unsigned long size,
> + unsigned int max_order)
> +{
> + struct page *page;
> + int i;
> +
> + for (i = 0; i < NUM_ORDERS; i++) {
> + if (size < (PAGE_SIZE << orders[i]))
> + continue;
> + if (max_order < orders[i])
> +
[PATCH] firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/
Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h.
This removes 1 of a few remaining Qualcomm-specific headers into a more
approciate subdirectory under include/.
Suggested-by: Bjorn Andersson
Signed-off-by: Elliot Berman
---
arch/arm/mach-qcom/platsmp.c | 2 +-
drivers/cpuidle/cpuidle-qcom-spm.c | 2 +-
drivers/firmware/qcom_scm-legacy.c | 2 +-
drivers/firmware/qcom_scm-smc.c | 2 +-
drivers/firmware/qcom_scm.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c | 2 +-
drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +-
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 +-
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 2 +-
drivers/media/platform/qcom/venus/firmware.c | 2 +-
drivers/misc/fastrpc.c | 2 +-
drivers/mmc/host/sdhci-msm.c | 2 +-
drivers/net/ipa/ipa_main.c | 2 +-
drivers/net/wireless/ath/ath10k/qmi.c| 2 +-
drivers/pinctrl/qcom/pinctrl-msm.c | 2 +-
drivers/remoteproc/qcom_q6v5_mss.c | 2 +-
drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
drivers/remoteproc/qcom_wcnss.c | 2 +-
drivers/soc/qcom/mdt_loader.c| 2 +-
drivers/soc/qcom/ocmem.c | 2 +-
drivers/soc/qcom/rmtfs_mem.c | 2 +-
drivers/thermal/qcom/lmh.c | 2 +-
drivers/ufs/host/ufs-qcom-ice.c | 2 +-
include/linux/{ => firmware/qcom}/qcom_scm.h | 0
26 files changed, 25 insertions(+), 25 deletions(-)
rename include/linux/{ => firmware/qcom}/qcom_scm.h (100%)
diff --git a/arch/arm/mach-qcom/platsmp.c b/arch/arm/mach-qcom/platsmp.c
index 5d2f386a46d8..eca2fe0f4314 100644
--- a/arch/arm/mach-qcom/platsmp.c
+++ b/arch/arm/mach-qcom/platsmp.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
diff --git a/drivers/cpuidle/cpuidle-qcom-spm.c
b/drivers/cpuidle/cpuidle-qcom-spm.c
index beedf22cbe78..4ac83918edf2 100644
--- a/drivers/cpuidle/cpuidle-qcom-spm.c
+++ b/drivers/cpuidle/cpuidle-qcom-spm.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/firmware/qcom_scm-legacy.c
b/drivers/firmware/qcom_scm-legacy.c
index 9f918b9e6f8f..029e6d117cb8 100644
--- a/drivers/firmware/qcom_scm-legacy.c
+++ b/drivers/firmware/qcom_scm-legacy.c
@@ -9,7 +9,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/firmware/qcom_scm-smc.c b/drivers/firmware/qcom_scm-smc.c
index bb3235a64b8f..16cf88acfa8e 100644
--- a/drivers/firmware/qcom_scm-smc.c
+++ b/drivers/firmware/qcom_scm-smc.c
@@ -8,7 +8,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2000323722bf..468d4d5ab550 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 660ba0db8900..d09221f97f71 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -5,7 +5,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 57586c794b84..89ff978b81bb 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -8,7 +8,7 @@
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
index e7748461cffc..0752fe373351 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
@@ -3,7 +3,7 @@
*/
#include "hdmi.h"
-#include
+#include
#define HDCP_REG_ENABLE 0x01
#define HDCP_REG_DISABLE 0x00
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
index 74e9ef2fd580..b5b14108e086 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
@@ -4,7 +4,7 @@
*/
#include
-#include
+#include
#include
#include "arm-smmu.h"
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 91d404deb115..ef42329e82ce 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -7,7 +7,7 @@
#include
#include
#include
-#include
+#include
#include &
