linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanimir Varbanov <stanimir.varbanov@linaro.org>
To: Elliot Berman <eberman@codeaurora.org>,
	Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PATCH 1/2] firmware: qcom_scm: Add memory protect virtual address ranges
Date: Fri, 31 Jul 2020 12:49:57 +0300	[thread overview]
Message-ID: <08538e8e-8558-66af-8120-279530ab158c@linaro.org> (raw)
In-Reply-To: <46632fb9-e07e-fa40-5f13-fb45b4014e03@codeaurora.org>

Hi Elliot,

Thanks for the comments!

On 7/29/20 8:15 PM, Elliot Berman wrote:
> ++
> 
> On 7/24/2020 8:04 AM, Stanimir Varbanov wrote:
>> Hi,
>>
>> Gentle ping for review.
>>
>> On 7/9/20 2:58 PM, Stanimir Varbanov wrote:
>>> This adds a new SCM memprotect command to set virtual address ranges.
>>>
>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>>> ---
>>>  drivers/firmware/qcom_scm.c | 24 ++++++++++++++++++++++++
>>>  drivers/firmware/qcom_scm.h |  1 +
>>>  include/linux/qcom_scm.h    |  8 +++++++-
>>>  3 files changed, 32 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
>>> index 0e7233a20f34..a73870255c2e 100644
>>> --- a/drivers/firmware/qcom_scm.c
>>> +++ b/drivers/firmware/qcom_scm.c
>>> @@ -864,6 +864,30 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz,
>>>  }
>>>  EXPORT_SYMBOL(qcom_scm_assign_mem);
>>>  
>>> +int qcom_scm_mem_protect_video_var(u32 cp_start, u32 cp_size,
>>> +				   u32 cp_nonpixel_start,
>>> +				   u32 cp_nonpixel_size)
>>> +{
>>> +	int ret;
>>> +	struct qcom_scm_desc desc = {
>>> +		.svc = QCOM_SCM_SVC_MP,
>>> +		.cmd = QCOM_SCM_MP_VIDEO_VAR,
>>> +		.arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_VAL, QCOM_SCM_VAL,
>>> +					 QCOM_SCM_VAL, QCOM_SCM_VAL),
>>> +		.args[0] = cp_start,
>>> +		.args[1] = cp_size,
>>> +		.args[2] = cp_nonpixel_start,
>>> +		.args[3] = cp_nonpixel_size,
>>> +		.owner = ARM_SMCCC_OWNER_SIP,
>>> +	};
>>> +	struct qcom_scm_res res;
>>> +
>>> +	ret = qcom_scm_call(__scm->dev, &desc, &res);
>>> +
>>> +	return ret ? : res.result[0];
>>> +}
>>> +EXPORT_SYMBOL(qcom_scm_mem_protect_video_var);
>>> +
> 
> Small nit, can you bump the function above assign_mem? It would keep order aligned with
> the macros in qcom_scm.h

Sure, I will do that.

> 
>>>  /**
>>>   * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
>>>   */
>>> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
>>> index d9ed670da222..14da834ac593 100644
>>> --- a/drivers/firmware/qcom_scm.h
>>> +++ b/drivers/firmware/qcom_scm.h
>>> @@ -97,6 +97,7 @@ extern int scm_legacy_call(struct device *dev, const struct qcom_scm_desc *desc,
>>>  #define QCOM_SCM_MP_RESTORE_SEC_CFG		0x02
>>>  #define QCOM_SCM_MP_IOMMU_SECURE_PTBL_SIZE	0x03
>>>  #define QCOM_SCM_MP_IOMMU_SECURE_PTBL_INIT	0x04
>>> +#define QCOM_SCM_MP_VIDEO_VAR			0x08
>>>  #define QCOM_SCM_MP_ASSIGN			0x16
>>>  
>>>  #define QCOM_SCM_SVC_OCMEM		0x0f
>>> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
>>> index 3d6a24697761..19b5188d17f4 100644
>>> --- a/include/linux/qcom_scm.h
>>> +++ b/include/linux/qcom_scm.h
>>> @@ -81,7 +81,9 @@ extern int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz,
>>>  			       unsigned int *src,
>>>  			       const struct qcom_scm_vmperm *newvm,
>>>  			       unsigned int dest_cnt);
>>> -
>>> +extern int qcom_scm_mem_protect_video_var(u32 cp_start, u32 cp_size,
>>> +					  u32 cp_nonpixel_start,
>>> +					  u32 cp_nonpixel_size);
> 
> Same here.
> 
>>>  extern bool qcom_scm_ocmem_lock_available(void);
>>>  extern int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset,
>>>  			       u32 size, u32 mode);
>>> @@ -131,6 +133,10 @@ static inline int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare)
>>>  static inline int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz,
>>>  		unsigned int *src, const struct qcom_scm_vmperm *newvm,
>>>  		unsigned int dest_cnt) { return -ENODEV; }
>>> +extern inline int qcom_scm_mem_protect_video_var(u32 cp_start, u32 cp_size,
>>> +						 u32 cp_nonpixel_start,
>>> +						 u32 cp_nonpixel_size)
>>> +		{ return -ENODEV; }
> 
> Same here.
> 
>>>  
>>>  static inline bool qcom_scm_ocmem_lock_available(void) { return false; }
>>>  static inline int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset,
>>>
>>
> 

-- 
regards,
Stan

  reply	other threads:[~2020-07-31  9:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 11:58 [PATCH 0/2] Venus - fix firmware load failure Stanimir Varbanov
2020-07-09 11:58 ` [PATCH 1/2] firmware: qcom_scm: Add memory protect virtual address ranges Stanimir Varbanov
2020-07-24 15:04   ` Stanimir Varbanov
2020-07-29 17:15     ` Elliot Berman
2020-07-31  9:49       ` Stanimir Varbanov [this message]
2020-07-09 11:58 ` [PATCH 2/2] venus: firmware: Set " Stanimir Varbanov

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=08538e8e-8558-66af-8120-279530ab158c@linaro.org \
    --to=stanimir.varbanov@linaro.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=eberman@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).