Hi Tomi, On Tuesday 04 March 2014 14:21:09 Tomi Valkeinen wrote: > On 04/03/14 13:36, Philipp Zabel wrote: > > Am Dienstag, den 04.03.2014, 10:58 +0200 schrieb Tomi Valkeinen: > > [...] [snip] > >> Then, about the get_remote functions: I think there should be only one > >> function for that purpose, one that returns the device node that > >> contains the remote endpoint. > >> > >> My reasoning is that the ports and endpoints, and their contents, should > >> be private to the device. So the only use to get the remote is to get > >> the actual device, to see if it's been probed, or maybe get some video > >> API for that device. > > > > of_graph_get_remote_port currently is used in the exynos4-is/fimc-is.c > > v4l2 driver to get the mipi-csi channel id from the remote port, and > > I've started using it in imx-drm-core.c for two cases: > > - given an endpoint on the encoder, find the remote port connected to > > it, get the associated drm_crtc, to obtain its the drm_crtc_mask > > for encoder->possible_crtcs. > > > > - given an encoder and a connected drm_crtc, walk all endpoints to find > > the remote port associated with the drm_crtc, and then use the local > > endpoint parent port to determine multiplexer settings. > > Ok. > > In omapdss each driver handles only the ports and endpoints defined for > its device, and they can be considered private to that device. The only > reason to look for the remote endpoint is to find the remote device. To > me the omapdss model makes sense, and feels logical and sane =). So I > have to say I'm not really familiar with the model you're using. I agree with you that most of the content of the remote endpoint should be considered private to the remote device and not accessed by the local device driver. There is, however, one piece of information from the remote endpoint useful to the local device driver, it's the remote port identifier. This can be expressed by a phandle, a remote port number, a media entity pad pointer, or any other mean, but the information is useful for the local device driver to communicate with the remote device driver. For instance a driver could use it to ask its video stream source to start the video stream on a given port. > Of course, the different get_remove_* funcs do no harm, even if we have > a bunch of them. My point was only about enforcing the correct use of > the model, where "correct" is of course subjective =). -- Regards, Laurent Pinchart
Attachment:
signature.asc
Description: This is a digitally signed message part.
