Shared DDR RAM access on AMP system

2017-12-14 Thread Edward Wingate
On a dual-core ARM SOC (Zynq7020), I have Linux running on core0 and
an RTOS running on core1.  I share data between the two cores with a
4MB block of DDR RAM that I've marked in the MMU as shareable and
non-cacheable.  I use an entry in the device tree and the
uio_pdrv_genirq driver to create an uio device (/dev/uio0) in Linux.
With this device, I can use mmap to read/write the block of DDR RAM
from Linux.

Even though it's meant for memory mapped devices, the uio_pdrv_genirq
driver seems to work for accessing shared DDR RAM.  Are there any
potential issues that may arise from using this driver for accessing
shared DDR RAM?

Is the uio_dmem_genirq driver more appropriate for this? I couldn't
get it to work though, perhaps because of this bug:
https://forums.xilinx.com/t5/Embedded-Linux/Bug-in-uio-dmem-genirq-UIO-driver-support-for-device-tree/td-p/569120

Thanks for any advice/help.

Ed

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: hrtimer_interrupt time sync issues across cores

2017-12-14 Thread valdis . kletnieks
On Wed, 13 Dec 2017 23:01:57 -0800, Rajasekaran Chandrasekaran said:

> In our multi-core x86 based system that is running 3.4.19 version of

As Greg already pointed out, that's ancient history suitable only for kernel
archaeologists and masochists.

> Problem:
>
> Inside hrtimer_interrupt function, basenow.tv64 in CPU-3 is 1.6 seconds
> ahead of other CPU’s (we have 4 cores

I may be mis-remembering, but I think the timer code has undergone at least
2 major reworkings in the 6 years since 3.4.  So there's a good chance the bug
has already been fixed.  Of course, back-porting the fix may be close to 
impossible.

Good luck, you will need it.


pgpa5TCmmwqfk.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies