Re: I2C and devicetrees

Re: I2C and devicetrees

[Olof Johansson]

[+devicetree-discuss]

On Wed, Dec 5, 2012 at 2:36 PM, Peter Huewe <PeterHuewe-Mmb7MZpHnFY@public.gmane.org> wrote:
> Hi,
>
> I have a short question about the relations between i2c and devicetrees.
>
> I was wondering
> is the device part of the compatible string of a (trivial) i2c device
> instanciated via devicetree _always_ identical to name in i2c_client.name ?
> Or can it be somehow different?

It can be different, but the driver will then need to add a OF table
that matches the probing. By default the i2c/dt core code will strip
off the vendor prefix (before ",") and try probing with the rest of
the device name. If that doesn't match the client name, that is when
you need the additional table.


> Here's a short example:
> device tree:
> test {
>         compatible = "vendor,device1", "vendor,device2";
>         reg = <0x20>;
> }
>
> The driver has in its id table only this entry:
> static const struct i2c_device_id my_i2c_table[] = {
>         {"device2", 0},
>         {},
> };
>
> -> "vendor,device2" matches and the driver is called.
> --> Is i2c_client.name guaranteed to be "device2" ?
>
> Second question:
> Where would you probably add an i2c tpm?
> Would you add it to
>  Documentation/devicetree/bindings/i2c/trivial-devices.txt
> or if it's not trivial add it to a new file under
>  Documentation/devicetree/bindings/i2c/

A trivial device is a device that takes at most an address (or address
range) and an interrupt.

If it has a more elaborate binding than that, then a separate small
binding doc is needed.

> or create a new folder
>  Documentation/devicetree/bindings/tpm
> as there probably are more i2c tpms to come in the near future.

I'd leave it under i2c for now, we tend to group per bus, not per function.

> I'd probably prefer the first one, whereas Google already uses the second
> option:
> http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=history;f=Documentation/devicetree/bindings/tpm;hb=refs/heads/chromeos-3.4

The location of the file doesn't matter and it can easily be moved. I
was more concerned with getting the document written and included than
stored in the perfect location at the time.



-Olof

Re: I2C and devicetrees

[Stephen Warren]

On 12/11/2012 01:21 PM, Olof Johansson wrote:
> [+devicetree-discuss]
> 
> On Wed, Dec 5, 2012 at 2:36 PM, Peter Huewe <PeterHuewe-Mmb7MZpHnFY@public.gmane.org> wrote:
>> Hi,
>>
>> I have a short question about the relations between i2c and devicetrees.
>>
>> I was wondering
>> is the device part of the compatible string of a (trivial) i2c device
>> instanciated via devicetree _always_ identical to name in i2c_client.name ?
>> Or can it be somehow different?
> 
> It can be different, but the driver will then need to add a OF table
> that matches the probing. By default the i2c/dt core code will strip
> off the vendor prefix (before ",") and try probing with the rest of
> the device name. If that doesn't match the client name, that is when
> you need the additional table.

While relying on the prefix stripping works, I think I recall Grant
mentioning that people shouldn't rely on it - namely that any I2C device
that gets instantiated from DT should contain the OF match table
explicitly. I CC'd Grant in case I'm mis-quoting him.

Re: I2C and devicetrees

[Grant Likely]

On Tue, 11 Dec 2012 13:56:08 -0700, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> On 12/11/2012 01:21 PM, Olof Johansson wrote:
> > [+devicetree-discuss]
> > 
> > On Wed, Dec 5, 2012 at 2:36 PM, Peter Huewe <PeterHuewe-Mmb7MZpHnFY@public.gmane.org> wrote:
> >> Hi,
> >>
> >> I have a short question about the relations between i2c and devicetrees.
> >>
> >> I was wondering
> >> is the device part of the compatible string of a (trivial) i2c device
> >> instanciated via devicetree _always_ identical to name in i2c_client.name ?
> >> Or can it be somehow different?
> > 
> > It can be different, but the driver will then need to add a OF table
> > that matches the probing. By default the i2c/dt core code will strip
> > off the vendor prefix (before ",") and try probing with the rest of
> > the device name. If that doesn't match the client name, that is when
> > you need the additional table.
> 
> While relying on the prefix stripping works, I think I recall Grant
> mentioning that people shouldn't rely on it - namely that any I2C device
> that gets instantiated from DT should contain the OF match table
> explicitly. I CC'd Grant in case I'm mis-quoting him.

I'm not quite that strict about it. The behaviour described above is
based merely on a heuristic but for a lot of drivers that don't do
anything special it works just fine. The moment you need to identify a
specific device it becomes better to use an of match table.

g.

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.

Re: I2C and devicetrees

[Gerlando Falauto]

Hi everyone,

I have a similar question.
I'd like to "name" i2c devices so that a userspace application can 
somehow identify those devices with the same function across different 
boards (which may have different addresses or be connected to a 
different i2c bus, or be a physically different chip).

For instance "hwmon" devices get instantiated within sysfs under
/sys/class/hwmon/hwmonX

# cat /sys/class/hwmon/hwmon0/device/name
lm75

which I would like to be identified by the name "switch" (as in "switch 
temperature"). I was thinking about instantiating it as something like 
"lm75:switch" within i2c_board_info.type. For device-tree-less 
architectures, a trivial change within i2c_match_id() so to ignore the 
part following ":" seems to do the trick. Don't know about devicetree 
but I guess a similar approach could be imagined.

Another example would be given by EEPROMs: all boards are equipped with 
an EEPROM containing inventory management, which I would like to 
identify as "ivm". So something like "24c08:ivm".
After all, I'd like to be able to achive something like "named MTD 
partitions" which you can identify by looking at "/proc/mtd".

Maybe some other symbol could be used instead of ":", but anyhow, does 
the above make any sense at all to you?

Thanks a lot!
Gerlando

On 12/14/2012 09:38 PM, Grant Likely wrote:
> On Tue, 11 Dec 2012 13:56:08 -0700, Stephen Warren<swarren-3lzwWm7+Weoh9ZMKESR00Q-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>  wrote:
>> On 12/11/2012 01:21 PM, Olof Johansson wrote:
>>> [+devicetree-discuss]
>>>
>>> On Wed, Dec 5, 2012 at 2:36 PM, Peter Huewe<PeterHuewe-Mmb7MZpHnFY-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>  wrote:
>>>> Hi,
>>>>
>>>> I have a short question about the relations between i2c and devicetrees.
>>>>
>>>> I was wondering
>>>> is the device part of the compatible string of a (trivial) i2c device
>>>> instanciated via devicetree _always_ identical to name in i2c_client.name ?
>>>> Or can it be somehow different?
>>>
>>> It can be different, but the driver will then need to add a OF table
>>> that matches the probing. By default the i2c/dt core code will strip
>>> off the vendor prefix (before ",") and try probing with the rest of
>>> the device name. If that doesn't match the client name, that is when
>>> you need the additional table.
>>
>> While relying on the prefix stripping works, I think I recall Grant
>> mentioning that people shouldn't rely on it - namely that any I2C device
>> that gets instantiated from DT should contain the OF match table
>> explicitly. I CC'd Grant in case I'm mis-quoting him.
>
> I'm not quite that strict about it. The behaviour described above is
> based merely on a heuristic but for a lot of drivers that don't do
> anything special it works just fine. The moment you need to identify a
> specific device it becomes better to use an of match table.
>
> g.
>

Re: I2C and devicetrees

[Thomas De Schampheleire]

Hi,

On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
<gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org> wrote:
> Hi everyone,
>
> I have a similar question.
> I'd like to "name" i2c devices so that a userspace application can somehow
> identify those devices with the same function across different boards (which
> may have different addresses or be connected to a different i2c bus, or be a
> physically different chip).
>
> For instance "hwmon" devices get instantiated within sysfs under
> /sys/class/hwmon/hwmonX
>
> # cat /sys/class/hwmon/hwmon0/device/name
> lm75
>
> which I would like to be identified by the name "switch" (as in "switch
> temperature"). I was thinking about instantiating it as something like
> "lm75:switch" within i2c_board_info.type. For device-tree-less
> architectures, a trivial change within i2c_match_id() so to ignore the part
> following ":" seems to do the trick. Don't know about devicetree but I guess
> a similar approach could be imagined.
>
> Another example would be given by EEPROMs: all boards are equipped with an
> EEPROM containing inventory management, which I would like to identify as
> "ivm". So something like "24c08:ivm".
> After all, I'd like to be able to achive something like "named MTD
> partitions" which you can identify by looking at "/proc/mtd".
>
> Maybe some other symbol could be used instead of ":", but anyhow, does the
> above make any sense at all to you?

I have exactly the same request: I would like to put logical names in
the device tree for various devices (i2c, spi, ...) which are in some
way easily retrievable from a userspace application.
The purpose seems to be the same as Gerlando's: different boards have
different physical configuration but logically each has the same set
of devices.

How can we achieve that?

Thanks,
Thomas

Re: I2C and devicetrees

[Thomas De Schampheleire]

Hi,

On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
<gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org> wrote:
> Hi everyone,
>
> I have a similar question.
> I'd like to "name" i2c devices so that a userspace application can somehow
> identify those devices with the same function across different boards (which
> may have different addresses or be connected to a different i2c bus, or be a
> physically different chip).
>
> For instance "hwmon" devices get instantiated within sysfs under
> /sys/class/hwmon/hwmonX
>
> # cat /sys/class/hwmon/hwmon0/device/name
> lm75
>
> which I would like to be identified by the name "switch" (as in "switch
> temperature"). I was thinking about instantiating it as something like
> "lm75:switch" within i2c_board_info.type. For device-tree-less
> architectures, a trivial change within i2c_match_id() so to ignore the part
> following ":" seems to do the trick. Don't know about devicetree but I guess
> a similar approach could be imagined.
>
> Another example would be given by EEPROMs: all boards are equipped with an
> EEPROM containing inventory management, which I would like to identify as
> "ivm". So something like "24c08:ivm".
> After all, I'd like to be able to achive something like "named MTD
> partitions" which you can identify by looking at "/proc/mtd".
>
> Maybe some other symbol could be used instead of ":", but anyhow, does the
> above make any sense at all to you?
>

I have exactly the same request: I would like to put logical names in
the device tree for various devices (i2c, spi, ...) which are in some
way easily retrievable from a userspace application.
The purpose seems to be the same as Gerlando's: different boards have
different physical configuration but logically each has the same set
of devices.

How can one achieve that?

Thanks,
Thomas

Re: I2C and devicetrees

[Mitch Bradley]

On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:
> Hi,
> 
> On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
> <gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org> wrote:
>> Hi everyone,
>>
>> I have a similar question.
>> I'd like to "name" i2c devices so that a userspace application can somehow
>> identify those devices with the same function across different boards (which
>> may have different addresses or be connected to a different i2c bus, or be a
>> physically different chip).
>>
>> For instance "hwmon" devices get instantiated within sysfs under
>> /sys/class/hwmon/hwmonX
>>
>> # cat /sys/class/hwmon/hwmon0/device/name
>> lm75
>>
>> which I would like to be identified by the name "switch" (as in "switch
>> temperature"). I was thinking about instantiating it as something like
>> "lm75:switch" within i2c_board_info.type. For device-tree-less
>> architectures, a trivial change within i2c_match_id() so to ignore the part
>> following ":" seems to do the trick. Don't know about devicetree but I guess
>> a similar approach could be imagined.
>>
>> Another example would be given by EEPROMs: all boards are equipped with an
>> EEPROM containing inventory management, which I would like to identify as
>> "ivm". So something like "24c08:ivm".
>> After all, I'd like to be able to achive something like "named MTD
>> partitions" which you can identify by looking at "/proc/mtd".
>>
>> Maybe some other symbol could be used instead of ":", but anyhow, does the
>> above make any sense at all to you?
>>
> 
> I have exactly the same request: I would like to put logical names in
> the device tree for various devices (i2c, spi, ...) which are in some
> way easily retrievable from a userspace application.
> The purpose seems to be the same as Gerlando's: different boards have
> different physical configuration but logically each has the same set
> of devices.
> 
> How can one achieve that?

Unless I am misunderstanding your request, that is what the /aliases
node is intended for.  Each property name in /aliases is a logical name,
and the value refers to the corresponding device node.

I'm not sure about all the different ways that Linux exports information
in /aliases to userspace.  I do know that, in the case of some i2c,
serial, and ethernet devices, aliases like:

  serial1 = &uart1;

cause the assignment of small-integer unit numbers to specific device
instances.  That "serial<N>" pattern is somewhat of a Linux-specific
special case.  In general, the Open Firmware standard just says that
/aliases maps logical names to longer strings  representing fuller
pathnames, without imposing any structure (e.g. serial<N>) on the
logical names.

> 
> Thanks,
> Thomas
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

Re: I2C and devicetrees

[Stephen Warren]

On 03/01/2013 02:47 PM, Mitch Bradley wrote:
> On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:
>> Hi,
>>
>> On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
>> <gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org> wrote:
>>> Hi everyone,
>>>
>>> I have a similar question.
>>> I'd like to "name" i2c devices so that a userspace application can somehow
>>> identify those devices with the same function across different boards (which
>>> may have different addresses or be connected to a different i2c bus, or be a
>>> physically different chip).
>>>
>>> For instance "hwmon" devices get instantiated within sysfs under
>>> /sys/class/hwmon/hwmonX
>>>
>>> # cat /sys/class/hwmon/hwmon0/device/name
>>> lm75
>>>
>>> which I would like to be identified by the name "switch" (as in "switch
>>> temperature"). I was thinking about instantiating it as something like
>>> "lm75:switch" within i2c_board_info.type. For device-tree-less
>>> architectures, a trivial change within i2c_match_id() so to ignore the part
>>> following ":" seems to do the trick. Don't know about devicetree but I guess
>>> a similar approach could be imagined.
>>>
>>> Another example would be given by EEPROMs: all boards are equipped with an
>>> EEPROM containing inventory management, which I would like to identify as
>>> "ivm". So something like "24c08:ivm".
>>> After all, I'd like to be able to achive something like "named MTD
>>> partitions" which you can identify by looking at "/proc/mtd".
>>>
>>> Maybe some other symbol could be used instead of ":", but anyhow, does the
>>> above make any sense at all to you?
>>>
>>
>> I have exactly the same request: I would like to put logical names in
>> the device tree for various devices (i2c, spi, ...) which are in some
>> way easily retrievable from a userspace application.
>> The purpose seems to be the same as Gerlando's: different boards have
>> different physical configuration but logically each has the same set
>> of devices.
>>
>> How can one achieve that?
> 
> Unless I am misunderstanding your request, that is what the /aliases
> node is intended for.  Each property name in /aliases is a logical name,
> and the value refers to the corresponding device node.
> 
> I'm not sure about all the different ways that Linux exports information
> in /aliases to userspace.  I do know that, in the case of some i2c,
> serial, and ethernet devices, aliases like:
> 
>   serial1 = &uart1;
> 
> cause the assignment of small-integer unit numbers to specific device
> instances.  That "serial<N>" pattern is somewhat of a Linux-specific
> special case.  In general, the Open Firmware standard just says that
> /aliases maps logical names to longer strings  representing fuller
> pathnames, without imposing any structure (e.g. serial<N>) on the
> logical names.

I'm not sure if aliases solve all scenarios.

If you have a DT node that's a single UART, then aliases work OK, as in
your example above.

However, what if you have a single thermal sensor ID that has 4
channels. There will be a single DT node that represents this device.
However, the 4 channels could be hooked up arbitrarily on a board, and
you really want to name the individual channels, not just the IC that
contains those channels. Can you do that; will the following work?

/aliases {
    cpu-temp = <&i2cdev 1>; # 1 is the channel ID on the chip
    ambient-temp = <&i2cdev 3>;
};

All the code I recall so far that handles aliases searches for alias
entries with a specific prefix for the name (e.g. "i2c*", and then finds
"i2c0", "i2c1", etc.). In order to support the syntax above, you'd have
to instead search for all aliases that include the phandle of the node
in question. I guess it's easy enough to implement that, but it's quite
a different way of thinking about aliases, I think.

Re: I2C and devicetrees

[Mitch Bradley]

On 3/1/2013 1:17 PM, Stephen Warren wrote:
> On 03/01/2013 02:47 PM, Mitch Bradley wrote:
>> On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:
>>> Hi,
>>>
>>> On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
>>> <gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org> wrote:
>>>> Hi everyone,
>>>>
>>>> I have a similar question.
>>>> I'd like to "name" i2c devices so that a userspace application can somehow
>>>> identify those devices with the same function across different boards (which
>>>> may have different addresses or be connected to a different i2c bus, or be a
>>>> physically different chip).
>>>>
>>>> For instance "hwmon" devices get instantiated within sysfs under
>>>> /sys/class/hwmon/hwmonX
>>>>
>>>> # cat /sys/class/hwmon/hwmon0/device/name
>>>> lm75
>>>>
>>>> which I would like to be identified by the name "switch" (as in "switch
>>>> temperature"). I was thinking about instantiating it as something like
>>>> "lm75:switch" within i2c_board_info.type. For device-tree-less
>>>> architectures, a trivial change within i2c_match_id() so to ignore the part
>>>> following ":" seems to do the trick. Don't know about devicetree but I guess
>>>> a similar approach could be imagined.
>>>>
>>>> Another example would be given by EEPROMs: all boards are equipped with an
>>>> EEPROM containing inventory management, which I would like to identify as
>>>> "ivm". So something like "24c08:ivm".
>>>> After all, I'd like to be able to achive something like "named MTD
>>>> partitions" which you can identify by looking at "/proc/mtd".
>>>>
>>>> Maybe some other symbol could be used instead of ":", but anyhow, does the
>>>> above make any sense at all to you?
>>>>
>>>
>>> I have exactly the same request: I would like to put logical names in
>>> the device tree for various devices (i2c, spi, ...) which are in some
>>> way easily retrievable from a userspace application.
>>> The purpose seems to be the same as Gerlando's: different boards have
>>> different physical configuration but logically each has the same set
>>> of devices.
>>>
>>> How can one achieve that?
>>
>> Unless I am misunderstanding your request, that is what the /aliases
>> node is intended for.  Each property name in /aliases is a logical name,
>> and the value refers to the corresponding device node.
>>
>> I'm not sure about all the different ways that Linux exports information
>> in /aliases to userspace.  I do know that, in the case of some i2c,
>> serial, and ethernet devices, aliases like:
>>
>>   serial1 = &uart1;
>>
>> cause the assignment of small-integer unit numbers to specific device
>> instances.  That "serial<N>" pattern is somewhat of a Linux-specific
>> special case.  In general, the Open Firmware standard just says that
>> /aliases maps logical names to longer strings  representing fuller
>> pathnames, without imposing any structure (e.g. serial<N>) on the
>> logical names.
> 
> I'm not sure if aliases solve all scenarios.
> 
> If you have a DT node that's a single UART, then aliases work OK, as in
> your example above.
> 
> However, what if you have a single thermal sensor ID that has 4
> channels. There will be a single DT node that represents this device.
> However, the 4 channels could be hooked up arbitrarily on a board, and
> you really want to name the individual channels, not just the IC that
> contains those channels. Can you do that; will the following work?
> 
> /aliases {
>     cpu-temp = <&i2cdev 1>; # 1 is the channel ID on the chip
>     ambient-temp = <&i2cdev 3>;
> };

For that case, I would put child nodes underneath the 4-channel-sensor
node, e.g. cpu-temp@1, ambient-temp@3.  Those multiple channels fit
cleanly within the device tree's "child address space" concept.

I suppose that the driver for the sensor node would enumerate its
children and export their information via /sys.

I know that it's tempting to truncate the device tree too soon, as I
have fallen prey to that temptation many times.  For me, the temptation
usually happens for "endpoints" that don't need separate drivers, or for
which the endpoint-driver code is "buried" inside the parent driver.
But in the end, it has usually worked out better to fill out the leaves
of the tree, especially for on-board devices.

> 
> All the code I recall so far that handles aliases searches for alias
> entries with a specific prefix for the name (e.g. "i2c*", and then finds
> "i2c0", "i2c1", etc.). In order to support the syntax above, you'd have
> to instead search for all aliases that include the phandle of the node
> in question. I guess it's easy enough to implement that, but it's quite
> a different way of thinking about aliases, I think.
>