[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOAejn2pcFSn3Hf=j6zgg6Ui6GjJZrtRch6ywByHaVLsTLMk6A@mail.gmail.com>
Date: Wed, 14 Oct 2015 15:17:14 +0200
From: "M'boumba Cedric Madianga" <cedric.madianga@...il.com>
To: Daniel Thompson <daniel.thompson@...aro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@...il.com>, robh+dt@...nel.org,
pawel.moll@....com, Mark Rutland <mark.rutland@....com>,
ijc+devicetree@...lion.org.uk, Kumar Gala <galak@...eaurora.org>,
linux@....linux.org.uk, Vinod Koul <vinod.koul@...el.com>,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org
Subject: Re: [PATCH v2 2/4] dmaengine: Add STM32 DMA driver
Hi Daniel,
>>> +
>>> +static int stm32_dma_remove(struct platform_device *pdev)
>>> +{
>>> + struct stm32_dma_device *dmadev = platform_get_drvdata(pdev);
>>> +
>>> + of_dma_controller_free(pdev->dev.of_node);
>>> +
>>> + dma_async_device_unregister(&dmadev->ddev);
>>> +
>>> + clk_disable_unprepare(dmadev->clk);
>>
>>
>> What is the purpose of disabling/unpreparing the clock here?
>> stm32_dma_alloc_chan_resources() and stm32_dma_free_chan_resources() should
>> pair up and the clock should already be stopped.
stm32_dma_remove() could be called during an on-going transfer during
module unload.
So in that case, it seems that disabling/unpreparing the clock is needed.
BR,
Cedric
--
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