[PATCH 18/31] ASoC: tegra: allocate AHUB FIFO during probe() not startup()
Stephen Warren
swarren at wwwdotorg.org
Tue Dec 3 14:55:55 EST 2013
On 11/29/2013 07:40 AM, Thierry Reding wrote:
> On Fri, Nov 15, 2013 at 01:54:13PM -0700, Stephen Warren wrote:
>> Teh Tegra30 I2S driver currently allocates DMA FIFOs from the
>> AHUB only when an audio stream starts playback. This is
>> theoretically nice for resource sharing, but makes no practical
>> difference for any configuration the drivers currently support.
>> However, this deferral prevents conversion to the standard DMA DT
>> bindings, since conversion requires knowledge of the specific DMA
>> channel to be allocated, which in turn depends on which specific
>> FIFO was allocated.
>>
>> For this reason, move the FIFO allocate into probe() to allow
>> later
...
>> + i2s->playback_dma_data.addr_width =
>> DMA_SLAVE_BUSWIDTH_4_BYTES; + i2s->playback_dma_data.maxburst =
>> 4; + ret =
>> tegra30_ahub_allocate_tx_fifo(&i2s->playback_fifo_cif, +
>> &i2s->playback_dma_data.addr, +
>> &i2s->playback_dma_data.slave_id); + if (ret) { +
>> dev_err(&pdev->dev, "Could not alloc TX FIFO: %d\n", ret); +
>> goto err_suspend; + } + ret =
>> tegra30_ahub_set_rx_cif_source(i2s->playback_i2s_cif, +
>> i2s->playback_fifo_cif); + if (ret) { + dev_err(&pdev->dev,
>> "Could not route TX FIFO: %d\n", ret); + goto err_free_tx_fifo;
>> + } + + i2s->capture_dma_data.addr_width =
>> DMA_SLAVE_BUSWIDTH_4_BYTES; + i2s->capture_dma_data.maxburst =
>> 4; + ret = tegra30_ahub_allocate_rx_fifo(&i2s->capture_fifo_cif,
>> + &i2s->capture_dma_data.addr, +
>> &i2s->capture_dma_data.slave_id); + if (ret) { +
>> dev_err(&pdev->dev, "Could not alloc RX FIFO: %d\n", ret); +
>> goto err_unroute_tx_fifo; + } + ret =
>> tegra30_ahub_set_rx_cif_source(i2s->capture_fifo_cif, +
>> i2s->capture_i2s_cif); + if (ret) { + dev_err(&pdev->dev, "Could
>> not route TX FIFO: %d\n", ret); + goto err_free_rx_fifo; + } +
>
> It could be useful to have these in a separate function so as not
> to make the .probe() any larger. It's already pretty big as it is.
May I ignore this; I personally prefer larger linear functions; it's
much easier to follow the code-flow without having to jump back/forth
between a bunch of single-use functions.
More information about the linux-arm-kernel
mailing list