Messages in this thread | | | From | Peng Fan <> | Subject | RE: [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type | Date | Fri, 17 Jan 2020 02:26:43 +0000 |
| |
> 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 ?
Yes, will you implement that?
> > [...] > > > + > > + 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.
No need, I forgot the remove them.
Thanks Peng.
> > -- > Regards, > Sudeep
| |