On Thu, Mar 1, 2018 at 12:26 AM, Samuel Holland <samuel@xxxxxxxxxxxx> wrote: > On 02/28/18 12:14, Jassi Brar wrote: >> On Wed, Feb 28, 2018 at 11:21 PM, Samuel Holland <samuel@xxxxxxxxxxxx> wrote: >>> Hi, >>> >>> On 02/28/18 03:16, Jassi Brar wrote: >>>> On Wed, Feb 28, 2018 at 7:57 AM, Samuel Holland <samuel@xxxxxxxxxxxx> wrote: >>>> .... >>>> >>>>> +/* >>>>> + * The message box hardware provides 8 unidirectional channels. As the mailbox >>>>> + * framework expects them to be bidirectional >>>>> >>>> That is incorrect. Mailbox framework does not require a channel to be >>>> TX and RX capable. >>> >>> Sorry, it would be more accurate to say that the intended mailbox _client_ >>> expects the channels to be bidirectional. >>> >> Mailbox clients are very mailbox provider specific. Your client driver >> is unlikely to be reuseable over another controller+remote combo. >> Your client has to know already what a physical channel can do (RX, TX >> or RXTX). There is no api to provide that info. > > There's a public specification for SCPI available[1]. I'm writing the remote > endpoint to follow that protocol specification. (There's even an explicitly > platform-agnostic update to the protocol called SCMI[2]). Ideally, I should be > able to reuse the existing Linux client drivers for that protocol. > Thanks, I have already read those specs. Please note there are two parts of the spec - Chapter-4-Protocol and Chapter-5-Transport. You should definitely be able to reuse the Protocol implementation. However, transport can vary with platform - that is why it is separated out from Protocol. And mailbox is but one instance of transport. Consider a platform with "power manager" chip connected via, say, I2C - one could still make use of SCMI protocol. Or consider another platform that does have mailbox link to the "power manager" but there is no shared memory between them - you could then pass packets via the mailbox FIFOs. So no, we can't have common transport implementation for every platform. > Are you > suggesting that I need to write a copy of the arm_scpi driver, completely > identical except that it requests two mailbox channels per client (sending on > one and receiving on the other) instead of one? In the >1000 line file, this is > all that I would need to change: > I did unsuccessfully try to convince Sudeep to break the implementation into platform-agnostic protocol and platform-specific transport drivers. That way there would be no duplication of code. Also please realise that you should not be writing controller driver, keeping just one client driver (SCMI/SCPI) in mind. What if another platform with same mailbox controller needs 8 TX "broadcast" links? The h/w supports the usecase, but your driver wouldn't. Thanks -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
