Re: [EXT] Re: SCMI & Devfreq

[Sudeep Holla <sudeep.holla@arm.com>]

On Mon, Oct 07, 2019 at 06:20:40PM +0000, Sujeet Kumar Baranwal wrote:
> Hi Sudeep,
>
> Per SCMI perf protocol, the MAX_OPPS macro which is 16, means that at max
> there could be only 16 OPPs. In my platform implementation, I tried with 16
> OPPs but  when OPPs info came linux perf.c file from SCP, it only showed 12
> OPPs only.
>
> Suspecting the rx buffer size, I increased the size to 256 and now the
> message for all 16 OPPs were reliably received.
>

OK, but is there any reason why firmware can't use num_levels[31:16]
i.e Number of remaining performance levels and [11:00] i.e.Number of
performance levels that are returned by this call to break and send in
2 calls ? The interface was designed to work with minimum shmem size.


> *****************
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 449f713..737d675 100644 (file)
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -612,7 +612,7 @@ int scmi_handle_put(const struct scmi_handle *handle)
>  static const struct scmi_desc scmi_generic_desc = {
>         .max_rx_timeout_ms = 30,        /* We may increase this if required */
>         .max_msg = 20,          /* Limited by MBOX_TX_QUEUE_LEN */
> -       .max_msg_size = 128,
> +       .max_msg_size = 256,

If you need this, I prefer to introduce new compatible for the platform
scmi and add it as platform specific scmi_desc to start with.

--
Regards,
Sudeep