Hi, >> >> Command mode panels will work fine with a single VC, I don't think >> video mode can run by using only one VC. > > Okay, I think we're talking about different VCs =). It's > rather confusing in the TRM. A VC (in DSI packet sense) > refers to the channel ID sent in the packet, and a VC (in > OMAP DSS register sense) refers to a set of configurations > used to send DSI packets. I think we need to come up with > terms that clearly make the distinction between these, > because they really don't have anything in common. (I'd like > to hear the rationale for naming OMAP's config registers as VCs... =). >
Yeah, it took me a while to figure out the difference from the TRM too. As far as the driver is concerned, I think there was a "dest_per" member for each set of VC configurations, that really made things clear. Its not in the present kernel, but it would be nice to get it back. The present approach always correlates VC0 configuration to VC_ID 0, 1 to 1 and so on. That confused me for a while again :| >> Also, for command mode, there isn't a restriction to use a single VC. >> If you configure one VC to have slave port as source and the other as >> video port, the need to switch the VC source between L4 and VP would go away. > > This was what I had at some point. However, I was unsure how > transmissions are synchronized in that case. If there's > transmission going on from VP via, say, VC0, and I send a > message from L4 via VC1, what happens? Does VC1 wait until > VC0 is done? Or does it send the packet between VC0's packets? > I don't know how things works internally, but I am sure the 2 VC configuration works for a handful of phones :) Is this a thing that should be explained in the DSI specification, or is this something that should be taken care of while implementing DSI hardware? I'll try to find out. > But I agree, different VCs for L4 and VP usage would make > some things a bit simpler. > >> The most optimal way would be to use one VC for each peripheral, but I >> don't think the usecase of connecting 4 panels to the same > DSI lanes would ever be needed. > > Yes, that is quite unlikely. But it's difficult to say what > kind of devices one needs to connect (see below), but it > could be that we may come up with some kind of rules that fit > to all cases. > > For example, is there ever need to have to OMAP VCs > configured as VP at the same time? If not, we know that there > will always be 3 OMAP VCs free for L4 use. Etc. (I didn't > think this really, just throwing ideas =). > Yes it would be good to more of such rules. I don't think the one above is valid for OMAP4 though. One of the DSI blocks has 2 video ports as input. One VC can be configured in Video mode + Video Port and the other can be Command mode + Video port, and command mode and video port can run together. We haven't tried it out yet (and don't want to either :)) >>> >>> Nevertheless, it should be possible to use multiple VCs in one driver. >>> I've implemented a driver for a buffer chip that used all 4 channels. >> >> So did you connect more than one panel to DSI? I am curious about how >> it works > > The chip had it's own framebuffer memory, and you could > connect two displays to the chip. The virtual channel mapping > was something like > this: > 0 - routed to first panel > 1 - routed to second panel > 2 - buffer chip config > 3 - buffer chip framebuffer config > That's interesting, slightly out of topic question: How would a buffer chip / LVDS bridge chip fit in the DSS2 fw. Should it be in the panel driver or have its own driver? Asking out of curiosity. Regards, Archit-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
