On Monday 17 March 2014, Jassi Brar wrote:
> On Mon, Mar 17, 2014 at 5:45 PM, Arnd Bergmann <a...@arndb.de> wrote:
> > On Monday 17 March 2014 17:33:59 Girish K S wrote:
> >> +Samsung Mailbox Driver
> >> +
> >> +Required properties:
> >> +- compatible: Should be one of the following,
> >> + "samsung,gh7-mailbox" for
> >> + Samsung GH7 SoC series
> >> + "samsung,exynos-mailbox" for
> >> + exynosx SoC series
> >> +- reg: Contains the mailbox register address range (base
> >> address
> >> + and length)
> >> +- interrupts: Contains the interrupt information for the mailbox
> >> + device.
> >> +- samsung,mbox-names: Array of the names of the mailboxes
> >>
> >
> > I think we should not allow new mailbox drivers that don't conform to
> > the framework that is currently under discussion. In particular, this
> > means don't do a "samsung,mbox-names" property. The current consensus
> > seems to be to have a #mbox-cells" property that allows to pass extra
> > parameters from the client driver, and uses an "mboxes" property
> > to reference the mailbox provided.
> >
> > It would be good if you follow up for the subsystem discussion and
> > ensure it gets merged in time, and supports all the use cases you are
> > interested in. The interface is not entirely nailed down yet, so
> > it's a good time to contribute. However, I can already promise that
> > it won't use matching by strings.
> >
> I was just about to submit next revision of framework that this
> Samsung driver conforms to. Now I think I need some expert opinion ...
> (sorry if following is repetition)
>
> As Kumar Gala pointed out in the other thread, the mailbox/ipc chain
> is going to be _very_ platform specific so much so that one rethinks
> if a common api is even warranted : because the client driver will be
> different even if just the remote api(which is going to be
> proprietary) changes, keeping everything else same. For example, a
> client driver for Highbank is highly unlikely to be reusable on
> Exynos, even if both used the same mailbox controller. By my limited
> foresight, mailbox assignment via DT doesn't bring us much benefit but
> only ritual code.
I don't see what that would change. Doing a cross-device binding in DT
is hard, as we see by lots of people (e.g. the above "samsung,mbox-names"
crap) getting it wrong. If we do it properly once, everyone can use the
same binding, and common code to parse the connection between the
mailbox driver and the user.
> Perhaps the mailbox controller driver should name its links as it
> wants. By how the remote works with the mailbox links, the client
> driver asks for a specific mailbox link (which maybe a hardcoded
> string in the driver or be gotten alongside other data via client's
> DT) ?
I don't see why we should do it any different from the other bindings.
Let's just stick with mboxes/mbox-names or mailboxes/mailbox-names
if you prefer.
> IOW we can't have a generic API/DT-bindings that could get us
> reusable client drivers. But only common framework/code that would
> otherwise be duplicated by every platform.
That is a major benefit though.
Also even if most drivers won't work across multiple platforms, there
is still a reasonable chance that /some/ drivers will.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
