On Sun, Jul 1, 2018 at 1:01 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Wed, Jun 27, 2018 at 7:21 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > On Thu, Jun 21, 2018 at 08:49:41PM +0200, Linus Walleij wrote: > > > > +This panel driver can driver a variety of panels. It requires > > > > s/can driver/can drive/ > > > > Though what a driver supports is irrelevant to the binding... > > It it not a software driver the text is referring to. It is a > electrical interface to a panel. Like how a TTL circuit connected > to a LED is referred to as a "LED driver", it's simply what the > industry calls these things. Yes, I'm aware of the term, but I see *far* more of the other use of "driver". Can you say "panel driver IC" to clarify. > So there are two things: the panel driver and the panel, the > same panel driver is used with several panels. What the > electronics engineer will do is put a panel driver like this > into his design and then connect some panel s/he finds > in the right quantity in the streets of Shenzhen. Yep. I've had the fun of trying to figure out how to get panels working and having the piecemeal documentation of the driver IC without all the hook-up details... > > If you remove timings, how does it drive a variety of panels? Just by > > compatible? > > Yes. > > Like we did for > Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt > which is similar to this. According to that, there's only 1 panel supported. > In fact I think many panel drivers are just sloppily slipping in > under the radar as "panels" in our bindings. Indeed. I'm not sure that trying to split driver ICs and panels is really feasible at least up front given how poor the documentation is typically. > >That would mean "tpo,tpg110" alone is not valid nor useful > > as a fallback. > > Actually it is. The hardware is wired up to the desired > resolution with hardware straps, which appear in > the registers the (software) driver can read out so > this is ideally self-describing hardware. Nice. Can you add that detail. > But for the event that something needs tweaking in the > future, like we overspecify say SoCs, I include the > exact system on which it is deployd as a separate > compatible string. > > > > +a few GPIO lines for control of its reset line and custom serial > > > +protocol. > > > > > > Required properties: > > > -- compatible : "tpo,tpg110" > > > +- compatible : one of: > > > + "ste,nomadik-nhk15-display", "tpo,tpg110" > > > + "tpo,tpg110" > > > - grestb-gpios : panel reset GPIO Also, use 'reset-gpios' as that is the standard name. > > > - scen-gpios : serial control enable GPIO > > > - scl-gpios : serial control clock line GPIO > > > - sda-gpios : serial control data line GPIO > > > > I2C? That should be done differently... > > It is not I2C, the lines are just named confusingly > similar. None of the I2C (-like) protocols apply. > I was similarly confused when I first implemented it. If this is 3-wire SPI then as Andrzej says, then still it should be done as spi-gpio. Which really just means these gpio properties go away and this should be a SPI child node. Rob -- 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
