HACK: rpmsg: virtio_rpmsg_bus: fix up vring buffer logic for TI Keystone SoCs
authorSuman Anna <s-anna@ti.com>
Sun, 24 Feb 2019 05:09:56 +0000 (23:09 -0600)
committerSuman Anna <s-anna@ti.com>
Sun, 24 Feb 2019 05:09:56 +0000 (23:09 -0600)
commit55ea3132f773ce4aee5353e2c54ffc7a3a851934
tree63353b681cca871cbfb9372247f29bac4651af53
parent1b5a3b2ef344bdd695ae410893fab7f4665dd55e
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 9dd87c2af651 ("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: Suman Anna <s-anna@ti.com>
drivers/rpmsg/virtio_rpmsg_bus.c