On 2013-12-09 15:10, Thierry Reding wrote: >> No idea. But I have worked with a device, that used VC0 for the device's >> configuration registers, VC1 for buffer commands (the device had a >> framebuffer), VC2 and VC3 for panels connected to that device. > > Well, VC2 and VC3 certainly sound like logically separate devices to me. > If they are only connected to the device it sounds like they aren't part > of the device at all.
Yes, the two panels are obviously separate devices. > One could even argue that a device's configuration and the framebuffer > are logically separate and therefore it wouldn't be a problem to address > them as separate devices. True. But one could also argue that handling them with separate linux devices just causes unnecessary complexity. >>>> So I think we should consider DSI as a one-to-one link, and let the DSI >>>> peripheral manage the VC IDs as it wants. >>> >>> But doing so would prevent us from supporting setups where we have two >>> separate peripherals with different VC numbers. >> >> No it wouldn't. We could still communicate with the extra peripherals >> via the hub device. What I was trying to say is that we shouldn't think >> or model DSI with multiple devices as multiple devices connected to the >> same DSI bus. Instead, it should be seen as a tree of one-to-one links >> (as it is in the HW). > > But even if you have a tree of one-to-one links, you still need some way > to address the individual nodes in the tree. The VC ID is the only way > by which you can address a node. I don't see how you can possible send > packets to more than one node if you keep sending packets to the same > address. Where does the missing information magically come from?
