On 25-10-16 18:30, Edward Wingate wrote:
On Tue, Oct 25, 2016 at 12:01 AM, Mike Looijmans
wrote:
Usually the term "real time" is applied to too many things. For example,
your desktop PC experiences latencies of over 1 ms for typical interrupts,
but it still functions fine when running various
On Tue, Oct 25, 2016 at 12:01 AM, Mike Looijmans
wrote:
> Usually the term "real time" is applied to too many things. For example,
> your desktop PC experiences latencies of over 1 ms for typical interrupts,
> but it still functions fine when running various audio and video
> applications that hav
On 25-10-16 08:39, Edward Wingate wrote:
On Mon, Oct 24, 2016 at 11:16 PM, Mike Looijmans
wrote:
On 25-10-16 08:03, Edward Wingate wrote:
Could you explain about how GPIO hogs eliminate dealing with
race-condition prone registers? Which registers are prone to race
conditions in the first pla
On Mon, Oct 24, 2016 at 11:16 PM, Mike Looijmans
wrote:
> On 25-10-16 08:03, Edward Wingate wrote:
>> Could you explain about how GPIO hogs eliminate dealing with
>> race-condition prone registers? Which registers are prone to race
>> conditions in the first place?
>
> For example, to enable the
On 25-10-16 08:03, Edward Wingate wrote:
On Sat, Oct 22, 2016 at 3:06 AM, Mike Looijmans wrote:
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 (thou
On Sat, Oct 22, 2016 at 3:06 AM, Mike Looijmans wrote:
> 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 f
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). T
HI Edward,
> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Edward Wingate
> Sent: Friday, October 21, 2016 12:42 PM
> To: Nathan Rossi
> Cc: meta-xilinx@yoctoproject.org
> Subject: Re: [
On Fri, Oct 21, 2016 at 12:26 AM, Nathan Rossi wrote:
> This is informing that the ttc device is probed and setup as a
> clocksource device. Althought it is probably not used.
> You can also check to see what is currently in use: cat
> /sys/devices/system/clocksource/clocksource0/current_clocksour
On Fri, Oct 21, 2016 at 2:19 PM, Edward Wingate wrote:
> It looks like Linux is aware of TTC0 at least, from dmesg:
> clocksource: ttc_clocksource: mask: 0x max_cycles: 0x,
> max_idle_ns: 537538477 ns
> ps7-ttc #0 at 9e808000, irq=18
>
> And it is allocated with virtual memory mapping (/pr
It looks like Linux is aware of TTC0 at least, from dmesg:
clocksource: ttc_clocksource: mask: 0x max_cycles: 0x,
max_idle_ns: 537538477 ns
ps7-ttc #0 at 9e808000, irq=18
And it is allocated with virtual memory mapping (/proc/vmallocinfo):
0x9e808000-0x9e80a0008192 of_iomap+0x2c/0x34 p
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
--
__
12 matches
Mail list logo
