| Message ID | 20180302145531.20463-3-srinivas.kandagatla@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 02/03/18 14:55, srinivas.kandagatla@linaro.org wrote: > From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> > > Many of the rpmsg clients like audio drivers need to allocate > dma memory. Make this bus DMA capable so that the child devices > can use dma apis. AFAICS after 15 minutes in the docs and code, the rpmsg "bus" is a virtual one based around shared-memory mailbox communication, so I don't really see how DMA exists in that context - I think maybe that abstraction needs looking at. However, from grepping through the DTs it seems at first glance like the non-trivial things under the "qcom,smd" bus mostly map to actual platform devices via the "qcom,smd-edge" property - if those platform devices are the physical DMA masters, they should be the ones used for DMA API operations. > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> > --- > drivers/rpmsg/rpmsg_core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c > index e84c71f8d6ab..540a3f3567b8 100644 > --- a/drivers/rpmsg/rpmsg_core.c > +++ b/drivers/rpmsg/rpmsg_core.c > @@ -472,6 +472,7 @@ struct bus_type rpmsg_bus = { > .uevent = rpmsg_uevent, > .probe = rpmsg_dev_probe, > .remove = rpmsg_dev_remove, > + .force_dma = true, Regardless of the above, would you really need to use this brute force hack instead of just fixing the DTs? I'm struggling to find which drivers might currently be relying on this :/ Robin. > }; > EXPORT_SYMBOL(rpmsg_bus); > > -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks for your time, On 02/03/18 16:14, Robin Murphy wrote: > On 02/03/18 14:55, srinivas.kandagatla@linaro.org wrote: >> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> >> >> Many of the rpmsg clients like audio drivers need to allocate >> dma memory. Make this bus DMA capable so that the child devices >> can use dma apis. > > AFAICS after 15 minutes in the docs and code, the rpmsg "bus" is a > virtual one based around shared-memory mailbox communication, so I don't > really see how DMA exists in that context - I think maybe that > abstraction needs looking at. > > However, from grepping through the DTs it seems at first glance like the > non-trivial things under the "qcom,smd" bus mostly map to actual > platform devices via the "qcom,smd-edge" property - if those platform > devices are the physical DMA masters, they should be the ones used for > DMA API operations. Currently there are very limited rpmsg devices in the mainline that use dma. Only one I can think of is wcnss WIFI driver which models up itself into another layer of platform device. Not sure if the DMA was the reason to do that. However am working on audio drivers [1] which I modeled up as children of the rpmsg bus, so the problem started. There is an IOMMU in between APPs and DSP which provides audio services. There are also other projects like FastRPC which have used similar driver model which ended up with same issues. It all depends on how you model your driver. Audio case we have a rpmsg channel which exposes audio functionality. so If we want to use the iommu/dma operations we have to add another layer of platform device. Which also means that rpmsg channel notifications have to be passed to these platform devices in some way. Am not 100% sure if this correct way to fix the issue. > >> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> >> --- >> drivers/rpmsg/rpmsg_core.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c >> index e84c71f8d6ab..540a3f3567b8 100644 >> --- a/drivers/rpmsg/rpmsg_core.c >> +++ b/drivers/rpmsg/rpmsg_core.c >> @@ -472,6 +472,7 @@ struct bus_type rpmsg_bus = { >> .uevent = rpmsg_uevent, >> .probe = rpmsg_dev_probe, >> .remove = rpmsg_dev_remove, >> + .force_dma = true, > > Regardless of the above, would you really need to use this brute force > hack instead of just fixing the DTs? I'm struggling to find which > drivers might currently be relying on this :/ This is one of the two issues. dma-ranges might work in this case, but we still have iommu case. > > Robin. > >> }; >> EXPORT_SYMBOL(rpmsg_bus); >> thanks, srini [1]: https://lkml.org/lkml/2018/2/13/719 -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 02 Mar 08:14 PST 2018, Robin Murphy wrote: > On 02/03/18 14:55, srinivas.kandagatla@linaro.org wrote: > > From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> > > > > Many of the rpmsg clients like audio drivers need to allocate > > dma memory. Make this bus DMA capable so that the child devices > > can use dma apis. > > AFAICS after 15 minutes in the docs and code, the rpmsg "bus" is a virtual > one based around shared-memory mailbox communication, so I don't really see > how DMA exists in that context - I think maybe that abstraction needs > looking at. > That's right, rpmsg shuffles messages back and forth to some coprocessor over shared memory, the contexts generating and receiving these messages are "rpmsg devices". The problem Srinivas is facing is that one of these rpmsg devices is trying to allocate and map a larger chunk of memory to be shared with the coprocessor, which is then going to be referenced in the messages being passed in rpmsg. > However, from grepping through the DTs it seems at first glance like the > non-trivial things under the "qcom,smd" bus mostly map to actual platform > devices via the "qcom,smd-edge" property - if those platform devices are the > physical DMA masters, they should be the ones used for DMA API operations. > One of the rpmsg implementations is virtio based and have a similar problem, there dma_alloc*() is called with dev->parent->parent as device, but this causes issues as dev->parent might not be what the original author expected it to -- so this needs to be reworked as well. > > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> > > --- > > drivers/rpmsg/rpmsg_core.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c > > index e84c71f8d6ab..540a3f3567b8 100644 > > --- a/drivers/rpmsg/rpmsg_core.c > > +++ b/drivers/rpmsg/rpmsg_core.c > > @@ -472,6 +472,7 @@ struct bus_type rpmsg_bus = { > > .uevent = rpmsg_uevent, > > .probe = rpmsg_dev_probe, > > .remove = rpmsg_dev_remove, > > + .force_dma = true, > > Regardless of the above, would you really need to use this brute force hack > instead of just fixing the DTs? I'm struggling to find which drivers might > currently be relying on this :/ > The rpmsg devices, described as child nodes of rpmsg bus relates to specific functions in the coprocessor firmware. The fact that the firmware can be started and stopped dynamically makes the current layout quite convenient (in comparison to e.g. how we would describe a mailbox). We know for these cases that dev->parent->parent is a remoteproc instance representing the coprocessor that sits on the other side of the communication channel. So we did investigate if we could just have that to allocate and map buffers. The problem with this is that these functions has multiple iommu contexts. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c index e84c71f8d6ab..540a3f3567b8 100644 --- a/drivers/rpmsg/rpmsg_core.c +++ b/drivers/rpmsg/rpmsg_core.c @@ -472,6 +472,7 @@ struct bus_type rpmsg_bus = { .uevent = rpmsg_uevent, .probe = rpmsg_dev_probe, .remove = rpmsg_dev_remove, + .force_dma = true, }; EXPORT_SYMBOL(rpmsg_bus);