On Wed, 2013-09-11 at 22:14 +0100, Sylwester Nawrocki wrote: > Yes, I wasn't aware then that your "video RAM" is a separate chip attached > to a distinct bus. > My idea was to reuse memory node structure, including "reserved-memory" > compatible value (note there are some fixups pending and those names are > subject to change). Not sure about the property in CLCD device node > containing phandle to the memory node (currently 'memory-region'). As I just told Steven, I'll just make it painfully low-level property defining "address you have to generate to access base of the framebuffer". Of course one can still go the CMA way, if such need arises. > > Ok, I see what you're saying. Yes, this could be done. No, I don't claim > > to have enough expertise either (micrometers??? :-O ;-) The other thing > > is that I don't really expect generic CDF bindings to cover such things. > > They will (hopefully) only describe what's connected with what. And the > > drivers should know how. Of course they may need the dimensions& alike > > in the tree (of course having them standardised would help here), but > > it's not a CDF job to provide those. > > Of course it's always easier to define couple of DT properties that would > cover part of functionality of some specific device. But then such > properties should be prefixed with vendor name AFAIU, since they are > not approved as common ones and useful for wider set of devices. This is a policy that changed many times already... Anyway, I think I've got an idea how to render the problem custom panel properties invalid. If so, I'll send another version of the patch. > From the device tree perspective CDF is just a collection of (display > related) devices and a complete set of DT properties will be needed to > describe them. Certainly some share of device-specific properties should > be expected. Links between (sub)devices can be already described in DT by > the binding documented in video-interfaces.txt. Whether to use the v4l scheme or not still seems to be a bone of contention between the video and the DRM/KMS folk, so I wouldn't draw any conclusions yet. Paweł -- 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
