Re: [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries

[Rodrigo Alencar]

On 26/05/17 07:37PM, Rodrigo Alencar via B4 Relay wrote:
> From: Rodrigo Alencar <rodrigo.alencar@xxxxxxxxxx>
> 
> Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
> control Parallel Port, Digital Ramp Generator and OSK parameters.

...

> +What:		/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_offset
> +KernelVersion:
> +Contact:	linux-iio@xxxxxxxxxxxxxxx
> +Description:
> +		For a channel that allows frequency control through buffers, this
> +		represents the base frequency value in Hz. The actual output frequency
> +		is derived from this offset combined with the processed buffer sample
> +		value.
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_scale
> +KernelVersion:
> +Contact:	linux-iio@xxxxxxxxxxxxxxx
> +Description:
> +		For a channel that allows frequency control through buffers, this
> +		represents the frequency modulation gain. This value multiplies the
> +		buffer input sample value before it is added to a frequency offset.
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase_offset
> +KernelVersion:
> +Contact:	linux-iio@xxxxxxxxxxxxxxx
> +Description:
> +		For a channel that allows phase control through buffers, this
> +		represents the base phase value in radians. The actual output phase	is
> +		derived from this offset combined with the processed buffer sample
> +		value.
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_offset
> +KernelVersion:
> +Contact:	linux-iio@xxxxxxxxxxxxxxx
> +Description:
> +		For a channel that allows amplitude control through buffers, this
> +		represents the value for a base amplitude scale. The actual output
> +		amplitude scale is derived from this offset combined with the processed
> +		buffer sample value.
> +

This will become just offset with altcurrent channels. I noticed we have a IIO_PHASE
iio_chan_type, could we have a IIO_FREQUENCY too? Parallel port needs actual raw
frequency values in that case to be written to the dma buffer.

Then we may have buffer capable channels for the parallel port:

out_altcurrent120
	offset
out_phase120
	offset
out_frequency120
	scale
	offset

Problem is that the math for the actual frequency output is:

	f_OUT = f_FTW + (f_RAW * FM)

where f_FTW is a base frequency (already scaled), FM is a
modulation gain and f_RAW is the contribution from the parallel
port, which is the already scaled:

	f_RAW = RAW * f_SYSCLK / 2^32
	f_FTW = FTW * f_SYSCLK / 2^32

so the above becomes:

	f_OUT = (FTW * f_SYSCLK / 2^32) + (RAW * f_SYSCLK / 2^32) * FM
	f_OUT = (FTW/FM + RAW) * f_SYSCLK * FM / 2^32

if I make:

	SCALE = f_SYSCLK * FM / 2^32
	OFFSET = FTW/FM
	f_OUT = (OFFSET + RAW) * SCALE

That would work for a IIO_FREQUENCY channel type, problem is that both
scale and offset would depend on the modulation gain (FM)... I suppose
scale should be setting that and offset assumes it is constant to act
only on FTW.

I suppose we can keep altcurrent for other modes as phase and frequency
can be attributes (knobs) for them. However, in parallel mode we are effectively
pushing frequency, phase or amplitude values into the buffer.

The polar destination is a corner case, but can be solved when both
phase and altcurrent channels are enabled. When that happens we can
change the scan_type with has_ext_scan_type = 1, so the 16-bit data
bus is split between the two.

With the above, all of those *_offset and *_scale custom ABI can be dropped. 

-- 
Kind regards,

Rodrigo Alencar