Message ID | cea12544-6dfd-55d4-7c85-68290c720515@arm.com |
---|---|
State | New |
Headers | show |
Hi Neil, On 16/08/16 10:41, Neil Armstrong wrote: > On 08/15/2016 03:35 PM, Sudeep Holla wrote: >> Hi Neil, >> >> On 09/08/16 11:29, Neil Armstrong wrote: >>> Add legacy protocol driver for an early published SCPI implementation >>> by supporting old command indexes and structure. >>> This driver also supports vendor messages and rockchip specific >>> mailbox data structure for message passing to SCP. >>> >> > > Hi Sudeep, > >> Sorry for the delay but I expected some attempts to reduce the >> duplication of code we have here. I really don't like the duplication of >> the code. As I mentioned earlier it can be reduced. I see lot of scope >> for that and I see that you made zero attempts since v2. > > Yes, this post is an intermediate RFC to show to rockchip guys how I > could implement supportfor their vendor commands, the next RFC will > certainly merge the two drivers with minimal code duplication. > Ah sorry for the comment then, I didn't realize that. I missed those discussions. >>> +enum legacy_scpi_client_id { >>> + SCPI_CL_NONE, >>> + SCPI_CL_CLOCKS, >>> + SCPI_CL_DVFS, >>> + SCPI_CL_POWER, >>> + SCPI_CL_THERMAL, >>> + SCPI_MAX, >>> +}; >>> + >> >> As I said before these values were introduced by me initially and I >> reckon firmware doesn't depend on that. Have you really tested dropping >> them ? This must go as they are useless and we now have tokens which are >> much better. > > I am not sure, I'm currently waiting for Amlogic's SCPI FW specification to be sure > these are not needed at all, in the meantime I will still implement them. > Just change and give it a spin on your board. The initial spec mentions that the SCP should return this as is as sent by the requester. I thought of this grouping initially and then found certain limitations and went with token which is bit more useful compared to this after some review. >> >> I will stop here and ask why can't you start with simple change like >> below ? Then we can add or re-define the structures/enums when >> absolutely needed. Please don't just copy the entire driver and make >> changes where-ever needed or please try to adapt to the new driver and >> try to deviate as less as required by the firmware. > > It will be done in RFC v4. > Cool, thanks. I will try to review ASAP, so that we can target v4.9 -- Regards, Sudeep
diff --git i/drivers/firmware/arm_scpi.c w/drivers/firmware/arm_scpi.c index 438893762076..b394ffb5939c 100644 --- i/drivers/firmware/arm_scpi.c +++ w/drivers/firmware/arm_scpi.c @@ -82,6 +82,9 @@ #define MAX_RX_TIMEOUT (msecs_to_jiffies(30)) +typedef int (*scpi_send_msg_func)(u8 cmd, void *tx_buf, unsigned int tx_len, + void *rx_buf, unsigned int rx_len); + enum scpi_error_codes { SCPI_SUCCESS = 0, /* Success */