On 3/16/2012 11:03 AM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
We do have a bunch of drivers that are using IORESOURCE_DMA today to
retrieve the DMA request. Since we do have an unique DMA controller it
was easy and convenient.
And it seems that other ARM SoCs are using it for the same purpose.
There are at least 230+ IORESOURCE_DMA instances in the kernel today.
+/**
+ * of_dma_to_resource - Decode a node's DMA and return it as a resource
+ * @dev: pointer to device tree node
+ * @index: zero-based index of the DMA request
+ * @r: pointer to resource structure to return result into.
+ *
+ * Using a resource to export a DMA request number to a driver should
+ * be used only for legacy purpose and on system when only one DMA controller
+ * is present.
+ * The proper and only scalable way is to use the native of_get_dma_request API
+ * in order retrieve both the DMA controller device node and the DMA request
+ * line for that controller.
+ */
+int of_dma_to_resource(struct device_node *dev, int index, struct resource *r)
+{
I think a better way to discourage the use of IORESOURCE_DMA is to not provide
this function at all, especially given that it's not really well-defined what
it will do when you have more than one cell for the dma channel identifier or
when you have multiple DMA engines, so any driver relying on it is inherently
nonportable.
For the moment it is still used in a lot of places, and without any
other better API yet, it is still useful. As written it is there only
for simple single DMA controller case.
By maintaining that IORESOURCE_DMA for the moment we can adapt some
driver to DT without having to change the way they are retrieving
information. By using IORESOURCE_IRQ and IORESOURCE_MEM, we had the same
advantage.
Otherwise how are we supposed to get the DMA channel for non-DT boot
until we have migrated everything to DT? A bunch of ARM SoC are using
IORESOURCE_DMA for the same purpose.
The goal here is really to maintain that during the transition phase
only. As soon as the full DT support is there, we can switch to the of_ API.
Ideally, we should define and use a generic API non dependent of DT.
AFAIK, that does not exist so far.
And since most drivers are not using dmaengine, we do not even have a
common DMA fmwk to define an API on top.
I fully agree that this IORESOURCE_DMA is not scalable for multiple
controller, ugly, and must be avoided like the plague.
But what other options do we have during the transition?
Regards,
Benoit
--
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
