Hi Tomi,

On Tuesday 04 March 2014 14:21:09 Tomi Valkeinen wrote:

On 04/03/14 13:36, Philipp Zabel wrote:

quoted

Am Dienstag, den 04.03.2014, 10:58 +0200 schrieb Tomi Valkeinen:
[...]

[snip]

quoted

quoted

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