Messages in this thread | | | Date | Wed, 15 Jan 2020 14:33:25 +0000 | From | Sudeep Holla <> | Subject | Re: [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type |
| |
On Wed, Jan 15, 2020 at 08:53:51AM +0000, Peng Fan wrote: > > > Subject: [PATCH V2] firmware: arm_scmi: Make scmi core independent of > > transport type > > > > The SCMI specification is fairly independent of the transport protocol, which > > can be a simple mailbox (already implemented) or anything else. > > The current Linux implementation however is very much dependent of the > > mailbox transport layer. > > > > This patch makes the SCMI core code (driver.c) independent of the mailbox > > transport layer and moves all mailbox related code to a new > > file: mailbox.c. > > > > We can now implement more transport protocols to transport SCMI messages, > > some of the transport protocols getting discussed currently are SMC/HVC, > > SPCI (built on top of SMC/HVC), OPTEE based mailbox (similar to SPCI), and > > vitio based transport as alternative to mailbox. > > > > The transport protocols just need to provide struct scmi_desc, which also > > implements the struct scmi_transport_ops. > > I need put shmem for each protocol, is this expected?
No, it's optional. If some/all protocols need dedicated channel for whatever reasons(like DVFS/Perf for polling based transfers), they can specify. Absence of dedicated channel infers all protocols share the channel(s).
> Sudeep, > I am able to use smc to directly transport data, > with adding a new file, just named smc.c including a scmi_smc_desc,
Good.
> But I not find a good way to pass smc id to smc transport file. >
IMO, we have to deal this in transport specific init. I am thinking of chan_setup in context of this patch. Does that make sense ?
[...]
> + > + scmi_clk: protocol@14 { > + reg = <0x14>; > + shmem = <&cpu_scp_lpri>; > + #clock-cells = <1>; > + clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>, > + <&clk_ext3>, <&clk_ext4>; > + clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2", > + "clk_ext3", "clk_ext4";
This caught my attention, why do we need these clocks phandle list and clock names above ? Ideally just need scmi_clk phandle and the index to refer and names need to be provided by the firmware.
-- Regards, Sudeep
| |