Marc Dietrich wrote at Sunday, October 30, 2011 2:58 PM:
> On Friday 28 October 2011 09:56:41 you wrote:
> > Marc Dietrich wrote at Friday, October 28, 2011 5:02 AM:
> > > Am Donnerstag, 27. Oktober 2011, 12:17:25 schrieb Stephen Warren:
> > > > Marc Dietrich wrote at Wednesday, October 26, 2011 1:59 PM:
> > > > > This adds device tree support to the nvec driver. By using this
> > > > > method it is no longer necessary to specify platform data
> > > > > through a board file.
> >
> > ...
> >
> > > > > +/* Match table for of_platform binding */
> > > > > +static const struct of_device_id nvidia_nvec_of_match[]
> > > > > __devinitconst = { + { .compatible = "nvidia,nvec", },
...
> > I'd like to call this "nvidia,nvec-1.0" to version this compatible
> > property; that's the specification version in the latest document that
> > I saw. While we do seemed to have abandoned this approach, I want to
> > make sure this is extensible if someone suddenly decides to go back to
> > it and creates a 2.0 in the future. Does that seem reasonable?
>
> mmh, I can't see why we should add it now. There is no V2 I can see in my
> limited view. If your company plans to expand the protocol you can either
> enhance our driver or create a new one (nvec2), which can add a nvidia,nvec-2
> compatibility property (we can also change ours to nvidia,nvec-1 at the same
> time, but that's not required).
We can't rename anything in DT once we've started using it; if we release
a new kernel that changes (rather than just adds to) the compatible values
it supports, that'd cause old DT files to cease to operate against the new
kernel.
I suppose nvidia,nvec is fine. We can always add nvidia,nvec2 if we do
rev the protocol, and have the existing unnumbered value implicitly be
version 1.
> > That said, there are apparently some OEMs who did change the protocol
> > and do something slightly different. I'm trying to confirm whether PAZ00
> > was one of them. I guess not if PAZ00 works with the standard driver that
> > you linked to.
>
> There are so called OEM commands which we will move to a board specific nvec
> file (e.g. nvec_paz00.c). We haven't got the chance to test it on other boards
> using it yet (e.g. toshiba folio, advent vega, ...). The tablets are mostly
> using it for power control and maybe also leds/switches. I don't think any
> other board uses keyboard / mouse functions.
It sounded like some OEMS had used a completely different protocol rather
than just making use of the OEM commands. Still, it isn't entirely clear
whether that's true yet. I don't think it impacts this driver/board, so
we can just ignore this for now.
--
nvpublic
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
