On Wed, Jun 27, 2012 at 11:49:43AM -0600, Stephen Warren wrote: > On 06/26/2012 11:07 PM, Thierry Reding wrote: > > On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote: > ... > > I actually like what you proposed above a lot, so if you don't > > mind either way I'll go with that proposal. Keeping the connector > > nodes as children of the outputs has the advantage of being able to > > reference them if we need it at some point. But it is also > > redundant in that a single output doesn't usually (never?) driver > > more than one connector. > > Yes, I believe that each output is 1:1 with (the video portion of) a > connector. The display controllers obviously aren't 1:1. Yes, the display controllers are only 1:1 for the RGB outputs. I'll merge your proposed changes and see if I can come up with some code to parse it. > > The same issue will have to be addressed for the CSI and VI nodes, > > but as I currently use neither of those I don't feel qualified to > > propose a binding for them. Also for the VI part we're completely > > missing documentation. Maybe somebody could push this to be > > released as well? > > I did file a bug noting the request for VI documentation. At this > point in time, it's too early to say what, if anything, will come of that. I think we have some raw register documentation for VI but it's next to impossible to really understand the hardware block just by looking at the registers. > > If I understand correctly, most of the host1x children can also be > > chained in a processing pipeline to do postprocessing an video > > input for example. I suppose that's generic and doesn't need to be > > represented in DT either, right? > > Yes, I believe that's something internal to the driver. Okay. So I think apart from the carveout topic in the other subthread I think we've settled on solutions for the remaining points. I'll try to find some time to work all the changes into a new binding proposal and get working on the code. Thierry
Attachment:
pgpqLGwZz9HDz.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
