Add i2c dump filtering

[barnas-michal]

This PR changes format of the i2c messages dump, to align the messages for easier comparison, and in case of device emulators, it's using the target device name instead of generic "emul".
It also adds a possibility to filter which devices transactions should be dumped. If someone is debugging the i2c communication, the log being flooded with other devices' transactions make it hard to debug. The logged devices
should be specified in the device-tree using the compatible string.

Example of device-tree node:
i2c-dump-filter {
compatible = "zephyr,i2c-dump-filter";
devices = < &display0 >, < &sensor3 >;
};

[galak]

I'm not fan of this as a devicetree node. Maybe a property under a controller or something.

[barnas-michal]

I'm not fan of this as a devicetree node. Maybe a property under a controller or something.

I am not sure if I would be able to easily iterate over all devices with some property set. It would also require to add the optional property to all possible i2c devices.
I know that this node doesn't represent any physical device, but I think it is the easiest and most readable approach to this functionality.

[tmon-nordic]

I know that this node doesn't represent any physical device, but I think it is the easiest and most readable approach to this functionality.

I agree that this is the easiest approach. However, there is constantly a disagreement (not only in Zephyr, but also in Linux kernel) what constitutes a devicetree and what does not. Linux kernel tends to be stricter about not using devicetree for configuration purposes.

Unfortunately I cannot find my older comments about the same issue, but this is perfect example of a place where some "devicetree-like-configuration" would make sense. Maybe we should group such use cases into some issue?

[teburd]

I like the way this works.

I was under the impression that zephyr compatibles were understood to be zephyr/virtual-ish like devices and configuration.

I don't see how this would easily be done in Kconfig. It wants structured data as configuration and DT is the tool Zephyr has for that.

[aaronemassey]

@semihalf-barnas-michal

I know that this node doesn't represent any physical device, but I think it is the easiest and most readable approach to this functionality.

@tmon-nordic

I agree that this is the easiest approach.

In my opinion, this is really similar to the first acknowledged type of exception scenario listed in Zephyr's docs comparing DeviceTree with KConfig. So it's acceptable to me as devicetree mechanism.

[keith-zephyr]

Non-blocking nits from me.

[keith-zephyr]

I'm not fan of this as a devicetree node. Maybe a property under a controller or something.

I am not sure if I would be able to easily iterate over all devices with some property set. It would also require to add the optional property to all possible i2c devices. I know that this node doesn't represent any physical device, but I think it is the easiest and most readable approach to this functionality.

The GPIO hogs driver provides an example for iterating over all devicetree nodes that have the gpio-controller property. Something similar could be done here by adding properties to the i2c-controller.yaml base class. But considering this is a debug feature I like the single devicetree node that collects up the list of I2C devices to log.

[teburd]

@semihalf-barnas-michal Perhaps it would be beneficial to document this debug feature in the i2c bus docs somewhere, as an opt in feature to dump messages, or dump messages with filtering abilities using a dts node.

At the moment someone would need to read the source code to understand how to use this feature.

[barnas-michal]

in the i2c bus docs somewhere

I've extracted some of the debugging documentation to another file and added the documentation about this feature there. If you do not like it, I can revert and just add the documentation to the i2c doc file.
I see that there is another file, services/debug which may be in a conflict to my extraction... However I am not sure if the I2C documentation is suitable for this, since it is very long and mostly describing the I2C interface and API...

[teburd]

in the i2c bus docs somewhere

I've extracted some of the debugging documentation to another file and added the documentation about this feature there. If you do not like it, I can revert and just add the documentation to the i2c doc file. I see that there is another file, services/debug which may be in a conflict to my extraction... However I am not sure if the I2C documentation is suitable for this, since it is very long and mostly describing the I2C interface and API...

Great thank you, I think as long as there's some documentation somewhere on it, it will be helpful. If it turns out to be in the wrong place that's easily fixed.

stale

[teburd]

Some of the single quoted additions to the docs don't make much sense to me at a quick glance