-
Notifications
You must be signed in to change notification settings - Fork 292
WW50
wjliang edited this page Dec 14, 2018
·
6 revisions
- Participants:
- Arnaud Pouliquen – ST
- Bill Mills – TI
- Etsam Anjum - Mentor
- Felix Rubinstein – Xilinx
- Tomas Evensen – Xilinx
- Stefano Stabellini – Xilinx
- Jiaying (Wendy) Liang – Xilinx
- Sergei Korneichuk – Xilinx
- Patrik Stromblad – Enea
Wendy (Xilinx)
- Linaro switching to Zoom starting from 2019
- Tomas to reach out to NXP to get status
Wendy presented libmetal shared memory allocation architecture. It's available here. http://openamp.github.io/docs/mca/Libmetal-Shared-Memory-Allocation.pdf
- Loic - not against ION.
- common kernel interface share buffers with co-processor, standard messaging to exchange data
- Bill - a lot of criticism on ION. But ION makes a lot of sense to allocate OMAP drm to get buffers for graphics. Proposes to talk about ION choice. It would be great to support the same set of ioctl's of what ION supports on remoteproc or other device driver.
- proposed to hide the implementation away from the application
- some kernel driver wants to hide dma physical address. In this case, rather use buffer id and the offset
- support for scatter gather case
- Stefano - libmetal allocation API should support multiple implementations not only ION
- Patrik - How can we understand the physical memory corresponds to virtual memory?
- Wendy - remoteproc driver or device driver will provide the mapping. Can use libmetal io_region to store this mapping information.
- Tomas - How to support cache?
- Wendy - The memory source driver (buffer provider) will be responsible to provide cache support. If using ION, ION allocation API allow user to specify the type of memory.