On 5/18/23 12:00 PM, Shah, Tanmay wrote:
> Hi all,
>
> As of now, rpmsg buffer size is decided by RPMSG_BUF_SIZE macro. This is
> fixed to 512 bytes.
>
> If platform needs to send larger than 512 bytes of payload, then the
> payload needs to be split between multiple buffers.
>
> Instead of that, it would be useful if platform can configure
> RPMSG_BUF_SIZE somehow.
>
> There are multiple options to achieve this:
>
> 1. Move RPMSG_BUF_SIZE to Kconfig -> The approach is not accepted as
> single kernel may not work for all platforms.
> 2. Keep device-tree property that mentions rpmsg buffer size.
> 1. Something in dts: “rpmsg-buf-size = <512>”
> 2. This way one kernel can work for all the platforms. If property
> is not mentioned, then we fallback to default size of 512 bytes.
> 3. Dynamic buffer allocation
> 1. This effort was done previously. Please refer to following
> discussion from kernel and openamp library:
>
> i.Openamp library: https://github.com/OpenAMP/open-amp/pull/155
> <https://github.com/OpenAMP/open-amp/pull/155>
>
> 1. Conclusion:
> https://github.com/OpenAMP/open-amp/issues/322#issuecomment-986573828 <https://github.com/OpenAMP/open-amp/issues/322#issuecomment-986573828>
>
> ii.Kernel:
> https://patchwork.kernel.org/project/linux-remoteproc/cover/1548949280-3179… <https://patchwork.kernel.org/project/linux-remoteproc/cover/1548949280-3179…>
>
Lore link to same:
https://lore.kernel.org/lkml/20190605043452.GI22737@tuxbook-pro/T/
I saw nothing in this thread that I would call a rejection.
It made the size choice based on the virtio config space which could
come from firmware resource table now or virtio device config space if
using virtio-mmio etc.
Bjorn did point out that a system where each side allocated its own
buffers of whatever size desired would be more flexible but:
* did not object to this step
* that would be a pretty big departure from what we have not and we
would still need to negotiate its use.
The biggest issues I saw with the patch series was the details of how it
did the config. That could have been fixed with a bit more effort.
I would vote we just resurrect this patch set and clean it up rather
than going down the DTS route.
Bill
> 2. As part of this, RPMSG_BUF_SIZE is configurable on library side,
> but not on kernel side.
>
> If it looks reasonable to go with approach 2 without side-effects, I can
> develop and send the patch.
>
> Thanks,
>
> Tanmay
>
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
