Re: [Freedreno] [PATCH 10/12] firmware: qcom_scm: Add qcom_scm_gpu_zap_resume()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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.
> 
> 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.

-- 
regards,
Stan
--
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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux