Messages in this thread | | | Date | Tue, 10 Dec 2019 18:46:33 +0000 | From | Sudeep Holla <> | Subject | Re: [PATCH] firmware: arm_scmi: Make scmi core independent of transport type |
| |
On Tue, Dec 10, 2019 at 11:04:48AM +0530, Viresh Kumar wrote: > On 09-12-19, 18:13, Cristian Marussi wrote: > > On 29/11/2019 09:31, Viresh Kumar wrote:
[...]
> > > desc = of_device_get_match_data(dev); > > > if (!desc) > > > return -EINVAL; > > > > This scmi_desc struct descriptor is retrieved from of_match_table .data and points to > > the driver-provided scmi_generic_desc > > > > 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, > > }; > > > > Is not this kind of information possibly (maybe partially) related to the selected > > transport, and as such it should be also provided dynamically by the chosen transport > > layer at probe time, like the transport_ops, instead of being hard-coded in > > this driver ? > > I had my doubts about this thing and I missed checking it out. > > @Sudeep: Is this information completely mailbox specific ? Should I move it to > mailbox.c here ? >
May be to some/small extent.
1. max_rx_timeout_ms is firmware dependent, maximum time it expects to complete a synchronous request or acknowledge async request(worst case value). 2. max_msg_size is maximum size of the buffer we need to allocate, mostly based on the specification and we don't have any more that 0x80. But the custom/vendor specific protocols may wary and hence I thought of keeping it configurable for platforms. 3. max_msg is the maximum number of messages the transport can support. This is currently based on the mailbox layer. For SMC/HVC we can have upto nr_cpus, something different for spci/optee. We must be able to make it transport independent if required.
This is mainly used to pre-allocate number of (tx/rx) buffers.
-- Regards, Sudeep
| |