On 03/05/2015 12:50 PM, Eric Anholt wrote: > Stephen Warren <swarren@xxxxxxxxxxxxx> writes: > >> On 03/02/2015 01:54 PM, Eric Anholt wrote: >>> I was tempted to have the mailbox property channel support just >>> be in the 2835 mailbox driver itself, but >>> mbox_request_channel() wants its device to have the "mboxes" >>> node, and that appears to be only intended for mailbox clients, >>> not controllers. >> >> This is more of a particular format/protocol of messages you can >> send over the mailbox HW than a device. I wonder if it actually >> makes sense to represent it in DT as a device at all? >> >> If we do represent this as a device in DT, shouldn't it also look >> like a mailbox device so that other drivers (clock, display, ...) >> can bind to it and send messages using the mailbox API? > > I don't think it makes sense as a mailbox device. mailbox devices > can only have one client per channel, while there's no reason to > have that limitation on the property channel. You could imagine > having the individual tags be channels, except that again there's > no reason to have the one-client limitation, but more importantly > the indivudual messages to the firmware are composed of N tags. My inclination would be to structure everything as: a) A mailbox driver/device. This doesn't implement any of the protocol code. The device appears in DT, since it's real HW. b) A RPi firmware protocol implementation. This is the only code that talks directly to the mailbox driver. This would implement support for all aspects of the RPi firmware protocol; both the non-property and property channels; they're just different aspects of the one RPi firmware. I guess there could be a DT node that represents the existence of the RPi firmware. It would be a bit of a "virtual device" rather than an actual piece of physical HW, but since firmware is an interface that the SW interacts with, I guess a DT node makes sense. This DT node would contain a property pointing at the physical mailbox provider, so it could send messages. c) Client drivers (clocks, power domains, ...) All client drivers talk to (b) not (a). The DT nodes for this code might contain a property that points at (b), but the API from c->b would likely be something custom rather than the mailbox API, since the RPi firmware protocol implements something custom rather than standard. I'd be interested to hear opinions from people much more familiar with other mailbox HW and protocol drivers. Perhaps they're all lumped together on other platforms? -- 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
