[PATCH v3 2/7] mmc: atmel-mci: prepare clk before calling enable
b.brezillon at overkiz.com
Tue Jul 16 11:49:11 EDT 2013
On 16/07/2013 17:13, Thomas Petazzoni wrote:
> Dear Boris BREZILLON,
> On Tue, 16 Jul 2013 17:06:48 +0200, Boris BREZILLON wrote:
>> buf = kmalloc(ATMCI_REGS_SIZE, GFP_KERNEL);
>> if (!buf)
>> @@ -389,9 +391,13 @@ static int atmci_regs_show(struct seq_file *s, void *v)
>> * consistent.
>> - clk_enable(host->mck);
>> + ret = clk_prepare_enable(host->mck);
> I am not very familiar with the spin_lock_bh() variant, but are you
> sure we are allowed to sleep within a spin_lock_bh()-protected critical
> Remember that clk_prepare_enable() calls both ->prepare() and
> ->enable() for the clock, and ->prepare() is allowed to sleep, while
> ->enable() is guaranteed not to sleep.
> Therefore, clk_prepare() is usually called at probe time, while
> clk_enable() is called whenever enabling/disabling the clock is really
> needed. So not all clk_enable() can transparently be converted into a
You're absolutely right. We should not call clk_prepare/unprepare inside
a critical section,
as the prepare/unprepare callback may sleep.
In this particular case it won't hurt as the mci clk is a peripheral clk
which does not
implement the prepare callback (and as a result won't sleep).
Anyway, I will fix it.
What is the best approach to do so ?
1) call clk_prepare/unprepare in the probe/remove functions and call
in resume/suspend functions
2) get clk_prepare_enable/disable_unprepare outside of the critical
sections (I don't think
there is any need for the mci host lock to be held when enabling
clk framework already handle concurrent accesses to clks)
I will check other patches of this series to see if they introduce
> Best regards,
More information about the linux-arm-kernel