| Message ID | 1480361317-9937-11-git-send-email-jcrouse@codeaurora.org (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Andy Gross |
| Headers | show |
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; > + desc.args[1] = 13; 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. 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. Thanks. Andy -- 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
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; > > + desc.args[1] = 13; > > 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. > > 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. Thanks for reaching out. Since this isn't my usual area I'll need to work out some terminology with the SCM folks to make sure I don't accidentally do anything that will get me in trouble. Jordan
On Fri, Jan 13, 2017 at 10:22:45AM -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; > > > + desc.args[1] = 13; > > > > 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. > > > > 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. > > Thanks for reaching out. Since this isn't my usual area I'll need to work out > some terminology with the SCM folks to make sure I don't accidentally do > anything that will get me in trouble. Yeah I did a brief look through CAF. I saw basically the same information. If you can't get an answer, let me know and I'll just take it and put in a comment. Andy -- 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
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. Jordan
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. Andy -- 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
+ 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 -- 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
Hi Andy, On 01/15/2017 07:20 AM, 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@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? I'm fine with that.
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@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
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@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. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c index c6aeedb..1a0876c 100644 --- a/drivers/firmware/qcom_scm-32.c +++ b/drivers/firmware/qcom_scm-32.c @@ -560,3 +560,8 @@ int __qcom_scm_pas_mss_reset(struct device *dev, bool reset) return ret ? : le32_to_cpu(out); } + +int __qcom_scm_gpu_zap_resume(struct device *dev) +{ + return -ENOTSUPP; +} diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c index cdf422f2..82aba97 100644 --- a/drivers/firmware/qcom_scm-64.c +++ b/drivers/firmware/qcom_scm-64.c @@ -363,3 +363,18 @@ int __qcom_scm_pas_mss_reset(struct device *dev, bool reset) return ret ? : res.a1; } + +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; + desc.args[1] = 13; + desc.arginfo = QCOM_SCM_ARGS(2); + + ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, 0x0A, &desc, &res); + + return ret ? : res.a1; +} diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index 143edbc..e26c7f4 100644 --- a/drivers/firmware/qcom_scm.c +++ b/drivers/firmware/qcom_scm.c @@ -312,6 +312,12 @@ static const struct reset_control_ops qcom_scm_pas_reset_ops = { .deassert = qcom_scm_pas_reset_deassert, }; +int qcom_scm_gpu_zap_resume(void) +{ + return __qcom_scm_gpu_zap_resume(__scm->dev); +} +EXPORT_SYMBOL(qcom_scm_gpu_zap_resume); + /** * qcom_scm_is_available() - Checks if SCM is available */ diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h index 3584b00..581f934 100644 --- a/drivers/firmware/qcom_scm.h +++ b/drivers/firmware/qcom_scm.h @@ -56,6 +56,8 @@ extern int __qcom_scm_pas_auth_and_reset(struct device *dev, u32 peripheral); extern int __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral); extern int __qcom_scm_pas_mss_reset(struct device *dev, bool reset); +extern int __qcom_scm_gpu_zap_resume(struct device *dev); + /* common error codes */ #define QCOM_SCM_V2_EBUSY -12 #define QCOM_SCM_ENOMEM -5 diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h index cc32ab8..e1729fb 100644 --- a/include/linux/qcom_scm.h +++ b/include/linux/qcom_scm.h @@ -37,6 +37,8 @@ extern int qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr, extern int qcom_scm_pas_auth_and_reset(u32 peripheral); extern int qcom_scm_pas_shutdown(u32 peripheral); +extern int qcom_scm_gpu_zap_resume(void); + #define QCOM_SCM_CPU_PWR_DOWN_L2_ON 0x0 #define QCOM_SCM_CPU_PWR_DOWN_L2_OFF 0x1
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> --- drivers/firmware/qcom_scm-32.c | 5 +++++ drivers/firmware/qcom_scm-64.c | 15 +++++++++++++++ drivers/firmware/qcom_scm.c | 6 ++++++ drivers/firmware/qcom_scm.h | 2 ++ include/linux/qcom_scm.h | 2 ++ 5 files changed, 30 insertions(+)