On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:
> Hi Stephen
> 
> On Wed, 12 Sep 2012, Stephen Warren wrote:
> 
>> On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
>>> This patch adds a document, describing common V4L2 device tree bindings.
>>>
>>> Co-authored-by: Sylwester Nawrocki <s.nawro...@samsung.com>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovet...@gmx.de>
>>
>> Overall, I think this looks pretty reasonable, so:
...
>>
>>> +                   clock-frequency = <50000000>;   /* max clock frequency 
>>> */
>>> +                   clock-output-names = "mclk";
>>> +           };
>>> +
>>> +           port {
>> ...
>>> +                   ceu0_0: link@0 {
>>> +                           reg = <0>;
>>> +                           remote = <&csi2_2>;
>>> +                           immutable;
>>
>> Did we decide "immutable" was actually needed? Presumably the driver for
>> the HW in question knows the HW isn't configurable, and would simply not
>> attempt to apply any configuration even if the .dts author erroneously
>> provided some?
> 
> Well, I've been thinking about this today. I think, bridge drivers will 

Sorry, I'm not sure what a "bridge" driver is; is it any v4l2 device?

> call centrally provided helper functions to enumerate links inside ports. 

Presumably a given driver would only parse the ports/links of its own DT
node, and hence would be able to provide a parameter to any helper
function that indicated the same information that "immutable" would?

> While doing that they will want to differentiate between links to external 
> devices with explicit configuration, and links to internal devices, whose 
> configuration drivers might be able to figure out themselves. How should a 
> driver find out what device this link is pointing to? Should it follow the 
> "remote" phandle and then check the "compatible" property? The word 
> "immutable" is a hint, that this is a link to an internal device, but it 
> might either be unneeded or be transformed into something more 
> informative.

I would imagine that a given driver would only ever parse its own DT
node; the far end of any link is purely the domain of the other driver.
I thought that each link node would contain whatever hsync-active,
data-lanes, ... properties that were needed to configure the local device?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to