[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6922343.04ZpTXZq7O@wuerfel>
Date: Thu, 03 Dec 2015 16:32:12 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Peter Ujfalusi <peter.ujfalusi@...com>
Cc: vinod.koul@...el.com, andy.shevchenko@...il.com,
linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org,
linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
nsekhar@...com, tony@...mide.com
Subject: Re: [PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel
On Thursday 03 December 2015 16:33:11 Peter Ujfalusi wrote:
> +
> +/**
> + * dma_request_chan - try to allocate an exclusive slave channel
> + * @dev: pointer to client device structure
> + * @name: slave channel name
> + *
> + * Returns pointer to appropriate DMA channel on success or an error pointer.
> + */
> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
> +{
> + struct dma_device *d, *_d;
> + struct dma_chan *chan = NULL;
> +
> + /* If device-tree is present get slave info from here */
> + if (dev->of_node)
> + chan = of_dma_request_slave_channel(dev->of_node, name);
> +
> + /* If device was enumerated by ACPI get slave info from here */
> + if (has_acpi_companion(dev) && !chan)
> + chan = acpi_dma_request_slave_chan_by_name(dev, name);
I just noticed that you are creating this as a new interface, rather than
changing dma_request_slave_channel_reason() and making the old interface
a static inline wrapper. What is the reasoning behind that?
I think if we make both interfaces do the same thing, it's easier
to do the migration.
> + if (chan) {
> + /* Valid channel found */
> + if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
> + return chan;
> +
> + pr_warn("%s: %s DMA request failed, falling back to legacy\n",
> + __func__, dev->of_node ? "OF" : "ACPI");
> + }
Maybe print the error code as well?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists