On Thursday 29 January 2015 01:24:06 Kuninori Morimoto wrote:
> Current rcar-audmapp is assuming that CHCR value are specified
> from platform data or DTS bindings. but, it is possible to
> calculate CHCR settings from src/dst address.
> DTS bindings node can be reduced by this patch.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@xxxxxxxxxxx>
The intention definitely looks good, but I'm worried that the
table you add here might be too SoC specific.
> +struct id_addr_table {
> + u8 id;
> + u16 addr;
> +};
> +
> +static u32 audmapp_addr_to_id(struct device *dev, u32 addr)
> +{
> + struct id_addr_table ssi_id_table[] = {
> + {0x00, 0x0000}, /* SSI00 */
> + {0x01, 0x0400}, /* SSI01 */
> + {0x02, 0x0800}, /* SSI02 */
> + {0x03, 0x0C00}, /* SSI03 */
> + {0x04, 0x1000}, /* SSI10 */
> + {0x05, 0x1400}, /* SSI11 */
> + {0x06, 0x1800}, /* SSI12 */
> + {0x07, 0x1C00}, /* SSI13 */
> + {0x08, 0x2000}, /* SSI20 */
Isn't the address part here the physical address of the FIFO,
which can be different for each implementation that contains
an audmapp device?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
