On 06/18/2014 05:17 PM, Bounine, Alexandre wrote:
On Friday, June 13, 2014 7:09 AM Martijn de Gouw
[mailto:martijn.de.gouw@prodrive-
technologies.com] wrote:
Add support for mapping and unmapping of inbound rapidio windows.
Signed-off-by: Martijn de Gouw <martijn.de.g...@prodrive.nl>
---
... skip ...
+
+int fsl_map_inb_mem(struct rio_mport *mport, dma_addr_t lstart,
+ u64 rstart, u32 size, u32 flags)
+{
+ struct rio_priv *priv = mport->priv;
+ u32 base_size;
+ unsigned int base_size_log;
+ u64 win_start, win_end;
+ u32 riwar;
+ int i;
+
+ base_size_log = __ilog2(size) + ((size & (size - 1)) != 0);
+ base_size = 1 << base_size_log;
+
+ for (i = 0; i < RIO_INB_ATMU_COUNT; i++) {
+ riwar = in_be32(&priv->inb_atmu_regs[i].riwar);
+ if ((riwar & RIWAR_ENABLE) == 0)
+ break;
+ /* check conflicting ranges */
+ win_start = ((u64)(in_be32(&priv->inb_atmu_regs[i].riwbar) &
RIWBAR_BADD_MASK))
+ << RIWBAR_BADD_VAL_SHIFT;
+ win_end = win_start + ((1 << ((riwar & RIWAR_SIZE_MASK) + 1)) -
1);
+ if (rstart < win_end && (rstart + size) > win_start)
+ return -EINVAL;
+ }
It looks like the check for conflicting ranges assumes sequential mapping
requests only.
This check will be missed if ATMU windows are dynamically mapped/unmapped
out-of-order.
Because the unmap callback is implemented please consider possibility of using
ATMU windows
in any order.
You are correct. I'll send a new patch which first check all enabled
windows for conflicts, before is searches for a free ATMU.
--
Martijn de Gouw
Engineer
Prodrive Technologies B.V.
Mobile: +31 63 17 76 161
Phone: +31 40 26 76 200
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
