[PATCH] fsl-rio: add support for mapping inbound windows

[Bounine, Alexandre]

On Friday, June 13, 2014 7:09 AM Martijn de Gouw [mailto:martijn.de.gouw at prodrive-
technologies.com] wrote:

> Add support for mapping and unmapping of inbound rapidio windows.
> 
> Signed-off-by: Martijn de Gouw <martijn.de.gouw at 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.