From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Gross <andy.gross@linaro.org>
Subject: Re: [Freedreno] [PATCH 10/12] firmware: qcom_scm: Add
 qcom_scm_gpu_zap_resume()
Date: Sat, 14 Jan 2017 23:20:58 -0600
Message-ID: <20170115052058.GK5710@hector.attlocal.net>
References: <1480361317-9937-1-git-send-email-jcrouse@codeaurora.org>
 <1480361317-9937-11-git-send-email-jcrouse@codeaurora.org>
 <20170113171241.GH5710@hector.attlocal.net>
 <20170113232438.GA24139@jcrouse-lnx.qualcomm.com>
 <20170115034901.GJ5710@hector.attlocal.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-arm-msm-owner@vger.kernel.org>
Received: from mail-ot0-f180.google.com ([74.125.82.180]:35992 "EHLO
        mail-ot0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750832AbdAOFVC (ORCPT
        <rfc822;linux-arm-msm@vger.kernel.org>);
        Sun, 15 Jan 2017 00:21:02 -0500
Received: by mail-ot0-f180.google.com with SMTP id 104so26658970otd.3
        for <linux-arm-msm@vger.kernel.org>; Sat, 14 Jan 2017 21:21:02 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <20170115034901.GJ5710@hector.attlocal.net>
Sender: linux-arm-msm-owner@vger.kernel.org
List-Id: linux-arm-msm@vger.kernel.org
To: linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: stanimir.varbanov@linaro.org

+ Stanimir

On Sat, Jan 14, 2017 at 09:49:01PM -0600, Andy Gross wrote:
> On Fri, Jan 13, 2017 at 04:24:38PM -0700, Jordan Crouse wrote:
> > On Fri, Jan 13, 2017 at 11:12:41AM -0600, Andy Gross wrote:
> > > On Mon, Nov 28, 2016 at 12:28:35PM -0700, Jordan Crouse wrote:
> > > > Add an interface to trigger the remote processor to reinitialize the GPU
> > > > zap shader on power-up.
> > > > 
> > > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > > ---
> > > 
> > > <snip>
> > > 
> > > > +int __qcom_scm_gpu_zap_resume(struct device *dev)
> > > > +{
> > > > +	struct qcom_scm_desc desc = {0};
> > > > +	struct arm_smccc_res res;
> > > > +	int ret;
> > > > +
> > > > +	desc.args[0] = 0;
> > 
> > This is an opcode to force the state to resume.
> > 
> > QCOM_SCM_BOOT_SET_STATE_RESUME perhaps?  Or something similar but shorter.
> > 
> > > > +	desc.args[1] = 13;
> > 
> > This is the same as the SCM id of the GPU but I think that is a coincidence.
> > We've always used it to identify the GPU in this call.
> > 
> > QCOM_SCM_BOOT_SET_STATE_GPU would be fine here - or something similar.
> > 
> > > Can I get a define here for these two?  Or maybe a comment on what these values
> > > are?
> > > 
> > > > +	desc.arginfo = QCOM_SCM_ARGS(2);
> > > > +
> > > > +	ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, 0x0A, &desc, &res);
> > > 
> > > Same with the 0xA.  We usually throw a #define in for the command definitions.
> > 
> > 0x0A sets the state of the device - for us it is always 0 (resume) and always
> > the GPU.
> > 
> > #define  QCOM_SCM_BOOT_SET_STATE 0x0A
> > 
> > > Otherwise this all looks fine.  If you can get back to me with either the values
> > > or a new patch I can include this in the next pull.
> > 
> > I'll make the changes and start the song and dance, but you'll no doubt be
> > faster than I.
> 
> I can just fix up the patch with the above.  Thanks for the additional details.

The plot thickens.  So I have a patch from Stanimir concerning another SCM call
that is using the same command and number of arguments.  And it also concerns
setting state.  I think that we need to roll a common API for setting the state
and then both of you can call it.  That way we can kill two birds with one
stone.

Something along the lines of a function prototype:
int qcom_scm_set_remote_state(u32 state, u32 id)
{
	return __qcom_scm_set_remote_state(__scm->dev, state, id);
}
EXPORT_SYMBOL(qcom_scm_set_remote_state);

where state is the state you want set, and id is the identifier of the remote
proc.

Does this make sense for both of your use cases?

Andy