[PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices
sylvester.nawrocki at gmail.com
Thu Feb 14 18:03:42 EST 2013
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
just fail when alias is not present and only rarely it is not treated as an
>> And there is a new patch series that allows I2C bus controller enumeration
>> by means of the aliases:
> 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.
More information about the linux-arm-kernel