On 08/15/2014 11:02 PM, Tony Lindgren wrote:
> * 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?
To what exactly? The trigger level, the TX-bug or using DMA in the
first place?
> It would be also nice to be able to specify the use of DMA from
> the board specific .dts file.
Really? I don't see this requirement for MMC for instance. However you
still could provide an empty "dma-names" property in your board .dts
file if you do not want use DMA. Would this work?
> 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.
Hmm. This would explain something. This would mean that I should cancel
the RX DMA transfer in the PM-suspend routine. Let me see how that
works.
> Regards,
>
> Tony
Sebastian
--
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
