linux-kernel - Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <531BA6D3.4030004@gmail.com>
Date:	Sun, 09 Mar 2014 00:25:07 +0100
From:	Sylwester Nawrocki <sylvester.nawrocki@...il.com>
To:	Grant Likely <grant.likely@...aro.org>,
	Tomi Valkeinen <tomi.valkeinen@...com>
CC:	Philipp Zabel <p.zabel@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Rob Herring <robherring2@...il.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Philipp Zabel <philipp.zabel@...il.com>
Subject: Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core
 to drivers/of

On 03/08/2014 12:41 PM, Grant Likely wrote:
>>> Another thought. In terms of the pattern, I would add a recommendation
>>> >  >  that there should be a way to identify ports of a particular type. ie.
>>> >  >  If I were using the pattern to implement an patch bay of DSP filters,
>>> >  >  where each input and output, then each target node should have a unique
>>> >  >  identifier property analogous to "interrupt-controller" or
>>> >  >  "gpio-controller". In this fictitious example I would probably choose
>>> >  >  "audiostream-input-port" and "audiostream-output-port" as empty
>>> >  >  properties in the port nodes. (I'm not suggesting a change to the
>>> >  >  existing binding, but making a recommendation to new users).
>> >
>> >  I don't see any harm in that, but I don't right away see what could be
>> >  done with them? Did you have something in mind?
>
> It would help with schema validation and allow ports of the same
> interface to get grouped together.
>
>> >  I guess those could be used to study the graph before the drivers have
>> >  been loaded. After the drivers have been loaded, the drivers should
>> >  somehow register themselves and the ports/endpoints. And as the driver
>> >  knows what kind of ports they are, it can supply this information in the
>> >  runtime data structures.
>> >
>> >  If we do that, would it be better to have two pieces of data:
>> >  input/output/bi-directional, and the port type (say, mipi-dpi, lvds, etc.)?

I'm not sure about the direction information (it also came up when we
originally discussed this binding), but the port type information would
be useful. As it turns out, it is not always possible to describe a data
bus interface type/data transmission protocol with a set of primitive
properties in an endpoint node. Especially in cases when the physical
layer is basically identical, for instance in case of MIPI CSI-2 and
SMIA CCP2, or in future MIPI CSI-3 and MIPI CSI-2.

In general there could likely be more than one supported, if both the
transmitter and the receiver are sufficiently configurable.

Then, to be able to fully describe a data port, perhaps we could
add a property like 'interface-type' or 'bus-type' with values like
"mipi-dbi", mipi-dsi", "mipi-csi2", "smia-ccp2", "hdmi", etc.

> Sure. That's worth considering.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/