[meta-xilinx] Zynq TTC usage by Linux

Mike Looijmans mike.looijmans at topic.nl
Sat Oct 22 03:06:58 PDT 2016


One of the TTCs used to be used for clock source. This should still be 
the case if you use dynamic clocks, because the ARM timer is fixed to 
the CPU speed and does not handle frequency changes (though I think it 
should be possible to fix this purely in software, no-one seems to care 
though). The TTC can use the prescaler to adjust the timing when the CPU 
speed changes. But if you use AMP, frequency scaling will affect both 
cores, so you probably cannot use it anyway.

For AMP, I assigned the TTC1 interrupts to the remoteproc. I also add 
GPIO "hogs" for all GPIO signals it uses. That way, the AMP firmware 
doesn't need to modify various race-condition prone registers.

On 21-10-16 06:19, Edward Wingate wrote:
> It looks like Linux is aware of TTC0 at least, from dmesg:
> clocksource: ttc_clocksource: mask: 0xffff max_cycles: 0xffff,
> max_idle_ns: 537538477 ns
> ps7-ttc #0 at 9e808000, irq=18
>
> And it is allocated with virtual memory mapping (/proc/vmallocinfo):
> 0x9e808000-0x9e80a000    8192 of_iomap+0x2c/0x34 phys=f8001000 ioremap
>
> I can disable it in my device tree with:
> ps7_ttc_0: ps7-ttc at f8001000 { compatible = "invalid"; }
>
> Does anyone know what TTC0 would be used for?  Doesn't seem to be
> critical as Linux stills boots and runs OK.  Thanks for your help.
>
>
>
>
> On Thu, Oct 20, 2016 at 5:31 PM, Edward Wingate <edwingate8 at gmail.com> wrote:
>> Does Linux use the Zynq's triple timer counters (TTC0/1) for anything
>> by default?  Running in AMP mode with Linux on CPU0, I'm trying to use
>> TTC0/TTC1 from CPU1, but don't seem to be able to. I don't see the
>> TTCs' address space in /proc/iomem though.  Thanks for any help.
>>
>> Ed


-- 
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail








More information about the meta-xilinx mailing list