Re: [PATCH v2] remoteproc: qcom: Add venus rproc support on msm8996 platform.

[Stephen Boyd <sboyd@codeaurora.org>]

On 11/25, Avaneesh Kumar Dwivedi wrote:
> This patch is based on
> 	https://patchwork.kernel.org/patch/9415627/
> 	https://patchwork.kernel.org/patch/9415651/
> 
> This patch add clock initialization, enable and disable support.
> Required resource name string and rating are differentiated based
> on compatible string. Also added documentation for venus pil on
> msm8996.
> 
> Signed-off-by: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org>
> ---

Why isn't Stan Cced on this patch?

>  .../devicetree/bindings/remoteproc/qcom,venus.txt  |   3 +-
>  drivers/remoteproc/qcom_venus_pil.c                | 115 ++++++++++++++++++++-
>  2 files changed, 116 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> index 2d73ba1..c986f52 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> @@ -6,7 +6,8 @@ on the Qualcomm Venus remote processor core.
>  - compatible:
>  	Usage: required
>  	Value type: <string>
> -	Definition: must contain "qcom,venus-pil"
> +	Definition: must contain "qcom,venus-pil" or
> +				"qcom,venus-8996-pil"
>  
>  - memory-region:
>  	Usage: required

No addition of clocks or clock-names properties in this document?

> diff --git a/drivers/remoteproc/qcom_venus_pil.c b/drivers/remoteproc/qcom_venus_pil.c
> index 6d4e55b..23b7e99 100644
> --- a/drivers/remoteproc/qcom_venus_pil.c
> +++ b/drivers/remoteproc/qcom_venus_pil.c
> @@ -194,8 +296,19 @@ static int venus_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct venus_rproc_res venus_8996_res = {
> +	.venus_clks = (char*[]){"mx", "cx", "pll", NULL},
> +	.venus_clk_rate = {19200000, 19200000, 19200000, 80000000},

I'm very much lost. I don't really understand why we're adding
clock control here. Perhaps that is the responsibility of the
video driver itself and isn't supposed to be in the remoteproc
portion? Testing things standalone without the video driver seems
like a unit test, which is not too useful of a test if it doesn't
mirror real use cases.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project