Re: [PATCH RFC v2 2/7] Documentation: iio: add Open Sensor Fusion protocol v0 reference

[Kim Jinseob]

Sorry, resending in plain text.

> Can we have some background information. Where does this OSF thing come from?
> Is it a general standard or something you are personally developing?
> Some links would definitely help.

Addressed in RFC v3.

I added a Background section and public project links. I also clarified that
OSF0 is not a general standard, but the current wire format used by the Open
Sensor Fusion project and by this RFC driver.

The public links are now included in the documentation and cover letter:

https://www.opensensorfusion.org/
https://github.com/opensensorfusion
https://github.com/opensensorfusion/opensensorfusion-hardware
https://github.com/opensensorfusion/opensensorfusion-linux

> s32 given this is kernel code and i'm not sure what else this is referring to.

Addressed in RFC v3. I changed the kernel-facing wording to use s32.

> Not sure that is meaninful given expectation that there will be channels.
> I'd describe it as a payload header, or express this as 16 + 4 * channel_count

Addressed in RFC v3. The SENSOR_SAMPLE payload is now described as a 16-byte
payload header followed by 4 * channel_count bytes of s32 channel data.

> Is this spec defined, or just what the driver supports?
> I think this doc needs to distinguish between those two cases
> more clearly.

Addressed in RFC v3 I separated the OSF0 wire format description from the
subset currently supported by this RFC driver.


> Is there likely to be a non trivial delay?  If so we should figure out how to use
> that timestamp to get something more useful.

Addressed in RFC v3. I clarified that timestamp_us is a device-side timestamp
and that the current RFC driver does not claim production-grade host/device
timestamp correlation.

> What is AHRS?  I'd spell it out.

Addressed in RFC v3 as Attitude and Heading Reference System (AHRS).

Thanks

Jinseob