On 02/13/2013 09:42 PM, Stephen Warren wrote:
On 02/12/2013 03:39 PM, Sylwester Nawrocki wrote:
[...]
The whole subsystem topology is exposed to user space through the Media
Controller API.
OK, stable user-visible names are a reasonable use for device tree. I
still don't think you should use those user-visible IDs for making any
other kind of decision though.
OK, I will update the bindings so all variant details are placed in the
device tree. Then the routing information would mostly be coming from the
device specific dt properties/the common media bindings and the state of
links between the media entities, set by the user.
It's a bit simpler than that. We would need only to look for the reg
property in a local port subnode. MIPI-CSIS correspond to physical MIPI
CSI-2 bus interface of an SoC, hence it has to have specific reg values
that identify each camera input interface.
Oh I see. I guess if a device is using its own node to determine its own
identify, that's reasonable.
OK, I'm going to post an updated patch series in a week or two.
I thought you were talking about a situation like:
FIMC <--> XXX
where FIMC wanted to determine what ID XXX knew that particular FIMC as.
Ah, no. Sorry for the poor explanation. FIMC are on a sort if interconnect
bus and they can be attached to a single data source, even in parallel,
and the data source entity don't even need to be fully aware of it.
I can see aliases used in bindings of multiple devices: uart, spi, sound
interfaces, gpio, ... And all bindings seem to impose some rules on how
their aliases are created.
Do you have specific examples? I really don't think the bindings should
be dictating the alias values.
I just grepped through the existing bindings documentation:
...
I think "correctly numbered" in the above statements means there are some
specific rules on how the aliases are created, however those seem not
clearly communicated.
A binding specifying that an alias must (or even should) exist for each
node seems odd to me. In the absence of an explicit rule for how to
determine the alias IDs to use, I think the rule would simply be that
the aliases must be unique?
I guess so. Inspecting of_alias_get_id() call sites tells us that most
drivers
just fail when alias is not present and only rarely it is not treated as an
error condition.
And there is a new patch series that allows I2C bus controller enumeration
by means of the aliases:
http://www.spinics.net/lists/arm-kernel/msg224162.html
That's not enumerating controllers by alias (they're still enumerated by
scanning the DT nodes for buses in the normal way). The change simply
assigns the bus ID of each controller from an alias; exactly what
aliases are for.
OK, that clarifies a bit my understanding of the aliases.
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
