On 26/01/15 17:25, Hartley Sweeten wrote:
On Monday, January 26, 2015 3:29 AM, Ian Abbott wrote:
On 23/01/15 23:12, H Hartley Sweeten wrote:
The analog input (*do_cmdtest) in this driver currently validates that the
scan_begin_src is TRIG_FOLLOW or, if the board can_burst, TRIG_TIMER or
TRIG_EXT.
The rest of the driver is coded to assume that the scan_begin_src is always
TRIG_FOLLOW.
I don't think that's correct. If the device allows bursting,
das16_cmd_ext() (*do_cmd()) has code to handle convert_src == TRIG_NOW,
which due to the validations in das16_cmd_test() (*do_cmdtest()) (step
2b) implies that scan_begin_src != TRIG_FOLLOW.
Ah.. I overlooked that. Step 2b isn't very clear. Step 4 doesn't help clarify
it,
especially since the divisors are calculated again in the (*do_cmd). It's also
not nice that the (*do_cmd) possibly modifies cmd->convert_arg.
I'll take another look at it...
It's not that clear, but basically it supports either scans running
continually (scan_begin_src == TRIG_FOLLOW) with samples triggered
individually (convert_src == TRIG_TIMER or TRIG_EXT), or scans triggered
individually (scan_begin_src == TRIG_TIMER or TRIG_EXT) with samples
triggered altogether in a burst (convert_src == TRIG_NOW). Not all the
supported boards support bursting.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbo...@mev.co.uk> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
