The Am3352 has 8 dm_timers. I want a counter function which can count pulse. Can the DM_timer use as a counter? Does the DM timer IP work well when TCLKIN hasnot signal?
When I select TCLKIN as the functional clock of dm timer and TCLKIN is no signal, then the Linux driver cannot access the dm timer.
Did you reconfigure the timer to posted mode (before switching the clock source to TCLKIN) as I mentioned in my previous mail? Although I didn't test very thoroughly, I did not notice any lockups when doing so.
Chris Pendleton said:Can you describe the requirement for the 2 pulses
It is known as synchronization delay, and a bit technical:
An input to a synchronous circuit (meaning one operating on a clock signal) needs to be valid 0 or valid 1 during some window of time during each clock cycle (indicated by the "setup time" and "hold time") to ensure it is sampled correctly. If the input is transitions during this window of time then the flip-flop starts having trouble deciding:
(click to zoom)
This image (from Metastability and Synchronizers — A Tutorial) shows how the output varies depending on the timing of a transition of the input signal (relative to the clock). You notice that the output may briefly hover near the center briefly before settling to 0 or 1. In fact if the input edge is sufficiently ill-timed, the flip-flop cannot decide and ends up in a metastable state, balancing on the edge until random influences finally push it over.
Metastability is generally highly undesirable in digital logic: functional behaviour of the rest of the circuit may become unpredictable, and power consumption increases greatly (in some cases leading to destruction). To deal with this, special synchronization circuits are needed.
A very common structure consists of two consecutive flip-flops: the first may go occasionally go metastable, but it is designed to ensure its output will settle in time for the second flip-flop to sample it safely. This is ultimately the origin of the "two pulses" requirement you mention.
Note that these things are all over the SoC, really lots of them (the cortex-A8 interrupt controller alone has 128 synchronizers: one for each irq input), but all clock signals are sufficiently fast that you'd never notice except by careful timing tests. However, if you select TCLKIN as the functional clock for a timer, but instead of a clock you send individual pulses, such delays can suddenly become highly visible.
Chris Pendleton said:I see the QEP counters (and GPIO control) lock up
I'm assuming you mean an attempt to access the QEP counter locks up, not the counter itself?
The explanation in this case is simple: all three modules are attached to the same L4 interconnect, which serializes all read/write requests. This means that as long as the timer module is stalling a write, later requests to any peripheral on the same interconnect will be stuck in some queue.
It is possible btw to configure timeouts in the L4 interconnect to prevent this sort of thing from locking up the whole system (although this leaves communication with that module in an undefined state). I can give more details if desired.
