drivers:timer:cdns zcu102 timer driver using cadence TTC device #407
Conversation
9275852 to
24bf7c4
Compare
|
I'll wait until we're both in the lab together to review this. It will be much easier/quicker to do it in person. |
| * the LSBUS clock in the Low Power Domain, (controlled by LPD_LSBUS_CTRL). | ||
| */ | ||
| /* TODO: | ||
| * More graceful error when user requests timeout greater than served by ZCU102_TIMER_MAX_TICKS (at 25MHz (downscaled), 32-bit counter thats ~2min 51.799s) |
There was a problem hiding this comment.
Shouldn't the driver just handle this kind of timeout by waiting for multiple hardware-level timeouts? I thought that's how the other drivers worked.
There was a problem hiding this comment.
I was looking for how to handle this, and went for the most simple solution based on how jh7110 driver handles this case: https://github.com/au-ts/sddf/blob/main/drivers/timer/jh7110/timer.c#L132
I can rewrite it to handle longer timeouts as you've suggested for both the drivers, just some more logic will be needed.
There was a problem hiding this comment.
Okay I guess I was lazy with that timer driver.
There was a problem hiding this comment.
I'll add a fix for that in both then, shouldn't be too difficult.
build.zig zcu102 Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
* debugging undelivered IRQ on race condition * update client to spam timeouts (1us) * update print messages Example race cond with no IRQ: CLIENT|INFO: Now the time (in nanoseconds) is: 212911778590 i: 21000000 RACE CONDITION: get_ticks_in_ns incrementing counter_timer_elapses boop CLIENT|INFO: Now the time (in nanoseconds) is: 223063550190 i: 22000000 Example race cond with IRQ: CLIENT|INFO: Now the time (in nanoseconds) is: 294058739400 i: 29000000 RACE CONDITION: get_ticks_in_ns incrementing counter_timer_elapses boop RACE CONDITION: counter_timer_elapses alread yincremented! CLIENT|INFO: Now the time (in nanoseconds) is: 304214590370 i: 30000000 Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
* As no clock driver implemented yet, assumes the clock frequencies are untouched and left as default by u-boot (100MHz for LSBUS clock) * Ensures prescaler is always clamped to 0xf Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
Signed-off-by: Szymon Duchniewicz <s.duchniewicz@unsw.edu.au>
Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
Adds the cadence Triple Timer Counter (TTC) based timer driver.
Caveats:
Draft because of the following:
ZCU102_defines to begin withZYNQMP_(SoC specific rather than dev board specific)need to ensure Clock used for the counter is always set to 100MHz/use a different oneclean up serial driver skeleton code