* Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> [140815 11:13]:
> +#ifdef CONFIG_SERIAL_8250_DMA
> + if (pdev->dev.of_node) {
> + /*
> + * Oh DMA support. If there are no DMA properties in the DT then
> + * we will fall back to a generic DMA channel which does not
> + * really work here. To ensure that we do not get a generic DMA
> + * channel assigned, we have the the_no_dma_filter_fn() here.
> + * To avoid "failed to request DMA" messages we check for DMA
> + * properties in DT.
> + */
> + ret = of_property_count_strings(pdev->dev.of_node, "dma-names");
> + if (ret == 2) {
> + up.dma = &priv->omap8250_dma;
> + priv->omap8250_dma.fn = the_no_dma_filter_fn;
> + priv->omap8250_dma.rx_size = RX_TRIGGER;
> + priv->omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
> + priv->omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
> +
> + if (of_machine_is_compatible("ti,am33xx"))
> + up.bugs |= UART_BUG_DMATX;
> + }
> + }
> +#endif
Hmm I wonder if there's a more generic solution to this?
It would be also nice to be able to specify the use of DMA from
the board specific .dts file.
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
