linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: "Dwivedi, Avaneesh Kumar (avani)" <akdwived@codeaurora.org>
Cc: sboyd@codeaurora.org, agross@codeaurora.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-remoteproc@vger.kernel.org
Subject: Re: [PATCH v5 3/4] remoteproc: qcom: Make secure world call for mem ownership switch
Date: Fri, 2 Jun 2017 10:55:40 -0700	[thread overview]
Message-ID: <20170602175540.GD12920@tuxbook> (raw)
In-Reply-To: <613203ac-a1a1-05b1-db5c-a48003003b53@codeaurora.org>

On Thu 01 Jun 14:42 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:

> Hi Bjorn,
> 
> Thanks lot many for such a blazing fast response :)
> 
> regarding your points.
> 
> a- Do you mean caller's of q6v5_xfer_mem_ownership() should pass two
> additional inputs i.e. *next_perm and *next_vmid
> 

You have two cases; assign to HLOS and assign to MSS, so I imagine that
you pass a single indicator of which you want to assign. I.e. rather
than looking at what the current state is and flipping you pass the
conditional of that if statement as a parameter.

>     and that based on successful return of qcom_scm_assign () they should be
> treated as *current_perm and *current_vmid
> 

Instead of your index, you take a "int *curr_perms", which you use as
the current vmid list and you assign at the end of the function (like
you do today).

So to transfer the ownership to the MSS you would make a function call
like:

ret = q6v5_xfer_mem_ownership(qproc, &qproc->mpss_owner, ..., true);

mpss_owner would have to be initialize to HLOS before calling this, but
will always be holding the current value.

>    by caller? if so caller will have to do flipping between MSS and HLOS,
> isn't it?
> 

As far as I can see each call to this driver is either a "transfer to
MSS" or "transfer to HLOS", so that shouldn't be a problem.

>    Also code churning will increase this way, and also logging the way is
> being handled now may require to change again.
> 
>    or am i misunderstanding your proposal?
> 

Could be that I'm missing something, if above doesn't make sense please
do let me know.

>    Sorry for inconvenience, but if you could through little more light, that
> will help.
> 

There's no inconvenience, thanks for reaching out for clarifications on
my comments.

Regards,
Bjorn

> 
> -Avaneesh
> 
> 
> On 6/2/2017 2:12 AM, Bjorn Andersson wrote:
> > On Thu 01 Jun 12:17 PDT 2017, Avaneesh Kumar Dwivedi wrote:
> > 
> > > MSS proc on msm8996 can not access fw loaded region without stage
> > > second translation of memory pages where mpss image are loaded.
> > > This patch in order to enable mss boot on msm8996 invoke scm call
> > > to switch or share ownership between apps and modem.
> > > 
> > Overall this looks good now, I have two minor notes that I want you to
> > fix up though.
> > 
> > > diff --git a/drivers/remoteproc/qcom_q6v5_pil.c b/drivers/remoteproc/qcom_q6v5_pil.c
> > > @@ -288,6 +290,40 @@ static struct resource_table *q6v5_find_rsc_table(struct rproc *rproc,
> > >   	return &table;
> > >   }
> > > +static int q6v5_xfer_mem_ownership(struct q6v5 *qproc,
> > > +				   int image, phys_addr_t addr,
> > Rather than relying on a static int to keep track of current permissions
> > pass a "int *current_perms", that you update on success.
> > 
> > Add int mba_perm and int mpss_perm to the struct q6v5 and initialize
> > them in probe and just keep the metadata_perm on the stack in
> > q6v5_mpss_init_image.
> > 
> > > +				   size_t size)
> > > +{
> > > +	static int current_owner[3][1] = {{BIT(QCOM_SCM_VMID_HLOS)},
> > > +			{BIT(QCOM_SCM_VMID_HLOS)},
> > > +			{BIT(QCOM_SCM_VMID_HLOS)} };
> > > +	struct qcom_scm_vmperm next[] = {{0} };
> > You don't need to initialize this, and if you just keep it "struct
> > qcom_scm_vmperm next" you can pass it as &next in the
> > qcom_scm_assign_mem() call.
> > 
> > > +	int ret;
> > > +
> > > +	if (!qproc->need_mem_protection)
> > > +		return 0;
> > > +
> > > +	if (current_owner[image][0] == BIT(QCOM_SCM_VMID_HLOS)) {
> > And rather than making this flip back and forth with every call, I think
> > it's more robust if you pass the new expected owner as a parameter to
> > the function. Simplest way I can think of it to add a "bool
> > remote_owner" as a parameter; it makes the changes minimal and works
> > with the naming of the function.
> > 
> > > +		next->vmid = QCOM_SCM_VMID_MSS_MSA;
> > > +		next->perm = QCOM_SCM_PERM_RW;
> > > +	} else {
> > > +		next->vmid = QCOM_SCM_VMID_HLOS;
> > > +		next->perm = QCOM_SCM_PERM_RWX;
> > > +	}
> > > +
> > > +	ret = qcom_scm_assign_mem(addr, ALIGN(size, SZ_4K),
> > > +		current_owner[image][0], next, 1);
> > > +	if (ret < 0) {
> > > +		pr_err("Failed to assign %s memory access in range %p to %p ret = %d\n",
> > > +			(image == 0 ? "MDT" : image == 1 ? "MBA" : "MPSS"),
> > > +			(void *)addr, (void *)(addr + size), ret);
> > > +		return ret;
> > > +	}
> > > +
> > > +	current_owner[image][0] = ret;
> > > +	return 0;
> > > +}
> > > +
> > Regards,
> > Bjorn
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project.
> 

  reply	other threads:[~2017-06-02 17:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01 19:17 [PATCH v5 0/4] Add memory ownership switch support and enable mss rproc on msm8996 Avaneesh Kumar Dwivedi
2017-06-01 19:17 ` [PATCH v5 1/4] firmware: scm: Add new SCM call API for switching memory ownership Avaneesh Kumar Dwivedi
2017-06-01 20:30   ` Bjorn Andersson
2017-06-02 18:22   ` Stephen Boyd
2017-06-07 16:06     ` Dwivedi, Avaneesh Kumar (avani)
2017-06-01 19:17 ` [PATCH v5 2/4] remoteproc: qcom: refactor mss fw image loading sequence Avaneesh Kumar Dwivedi
2017-06-01 20:32   ` Bjorn Andersson
2017-06-01 19:17 ` [PATCH v5 3/4] remoteproc: qcom: Make secure world call for mem ownership switch Avaneesh Kumar Dwivedi
2017-06-01 20:42   ` Bjorn Andersson
2017-06-01 21:42     ` Dwivedi, Avaneesh Kumar (avani)
2017-06-02 17:55       ` Bjorn Andersson [this message]
2017-06-07 16:27         ` Dwivedi, Avaneesh Kumar (avani)
2017-06-07 21:20           ` Bjorn Andersson
2017-06-01 19:17 ` [PATCH v5 4/4] remoteproc: qcom: Add support for mss remoteproc on msm8996 Avaneesh Kumar Dwivedi
2017-06-01 20:33   ` Bjorn Andersson

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=20170602175540.GD12920@tuxbook \
    --to=bjorn.andersson@linaro.org \
    --cc=agross@codeaurora.org \
    --cc=akdwived@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=sboyd@codeaurora.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).