On Sat, Jan 14, 2017 at 11:20:58PM -0600, Andy Gross wrote:
> + 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 <jcro...@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.
I was worried about this, but not this quickly - glad to see that the other
drivers are coming along too.
If you look carefully, you'll note that the values are inverted - the video
state uses 0 to suspend and 1 to resume, and GPU uses 0 to resume and no
suspend. I asked why and got a bunch of shrugging back. Its not a big deal
because your API accounts for this but expect GPU to have a RESUME #define
that is a different value.
> 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?
Yep - this is fine.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
