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@xxxxxxxxxxxxxx>
> > > ---
> >
> > <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.
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
