On Tue, Jan 17, 2017 at 10:04:59AM -0700, Jordan Crouse wrote: > 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 <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. > > > > 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. If you guys can ack/sob that patch I'd appreciate it. As for the #defines, you guys can define whatever you like in your drivers. This API just pushes all that into your client drivers. 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