Commit e3eeb689 authored by Suman Anna's avatar Suman Anna
Browse files

HACK: rpmsg: virtio_rpmsg_bus: fix up vring buffer logic for TI Keystone SoCs



The virtio rpmsg logic is always based on publishing the physical vring
buffers in the vring control structures to expose them to the remote
processor side. Commit 9dd87c2a ("rpmsg: virtio_rpmsg_bus: fix
sg_set_buf() when addr is not a valid kernel address") has fixed up
this logic to scale for the case with the virtio rpmsg buffers were
allocated from either a HighMem region or a dedicated carveout (mapped
into kernel in vmalloc space). The fix initialized the sg_table with
appropriate page address which is translated back to a dma_addr_t
using sg_phys() call in virtqueue_add() (in vring_map_one_sg())
function. This fix was sufficient for SoCs where both the host and
the remote processors used 32-bit addressing scheme.

This logic failed for TI Keystone platforms though, which have a 36-bit
physical address and only a regular 32-bit dma address (the first 2 GB
of RAM at 0x800000000 is aliased at 0x80000000) due to the truncation of
the physical address. Furthermore, the remote processors on these SoCs
leverage the 32-bit aliased address for referencing the IPC shared memory
buffers. Fix this issue and make the virtio rpmsg stack functional on
these platforms by initializing the sg entry with the page address
corresponding to the dma address of the vring buffer instead of it's
physical address. This solution allows the core virtio_ring code to
remain unchanged, and results in publishing the desired aliased
addresses in the vring control structures.

Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
parent e305e429
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment