| Message ID | 1483722973-21531-4-git-send-email-loic.pallardy@st.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 9a507e7..4af80cb 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -625,6 +625,11 @@ static int rproc_handle_carveout(struct rproc *rproc, dev_dbg(dev, "carveout rsc: name: %s, da 0x%x, pa 0x%x, len 0x%x, flags 0x%x\n", rsc->name, rsc->da, rsc->pa, rsc->len, rsc->flags); + if (rsc->pa != FW_RSC_ADDR_ANY || rsc->da != FW_RSC_ADDR_ANY) { + dev_dbg(dev, "carveout already allocated by low level driver\n"); + return 0; + } + carveout = kzalloc(sizeof(*carveout), GFP_KERNEL); if (!carveout) return -ENOMEM;
Remoteproc doesn't check if firmware requests fixed addresses for carveout regions. Current assumption is that platform specific driver is in charge of coprocessor specific memory region allocation and remoteproc core doesn't have to handle them. If a da or a pa is specified in firmware resource table, remoteproc core doesn't have to perform any allocation. Access to carveout will be done thanks to rproc_da_to_pa function, which will provide virtual address on carveout region allocated by platform specific driver. Signed-off-by: Loic Pallardy <loic.pallardy@st.com> --- drivers/remoteproc/remoteproc_core.c | 5 +++++ 1 file changed, 5 insertions(+)